Afinal o que é um Service Mesh?

No passado, quando queríamos conectar um computador A com um computador B o fazíamos literalmente através de um cabo de rede. Dentro da nossa aplicação eu possuía minha lógica de negocio e também a lógica que controlava a minha comunicação.

Podemos melhorar isso? Sim! Podemos deixar a lógica de aplicação no nosso serviço (aplicação) e passar o controle de fluxo (comunicação) para outro lugar (exemplo: dentro da minha stack de network).

Estou tendo UM salto entre o serviço A e o serviço B.

Passa o tempo e resolvemos quebrar o nosso monolito em microserviços e com isso ganhamos de presente um outro tipo de complexidade. Principalmente na parte de comunicação. Agora temos VÁRIOS saltos. Um serviço comunicando com outros serviços. E o que usamos para por exemplo monitorar e configurar um monólito NÃO encaixa para a nossa nova arquitetura de microserviços.

Entra em cena as OITO falácias da computação distribuída:

1. A rede é confiável
2. A latência é zero
3. A largura de banda é infinita
4. A rede é segura
5. A topologia da rede nunca muda
6. Existe um administrador
7. Custo de transferência de dados é zero
8. A rede é homogênea

Você pode aprendar mais a respeito nesta palestra:

Note que na maior parte das falácias a gente fala de network. OU seja, problema de COMUNICAÇÃO. Como uma aplicação fala com a outra.

Já falamos acima que ao adotarmos uma arquitetura de microserviços ganhamos de presente uma serie de complexidades dentre as quais:

  • Granularidade alta;
  • Latência;
  • Testar microsserviços pode ser uma tarefa complexa
  • Tracing Distribuído
  • Logging
  • Orquestração
  • Monitoramento
  • Segurança
  • Contratos
  • Observabilidade
  • Resiliência
  • etc...

Google, Twitter, Netflix e outras empresas quebraram as suas aplicações em Microserviços e passaram a enfrentar as complexidades de uma arquitetura assim definida.

Para lidar com tais complexidades criaram bibliotecas internas. E ai vem outros problemas. Como uso essas bibliotecas em um ambiente não JVM?

Em 2015 a CNCF foi criada e com ela vemos cada vez mais falar sobre o conceito de aplicações Cloud Native.  Em resumo: Microservicos, conteinerizados sendo orquestrados por um K8s da vida.

A combinacao de complexidade + criatividade motiva o uso de uma camada dedicada de comunicação entre estes serviços. E essa comunicação TEM QUE ser desacoplada do código, da lógica de negocio da minha aplicação. E essa camada dedicada de infraestrutura é o que chamamos de Service Mesh.

A definição foi criada pelo William Morgan da Buoyant. Pessoal da Buoyant são ex engenheiros do twitter e enfrentaram os problemas acima citados numa arquitetura de microserviços.

O service mesh assume que L3 e L4 ja existem e sao capazes de entregar bytes de ponta a ponta.

Arquitetura de um Service Mesh:

  • Control Plane: aonde tenho meu portal de gerenciamenteo centralizado, politicas, moniotramente, etc
  • Data Plane: responsável por quem conversa com quem, coletar métricas, forward de pacotes, roteamento, etc

No caso do Data Plane ele utiliza de um pattern chamado Sidecar. Desacoplo do meu microservico a questão de comunicação. Toda comunicação inter-serviços são feitas através do side car. Um Microservice não conversa com outro Microservice diretamente. Conversam através do sidecar.

Existem diversos “players” no mercado como: Maesh, Envoy, Istio, Consul, Linkerd, Kuma.

SMI-Spec: Service Mesh Interface Specification - a idéia aqui é pegar tudo o que é comum de features entre service meshes, crio uma interface padrão dou pro vendor e a implementação não me importa. Siga o que a interface diz e não me importo com a implementação.

Espero que com este artigo você possa ter um entendimento melhor de Service Mesh.

Se quiser a "versão em vídeo" deste artigo assista a palestra que eu dei no DevOps Days BH 2019: