Assine a nossa newsletter | Receba insights sobre Transformação Digital

Construindo Pipelines Serverless com eventos do Amazon CloudWatch

Construindo Pipelines Serverless com eventos do Amazon CloudWatch

Eventos e Serverless andam juntos como carne e churrasco. A mentalidade Serverless (sem servidor) diz para se concentrar no código e na configuração que fornecem valor comercial.

Acontece que na maior parte do tempo, isso significa trabalhar com eventos: dados estruturados correspondentes às coisas que acontecem no mundo exterior. Em vez de manter tarefas demoradas do servidor que consomem recursos durante a pesquisa, é possível criar aplicativos Serverless que funcionam em resposta a “disparadores de eventos”.

Temos muitas opções ao trabalhar com eventos na AWS: Amazon Kinesis Data Streams, Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS) e muito mais, dependendo dos requisitos. Ultimamente vem sendo utilizado um serviço com mais frequência que tem a palavra “evento” o: Eventos do Amazon CloudWatch.

CloudWatch Events: O segredo mais bem guardado no processamento de eventos Serverless

Conhecemos o CloudWatch como o serviço que coleta os logs do Lambda e que permite executar funções em um cronograma. Mas o CloudWatch Events também permite publicar os próprios eventos personalizados usando o API do CloudWatch. Ele tem garantias semelhantes de preço e entrega para o SNS e oferece suporte a vários serviços da AWS..

O melhor de tudo, não é preciso provisionar o barramento de eventos – está lá no console do CloudWatch. É possível publicar um evento agora, usando o boto3 AWS SDK for Python:

import boto3

cw = boto3.client(‘cloudwatch’)

cw.put_events(

Entries=[

     {

         ‘Source’: ‘my.app.event’,

         ‘DetailType’: ‘MY_EVENT_TYPE’,

         ‘Detail’: ‘{“my_data”:”As a JSON string”}’

     }

]

)

Em suma, o CloudWatch Events oferece um canal de eventos totalmente gerenciado que suporta um número arbitrário de consumidores, onde é possível descartar qualquer tipo de string JSON que você queira. E isso é muito útil para criar aplicativos Serverless.

Arquiteturas orientadas a eventos em ação:

Construímos soluções nativas da nuvem para clientes diariamente. Frequentemente, usamos arquiteturas orientadas a eventos como uma maneira poderosa de migrar sistemas legados para Serverless, habilitar integrações mais simples e mais. A seguir vamos mostrar alguns padrões:

  • Projetando aplicativos de origem de eventos
  • “Strangling” ou estrangulando (traduzindo para o português) banco de dados legados
  • Projetando aplicativos de origem de eventos

“Estrangulando” bancos de dados legados

O “padrão strangler” oculta um sistema legado por trás de uma API de wrapper, enquanto gradualmente migra os usuários para a nova interface. A transmissão de alterações para a nuvem, como eventos, é uma ótima maneira de abrir casos de uso de relatórios e análises e, ao mesmo tempo, remover a carga de um banco de dados legado. O diagrama a seguir mostra a gravação de um banco de dados herdado em eventos.

(img: blog aws amazon)

Esse padrão também pode funcionar de outra maneira: é possível gravar novos dados no CloudWatch Events, consumí-los em uma fonte de dados moderna e criar um seguindo consumidor que sincronize os dados com o seu sistema legado.

Projetando aplicativos originados por eventos:

A terceirização de eventos significa simplesmente tratar as mudanças no estado do sistema como eventos, publicando-os em um “ledge” ou em um barramento onde eles podem ser consumidos por diferentes aplicativos de recebimento de dados.

Usando os eventos do CloudWatch como um barramento centralizado, é possível disponibilizar um registro limpo de eventos, conforme mostrado no diagrama de fluxo de validação de eventos a seguir:

(img: blog aws amazon)

A função de validação garante que apenas os eventos que correspondam aos padrões do meu aplicativo sejam marcados como “válidos” e disponibilizados para os consumidores downstream. O barramento padrão lida com muitos eventos. Por isso é importante configurar regras que correspondam apenas aos eventos que me interessam.

O CloudWatch Events simplifica esses padrões fornecendo um único barramento, no qual é possível aplicar filtros e inscrever clientes, sem ter que provisionar ou manter qualquer infraestrutura. E isso é apenas o começo. 🙂

Caso de uso: processamento de eventos com várias contas com eventos CloudWatch

O CloudWatch Events fica mais interessante quando começamos a conectar várias contas, usando regras de filtragem para escolher quais eventos serão encaminhados.

Como por exemplo, imagine um sistema de processamento de widgets para uma grande empresa, a “Empresa Exemplo”. A “Empresa Exemplo” tem várias equipes de desenvolvimento diferentes, cada uma usando sua própria conta na AWS. Alguns serviços estão produzindo informações sobre widgets quando eles acessam os armazéns ou viajam pelo país. Outros precisam desses dados para gerar relatórios ou inovar novos produtos.

Suponha que o “Serviço A” produza informações sobre novos widgets, o “Serviço B” deseja visualizar agregados sobre widgets em tempo real e o “Serviço C” precisa de dados históricos sobre widgets para relatório. O fluxo de eventos completo se parecerá com o diagrama a seguir:

1.   O “Serviço A” publica o novo evento de widget no CloudWatch Events em sua conta da AWS com o seguinte evento:

{

         ‘Source’: ‘cwi.servicea’,

‘DetailType’: ‘NEW_WIDGET’,

‘Detail’: ‘{“widget_id”:”abc123″}’

}

2. Uma regra de filtragem encaminha eventos marcados com cwi.services a conta de processamento de evento central. Usando o CloudFormation, eles poderiam definir a regra da seguinte maneira:

CentralForwardingRule:

Type: AWS::Events::Rule

Properties:

Description: Rule for sending events to central account

EventPattern:

source:

– cwi.servicea

Targets:

– Arn: !Sub arn:aws:events:${CENTRAL_ACCOUNT_REGION}:${CENTRAL_ACCOUNT_ID}:event-bus/default

Id: CentralTarget

RoleArn:

3.     O evento é validado de acordo com seus padrões.

4. O evento válido é republicado no barramento central de eventos com uma nova fonte valid.cw.servicea. isso é importante porque, para evitar loops infinitos, um evento individual só pode ser encaminhado uma vez.

5.  Uma regra de filtragem encaminha o evento válido para a conta AWS do Serviço B, onde atualiza uma tabela do DynamoDB conectada a uma API do AWS AppSync.

6.   Uma segunda regra encaminha o mesmo evento para a conta do Service C, na qual ele passa pelo Kinesis Data Forehose para um bucket do Amazon S3 para análise usando o Amazon Athena.

O que o CloudWatch Events fornece aqui é um sistema desacoplado que usa principalmente serviços “plug-and-play” e ainda abre flexibilidade para inovações futuras.

Aproveitando ao máximo a nuvem

A maior razão pela qual o CloudWatch Events é amado? É um serviço fantasticamente nativo da nuvem. Há pouco código necessário e nenhuma responsabilidade operacional além de observar os limites de serviço da AWS. Não é preciso implantar nada para começar a usá-lo.

Isso é muito próximo do ideal platônico dos aplicativos Serverless.

Fonte: blog aws