Microsserviços: uma promessa resiliente?

No cenário atual da engenharia de software, a arquitetura de microsserviços tem sido um dos estilos arquiteturais que mais ganharam fama na comunidade. Com essa popularidade, surgem diversos argumentos em defesa de sua adoção. Algumas dessas falas seguem a linha dos tópicos abaixo:

• “Aplicações na arquitetura de microsserviços são mais performáticas”;
• “Microsserviços trazem velocidade de desenvolvimento”;
• “A arquitetura de microsserviços é resiliente”;
• “A arquitetura de microsserviços é tolerante a falhas”;
• “Microsserviços são escaláveis”;
• “Migrar de monólitos para microsserviços resolve problemas de disponibilidade”.

Ao escutar alegações como essas, o estilo de microsserviços se apresenta de forma muito atraente. Pode parecer que basta migrar uma aplicação para essa arquitetura — ou já começar seguindo esse padrão — para ter uma aplicação performática, escalável, disponível, resiliente, tolerante a falhas, segura e com alta velocidade de desenvolvimento.

Qual profissional de engenharia de software não se sentiria atraído por esse conto, não é verdade?

No entanto, será que tudo isso é verdade? Basta utilizar essa arquitetura para atingir todas essas características? Será que, apenas começando minha aplicação com dois serviços, ela será resiliente e tolerante a falhas?

De antemão, posso dizer: não, não e não. A simples adoção da arquitetura de microsserviços não transforma uma aplicação por si só.

Mesmo já tendo adiantado que essas afirmações não são verdades, gostaria de me aprofundar nessas características e na relação de cada uma com a arquitetura de microsserviços. Como são muitas, neste artigo vou me concentrar nas falas “a arquitetura de microsserviços é resiliente” e “a arquitetura de microsserviços é tolerante a falhas” — mais precisamente, na característica arquitetural de resiliência.

O que é resiliência, afinal?

Antes de entender mais sobre resiliência em microsserviços, vale entender o que é resiliência e o que significa ser resiliente. Para a física, resiliência é a propriedade que alguns corpos apresentam de retornar à forma original após terem sido submetidos a uma deformação elástica. No sentido figurado, o dicionário a define como a capacidade de se recobrar facilmente ou se adaptar à má sorte ou às mudanças.

Já no âmbito da engenharia e da arquitetura de software, a resiliência se encaixa nas capacidades técnicas das aplicações de atender aos seus requisitos de entrega, na realização de suas atividades, sem serem impactadas por alguma adversidade (interna ou externa).

Então, por que a arquitetura de microsserviços seria categorizada como resiliente e tolerante a falhas?

O argumento se apoia na comparação com arquiteturas monolíticas, em que os componentes internos estão todos agrupados em um conjunto único e sofrem de um fardo chamado acoplamento.

O acoplamento age porque diversos componentes vivem em um conjunto único, todos conectados, e partes saudáveis desse conjunto podem ser afetadas “por tabela” por partes debilitadas.

Como a arquitetura de microsserviços promove o desacoplamento entre componentes, ela seria mais resiliente e tolerante a falhas parciais do que o padrão monolítico.

Sendo assim, pode-se dizer que a arquitetura de microsserviços é realmente mais resiliente que a monolítica?

A rede cobra o seu preço

Não necessariamente. Como primeiro ponto de atenção, é válido entender que, em arquiteturas monolíticas, os componentes internos em sua maioria se comunicam em memória, de forma leve. Na arquitetura distribuída, por outro lado, os componentes geralmente se comunicam pela rede — uma comunicação mais pesada e suscetível a falhas.

As oito falácias da computação distribuída, de Peter Deutsch, trazem ótimos pontos para constatar que essa arquitetura não será resiliente por si só:

1. A rede é confiável;
2. A latência é zero;
3. A largura de banda é infinita;
4. A rede é segura;
5. A topologia nunca muda;
6. Existe apenas um administrador;
7. O custo de transporte é zero;
8. A rede é homogênea.

Essas falácias nos lembram que cada chamada entre serviços pode falhar, que o tempo de resposta pode variar, que a rede pode sofrer interrupções, que dependências externas podem estar indisponíveis — e que tudo isso deve ser previsto se queremos que nossa aplicação seja realmente resiliente.

Contudo, as falácias se concentram apenas na comunicação via rede. Mesmo que sejam implementados mecanismos para esses pontos de risco, a resiliência ainda não será atingida como característica geral da arquitetura.

Resiliente a quê?

Resiliência não se resume a um único ponto de controle, e é isso que faz com que nada seja 100% resiliente. A resiliência não depende apenas de fatores não funcionais, mas principalmente de fatores funcionais da aplicação — o que torna essa característica relativa ao que cada software se propõe a resolver.

Para diferentes serviços, a resiliência se apresenta de diferentes formas, como nos exemplos abaixo, em que cada cenário tem uma necessidade diferente:

Conclusão

Ao final, podemos perguntar novamente: a arquitetura de microsserviços, por si só, é resiliente? Posso afirmar sem dúvidas: definitivamente não.

É claro que a arquitetura de microsserviços oferece possibilidades mais promissoras para implementar resiliência do que outros estilos arquiteturais. Mas resiliência não é uma flag que se marca como verdadeira na aplicação, nem se resume a adicionar uma ferramenta que trate um único ponto de falha. É uma característica muito mais complexa, abrangente e profunda do que aparentava nas falas iniciais.

Como conselho, eu diria: investigue seu sistema e entenda o domínio para encontrar seus pontos de controle, ordene-os por prioridade e resolva-os à medida que for possível. E nunca deixe de olhar para esses pontos de controle e verificar se estão cumprindo o esperado em relação às suas responsabilidades.

Lembre-se: a arquitetura de software é feita de decisões e trade-offs, e não de promessas prontas.

Este é um tema amplo e cheio de nuances. Se você tem vivências, aprendizados ou discordâncias, me conte. Vamos aprender uns com os outros e enriquecer a discussão sobre arquitetura e resiliência.