fbpx

Service Mesh |Por Bruno Dias

Fala galera, o post de hoje é uma contribuição do meu querido amigo Bruno Dias

Software Engineering Manager no Itaú Unibanco

Afinal, o que é o Service Mesh?

 Antes de falar especificamente do Service Mesh vamos abordar os desafios da comunicação síncrona.

Em um monolito, temos o tráfego vertical (ou Norte-Sul), como em um API Gateway. Começa no cliente, bate na aplicação e volta para ele.

Com arquitetura baseada em microsserviços, nossas requisições passam por serviços diferentes. É conhecido como tráfego horizontal, ou Leste-Oeste.

Os frameworks de Service Mesh, apoiam nos desafios que os desenvolvedores e operadores enfrentam à medida que os aplicativos monolíticos fazem a transição para uma arquitetura distribuída de microsserviços, que lidam com a comunicação entre os microsserviços, provendo confiabilidade, segurança, rastreamento e observability.

O Service Mesh surgiu com um conjunto de recursos que são necessários para a implementação pragmática de microsserviços.

O termo Service Mesh, que traduzindo para português significa malha de serviço, é usado para descrever a rede de microsserviços que compõe esses aplicativos e as interações entre eles.


O que o desenvolvedor e a aplicação ganham?

Conforme o volume de serviços cresce em tamanho e complexidade, pode se tornar mais difícil de entender e gerenciar.

Em um cenário onde temos por exemplo milhares de micro serviços, através do uso de service mesh, conseguimos retirar as questões de tráfego do software e colocar na camada de infraestrutura, retirando código que não pertence ao serviço de negócio.

Dessa forma, a Service Mesh implementa a maior parte das funções de rede, permitindo ao engenheiro e desenvolvedor do microsserviço se concentrar na lógica do business, e com isso libera os desenvolvedores das questões de rede, onde o Service Mesh provê os controles para descoberta de serviço, monitoramento, resiliência e segurança por exemplo.

O Service Mesh é geralmente implementado com uma instância de proxy de envio, chamada de sidecar. O contêiner secundário nada mais é do que outro contêiner que é implantado e anexado a cada serviço de microsserviço desenvolvido. Ele lida com todo o tráfego que entra e sai dos microsserviços, obtendo melhor visibilidade, resiliência, controle de tráfego, segurança e observability.

Importante mencionar que cada vez mais, esses aplicativos em contêiner são baseados em Kubernetes, uma vez que se tornou o padrão de fato para orquestração de contêiner.

Falaremos de Kubernetes e Docker eu um capítulo a parte.


Benefícios gerais

Se implementado corretamente, o Service Mesh oferece algumas features, tais como:

  • Service Discovery (Descoberta de serviços processo de localizar automaticamente quais instâncias de serviço atendem a uma determinada necessidade); 
  • Balanceamento de carga;
  • Padrões de resiliência (timeout, retry, circuit breaker e fault injection);
  • Gerenciamento de rotas;
  • Segurança (criptografia, autenticação, autorização); e
  • Observability (Métricas para identificar gargalo de latência, erros ou comportamento inadequado).

Service mesh: what it is and why it matters? Techblost, 2021. Disponível em: https://techblost.com/service-mesh-what-it-is-and-why-it-matters/


Ferramentas de Service Mesh

O service mesh tem dois elementos importantes: Control Plane (configuração de comportamento de rede e gerenciamento de tráfego) e o Data Plane (atua como conjunto de proxies nos serviços, gerenciando comunicação de rede, além de coletar métricas e trace dos serviços).

SMITH, Floyd. What Is a Service Mesh? NGINX, 2018. Disponível em: https://www.nginx.com/blog/what-is-a-service-mesh

Atualmente, um proxy muito utilizado é o Envoy, utilizando o padrão sidecar, para executar um contêiner auxiliar dentro do mesmo POD.

Com o uso do Service Mesh, temos uma porta para implementar estratégia de entrega contínua, como blue green e canary.

A ferramenta mais conhecida hoje é o ISTIO, mas temos outras como o Linkerd, Kuma, Open Service Mesh e o Conduit.

ISTIO. istio.io, 2021. Disponível em: https://istio.io/latest/docs/ops/deployment/architecture/


Conclusão

Se me perguntarem se vale a pena o uso do Service Mesh, a resposta será: depende. Se há a necessidade por exemplo, do desenvolvimento de centenas ou milhares microsserviços com comunicação síncrona, o Service Mesh pode ser sim uma ótima escolha, após avaliação dos engenheiros e arquitetos de soluções.

Curtiu? Se sim, podemos fazer outro artigo falando de Service Mesh versus Mensageria ou até mesmo compará-lo aos API Gateways.

Deixe uma resposta

Powered by WordPress.com. por Anders Noren

Acima ↑

%d blogueiros gostam disto: