Os avanços técnicos em todos os aspectos do ciclo de vida de desenvolvimento de software deixam claro que existe solução para qualquer problema
Ultimamente, muito tem se ouvido falar sobre microsserviços. A arquitetura baseada em microsserviços oferece muitas vantagens sobre arquiteturas monolíticas. Mas, em contrapartida, também traz, por exemplo, maior complexidade, como a manutenção de contratos, registro, descoberta, disponibilidade e segurança de acesso a serviços, capacidade de resposta e gerenciamento de transações distribuídas, entre outros.
Para quem não conhece essa arquitetura, vale a pena conferir o artigo Microservices, escrito por Martin Fowler e James Lewis e considerado o guia a ser seguido sobre o assunto, independentemente da linguagem de programação utilizada.
A arquitetura de microsserviços ganhou popularidade e evoluiu na última década, trazendo com ela vários frameworks e padrões que foram criados para superar as complexidades sem comprometer seu benefício. Um exemplo bem conhecido é a Netflix OSS, que introduziu vários frameworks como Eureka, Hystrix e Ribbon para tornar as soluções mais resilientes, sustentáveis e robustas.
Com o uso do Netflix OSS vários problemas desta arquitetura foram resolvidos. No entanto, as aplicações ficaram cada vez maiores e com mais responsabilidades. Com ele, as regras de negócio, que por sua vez já são complexas, também é preciso conhecer normas inerentes ao ambiente, como: onde está o servidor de configuração, qual código de ‘retry’ deve ser implementado para cada serviço, além de atentar para a segurança de autenticação e autorização na comunicação entre serviços. Isso ajuda a trazer um forte acoplamento entre os serviços, ferindo um dos principais princípios da arquitetura de microsserviços, que diz que os serviços devem ser independentes.
E como usufruir dos benefícios deste padrão de desenvolvimento sem trazer essas responsabilidades para as aplicações? A resposta está na adoção de um framework de ‘Service Mesh’.
O ‘Service Mesh’ é uma camada de infraestrutura configurável e de baixa latência projetada para lidar com um alto volume de comunicação entre processos. Ela é baseada na rede entre serviços de infraestrutura de aplicativos usando interfaces de programação de aplicativos (APIs) e garante que a comunicação entre serviços de infraestrutura de aplicativos seja rápida, confiável e segura, fornecendo recursos críticos, como: descoberta de serviços; balanceamento de carga; suporte a vários protocolos (HTTP2 / gRPC), tolerância à falha, escalabilidade, telemetria, rastreio distribuído e segurança (autorização e autenticação).
Impulsionado pelo o uso de containers e orquestradores de containers como kubernetes, esse ‘pattern’ está ganhando cada vez mais espaço nas empresas. Ele funciona, basicamente, com dois componentes, o painel de controle – responsável por controlar todo o fluxo das mensagens – e o sidecar, que fica acoplado à aplicação e envia todos os dados necessários para o painel de controle, como mostra a figura acima.
O fato de o framework funcionar em containers permite que ele dê suporte a várias linguagens de programação. Ao fazer uso desse ‘pattern’, o serviço não precisa mais se preocupar com assuntos inerentes ao ambiente, somente com as suas regras de negócio, tirando, assim, essa responsabilidade das mãos dos times de desenvolvimento e as entregando para os times de operações.
Além disso, a configuração da comunicação entre os serviços fica centralizada e não mai espalhada em várias aplicações. Quem se interessa sobre o assunto, pode aprender um pouco mais por meio de algumas opções ‘Open Source’ bem interessantes, como, por exemplo: Linkerd, Envoy, Istio e Conduit. As principais empresas de cloud (AWS App Mesh, Google Service Mesh e Azure Service Mesh), inclusive, também possuem suas próprias implementações baseadas nos projetos ‘Open Source’.
O objetivo, aqui, não é mostrar como usar o ‘Service Mesh’ e tampouco dizer qual deles é o mais indicado para estudar. Mas, sim, mostrar as vantagens da adoção de um framework como esse em comparação com outras opções de mercado como o Netflix OSS, que, certamente, são bem interessantes e fazem sentido em muitos casos. Como eu disse no início, claro que existe mais de uma solução para qualquer problema.
E para quem está em busca de um ambiente mais homogêneo, resiliente e com configurações centralizadas, com uma equipe de desenvolvimento mais ágil e um time de operações com maior autonomia, vale a pena considerar fortemente o uso deste ‘pattern’. Fica a dica!
*Diego Dantas é gerente de desenvolvimento no pag!
