Persistência de dados: para persistir os eventos de nosso eventStore podemos fazer uso do DynamoDb

Streaming dos Eventos: para propagarmos as mudanças feitos no nosso DynamoDb (usado na persistência) podemos usar tanto DynamoDb Streams como o Kinesis DataStream

Filtragem , roteamento dos Eventos: para realizar a filtragem, transformação e enriquecimento dos Eventos a ferramenta ideal será o EventBridge Pipes. Permitindo de forma simples padrões avançados para o consumo desses eventos

Solução na AWS

Schema do EventStore

• AggregateId: id da raiz de agregação
• EventType: tipo do evento. Exemplos: PedidoFinalizado
• EventDatetime: data e hora do evento formato ISO 8601
• RawData: JSON com o payload do Evento

Referência e Links

• Build a CQRS event store with Amazon DynamoDB | Amazon Web Services
• EventStoreDB - the state-transition database for data-driven businesses
• GitHub - vladikk/elastic-event-store: A fully serverless event store

https://domaincentric.net/blog/eventstoredb-vs-kafka

Conclusão

Em Resumo, o EventBridge Pipes é um serviço muito promissor e permite endereçar problemas complexos de filtragem, roteamento , enriquecimento de mensagens e podendo ser um dos componentes chaves para uma implementação de um EventStore na AWS

Obrigado pela leitura , Abraços
As opiniões citadas nesse artigo são minhas.

#aws

#dynamoDb

#eventBridge

#eventBridgePipes

#awscommunity #awscommunitybuilder

#eventsourcing

#eventstore

Eventsourcing, relação com Aggregate e seu respectivo Stream

