Microsserviços são complexos e muito difíceis, todo desenvolvedor chega a essa conclusão quando coloca o primeiro projeto em produção usando a arquitetura.

Este artigo faz parte de uma série na qual escrevo sobre Istio. Ao final de cada post você encontrará a lista completa e atualizada contendo todas as publicações.

Se você é um engenheiro de software e trabalha com microsserviços utilizando containers e Kubernetes, provavelmente irá se deparar com o Istio em algum momento da sua carreira.

Informação importante

Não faz parte dos objetivos dessa série discutir as razões para uso de Kubernetes, microsserviços ou para qualquer outra decisão estratégica que seja prévia ao tema.

Ainda vamos falar sobre esses e outros assuntos relacionados. Para que você não perca nenhum post recomendo que me siga 😃

Se você trabalha em uma startup que vislumbra se tornar o próximo unicórnio, em algum momento pode ter passado pela sua cabeça a ideia de adotar microsserviços.

Não é um pensamento ruim, com o crescimento da empresa e consequentemente das necessidades, naturalmente microsserviços será um dos últimos estágios na evolução da sua arquitetura.

Contudo, é importante lembrar que a tecnologia deve servir apenas de suporte ao negócio, ou seja, você não deveria tomar nenhuma decisão baseado em hype.

Isso implica dizer que existe uma chance muito grande de você nunca precisar mudar para arquitetura distribuída.

Em outro momento falaremos melhor sobre isso, temos muito para cobrir e não podemos perder o foco.

Microsserviços

Ao falar sobre esse tópico gosto de resgatar os Princípios de Microsserviços explicados por Martin Fowler, é uma leitura que considero obrigatória antes de seguir nesse artigo.

Microsserviços é computação distribuída, com isso em mente, devemos nos lembrar das Falácias da Computação Distribuída.

Para deixar nossa jornada mais simples eu coloquei abaixo as falácias e as estratégias comumente adotadas para resolvê-las.

Tem bastante coisa nessa imagem, não é mesmo!?

Agora imagine que você está desenhando uma solução baseada em microsserviços e precisa mitigar cada uma dessas falácias para evitar os problemas que elas acarretam.

Acredito que de imediato você pensaria em algum pacote ou módulo de terceiro para prover cada uma dessas capacidades individualmente em seus artefatos.

Confesso que eu faria o mesmo, mas caímos num dilema: A aplicação deve mesmo conhecer e se responsabilizar pela infraestrutura? 🤔

Lembrar e viver, vamos retomar as capacidades fundamentais de um microsserviço.

Capacidades Fundamentais: São funcionalidades inerentes e imprescindíveis para o correto funcionamento da solução, sem as quais não há meios para escalabilidade e sustentabilidade.

Por mais tentador que seja, fornecer esses recursos por meio da própria aplicação pode ser algo extremamente problemático e difícil de manter.

É nesse momento que entra o service mesh Istio.

Uma malha de serviço (service mesh) é uma camada de infraestrutura dedicada para lidar com a comunicação serviço a serviço. É responsável pela entrega confiável de solicitações por meio da topologia complexa de serviços que inclui um aplicativo nativo da nuvem moderno.

Na prática, a malha de serviço é normalmente implementada como uma matriz de proxies de rede leves que são implantados juntamente com o código do aplicativo, sem que o aplicativo precise estar ciente.

Tradução livre de https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/

O Istio fornece monitoramento de tráfego, controle de acesso, descoberta, segurança, resiliência além de outros recursos úteis para um grupo de serviços.

Tudo isso é feito sem nenhuma exigência de alteração no código.

Para que essa mágica aconteça, o Istio insere um proxy (sidecar container) ao lado de cada microsserviço.

Todo o tráfego na malha vai para o proxy, que usa as políticas para decidir como, quando e se esse tráfego deve seguir para o serviço em questão.

O Istio também permite técnicas sofisticadas de DevOps, como Canary Deployment, circuit breakers, fault injection e muito mais.

Istio, Docker e Kubernetes

A mesh do Istio é uma implementação adicional de recursos e funções que são necessárias ao criar e gerenciar microsserviços.

Monitoring, tracing, circuit breakers, routing, load balancing, fault injection, retries, timeouts, mirroring, access control, rate limiting, e muito mais, todos esse recursos são parte da malha de serviços.

Embora você possa adicionar os recursos e funções do parágrafo anterior usando diversas bibliotecas, o que diferencia o Istio é a capacidade de obter esses benefícios sem alterações no código.

O Istio usa o modelo de sidecar (amplamente adotado por outros services mesh) que é executado em um container dentro dos pods do Kubernetes, ele injeta e extrai recursos e informações com base nas suas configurações.

Esta é a sua configuração, fora do seu código. Isso reduz imediatamente a complexidade e o peso do código-fonte.

Como as configurações da malha estão fora das aplicações, afastamos os aspectos operacionais do desenvolvimento de código.

Por que um engenheiro de software deveria se preocupar com circuit breaking e fault injection? O time de desenvolvimento deve se concentrar no domínio de negócio.

O Istio consegue fazer tudo isso em função da sua arquitetura de controle e comando, composta por dois grandes componentes: Data Plane e o Control Plane.

O Data Plane é composto por um grupo de proxies (sidecars containers que utilizam o Envoy como implementação). Esses proxies fazem a mediação e controlam toda a comunicação de rede entre os microsserviços.

Eles também coletam dados de todo o tráfego da malha para telemetria.

O Control Plane gerencia e configura todos os proxies para rotear o tráfego.

Istio é caro?

Sinceramente não, o Istio é extremamente rápido, isso porque a solução está escrita em Go e adiciona uma sobrecarga ínfima ao seu sistema.

Além disso, qualquer perda de desempenho ou pequeno aumento de latência deve ser pago pelo aumento da eficiência e pelo ganho de velocidade para os desenvolvedores.

É possível alguma variação nessas questões, afinal de contas cada negócio tem suas particularidades.

Não ignore o fato de que desenvolvedores de software são caros.

O Istio é open-source, sinta-se a vontade para consultar o código fonte antes de começar a usá-lo.

Conclusão

Na Juntos Somos Mais temos alguns microsserviços fazendo coisas bem interessantes e outros novos sendo criados com certa frequência, estamos amadurecendo aos poucos e tentando consolidar todo esse conhecimento em práticas sustentáveis para o negócio.

No momento em que escrevo este artigo não temos Istio em produção, porém já estamos com uma POC em vias de ser iniciada (em outro ambiente, é claro).

Estamos muito empolgados com a solução e com os ganhos que ela proporciona, assim que tudo passar, escreverei um outro artigo falando sobre a nossa experiência durante o processo.

Tive o privilégio de conduzir uma Tech Talk sobre Istio promovida pela Juntos, ficou muito legal, você está mais do que convidado a assistir no YouTube e a se inscrever no canal.

Um grande abraço e até o próximo artigo.

1. Microsserviços: Monitoramento e Solução de Problemas com Istio (Service Mesh)