O que é Service Mesh?

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.

Mapa de microsserviços da Netflix (2015)

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.

Exemplo de um modelo de Service Mesh

Para ilustrarmos como a comunicação funciona, no diagrama acima o seguinte fluxo ocorre:

  1. O Proxy A recebe uma requisição e encaminha para o Service A;
  2. 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.
  3. O Proxy B encaminha a requisição iniciada pelo Service A, ao Service B;
  4. 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.

Apenas uma layer de serviços

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!


Deixe uma resposta