Olá, pessoal! Tudo bem?
A algum tempo, escrevi um post a respeito do padrão Sidecar, falando sobre como ele segregava responsabilidades da aplicação, e como ele tinha relação com o modelo Service Mesh (Malha de Serviços). Pois bem, hoje é o dia de abordarmos este modelo.
O que é Service Mesh?
Quando falamos em sistemas distribuídos, algumas complexidades surgem oriundas da comunicação entre seus componentes. Tornar resiliente a transação entre dois serviços e manter a conexão entre eles segura, são apenas alguns dos desafios encontrados neste modelo de arquitetura, e tendem a ficar mais complicados com o aumento da quantidade de serviços envolvidos.
O Service Mesh é um modelo de arquitetura criado justamente para atacar estas complexidades, abstraindo responsabilidades como:
- Descoberta de serviços: A malha se encarrega de identificar instâncias novas e descartas antigas, mantendo a distribuição do trafego apenas para os serviços válidos;
- Balanceamento de carga: A malha de serviços gerencia a carga entre as diversas instâncias de um serviço. Em muitos casos, suportando inclusive implantações Canário (Canary Releases);
- Resiliência: Patterns como Retry e Circuit Breaker podem ser aplicados na comunicação da mesh para aumentar a resiliência;
- Roteamento dinâmico: Baseada nas atualizações na estrutura de serviços, a mesh atualiza automaticamente as suas regras de roteamento;
- Caching: Estratégias de caching podem ser aplicadas para otimizar o desempenho na comunicação;
- Autenticação e Autorização: A malha fornece mecanismos de autenticação e autorização entre serviços para aumentar a segurança na comunicação;
- Observabilidade: A mesh pode fornecer telemetria sobre os três pilares da observabilidade: logs, métricas e tracing.
Removendo estas atribuições da aplicação, os desenvolvedores podem focar na entrega de valor, implementando novas features, de forma mais produtiva.
Importante: Um ponto relevante a ser citado, é que a implementação das features citadas acima depende do framework adotado.
Como ele funciona?
Por alto, o Service Mesh é divido em duas partes com responsabilidades distintas e que se complementam: O Control Plane e o Data Plane. O primeiro é responsável pela gestão da mesh, onde configurações e políticas são gerenciadas e aplicadas a todos os serviços, para controlar a comunicação. O segundo é a parte operacional, ou seja, onde a mágica acontece. A grande mudança na arquitetura, é a adição de um sidecar com a função de proxy (que é o próprio Data Plane) a todos os serviços da Mesh. Este novo componente é responsável por tratar todos os itens citados na sessão anterior, através de configurações feitas no Control Plane.
Para ilustrarmos como a comunicação funciona, no diagrama acima o seguinte fluxo ocorre:
- O Proxy A recebe uma requisição e encaminha para o Service A;
- O Service A necessita consultar o Service B. Neste momento, a requisição é devolvida para o Proxy A, que através das regras de roteamento da mesh, invoca o Proxy B.
- O Proxy B encaminha a requisição iniciada pelo Service A, ao Service B;
- O Service B devolve a resposta fazendo o fluxo inverso, retornando-a para a origem.
Existem diversos frameworks para trabalharmos com Service Mesh. Podemos citar alguns exemplos como o Istio, que é o mais fomentado no mercado atual, o Linkerd, que implementa o Service Mesh com Kubernetes, e o App Mesh, da AWS, que não poderia ficar de fora 😀 . O interessante deste último, é que é possível utilizar diversas tecnologias em uma mesma mesh, incluindo todas os orquestradores de containers da AWS (ECS, EKS e Fargate) e instâncias EC2.
Quando não utilizar o Service Mesh?
Como citamos só vantagens até agora, vamos falar de alguns pontos negativos do Service Mesh. Primeiramente, ele é uma excelente ferramenta para abstrairmos complexidades em ambientes de microsserviços, porém, dependendo da topologia, adiciona complexidade demais de forma desnecessária. Se a topologia for rasa (poucas layers), principalmente, vale uma avaliação da arquitetura, pois talvez o Service Mesh não faça sentido.
Outro ponto a ser considerado, é o impacto no ciclo de vida de desenvolvimento. No meu ponto de vista, o maior impacto ocorre no ciclo de CI/CD, onde todos os serviços envolvidos na malha serão afetados pelo framework de Service Mesh.
Por hoje era isso, pessoal.
Como amanhã é Natal, desejo um Feliz Natal a todos e até a próxima!