Diego Dantas, gerente de desenvolvimento no pag! Foto: Vinícius Caus.
Os avanços técnicos em todos os aspectos do ciclo de vida de desenvolvimento de software deixam claro que existe mais de uma solução para qualquer problema. Neste artigo, irei abordar problemas que os desenvolvedores enfrentam nos dias de hoje.
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 o 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; e 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 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 de controle, como mostra a figura acima.
O fato de o framework funcionar em containers permite que ele dê e 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 ficam centralizadas e não mais espalhadas 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!
*Por Diego Dantas, gerente de desenvolvimento no pag!.