Documento de decisão Arquitetural de extração e distribuição de informações estratégicas de jogadores de futebol de clubes brasileiros.

# Documento de decisão Arquitetural de extração e distribuição de informações estratégicas de jogadores de futebol de clubes brasileiros. Esse documento está sendo escrito com base [nesse artigo](https://personal.utdallas.edu/~chung/SA/zz-Impreso-architecture_decisions-tyree-05.pdf). # Estruturando o racional Simplificando o processo como todo da Intera, temos esses seguintes macros que podem ser classificados como grupos: ![grupos](https://i.imgur.com/FJYYupF.png) Utilizaremos esse grupos para classificar os elementos de DA (documento de decisão arquitetural). ## Estimando as constraints do cenário Considerando que entre os desafios que teremos para colocar o produto no mercado, tenhamos algumas definições: * **Equipe reduzida por conta da dificuldade de encontrar profissionais qualificados:** Sabemos que uma equipe grande com capacidade técnica alta, e que seja essencial com todos os colaboradores, torna o processo sujeito a implicações externas como concorrência alta entre as startups, carga de trabalho motivacional por parte da liderança elevada, gaps de conhecimento por conta de ilhas de conhecimento que acontece conforme a solução ganha robustez e necessita de escalar pessoas, entre outros fatores. * **Time to Market:** Considerando que o produto está com seu modelo de negócio e fluxo de extração em um nível de maturidade considerável, teremos que converter o processo atual em um processo automatizável e escalável em que podemos já podemos estimar as métricas em cima das bases de clientes existentes e estimar até onde queremos chegar nos próximos anos, com isso podemos considerar que associado a um tempo de atingirmos o mercado com modelo escalável em um tempo mais curto possível. * **Filosofia orientada a Escalabilidade:** Sou adepto ferrenho da filosofia da programação funcional. Tenho empregado com sucesso o uso dela que me garantiu ganho de performance em resolução de problemas que envolvem desde a debugar problemas em produção, garantias da imutabilidade (não somente em funções, como em infraestrutura). Deixo anexo um [ppt da nubank](http://pesquisa.ufabc.edu.br/haskell/cursos/Haskell2018/files/clojure_101.pdf) no qual eles mostram as facilidades da imutabilidade e programação funcional em situações mais críticas como operações financeiras. * **Arquitetura de microserviços baseado em arquitetura hexagonal + clean arquitecture:** Não somente me inspiro na filosofia da programação funcional e imutabilidade, quanto também me inspiro nos modelos de arquitetura de microserviços que a Nubank escolheu. Estudei por um tempo a arquitetura e coloquei em ambientes produtivos, e ele se tornou extremamente útil quando um time é reduzido e tenha que lidar com desafios de sistemas distribuídos. [Tenho um Repositório de boilerplate](https://github.com/claytonsilva/nodejs-hexagonal-boilerplate) onde explico os elementos de decisões de forma resumida. * **Arquitetura orientada a eventos:** Teremos uma carga baseada a eventos que virão fora de nosso controle, como de fontes de dados externas, serviços externos, e toda carga de trabalho até o processamento do dado compilado terão que estar preparados e ser **normal** ocorrer erros e principalmente, o código estar orientado a falha de acordo com o [manifesto reativo](https://www.reactivemanifesto.org/pt-BR). * **Estaremos lidando com um modelo de dados NoSQL:** conforme as ferramentas de extração e outras ferramentas de normalização começarem a obter informações, teremos dados relevantes que podem demandar estruturas orientado ao dado, somente cabendo estruturação quando a informação está devidamente processada com seus KPI's para consumo final. Tomado por essas premissas, estou definindo alguns "facilitadores" de decisão: * Simplificar ao máximo o número de elementos tecnológicos (linguagens de programação, provedores de nuvem, etc). * Serviços e tecnologias em que estou familirializado, pois estarei na frente de muitas entregas a nível de codificação, e o tempo entre descobertas de resolução de problemas é curto. * Prioridade em utilizar Serviços na nuvem quando a outra opção é provisionar o próprio serviço, se o serviço não atender conforme o crescimento, já estaremos escalando e poderemos ter mais tempo para aprender a provisionar por conta própria. * Filosofia alinhada com imutabilidade e programação funcional. ## Primeira decisão: Linguagem base ### D01 - Linguagem de programação primária | Elemento |Conteúdo| |--- |--- | | Issue | Definir a principal linguagem de programação | | Decision | javascript | | Status | Pending | | Grouping | Todos, exceto "extrair e coletar" | | Assumptions | Time to Market; Dificuldade de mão de obra especializada Integração com serviços de mercado | | Constraints | - | | Positions | Javascript Python C# linguagens baseado na JVM | | Argument | Head tem facilidade de utilização na linguagem e pode formar novos colaboradores. Linguagem com ecossistema extremamente difundido em tecnologias na nuvem. Facilidade de integração com serviços disponíveis no mercado. | | Implications | Tipagem fraca e maior carga de teste para que tenha maior confiabilidade nas entregas. Além disso, das linguagens funcionais ela possui algumas limitações no escopo funcional como falta de suporte a TCO (tail call optimization), e falta de suporte nativo a imutabilidade, mas esse último pode ser controlado com o uso de linters. Atividades que demandarem grau alto de processamento não poderão utilizar dessa linguagem, ela é extremamente versátil em I/O, mas para cargas altas de processamento devemos considerar adotar linguagens baseada na máquina JVM | | Related decisions | Olhar "Estimando as constraints do cenário" | | Related requirements | - | | Related artifacts | - | | Related principles | - | | Notes | - | ### D02 - Linguagem de programação secundária | Elemento | Conteúdo | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issue | Definir uma linguagem secundária, com foco nas ferramentas de extração de dados não normalizados | | Decision | python | | Status | Pending | | Grouping | extrair e coletar | | Assumptions | Time to Market; Dificuldade de mão de obra especializada Integração com serviços de mercado; | | Constraints | - | | Positions | Javascript Python C# linguagens baseado na JVM| | Argument | Linguagem com curva de aprendizado baixa; Ecossistema de comunidade maduro em conceito de extração e tratamento de dados; Por conta de bibliotecas preparadas para os problemas que vamos resolver, o base code vai ser relativamente mais enxuto; Facilidade de acesso a ferramentas e modelos utilizados na comunidade e similaridade com ecossistema de Machine Learning; Facilidade de suporte a ferramentas de mercado com suporte à linguagem como opção para integração| | Implications | Falta de familiaridade do Head com casos reais de extrações e codificação em python exigirá de um esforço maior para iniciar os resultados; Disputa acirrada em profissionais da área de "Dados" de um modo geral pode ser um desafio para formar um time | | Related decisions | Olhar "Estimando as constraints do cenário" | | Related requirements | - | | Related artifacts | - | | Related principles | - | | Notes | - | ## Segunda decisão: Provider de nuvem padrão Retomando nosso esqueleto de grupos novamente teremos que analisar todos os problemas que teremos para resolver ![grupos](https://i.imgur.com/FJYYupF.png) ### Premissas por grupo de atividades da solução * Em extrair e coletar: * realizar cargas de trabalho coordenadas em função do tempo ou orientado a mudança de eventos das fontes de extração * as cargas de trabalhos são variadas e intensas, portanto devem ser realizadas de forma que o extratores sejam stateless e que o trabalho pode ser interrompido e sem perdas * as cargas de trabalho tem que ser mais baratas que uma carga padrão e podemos dar ao luxo de termos spots * **é necessário uma solução de mensageria que suporte a carga de informação** * Normalizar e enriquecer dados * normalização de dados exigirá um crescimento orgânico de serviços orientados à fonte de dados sem necessidade de exigir parada dos serviços * **é necessário uma solução de mensageria que suporte a carga de informação** * as cargas de trabalhos são variadas e intensas, portanto devem ser realizadas de forma que o extratores sejam stateless e que o trabalho pode ser interrompido e sem perdas * as cargas de trabalho podem ser mais baratas que uma carga padrão e podemos dar ao luxo de termos spots * as cargas de trabalho podem ser orientadas a eventos usando FaaS (Function as a Service) * Processar resumos e tomadas de decisões * **é necessário uma solução de mensageria que suporte a carga de informação** * as cargas de trabalhos são variadas e intensas, portanto devem ser realizadas de forma que o extratores sejam stateless e que o trabalho pode ser interrompido e sem perdas * as cargas de trabalho podem ser mais baratas que uma carga padrão e podemos dar ao luxo de termos spots * as cargas de trabalho podem ser orientadas a eventos usando FaaS (Function as a Service) * o provider deve fornecer solução simplificada para integração com soluções para usuário final (mobile/web/desktop). * (plus) o provider de nuvem deve fornecer soluções de ML para aproveitarmos o volume de dados que estará sendo processada. * Fornecer dados como serviço * **é necessário uma solução de mensageria que suporte a carga de informação** * A camada de dados precisa suportar uma carga de consultas que escale horizontalmente e esteja preparado tanto para aumento de volume de consumidores quanto aumento de volume de dados crescente. * A camada de dados como serviço irá garantir uptime, mesmo com time reduzido. * A api deve ser capaz de processar uma quantidade de consultas sem quebrar aplicação como por exemplo, eventos de memory leaks * A api deve estar protegido de ataques de DDOS e monitorada constantemente. Entre os providers de nuvem, devemos procurar a que fornecer soluções como serviço para maior parte das premissas adotadas acima: ### tabela 1 - comparação entre providers | Critérios | Google Cloud | AWS | |:------------------------------------------------------------------------------------:|:----------------:| --------------------- | | ferramenta de Busca como serviço | - | ElasticSearch Service | | Processamento de carga de trabalho em conteiner | CloudRun e GKE | EKS e ECS | | Facilidade de implantação | Média para Baixa | Alta | | Suporte a BigData como serviço | Sim | Sim | | Suporte a ML como serviço | Sim | Sim | | Suporte a Messageria como serviço | Sim | Sim | | Suporte a Processamento com instancias em preço reduzido | Moderado | Alto | | Maturidade do Head com as opções de messageria do Provider | Baixa | Alta | | Suporte a serviço de criação de soluções para usuário final com os dados processados | Firebase | Appsync | Dentre os pontos citados, temos um suporte grande do Elasticsearch que irá ajudar em vários pontos da nossa solução e devido ao suporte nativo da nuvem podemos desde integrar com serviços de api de alta disponibilidade quanto integrar com soluções que irão mostrar em tempo real dados processados, o que encaixa muito em nossas premissas. ### D03 - Providers de nuvem | Elemento | Conteúdo | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issue | Definir provider de nuvem principal de trabalho | | Decision | AWS | | Status | Pending | | Grouping | Todos | | Assumptions | Time to Market; Suporte Orientado a Serviços; Time de desenvolvimento enxuto | | Constraints | - | | Positions | AWS GCP | | Argument | Head tem facilidade de utilização do provider e pode formar os colaboradores; Suporte mais alto a carga de trabalho mais barato; Suporte integrado ao serviço de elasticsearch que será discutido posteriormente. | | Implications | - | | Related decisions | Olhar "Estimando as constraints do cenário" | | Related requirements | - | | Related artifacts | Olhar tabela 01 | | Related principles | - | | Notes | - | ## Terceira decisão: Messageria padrão Uma vez definido nosso provider de nuvem, devemos considerar as opções de carga de messageria. mas antes uma nota muito importante: **Não foi identificado durante toda a solução necessidade de processamento FIFO ou que a ordem de processamento interfira no negócio, então as questões de ordenação do processamento serão excluídas das tomadas de decisão.** ### Opções de messageria * **AWS Kinesis:** PubSub mais popular da AWS, com suporte a ferramentas de transformação de dados como [Firehose](https://aws.amazon.com/pt/kinesis/data-firehose/?kinesis-blogs.sort-by=item.additionalFields.createdDate&kinesis-blogs.sort-order=desc), que possui muitas features já conhecidas do KAFKA, mas requer um planejamento muito alto para definir seu volume de cluster, senão resultará em gargalos ou volume alto de despesa em seu uso. * **AWS MSK:** Semelhante ao Kinesis, mas é uma opção de custo mais controlado para quem quer controlar seu proprio Kafka sem ter necessidade de fato de ter o custo operacional de manter o Kafka em produção, a maioria das features encaixam com Kinesis, exceto suporte ao Firehose. * **AWS SQS+AWS SNS:** Melhor dos mundos entre PubSub e filas, onde podemos controlar os eventos instantâneos pelos tópicos e deixar que cada tópico tenha suas filas equivalentes para processamento em worker que podem ser orientado a eventos e com controle maior de resiliência. O suporte de volume de mensagens é alto. Dado nossa premissa inicial em "Estimando as constraints de cenário", vamos atentar somente as opções de KINESIS e SQS+SNS. E teremos uma ressalva, o design da arquitetura hexagonal vai permitir que caso um cenário não se tornar promissor o custo da troca de messageria será baixo. ### tabela 2 - comparação entre messageria | Critérios | Kinesis | SQS + SNS | |:-------------------------------:|:---------------------------:| ---------------------------------------------------------------------------- | | Custo | Alto e Sem início gratuito | Baixo e gratuito, sempre diretamente proporcional ao processamento utilizado | | Esforço de planejamento | Moderado | Baixo | | Facilidade de implantação | Média para Baixa | Baixa | | Maturidade do Head com a opção | Alto | Baixo Suporte a opções de resiliência | Moderado | Alto | ### D04 - Messageria padrão | Elemento | Conteúdo | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issue | Definir a messageria padrão | | Decision | SQS+SNS | | Status | Pending | | Grouping | Todos | | Assumptions | Time to Market; Suporte Orientado a Serviços; Time de desenvolvimento enxuto; Custo Baixo; Baixo custo em mudança. | | Constraints | Vendor Lock | | Positions | SNS+SQS Kinesis | | Argument | Head tem facilidade de utilização da tecnologia e pode formar os colaboradores. Flexibilidade maior em cenários de resiliência; Baixo custo inicial. | | Implications | - | | Related decisions | Olhar "Estimando as constraints do cenário" | | Related requirements | - | | Related artifacts | Olhar tabela 02 | | Related principles | - | | Notes | - | ## Quarta decisão: Persistência para dados como serviço Uma das decisões que favoreceu a escolha da AWS foi questão do uso do elasticsearch como serviço, nessa parte iremos formalizar a decisão com base em outros concorrentes como solução de RDS ou banco de dados tradicional. Queremos que a solução escale, junto com o escalonamento da aplicação, colocaremos na mesa a opção do DocumentDB, que é o equivalente ao mongodb. Em comparação entre as tecnologias devemos destacar o papel do elasticsearch como banco desenhado para consultas em larga escala enquanto o propósito do DocumentDB é banco orientado a documento, e o RDS é um banco transacional GERAL que pode ser convertido em outros propósitos, mas perdemos performance se não usarmos algo com a finalidade que foi projetada para tal. Com isso o peso do elasticsearch ganha, mas teremos um desafio de definir como iremos particionar os dados em índice de forma que fique performático a consulta e faça sentido para quem consumir a ferramenta. Estou acrescentando o uso do dynamodb para auxiliar, devido ao baixo custo que oferece para utilizarmos como fallback em situações de crise, ou outras necessidades como propagação dos dados (Usando DynamoDB streams). ### D05 - Persistência na solução de dados como serviço altamente disponível | Elemento | Conteúdo | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issue | Definir a persistência utilizada para consumo de dados como parte de serviços com 99.5% de disponibilidade | | Decision | Elasticsearch Service AWS + DynamoDB de fallback | | Status | Pending | | Grouping | Fornecer dados Como Serviço | | Assumptions | Suporte Orientado a Serviços; Time de desenvolvimento enxuto | | Constraints | Definir qual informação temporária que possuímos dos dados que estamos extraindo (como data da ultima atualização do dado) para que trabalhemos com o dado distribuído em índice temporal, aproveitando o melhor do elasticsearch; Teremos que ter mecanismos de recuperação de dados e outros modos de persistência, como o DynamoDB; Vendor Lock; | | Positions | Elasticsearch Service AWS AWS RDS AWS DocumentDB | | Argument | Head tem facilidade de utilização da tecnologia e pode formar os colaboradores;Escalabilidade Horizontal; Suporte a estrutura NoSQL; Api que favoreça suporte a consultas | | Implications | - | | Related decisions | Olhar "Estimando as constraints do cenário" | | Related requirements | - | | Related artifacts | - | | Related principles | - | | Notes | - | ## Quinta decisão: Orquestração de serviços Os serviços codificados dentro de casa poderão ser classificados como 3 tipos: * orientado a evento: ele dispara orientado ao evento que o invocou, seu ciclo de vida termina assim que o propósito do tratamento do evento conclui. * processos longos (long running process jobs): serviços que rodam em regime longo e precisam responder rápido a requisições, onde se encaixa perfeitamente no bloco "fornecer dados como serviço do diagrama simplificado abaixo" ![grupos](https://i.imgur.com/FJYYupF.png) * processos de extração: serão disparados de acordo com a lógica de negócio, e não possui padrões para sua execução, mas podem ser interrompidos sem perdas se forem projetados no cenário de resiliência. Eles que irão alimentar os eventos que serão processados pelas atividades orientada a eventos. Uma nova premissa: SIMPLICIDADE! Nessa premissa estou sendo o mais pragmático e considerando que iremos fazer o máximo aclopado possível com o Provider, para que tenhamos nossa SLA mais próxima da dele, claro que considerando até redundância de AZ's e possivelmente de região usando disaster recovery em uma evolução seguinte. Nessa premissa iremos sair da tendência normal de irmos para uma solução robusta como kubernetes (não que iremos ignorar num futuro próximo, mas sim mais alinhado com simplicidade e custo baixo dentro das premissas definidas em "Estimando as constraints do cenário"), iremos para as soluções mais simples padões usadas pela AWS, onde a segunda opção ou é kubernetes ou colocar aplicação na mão. Primeiramente vamos no caso de processamento orientado a evento, onde iremos ter uma vantagem fora da curva de Lambda sobre os demais, principalmente pelo custo ser diretamente proporcional ao volume de processamento, diminuindo custos operacionais de planejamento e diminuindo o tempo de desenvolvimento usando em cima da plataforma. A arquitetura hexagonal definida protege casos em que tivermos casos em que lambda não resolver e tivermos que migrar para outros modelos de execução. ### D06 - Definição de tecnologia para orquestrar processamento orientado a evento | Elemento | Conteúdo | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issue | Definir qual orquestração iremos usar para processamento orientado a eventos | | Decision | AWS Lambda | | Status | Pending | | Grouping | Normalizar e enriquecer dados; Processar resumos e tomadas de decisões. | | Assumptions | Suporte Orientado a Serviços; Time de desenvolvimento enxuto. | | Constraints | Vendor Lock | | Positions | AWS Lambda AWS ECS Fargate AWS EC2 | | Argument | Suporte Nativo do provider de nuvem para eventos dos serviços gerenciados por ele; Implementação mais rápida e com escalabilidade gerenciada por padrão; | | Implications | - | | Related decisions | Olhar "Estimando as constraints do cenário" | | Related requirements | - | | Related artifacts | - | | Related principles | - | | Notes | - | Nos casos de processamento de processos longos iremos para o caso de termos serviços que tenham sempre disponibilidade superior a 99,5%, isso demanda que não podemos dar ao luxo de falha "eventual" que pode ocorrer em orientado a evento. Pensando nisso e respeitando a premissa da simplicidade iremos partir para ECS Fargate, mas não é só isso: teremos que pensar em robustez da camada de resolução de api. Pensando nisso iremos para solução padrão da AWS que é provisionar o API Gateway, que irá garantir que possamos gerenciar várias api's em um único ponto com controle de segurança totalmente centralizado e externo das regras de negócio, para que possamos concentrar em aplicar as regras de negócio. Com isso podemos ter planejamento de Quotas de consumo por cliente para que não tenha nenhum cenário de que um consumo fora de contrato de um de nossos parceiros afete a qualidade de resposta de nossos serviços. Por fim para que proteja de ataques externos, devemos considerar usar ferramenta anti-ddos, no qual sugiro iniciar com Cloudflare. Nesse ponto estou usando da prática de uso para definir qual o produto usar, sem a cerimônia de abrir outras opções, podendo ser feito um processo mais detalhado posteriormente. Uma coisa que pode chamar atenção para quem está revisando é porque não usar solução interna da AWS para resolver o que o Cloudflare resolve, vou resumir que a palavra é preço. Extremamente alto o custo e não vale no estágio inicial. ### D07 - Definição de tecnologia para orquestrar processos longos (long running process jobs) | Elemento | Conteúdo | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issue | Definir qual orquestração iremos usar para processamentos longos e altamente disponíveis | | Decision | ECS Fargate + API Gateway + Cloudflare | | Status | Pending | | Grouping | Fornecer dados como serviço | | Assumptions | Suporte Orientado a Serviços; Time de desenvolvimento enxuto. | | Constraints | - | | Positions | AWS Lambda AWS ECS Fargate AWS EC2 | | Argument | Simplicidade em controle de entrega e monitoramento de conteineres; Implementação mais rápida e com escalabilidade gerenciada por padrão; Delegar controle de consumo de endpoints por dentro de uma ferramenta robusta; Solução como serviço de proteção contra ataques DDOS.| | Implications | - | | Related decisions | Olhar "Estimando as constraints do cenário" | | Related requirements | - | | Related artifacts | - | | Related principles | - | | Notes | - | Por último iremos falar da questão do processamento do que classificam como "Retaguarda", esses processos serão feitos dos mais variados fluxos, sendo disparados de hora em hora, orientado a mudança de eventos do provider da informação, ou simplesmente ficar rodando infinitamente. Como essa força de trabalho o produto deles será sempre um evento que será processado pelas etapas seguintes, iremos trabalhar da seguinte forma: 1. Os processos irão produzir artefatos que irão alimentar storage com S3 para dados grandes, e eventos que apontem para esses dados processados usando a nossa tomada de decição de messageria. 2. Eles podem ser interrompidos sem perdas pois todos os processos são stateless, processos que forem interrompidos pela metade não irão gerar artefatos para processamento. 3. Podemos disparar eventos usando AWS Cloudwatch Events sem necessidade de termos ferramenta do nosso lado para lidar com processamento orientado pelo tempo. 4. A AWS fornece também a solução de Event Bridge que podemos nos aventurar de escutar eventos dos providers de informação e sermos responsivos a eles. Olhando o ponto "2." podemos dar ao luxo de usarmos processamentos spots onde teremos redução de 80% de custo na carga de trabalho, podendo usar máquinas mais potentes para processamentos que demandarem de processamentos mais "intensos". ### D08 - Definição de tecnologia para orquestrar processos de extração | Elemento | Conteúdo | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issue | Definir qual orquestração iremos usar para processamentos de extração | | Decision | ECS Fargate SPOT ou ECS Classico com instancia SPOT + Cloudwatch Events + AWS Event Bridge | | Status | Pending | | Grouping | Extrair e Coletar | | Assumptions | Suporte Orientado a Serviços; Time de desenvolvimento enxuto; Redução de Custos em processamento grande | | Constraints | - | | Positions | AWS ECS Fargate AWS EC2 | | Argument | Simplicidade em controle de entrega e monitoramento de conteineres; Implementação mais rápida e com escalabilidade gerenciada por padrão; Barateamento do custo de processamento sem perder a capacidade de entrega | | Implications | - | | Related decisions | Olhar "Estimando as constraints do cenário" | | Related requirements | - | | Related artifacts | - | | Related principles | - | | Notes | - | ## Montando o diagrama de serviços Uma vez que as maiores decisões foram tomadas, iremos partir para diagramação da solução colocando cada componente no seu devido lugar, iremos abster de detalhes como vpc, e security group. ![diagrama resumido](https://i.imgur.com/oZK08P6.png) ## Infraestrutura como código Toda infraestrutura será provisionada com controle de versionamento e infraestutura como código usando possivelmente duas tecnologias: * Terraform * [AWS CDK](https://aws.amazon.com/pt/cdk/) ## Integração contínua e CI/CD Iremos usar em sua maioria o CircleCI para gerenciar o CI e usaremos o AWS Code Deploy para gerenciar as entregas, para que possamos usar do suporte nativo de entregas usando canary deploy e/ou blue green deployment. ## Observabilidade Premisas que são aplicadas a todos os produtos: * Todo serviço que rodar deve ter um payload de logs normalizado em json para enviar ao cloudwatch logs. * Todo serviço deve ter um APM coletando métricas de consumo para monitorarmos gargalos de processo. * Toda transação de cliente inicia com um número de transação que deve ser acompanhada desde a requisição, passando por todos os serviços até chegar na resposta que envia no cliente, teremos que rastrar pela id da requisição do cliente todos os microserviços que essa aplicação passou. * Iremos usar ferramenta como datadog ou new relic para coletar e consolidar metricas, recomendo datadog pelo custo-benefício de consolidar todos esses pontos, mas podemos inicialmente trabalhar dentro do cloudwatch usando o cloudwatch logs + cloudwatch metrics + x-ray (apm) ## Disclaimer: o que não foi colocado Devem ter notado a falta do tratamento de dados quanto à LGPD nesse processo, mas isso podemos discutir usando processos similares ao de proteção de dados sensíveis de cartão (PCI-DSS) e podemos encriptar a nível de servidor todos os dados usando AWS KMS, mas não irei aprofundar nesse ponto por questão de focarmos no processo principal.