A busca por novas tecnologias e práticas que auxiliem no desenvolvimento, correções, atualizações e bugs de um sistema, já é uma tarefa comum no dia a dia das equipes de tecnologia que trabalham com desenvolvimento de software ou aplicativos. Os frameworks existem justamente para isso, já que eles permitem a resolução de problemas recorrentes com uma abordagem genérica. Então, você pode optar pela utilização dos microsserviços framework reutilizável, que nada mais são do que uma padronização de elementos para a construção de aplicações em uma arquitetura de microsserviços.
Desenvolver um software utilizando a arquitetura de microsserviços significa dividir os componentes em “micro” serviços, que são construídos de forma independente, autônoma e com baixo acoplamento, em vez de optar pelo desenvolvimento de um monolito, que concentra todos os componentes em um único lugar.
A utilização dos microsserviços framework (que, normalmente, é baseado em Microservice Chassis Pattern) permite que os desenvolvedores não precisem reescrever o software toda vez que for necessário resolver algum problema. Pensando nisso, nós vamos falar nesse post sobre as principais vantagens de se utilizar um framework reutilizável para a construção de microsserviços, padronizando elementos comuns a todos eles, sem perder a liberdade que cada equipe possui de escolher a melhor tecnologia a ser utilizada durante o desenvolvimento.
- Microsserviços framework: por que utilizar?
- Benefícios
- Pattern Microservice Chassis
- Microsserviços framework: Service Mesh
Microsserviços framework: por que utilizar?
Conforme as empresas e as equipes de tecnologia vão crescendo e se desenvolvendo é comum que cada time escolha as ferramentas e a linguagem de programação a ser utilizada.
A tendência é que isso aumente a produtividade dos colaboradores do time, a medida em que eles ganham experiência e aprofundam seu conhecimento na tecnologia escolhida. Entretanto, isso também pode criar alguns vícios, ou até mesmo, uma certa barreira para a rotatividade de membros entre as equipes.
Outra questão importante a ser considerada é o fato de que pode ocorrer uma duplicação de trabalho, na qual equipes acabam resolvendo os mesmos problemas, de formas diferentes e com tecnologias diferentes. Sendo que, claro, esses esforços poderiam ter sido direcionados para outras questões ainda não resolvidas.
Entretanto, mesmo diante dessas dificuldades e possíveis duplicações de trabalho, ainda é melhor manter a liberdade de escolha do que definir regras rígidas para todas as equipes.
Afinal, uma das características da arquitetura de microsserviços é possibilidade de construir cada microsserviço de forma independente do restante da aplicação, o que proporciona uma maior liberdade de escolha com relação a tecnologia e as tecnologias que serão utilizadas, incluindo os mecanismos de persistência de dados.
Portanto, essa limitação acabaria ferindo os princípios dos microsserviços, o que poderia comprometer também a qualidade e a agilidade na criação e implantação das aplicações.
Uma possível solução para esse dilema seria adotar um framework (chassis) que seja capaz de tratar das questões gerais dos microsserviços, que sejam comuns a todas as tecnologias, como logging e health checking. Assim, as equipes podem continuar com suas escolhas de forma independente, mantendo o alinhamento por meio de ferramentas que disponibilizam a infraestrutura ideal para execução dos microsserviços.
Essa padronização diminui a redundância do sistema, abstraindo essa lógica comum em uma outra camada de implementação. Além disso, as questões referentes à conectividade, configuração e monitoramento da aplicação podem ser transferidas para esse framework.
>>Leitura recomendada: Migrando de Monolitos para Microsserviços
Benefícios
A adoção horizontal de um framework comum traz muitos benefícios para a organização e para as equipes de desenvolvimento e tecnologia.
Até mesmo porque, embora a arquitetura de microsserviços permita que as equipes escolham tecnologias distintas, na maioria dos casos, é comum que se utilize um número relativamente reduzido. Portanto, o compartilhamento de soluções prontas, bibliotecas e experiência pode representar um grande ganho para as equipes.
O microsserviços precisam ser criados com agilidade e de forma contínua. Para atender a essa necessidade, você pode utilizar uma estrutura básica, com um conjunto de ferramentas previamente aprovadas para cada linguagem utilizada na organização, que vão facilitar a construção dos microsserviços, aumentando as possibilidades de colocá-los em execução com mais rapidez.
Essa é uma forma de introduzir melhores práticas no dia a dia das equipes e ao mesmo tempo facilitar a rápida prototipação. Isso também garante que os esforços sejam destinados para a construção da lógica de negócio das aplicações, o que reduz o tempo gasto com a funcionalidade, infraestrutura e gerenciamento dos microsserviços em si.
Com a criação desse chassi, ou framework de microsserviço, você consegue respeitar as características dos microsserviços e ainda conquistar todos os benefícios que mencionamos acima.
Além disso, caso você encontre alguma vulnerabilidade em uma biblioteca, a atualização poderá ser realizada em um único ponto e ficará disponível para todos.
>>Leitura recomendada: Flutter: saiba tudo sobre esse novo framework
Pattern Microservice Chassis
O propósito de um microservice chassis pattern (que nada mais é do que um chassi compartilhado por vários microsserviço) é facilitar a criação de novos microsserviços. Ao mesmo tempo, ele fornece um conjunto de padrões que devem ser respeitados por todos os colaboradores envolvidos no projeto, independente da equipe a qual cada um pertence.
Eles facilitam:
- A entrada de novos membros nas equipes;
- Entendimento do código;
- Troca de experiências;
- Criação de um vocabulário em comum.
Isso também vai acabar refletindo na gestão de tempo dos projetos. Pensando na construção de um monolito, é comum gastar um ou dois dias, as vezes até mais, para organizar os mecanismos, garantindo que eles não afetem as particularidades de cada aplicação. Entretanto, a situação muda quando estamos falando de microsserviços.
Uma aplicação desenvolvida em microsserviços já possui uma dezena, ou mesmo uma centena de serviços e sempre vai ser possível adicionar mais serviços, que levarão apenas dias, ou no máximo semanas, para serem desenvolvidos. Ou seja, se você colocar na ponta do lápis verá que não vale a pena perder aqueles dias iniciais de organização, então pode optar pela utilização de um microservice chassi pattern.
Como você pode acompanhar na figura abaixo, algumas das funcionalidades que devem estar presentes nesse chassis são:
- Logging;
- Health checking;
- Tratamento de exceções;
- Autenticação;
- Registro;
- Descoberta de serviços;
- Métricas;
- Padrão de transporte de mensagens;
- Setup para bases de dados;
- Facilidades para instanciar novos microsserviços.
Outros aspectos como observabilidade, relatório de erros, balanceamento de carga e rate limiting também podem ser implementadas no seu microservice chassi pattern.
Figura 1: Microservice chassis compartilhado por vários serviços
O pattern microservice chassis também contribui para minimizar os riscos envolvidos na criação de novos microsserviços. Isso porque, ele oferece um conjunto de padrões e funcionalidades já testadas, aprovadas e em produção, incluindo combinações de linguagens e bibliotecas principais.
O trabalho envolvido em criar, manter e atualizar um microservice chassis pattern é capaz de trazer um enorme retorno para a organização, porque gera um setup correto, testado e reutilizável. Isso evita que você e sua equipe precisem gastar tempo na adequação dos serviços ao ambiente de execução, repetindo essa ação cada vez que um novo microsserviço for criado.
Entretanto, apesar de todos os benefícios que já mencionamos acima, é importante ter em mente que a adoção de um microservice chassi pattern, pode ser um obstáculo para a adoção de novas linguagens ou frameworks, justamente porque é necessário criar uma adaptação ao chassi para cada linguagem utilizada na organização. Por isso, é importante ter esse equilíbrio entre momentos de otimização e inovação nos projetos da empresa.
Existem vários frameworks para microservice chassi pattern disponíveis para utilização, como Spring Boot, Spring Cloud e Dropwizard.
Utilização do pattern microservice chassis
O pattern microservice chassis é uma forma de abstrair a implementação de algumas questões relacionadas à infraestrutura, uma vez que ele fornece mecanismos para uma rápida criação e inicialização dos microsserviços e também auxilia no compartilhamento de experiências entre as equipes.
Naturalmente, o chassi precisa ser mantido em constante evolução, a medida em que incorpora novas soluções encontradas pelas equipes, além de incluir as práticas e experiências que foram obtidas pela organização.
Por fim, cabe observar que muitas aspectos de resiliência dos microsserviços e comunicação entre eles normalmente estará isolada na camada de Service Mesh, não fazendo parte da funcionalidade de um chassis de microsserviços.
>>Leitura recomendada: Service Mesh para Microsserviços
Microsserviços framework: Service Mesh
Um dos maiores desafios do desenvolvimento dos microsserviços não é a construção deles em si, mas sim a comunicação entre esses serviços.
Já que a maioria dos requisitos de comunicação entre serviços é bastante genérica em implementações, é interessante pensar em transferir todas essas tarefas para uma camada diferente, para que seja possível manter o código do serviço independente. É aí que entra a service mesh, que nada mais é do que uma infraestrutura de comunicação entre serviços.
Assim, todas as comunicações serviço-a-serviço acontecerão por meio de um componente da service mesh, que fornece suporte integrado para algumas funções de rede, como resiliência, descoberta de serviços, etc.
Portanto, os desenvolvedores de serviços podem se concentrar mais na lógica do negócio, enquanto a maior parte do trabalho relacionado à comunicação de rede é transferida para a service mesh.
Não existe uma regra rigorosa sobre quais funcionalidades devem ser oferecidas por uma service mesh. Porém, os recursos mais comumente oferecidos são:
- Resiliência para comunicações entre serviços: Circuit breaking, retries e timeouts, injeção de falhas, gerenciamento de falhas, balanceamento de carga e failover;
- Descoberta de Serviço: Descoberta de endpoints de serviço por meio de um mecanismo de registro de serviço dedicado;
- Roteamento: Recursos primitivos de roteamento, mas nenhuma lógica de roteamento relacionada à funcionalidade do negócio do serviço;
- Observabilidade: métricas, monitoramento, logging distribuído, rastreamento distribuído;
- Segurança: Segurança no nível de transporte (TLS) e gerenciamento de chaves;
- Controle de acesso: controle de acesso baseado em blacklist e whitelist;
- Implantação: suporte nativo para contêineres. Docker e Kubernetes;
- Protocolos de comunicação entre serviços: HTTP1.x, HTTP2, gRPC.