Todos os eventos de dominio deveriam estar correlacionados ou gerados no contexto do Aggregate , inclusive quando é realizada sessões de Event Storming um passo importante é a clusterização dos Eventos e comandos no Aggregate
Exemplo: Pedido Aceito, Pedido Cancelado (em um Aggregate Pedido), Oferta Feita, Oferta Rejeitada , Oferta Aceita (em um Aggregate de Oferta), pagamento rejeitado, pagamento aprovado, pagamento estornado(em um Aggregate Pagamento

Projeções

Projeções são extremamente importantes quando usamos EventSourcing, por alguns motivos. Dentre os principais, acesso rápido a uma visão materializada com o ultimo estado do Aggregate

Exemplos: uso de uma projeção para servir APIs de consulta em cima da raiz de agregação

Podemos criar múltiplas projeções para um mesmo Aggregate.

Para criar as projeções precisamos fazer a leitura de todos os eventos do Aggregate

Snapshots

Snapshots são importantes quando usamos eventsourcing pois conseguimos ter uma “foto” do estado do Aggregate na linha do tempo . Permitindo um reprocessamento dos eventos a partir de um snapshot

EventStore

Embora não seja obrigatório é muito comum o uso de EventStore quando usamos EventSourcing. Existem inúmeras formas de fazer uso de um EventStore desde uma implementação mais artesanal ou comprando algum produto pronto para essa finalidade

Referência e Links

• Build a CQRS event store with Amazon DynamoDB | Amazon Web Services
• EventStoreDB - the state-transition database for data-driven businesses

https://domaincentric.net/blog/eventstoredb-vs-kafka

Conclusão

Em Resumo, o uso de eventos e uma arquitetura orientada a eventos(EDA) hoje em dia se torna quase que mandatória para desenvolver aplicações robustas e minimamente desacopladas, porém o uso de EventSourcing tem que ser feito com muita consciência , pensando desde o início quais projeções e / ou Snapshots são essenciais para atender as necessidades mais básicas do negócio

Obrigado pela leitura , Abraços
As opiniões citadas nesse artigo são minhas.

#DDD

#eda

#eventsourcing

#microservices

#eventstore

#aws

#awscommunity #awscommunitybuilder

Os Aggregates deveriam impactar vários aspectos de uma aplicação, como por exemplo: coleções de recursos (APIs) , persistência de dados (repositório), contexto de geração de eventos , escopo de um microservice (geralmente vinculado ao tamanho mínimo de um microservice)

Relevância para APIs

O Aggregate deveria ser a granularidade padrão para as APIs de negócios, as coleções de recursos deveriam ser baseadas neste nível
Abaixo exemplo ilustrativo para uma API de pedidos(Aggregate Pedido)

Exemplo de URI Template

“/{bounded-context-name}/v1{Aggregate-name/resource-collection-name}”

POST /pedidos

{
  "data_pedido": "2023-03-23T15:00:00",
  "id_cliente": 12345,
  "itens_do_pedido": [
    {
      "id_produto": 6789,
      "valor_unitario": 10.99,
      "quantidade": 2
    },
    {
      "id_produto": 4567,
      "valor_unitario": 5.99,
      "quantidade": 3
    }
  ],
  "planejamento_de_entrega": {
    "data": "2023-03-24",
    "endereco": "Rua da Amizade",
    "numero": "123",
    "cidade": "São Paulo",
    "cep": "01234-567"
  }
}


GET /pedidos/:id_pedido

{
  "id_pedido": 801-7800701-7435808,
  "data_pedido": "2023-03-23T15:00:00",
  "status": "Em andamento",
  "id_cliente": 12345,
  "itens_do_pedido": [
    {
      "id_produto": 6789,
      "valor_unitario": 10.99,
      "quantidade": 2
    },
    {
      "id_produto": 4567,
      "valor_unitario": 5.99,
      "quantidade": 3
    }
  ],
  "planejamento_de_entrega": {
    "data": "2023-03-24",
    "endereco": "Rua da Amizade",
    "numero": "123",
    "cidade": "São Paulo",
    "cep": "01234-567"
  }
}

Relevância para Persistência de Dados

O Aggregate é uma fronteira transacional, devido a isso temos sinergia com o pattern Repository

, Independente se o seu DataStore seja um database relacional ou NoSql , estruturando sua aplicação para que o seu Repositório de dados tenha a granularidade de sua raíz de Agregação e tomando o devido cuidado para que sua Entidade de negócio (Domain Model) não seja contaminada com particularidade do modelo de persistência (criando afinidade indesejada com a tecnologia), podemos ter a felicidade neste modelo de trocar a tecnologia de armazenamento/ banco de dados de forma mais suave, com pouco ou zero impacto em camadas mais core (aplicação e Domain)

Exemplo modelo NoSql — DynamoDb

Quando usamos um database NoSQL temos que ter uma atenção mais forte para padrões de acesso para definição de como vamos armazenar

Tabela:

• Pedido
  Partition Key: idPedido
  (Podendo variar na modelagem de acordo com padrão de acesso para usar 1 ou N linhas/itens para cada pedido)

Exemplo modelo SQL

Em um database relacional teríamos tabelas abaixo , com seus respectivos relacionamentos:

• Pedido , item de Pedido, Produto

Relevância para Microservices

O Aggregates podem ser bom caminho para chegar ao tamanho inicial de um microservice, dado que o Aggregate já é uma fronteira transacional .
Vale lembrar que transações não deveriam passar a fronteira do Aggregate

Este caminho geralmente é sugerido como o tamanho minimo para um microservice, enquanto o Bounded Context é sugerido como o tamanho maximo de um microservice

Relevância para Event Driven Architecture

Todos os eventos deveriam estar correlacionados ou gerados no contexto do Aggregate , inclusive quando é realizada sessões de Event Storming um passo importante é a clusterização dos Eventos e comandos no Aggregate
Exemplo: Pedido Aceito, Pedido Cancelado (em um Aggregate Pedido), Oferta Feita, Oferta Rejeitada , Oferta Aceita (em um Aggregate de Oferta)

Conclusão

Em Resumo, dado o impacto que a Raíz de Agregação deveria ter nas nossas aplicações devemos ter uma atenção toda especial, dado que ajudam a guiar a construção de APIs de negócios, delimitam os limites transacionais com isso nos dão um bom indicador para quebrar sistemas em microservices

Obrigado pela leitura , Abraços
As opiniões citadas nesse artigo são minhas.

#DDD #DDD_Aggregate #MICROSERVICES

#API #EDA

Referências

Aggregate: https://martinfowler.com/bliki/DDD_Aggregate.html

Aggregate Data Store: https://martinfowler.com/bliki/AggregateOrientedDatabase.html

APIs e Aggregate:
https://medium.com/@jayadebaj/api-architecture-part-1-an-api-style-guide-through-the-lensapi-architecture-c827fea451bd

Event Storming e Reactive Systems
https://blog.redelastic.com/corporate-arts-crafts-modelling-reactive-systems-with-event-storming-73c6236f5dd7

Desiging DDD Aggregates
https://medium.com/@albert.llousas/designing-ddd-aggregates-db633f1caf88

Clean Architecture evoluiu ao longo do tempo a partir de várias outras arquiteturas que focavam em desacoplamento, incluindo Arquitetura Hexagonal(Ports and Adapters) e Arquitetura Onion
Uncle Bob enfatiza cinco qualidades que todas as arquiteturas predecessoras e a Clean Architecture possuem:

• Independência de framework: a arquitetura é desacoplada de frameworks de terceiros.
• Testável: a arquitetura é fácil de escrever testes de unidade.
• Independência da interface do usuário: a arquitetura pode ser desconectada da interface do usuário
• Independência do banco de dados: a arquitetura é desacoplada do armazenamento de dados subjacente.
• Independência de agentes externos: as regras de negócios da arquitetura são isoladas e nada sabem sobre o mundo exterior.

Clean Architecture é uma abordagem que permite postergar decisões, onde focamos em construir código de regras de negócio e aplicação , atacamos o coração da aplicação: camadas de aplicação (use cases) e camada de domínio (entidades, Value objects) , com esse modelo de pensamento e construção conseguimos ajustar algum “detalhe técnico" sem precisar alterar o core da aplicação. Exemplo: seria possível trocar o mecanismo de armazenamento/ database de um banco relacional para um não relacional apenas trocando a classe concreta de um entity Gateway/ repository, Clean Architecture pode ser sua grande aliada na construção de arquitetura evolutivas de forma consistente

Estrutura Básica

Semelhante a outras arquiteturas focadas em desacoplamento (onion, hexagonal) , as regras de dependências são sempre do círculo/ camada mais externa para a mais interna. Toda aplicação Clean Architecture deveria respeitar a regra de dependência acima , onde a camada mais interna nunca conhece diretamente a camada externa

O objetivo do desenvolvimento de software usando o clean é focar no que realmente importa , que são suas regras de negócio (nivel domínio e aplicação).
Neste momento não importa SQL , HTML, javascript, modelo de deploy , container , FaaS (lambda) são detalhes, a “tecnologia é um detalhe”

Pegando a fala do uncle bob

• Database é um detalhe
• Web é um detalhe
• Protocolo de exposição ou comunicação é um detalhe

Entidades

As entidades encapsulam as regras de negócios. Uma entidade pode ser um objeto com métodos ou pode ser um conjunto de funções e estruturas de dados , as entidades são os objetos de negócios do aplicativo. Elas encapsulam as regras mais gerais e de alto nível , que são menos propensas a mudar quando algo externo muda. Por exemplo, você não esperaria que esses objetos fossem afetados por uma alteração na navegação da página ou na segurança. Nenhuma mudança operacional em qualquer aplicativo específico deve afetar a camada de entidade. Pode pensar nelas como Entidades do DDD (Domain Driven Design)

Use Cases

Regras de aplicação, necessidade de casos de uso

O software nesta camada contém regras de negócios específicas da aplicação. Esta camada encapsula e implementa todos os casos de uso do sistema. Esses casos de uso orquestram o fluxo de dados de e para as entidades e direcionam essas entidades para usar suas regras de negócios em toda a empresa para atingir os objetivos do caso de uso.

Não esperamos que mudanças nesta camada afetem as entidades. Também não esperamos que essa camada seja afetada por alterações nas externalidades, como o banco de dados, a interface do usuário ou qualquer uma das estruturas comuns. Esta camada é isolada de tais preocupações.

No entanto, esperamos que as alterações na operação do aplicativo afetem os casos de uso e, portanto, o software nesta camada. Se os detalhes de um caso de uso mudarem, algum código nessa camada certamente será afetado.

Interface adapters (Controller, presenters, Gateway)

Aqui estamos falando da camada de implementação de adaptadores para o mundo externo (portas de entrada e portas de saída)
Está camada é responsável por converter e formatar dados para uso adequado ao use case e tratar cenários de persistência e conversões necessárias

Pontos importantes sobre aspectos de implementação

Diagrama de Classes referência

Entidade

Na camada de domínio , devemos manter um domínio rico e não ter entidades anêmicas. Significa que devemos manter regras que dependem apenas de atributos da entidade em métodos da entidade. Dicas:

• Além da entidade devemos fazer uso de value objects (evitando a obsessão por tipos primitivos)
• Onde deveríamos gerar eventos de domínio ? Por que não nas entidades em métodos da entidade?
• Podemos ter serviços de domínio se for necessário, regras que não cabem a uma única entidade

Implementação do use case

Independente do nome que seja usado(Interactor, UseCaseImpl , etc):

• Deveria possuir um único método público (por exemplo “execute(request) : response")
• Recebe Request Model
  Transforma para entidades / tipos do domínio
• Pode aplicar regras que não cabem na entidade
• Podem manipular / despachar eventos para outros contextos (bounded context) ou microservices
• Retorna response model

Request / Response Models

• São tipos e estruturas de dados para atender um caso de uso específico (uma espécie de DTO (Data transfer Objects))
• Não deveriam possuir atributos/ anotações de Frameworks específicos (exemplos: não colocar anotações para serialização, caso precise de algo do gênero configure convenções de serialização do Framework)
• Ajudam a blindar o Domain Model, através dos request e response Models evita o risco de expor objetos de domínio por engano, prevenindo quebra de contratos por mudança de domínio e vazamento de informações de domínio não aplicáveis ao caso de uso

Camada de Gateway / Data Provider

Camada responsável por acessar ou prover dados para a aplicação. Dicas para implementação:

• Deveria ter a granularidade da raiz de Agregação
• A entrada e saída dos métodos das interfaces do Gateways deveriam ser sempre objetos do domínio (geralmente Entidades)
• Traduz Entidade/ tipos de domínio para necessidades de comunicação externa(serviços) ou ORM
• Pode conter persistence model (entidades para o orm) internamente se fizer sentido, exemplo: dependendo das capacidades do Framework de ORM para cenários mais simples o modelo de persistência é opcional
• Nesta camada deve-se fazer projeções quando necessário (evitar trazer todos os campos do banco de dados)
• Nesta camada implementamos a classe concreta que implementa a Gateway Interface, onde deveríamos receber na entrada tipos de domínio e retornar tipos de domínio (geralmente entidades)

Sugestões de Tipos de Objetos por Pasta / Package / Namespace

Domain

• Entidades
• Values Objects
• Domain Events
• Gateway Interfaces
• Domain Services (quando existir/ necessário)

Application

• Use Cases Interfaces
• Use Cases Implementation
• Request Models
• Response Models
• Mappers
• Mappers.From(RequestModel).To(Domain)
• Mappers.From(Domain).To(ResponseModel)

Infraestrutura

• Entity Gateway Implementation
• Persistence Models
• Modelos de Interfaces Externas
• Mappers (domínio=>externo | externo=> domínio)

Conclusão

Em Resumo, a abordagem proposta por Clean Architecture é muito útil pensando em construir software mais perenes, com maior flexibilidade e facilidade de evolução, que facilite uma arquitetura evolutiva. Atenção para não usar Clean Architecture como bala de prata e querer usar para qualquer projeto

Obrigado pela leitura , Abraços
As opiniões citadas nesse artigo são minhas.

#cleanarchitecture #cleancode #ddd #evolutionaryarchitecture

Referências

Uncle Bob Blog: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Livro: Clean Architecture: A Craftsman’s Guide to Software Structure — ISBN: 0134494164

Lake House approach

Antes de falar especificamente do RedShift, abaixo segue um resumo de Lakehouse

Como uma arquitetura de dados moderna, a abordagem da Lake House não se trata apenas de integrar seu data lake e seu data warehouse, mas também de conectar seu data lake, seu data warehouse e todos os seus outros serviços específicos em um todo coerente. O data lake permite que você tenha um único local para executar análises na maioria dos seus dados, enquanto os serviços de análise de propósito específico (purpose-built data services) fornecem a velocidade necessária para casos de uso específicos, como painéis em tempo real e análises de log.

Esta abordagem Lake House consiste nos seguintes elementos-chave:

• Scalable Data Lakes
• Purpose-built Data Services
• Seamless Data Movement
• Unified Governance
• Performant and Cost-effective

Lake House reference architecture on AWS

RedShift Spectrum

O Redshift Spectrum é uma das peças centrais da camada de armazenamento Lake House integrada nativamente.

O Redshift Spectrum permite que o Amazon Redshift apresente uma interface SQL unificada que pode aceitar e processar instruções SQL em que a mesma consulta pode referenciar e combinar conjuntos de dados hospedados no data lake, bem como armazenamento de data warehouse. O Amazon Redshift pode consultar petabytes de dados armazenados no Amazon S3 usando uma camada de até milhares de nós transitórios do Redshift Spectrum e aplicando as sofisticadas otimizações de consulta do Amazon Redshift. O Redshift Spectrum pode consultar dados particionados no data lake S3. Ele pode ler dados compactados usando codec de código aberto e armazenados em linha ou formatos colunares de código aberto, incluindo JSON, CSV, Avro, Parquet, ORC e ​​Apache Hudi.

Pré-requisitos

Para usar o Redshift Spectrum, é necessário um cluster do Amazon Redshift/ RedShif Serverless e um cliente SQL conectado ao cluster, de modo que você possa executar comandos de SQL. O cluster e os arquivos de dados do Amazon S3 devem estar localizados na mesma Região da AWS.

Exemplo de Passo a passo

create external schema myspectrum_schema
from data catalog
database 'myspectrum_catalogodb'
iam_role 'arn:aws:iam....'
create external database if not exists;

create external table myspectrum_schema.sales(
salesid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp)
row format delimited
fields terminated by '\t'
stored as textfile
location 's3://[meu-buckect]/tickit/spectrum/sales/'
table properties ('numRows'='172000');

SELECT * FROM "dev"."myspectrum_schema"."sales";

Casos de uso

O REDSHIFT spectrum se torna útil em cenários onde temos um data lake (S3), que possui dados úteis ou que complementem dados que estejam no DW(Data Warehouse). Desta forma, conseguimos evitar pipelines de dados para consumir esses dados no DW

Conclusão

Em Resumo, o REDSHIFT Spectrum pode ser um bom aliado na sua estratégia de analytics quando possui workloads e padrões de consumo da informação em uma abordagem DW / Lakehouse, evitando trabalho na construção de mais pipelines, replicação de dados , custo de armazenamento

Obrigado pela leitura , Abraços
As opiniões citadas nesse artigo são minhas.

#AWS #ANALYTICS #REDSHIFT #LAKEHOUSE

#awscommunity #awscommunitybuilder

Referências

https://docs.aws.amazon.com/pt_br/redshift/latest/dg/c-getting-started-using-spectrum.html

https://docs.aws.amazon.com/pt_br/redshift/latest/dg/c-getting-started-using-spectrum-query-s3-data.html

https://aws.amazon.com/blogs/big-data/build-a-lake-house-architecture-on-aws/

https://aws.amazon.com/blogs/big-data/harness-the-power-of-your-data-with-aws-analytics/

Serverless veio para ficar e pode ser considerado tranquilamente como uma opção padrão para muitos tipos de workloads, porém dependo de como estruturarmos os projetos podemos acabar em dezenas de projetos e bases de código apenas para um sub-domínio pequeno

SAM — Serverless Application Model

AWS SAM pode ser usado para projetos de qualquer tamanho, mas é particularmente útil para projetos de médio a grande porte, pois fornece uma estrutura para gerenciar e organizar os recursos do seu aplicativo de maneira eficiente. Além disso, o AWS SAM fornece uma linguagem de modelagem simples que permite definir seus recursos de serviço sem servidor de maneira clara e concisa, o que facilita a manutenção e a depuração do código.

O SAM além facilitar o IAC, pode ajudar a endereçar o problema de inúmeras funções, simplificando o deploy

Microservice-Based Templates

Dos modelos expostos acima , o que mais me agrada é o modelo baseado em microservice, onde podemos agrupar todas as funções , recursos Serverless, configuração de event sourcing contidas no microservice. Desta forma, simplifica muito o número de templates de IAC, repositórios de código, esteiras e etc.

Podemos ter microservice de vários tamanhos dependendo da necessidade e maturidade da organização, desde um microservice maior (orientado ao bounded context) como podemos ter microservice menores (orientado ao Aggregate Root) .

Entendo que quando temos microservice no nível de uma raiz de agregação (considerado como um caminho para o menor tamanho de um microservice) faz muito sentido usar o SAM para agrupar todos os recursos do mesmo.

Conclusão

Em Resumo, podemos fazer uso de FaaS e AWS Lambda para uma melhor eficiência computacional e simplificar a operação sem deixar nossa base de código complexa

Obrigado pela leitura , Abraços
As opiniões citadas nesse artigo são minhas.

#AWS #FaaS #Lambda #DDD #Microservice #DDD_Aggregate

Referências:

Organizando aplicações Serverless

https://aws.amazon.com/blogs/compute/best-practices-for-organizing-larger-serverless-applications/

Padrões de uso do SAM

https://serverlessland.com/patterns?framework=SAM

Microservice orientados a raíz de Agregação (Aggregates)

https://martinfowler.com/bliki/DDD_Aggregate.html

https://medium.com/@unmeshvjoshi/aggregate-oriented-microservices-d314eb04f2b1

SNS -> SQS (Fanout)

Quando usamos o SNS, podemos aplicar o conceito de Fanout usando subscription(assinatura do tópico SNS) e aplicando filtro na configuração da subscription, podemos ter uma fila SQS assinando um tópico SNS, aplicando o filtro na configuração dessa subscription

GreenHighQueueSubscription:
	    Type: AWS::SNS::Subscription
	    Properties:
	      Endpoint: !GetAtt GreenHighQueue.Arn
	      Protocol: sqs
	      FilterPolicy:
	        color:
	          - green
	        number:
	        - numeric:
	          - ">"
	          - 100

Amazon MQ(rabbit MQ)

Quando usamos Amazon MQ(flavor Rabbit MQ), com o Rabbit temos um recurso chamado EXCHANGE que permite distribuir a mensagem entre múltiplas filas
Além dos recursos nativos do Rabbit é possível usar o recurso de filtro no event sourcing mapping de Lambda

Eventbridge

Com o Eventbridge podemos usar o recurso de Eventbridge Rules, EventBridge Pipes, ou opção de filtro na configuração de Eventsourcing Mapping das Lambdas

Kinesis Data Stream

Usando o Kinesis DataStream podemos aplicar filtros em mapeamento de Eventsourcing de Lambdas ou usando EventBridge Pipes, dependendo do cenário(um pouco mais orientado a streaming) podemos usar também o Firehose e o Kinesis Analytics para aplicar filtro de mensagens

Lambda Event Source Mapping — Filter

Filtrando mensagens usando o ESM da Lambda , compatível com SQS, DynamoDb Stream, Kinesis , MSK(kafka)

Filter pattern

{
    "partitionKey": [ "1" ],
    "data": {
        "Location": [ "Los Angeles" ]
    }
}

Event Bridge Pipes

Por último e não menos importante temos o Event Bridge Pipes que é um serviço novo da AWS e muito promissor. EventBridge Pipes permite conectar fluxos de dados de mensagens , permitindo filtros, enriquecimento e transformações simples até direcionar ao destino

Conclusão

Em Resumo, usando alguns dos padrões citados acima conseguimos filtrar mensagens de forma eficiente sem a necessidade de aplicar o filtro das mensagens na aplicação consumidora, economizando tráfego de dados e evitando desperdícios de computação para aplicar filtros em cima das mensagens

#AWS #EDA #INTEGRATION #AWSLAMBDA #AWSCOMMUNITY

Referências

https://aws.amazon.com/blogs/compute/implementing-architectural-patterns-with-amazon-eventbridge-pipes/

https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns-content-based-filtering.html

https://aws.amazon.com/about-aws/whats-new/2022/03/amazon-eventbridge-rule-filtering-transformation-console/

https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventfiltering.html

https://aws.amazon.com/eventbridge/pipes/

Turbot Steampipe é uma ferramenta de gerenciamento de infraestrutura em nuvem, desenvolvida pela Turbot Inc, que ajuda as empresas a automatizar e otimizar suas operações de nuvem. Ela inclui recursos como gerenciamento de configuração, governança de segurança, conformidade e compliance, além de automação de provisionamento e escalabilidade. A ferramenta é compatível com várias plataformas de nuvem, incluindo AWS, Azure, e Google Cloud.

Plug-ins

steampipe plugin install aws

steampipe query

Consulta de Buckets para verificar se o bucket_policy esta público

select   name,   region,   account_id,   bucket_policy_is_public from   aws_s3_bucket;

Consulta de Tabela Dynamo sem backup ativado

select
  name,
  continuous_backups_status
from
  aws_dynamodb_table
where
  continuous_backups_status = 'DISABLED';

APIs gateways configurados como endpoints não privados

Referencia e Links

• Steampipe Hub
• Amazon Web Services plugin | Steampipe Hub

Conclusão

Em Resumo, com o SteamPipe podemos fazer querys rapidas para verificar se alguma regra esta sendo violada de forma exploratória como se tivesse consultando tabelas de uma banco de dados

Em outros artigos podemos explorar com mais detalhes outros recursos e características

Obrigado pela leitura , Abraços
As opiniões citadas nesse artigo são minhas.

#AWS #SteamPipe #Turbot #Compliance

Neste artigo, tenho por objetivo passar um pouco de contexto de banco de dados, e como o banco de dados DynamoDB pode ser muito útil para endereçar inumeros problemas do dia a dia fazendo uso de alguns padrões de modelagem, indo um pouco além do básico chave/valor / documento

No Passado para todos os problemas usavamos sempre bancos de dados relacional (one-size fits all)

Hoje temos novos desafios que precisam ser endereçados como milhões de requests por segundo, latências sub-milisegundo, disarter recovery, acesso global(multi-região) , e etc. Hoje Temos inúmeros bancos de dados disponíveis para cada propósito: chave/valor, documento, grafo, etc.

O DynamoDb é um banco de dados NoSQL , Serverless, com foco principal em atender cenários chave-valor e documento, com latência de 1 digito de milisegundo, disponibilidade global de forma simplificada(usando o recurso Global Table) , Além de ser muito flexível, permitindo inúmeros padrões de modelagem

O DynamoDB é um banco de dados schemaless(sem estrutura definida), onde temos a obrigatoriedade apenas da chave primaria, todos os demais atributos são opcionais, onde cada registro pode possuir sua própria estrutura

Primary Key

Simple primary keys
Composta por um único atributo que é a partition Key

Composite Primary Key
Composta por dois atributos que são chamados de partition Key + sort key

Índices

LSI
Local Secundary Index é um tipo de índice onde mantemos a mesma chave de partição da PK , porém com outra sort key

GSI
Com o Global Secundary Index, podemos alterar a chave de partição , permitindo muita flexibilidade através da SortKey(exemplo: padrão composite SortKey)

Padrões de Modelagem

Devido ao fato da chave primária ser composta pela PartitionKey e SortKey(opcional) e permitindo que cada Item ou registro seja uma Entidade diferente. Conseguimos através de técnicas específicas tratar desde cenários mais simples de chave/valor, documento até relações 1:N , N:N , permitindo diversos tipos pesquisas

Principais padrões: Single-Table, Multi-Table
Estratégias para relações 1: N , N:N : PrimaryKey+Query , Composite Sort Key, Adjacent List

Single-Table

o Padrao Single-Table é o padrão de modelagem onde todas as entidades da sua aplicação/ microservice são armazenadas em uma única tabela, embora seja útil em alguns cenários , devemos usar com muita moderação (pode criar complexidade para tratar multiplas entidades, dificulta o uso do DynamoDb Streams)

Multi-Table

E a abordagem mais simples , onde criamos uma tabela para cada documento, exemplo: Pedido , Nota Fiscal, Contrato

Primary key + query

Use uma chave primária composta para incluir a entidade pai(usando a partitionKey) e entidades relacionadas (usando a SortKey) na mesma coleção de itens. Este é o padrão de relacionamento um para muitos mais comum. Pense na busca pela partition Key como uma entidade raiz de agregação e quando necessário use na busca a PK+SK (opcional)

Composite Sort Key

Padrão de modelagem usado quando temos dados hierárquicos, onde temos uma concatenação de elementos na SortKey.
Exemplo: StatusPedido#DataPedido

Através desse padrão conseguimos fazer busca begin_with(semelhante ao Like)

Adjacent List

Modele cada entidade como um tipo de item e modele o relacionamento como um tipo de item. Um lado do relacionamento está na mesma coleção de itens para o chave primária, e o outro lado está na mesma coleção de itens em um índice secundário. Usado no relacionamento muitos para muitos. (comum criação de índice invertido(GSI invertendo PK E SK)

Referência

• Single-table vs. multi-table design in Amazon DynamoDB | Amazon Web Services
• Best practices for managing many-to-many relationships in DynamoDB tables

Conclusão

Em Resumo , o DynamoDB é um banco de dados poderoso , muito flexível , e pode endereçar vários problemas transacionais que no passado usavamos somente o banco de dados relacional. Conhecendo bem os padrões de acesso pode ser uma ótima ferramenta na construção de aplicações modernas

Em outros artigos podemos explorar com mais detalhes outros recursos e características

Obrigado pela leitura , Abraços

As opiniões citadas nesse artigo são minhas.

#AWS #DynamoDB