Microsserviços: patterns de implantação

No artigo “Microsserviços: Implantando”, apresentamos os principais conceitos referentes à implantação de microsserviços. Abordamos aspectos como disponibilidade, confiabilidade, escalabilidade e independência, verificamos as características do ambiente de produção de uma aplicação baseada em microsserviços e também apresentamos a necessidade de padronizar o empacotamento de cada microsserviço. Neste post, vamos tratar da implantação propriamente dita, apresentando microsserviços patterns de implantação,  no que diz respeito aos recursos utilizados (instâncias e hosts) e também à frequência da implantação.

Microsserviços patterns: instâncias e servidores

Existem alguns patterns para implantação de serviços que podem ser usados no contexto de microsserviços, dentre os quais destacamos: múltiplas instâncias do microsserviço por servidor, uma única instância do microsserviço por Máquina Virtual (VM) e uma única instância do microsserviço por Contêiner.

Antes de percorrermos cada um desses patterns, vamos ressaltar alguns requisitos que devem ser satisfeitos na implantação dos microsserviços:

• Os microsserviços devem ser implantados e “removidos” independentemente;
  
  
• O processo de criar e implantar os microsserviços deve ser realizado de forma rápida, confiável e econômica;
  
  
• Deve ser possível escalar cada microsserviço de maneira independente, pois um determinado microsserviço pode ter mais demanda que outros;
  
  
• Uma falha em um microsserviço não deve afetar os demais microsserviços.

É importante lembrar também que uma aplicação baseada em microsserviços pode possuir centenas de serviços que podem ter sido desenvolvidos em diferentes linguagens e frameworks. Muitos dos serviços podem precisar executar várias instâncias para atender à demanda em um determinado momento. Diante dessa realidade, alguns desafios precisam ser superados quando consideramos a implantação de microsserviços como, por exemplo, manter a estabilidade e a disponibilidade da aplicação, ao mesmo tempo em que são liberadas novas versões e alterações de microsserviços ou APIs, assim como a remoção de outros microsserviços.

Feitas essas considerações, vamos partir para analisar os patterns de implantação que citamos anteriormente.

Múltiplas instâncias do microsserviço por servidor

Podemos dizer que esse é o método mais tradicional de implantação de uma aplicação monolítica e podemos usá-la para os microsserviços, onde uma ou várias instâncias do microsserviço executam em um único servidor. Essas várias instâncias do microsserviço podem ser executadas no mesmo processo ou em um grupo de processos diferentes. Obviamente, como toda solução, ela tem suas vantagens e desvantagens. Vejamos:

Vantagens: 

• O uso dos recursos é relativamente eficiente, uma vez que as instâncias compartilham o mesmo servidor e o mesmo sistema operacional.
  
  
• A implantação de uma instância do serviço é relativamente rápida, uma vez que basta copiá-lo para o servidor e iniciá-lo.

Desvantagens:

• As instâncias têm pouco ou nenhum isolamento entre si e não existe uma maneira de limitar os recursos que cada uma utiliza. É possível, por exemplo, que uma instância utilize muita CPU ou aloque uma grande quantidade de memória do servidor durante sua execução, reduzindo os recursos disponíveis para as demais instâncias.
  
  
• A equipe que faz a implantação dos microsserviços precisa conhecer os detalhes técnicos de como fazê-la. Se lembrarmos que os microsserviços podem usar diferentes tecnologias, a complexidade e o risco de erros nesse processo podem aumentar consideravelmente.

Microsserviços patterns: uma única instância do microsserviço por Máquina Virtual (VM) 

Nessa abordagem, cada microsserviço é empacotado como uma imagem de uma máquina virtual (VM) e cada instância é iniciada utilizando essa imagem.

Vantagens:

• Cada instância do microsserviço executa de forma isolada, com uma quantidade definida de CPU e memória. Desta forma, as instâncias não podem utilizar os recursos destinados às demais.
  
  
• A máquina virtual encapsula os detalhes técnicos do microsserviço e a implantação é mais simples e confiável.
  
  
• A API da máquina virtual serve como a API do microsserviço.
  
  
• É possível usar a infraestrutura de nuvem para a implantação das instâncias e, assim, se beneficiar de funcionalidades como load balancing e autoscaling.

Desvantagens:

• A utilização dos recursos não é eficiente, já que cada instância do microsserviço utiliza uma máquina virtual completa (incluindo o sistema operacional).
  
  
• A implantação de uma nova instância do microsserviço é lenta, especialmente devido ao tamanho da imagem da máquina virtual que deve ser criada para cada uma das instâncias.

Microsserviços patterns: uma única instância do microsserviço por Contêiner

Primeiramente, vamos entender o que é um contêiner:

“Os containers proporcionam uma maneira padrão de empacotar código, configurações e dependências de seu aplicativo em um único objeto. Suas várias instâncias compartilham o sistema operacional instalado no servidor e são executados como processos isolados. Isso permite fazer implantações rápidas, confiáveis e consistentes, independentemente do ambiente.”

Descrição da AWS

De certa forma, os contêineres se comportam como máquinas virtuais. Entretanto, os contêineres não precisam replicar o sistema operacional inteiro, mas apenas os componentes individuais de que precisam para operar, proporcionando assim, um aumento significativo no desempenho e uma redução no tamanho do aplicativo. Além disso, eles não precisam alocar previamente os recursos necessários para sua execução, como memória, o que permite um compartilhamento dinâmico dos recursos disponíveis. Inclusive, é possível limitar quantidade de memória e CPU que cada instância de um determinado contêiner pode utilizar.

Dentre os softwares que implementam a tecnologia de contêineres o Docker é, atualmente, o mais popular por larga margem, mas há alternativas como o LXD, o Windows Container e o Linux VServer.

No modelo de uso de contêineres para implantar microsserviços, cada um executa em seu próprio contêiner. Assim, cada microsserviço é empacotado em uma imagem de contêiner independente. A partir daí, instanciar um microsserviço equivale a instanciar um contêiner, e é comum utilizar orquestradores de contêineres, como o Kubernetes, para gerenciá-los. O uso de um orquestrador desse tipo também facilita localizar as instâncias de cada microsserviço de acordo com os recursos necessários para executá-los, além de permitir o agrupamento ou distribuição de acordo com a estratégia de limitação de impactos em caso de falhas (zonas de falhas).

Vantagens:

• O contêiner é uma tecnologia leve, e é rápido e fácil criar imagens inicializar;
  
  
• Isola as instâncias dos microsserviços;
  
  
• Encapsula os detalhes tecnológicos de implementação específicos de cada microsserviço;
  
  
• A API do contêiner serve como a API do microsserviço.

Desvantagens:

• Alguns questionam sua segurança, pois compartilha o sistema operacional do servidor com os demais contêineres.
  
  
• Idealmente deve-se adotar um orquestrador de contêineres, como o Kubernetes, ou utilizar algum recurso disponível na infraestrutura de nuvem, como o Google Container Engine, Azure Kubernetes Services ou Elastic Kubernetes Services (AWS).

Essa última abordagem tem sido o pattern preferido para a implantação de microsserviços e muitas ferramentas estão disponíveis para automatizar as tarefas envolvidas.

Além de escolher a estratégia de implantação dos microsserviços, precisamos garantir a entrega contínua, que é uma das principais características das aplicações baseadas em microsserviços. 

Microsserviços patterns: entrega Contínua

A ideia por trás do conceito de entrega contínua é colocar o software em produção de forma segura e confiável e com muita frequência (possivelmente várias vezes ao dia). Para que isso seja possível, certamente será necessário automatizar o processo de testes recorrentes, de homologação e de implantação em produção. 

Na entrega contínua (ou implantação contínua) os ciclos de desenvolvimento de software são muito mais rápidos e cada atualização tem um tamanho reduzido, o que implica em um risco muito menor para a estabilidade do sistema. Além disso, testar cada mudança fica muito mais fácil e, em caso de falha, identificar o erro e reverter o código para a versão anterior também pode ser feito com mais rapidez. Ao realizar pequenas alterações de funcionalidades, os testes a serem realizados também são menores e, portanto, mais fáceis de serem adicionados ao processo automáticos de testes. Do ponto de vista dos desenvolvedores, testes e feedback contínuos ajudam a equipe a avançar na evolução do software. Em termos de negócios, isso significa que a empresa pode evoluir seus processos mais rapidamente, o que proporciona uma vantagem competitiva importante.

Para que seja possível executar uma nova versão de uma aplicação baseada em microsserviços sem que seja necessário derrubar a versão anterior, garantindo que a aplicação nunca fica fora do ar (zero downtime) para uma nova implantação, algumas estratégias são possíveis:

• Rolling: consiste em subir progressivamente os serviços em uma nova versão e, assim, substituir aos poucos a versão antiga do serviço. Desta forma, a versão antiga só é desativada quando a nova está totalmente funcional.
  
  

• Canário: consiste em adicionar uma nova instância do serviço para testar a confiabilidade da nova versão, antes de prosseguir para a substituição total da versão. Esta instância convive com as instâncias da versão anterior e ambas ficam disponíveis para utilização durante o período de avaliação. Eventualmente, algumas requisições de clientes podem ser roteadas diretamente para a instância que está rodando essa nova versão a fim de garantir que ela esteja funcionando corretamente. Uma vez comprovada sua correta execução, parte-se para a estratégia de Rolling, substituindo gradativamente as instâncias da versão antiga pela nova.
  
  

• Azul-verde: consiste em introduzir um ambiente paralelo (verde) com a nova versão do software e, uma vez que tudo é testado e está pronto para começar a operar, progressivamente todo o tráfego de usuários é redirecionado do ambiente atual (azul) para o novo ambiente (verde).

A escolha pelas estratégias canário ou azul-verde reduzem o impacto que possa surgir decorrente de defeitos na nova versão na disponibilidade da aplicação. Desta forma, são mais adequadas para aplicações baseadas em microsserviços.