Camadas de Arquitetura Serverless 🚀

Foto de Willian Justen de Vasconcellos no Unsplash

Introdução

Em arquitetura corporativa no mundo serverless, é imperativo planejarmos holisticamente e conceitualmente, nossas soluções gerais como um conjunto de padrões, modelos e proteções para garantir que não tenhamos uma arquitetura anêmica de pinball lambda , que com o tempo se torna uma grande bola de lama e provavelmente um monólito distribuído com muita duplicação de lógica de negócios e esforço de equipe desperdiçado. ( mostrado abaixo )

  • 🔵 Interface do usuário (apresentação) e aplicativo → Experiência
  • 🔵 Domínio → Domínios
  • 🔵 Infraestrutura → Plataformas

Camada de Experiência 🏂

No livro, a Interface do Usuário ou Camada de Apresentação é descrita como “Responsável por mostrar informações ao usuário e interpretar os comandos dos usuários” e a Camada de Aplicação é descrita como “Define os trabalhos que o software deve fazer e direciona os objetos de domínio expressivos para resolver problemas”.

Vamos ver um exemplo para nossa empresa fictícia

Podemos ver no diagrama abaixo que a equipe de estoque, que lida com o estoque de roupas de montanha, tem em sua arquitetura:

  1. Permitiu que a lógica de negócios vazasse no código de front-end para o sistema interno de verificação de estoque. Esta lógica não é acessível ao resto dos sistemas.
  2. Um aplicativo Alexa precisa adicionar funcionalidade para “verificar estoque online”; no entanto, essa lógica já foi duplicada nos dois back-end para front-end APIs, um para o sistema interno de verificação de estoque e outro para os websites que verificam o estoque.
  • 🔵 Garantir que a lógica de negócios não vaze pela organização. (Lambda Pinball).
  • 🔵 Garantir que a lógica de negócios seja reutilizável em toda a organização e camadas de experiência, não deve ficar em BFFs ou código de front-end.
  • 🔵 Permitir usar diferentes requisitos de autenticação por camada de experiência.
  • 🔵 A camada de experiência, ou seja, UI/Voice/UX, não deve conter lógica de negócios compartilhada.
  • 🔵 As APIs de back-end para front-end não devem conter estado (sem estado/stateless).

Camada transversal 📐

Não há equivalente no livro para Camada Transversal (cross-cutting layer) , mas isso é algo que, na minha opinião, é imperativo ao arquitetar soluções corporativas serverless.

Vamos ver um exemplo para nossa empresa fictícia

Em nosso exemplo para Lee James Mountain Wear, descobrimos que nossas equipes de estoque e pedidos estão construindo suas próprias bibliotecas de componentes React em seus próprios silos, pois há uma falta de comunicação, sem pensar nisso em nível empresarial.

  • 🔵 Evita complexidade, duplicação e carga cognitiva em cada equipe resolvendo os mesmos problemas.
  • 🔵 Permita que as pessoas se movimentem com mais facilidade entre as equipes, pois temos padrões.
  • 🔵 Aumenta a velocidade e agilidade nas equipes sem reinventar a roda.
  • 🔵 Nos permite obter melhores contratos com fornecedores de produtos SasS devido ao aumento do uso em escala empresarial.

Camada de Domínio 🛍️

A Camada de Domínio na minha opinião é a mais importante para acertar e focar. No livro, Eric Evans descreve isso como “Responsável por representar conceitos para o negócio, informações sobre a situação do negócio e regras de negócio.”.

  • 🔵 APIs e eventos versionados bem definidos garantem que os consumidores entendam como interagir com nossos domínios.
  • 🔵 Interfaces de domínio significam que podemos alterar as partes internas sem afetar os consumidores.
  • 🔵 Nossos serviços de domínio não são acessíveis externamente ao mundo, e apenas acessados ​​usando fluxos de máquina para máquina. (ou seja, usando API Gateways privados).
  • 🔵 Garantimos que os consumidores não interagem com serviços internos de nossos domínios, apenas por meio de nossas APIs e eventos bem definidos.
  • 🔵 A lógica de domínio pode ser utilizada por outros serviços, camadas de experiências e domínios, evitando que domínios anêmicos sejam divididos em um monólito distribuído.

Camada de dados 📊

A próxima camada Serverless é a camada de dados, que não é representada no livro; no entanto, no mundo de dados de hoje e orientado a eventos, precisamos pensar sobre isso em um nível empresarial.

  1. Enterprise Service Bus: Por exemplo, normalmente seria Amazon EventBridge ou Amazon MSK (Kafka) .
  2. Relatórios e BI: Por exemplo, normalmente seria Amazon QuickSite e Amazon Athena .
  3. Dados: Normalmente, seriam data lakes do Amazon Redshift ou do S3, por exemplo.

Vamos ver um exemplo para nossa empresa fictícia

Na organização empresarial Lee James Mountain Wear, temos três equipes diferentes utilizando três tecnologias diferentes (SNS, EventBridge e MSK), o que dificulta muito a comunicação de domínio com base em eventos. A padronização em nível empresarial desde o início tornaria isso muito mais fácil, reduzindo o tempo de desenvolvimento, reduzindo a carga cognitiva nas equipes e permitindo esquemas de eventos com versão e descoberta de eventos.

  • 🔵 Um Enterprise Service Bus nos permite coordenar eventos entre equipes de uma empresa.
  • 🔵 O Amazon EventBridge Schema Registry permite que outras equipes visualizem nossos eventos versionados e os consumam (fácil de descobrir, reduzindo a carga cognitiva e aprimorando a comunicação)
  • 🔵 Podemos relatar os dados e eventos transmitindo-os para data lakes ou warehouses e consumindo usando ferramentas como Athena e QuickSite.
  • 🔵 Podemos usar análise de sentimentos e eventos para criar visualizações de clientes únicos.
  • 🔵 Reduz a carga cognitiva nas equipes que utilizam um ESB e aumenta sua velocidade e agilidade.

Camada de plataformas 🌐

A camada final do livro, a Camada de Infraestrutura, é equivalente à Camada de Plataformas. No mundo serverless, as equipes estarão gerenciando sua própria arquitetura e serviços por meio de infraestrutura por código, ao invés do mundo tradicional de gerenciamento de servidores. O livro descreve a camada de infraestrutura como “Fornece recursos técnicos genéricos que suportam as camadas superiores”.

  1. Plataformas de Autenticação: Essa é uma maneira padrão de equipes realizarem comunicação de máquina para máquina.
  2. Pipelines e Contas: As equipes serverless não precisam pensar no trabalho pesado, como criar pipelines ou criar VPCs, configurações de redes, gateways de trânsito etc. Isso deve ter templates para rápido uso pelas novas equipes/domínios.
  3. Segurança: A segurança deve ser incorporada o mais cedo possível em nossos modelos quando novas equipes e soluções são lançadas, movendo isso para a esquerda no fluxo de desenvolvimento, o mais rápido possível (conceito “shift-left”).
  4. Especificações da API/Esquemas de Eventos: Eles devem ser centralizados e fáceis de serem descobertos pelas equipes, aumentando a agilidade e a velocidade.

Resumo

  • 🔵 Os portais e plataformas de desenvolvedores devem aumentar a velocidade e agilidade para as equipes Serverless.
  • 🔵 Definições de infraestrutura de baixo-nível como networking, configuração de VPCs, criação de pipelines etc devem ser fornecidos pela plataforma e com templates.
  • 🔵 Os portais do desenvolvedor devem facilitar para as equipes descobrirem APIs e definições de eventos.

Créditos

--

--

☕🇳🇿 - https://eduardorabelo.me

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store