Dominar arquiteturas orientadas a microsserviços não é simples. Ao contrário das construções monolíticas, esse tipo de abordagem desmembra funcionalidades de negócio em componentes atômicos e independentes, o que traz uma série de novos desafios para o dia a dia dos arquitetos, desenvolvedores e operadores. Questões como confiabilidade, flexibilidade, resiliência e tolerância a falhas de redes, antes tratadas como de responsabilidade da infraestrutura, passam a ser fundamentais para o funcionamento de tudo.

A adoção de uma arquitetura mais distribuída, onde cada vez mais o escopo funcional dos microsserviços diminui e permite uma maior agilidade, traz novas questões. As aplicações não rodam mais dentro de um mesmo processo ou em uma mesma máquina. Estão subdivididas em várias localidades, e, possivelmente, em servidores do outro lado do hemisfério. Esse fenômeno também é muito influenciado pela necessidade de adoção de uma capacidade computacional superior, como “cloud computing”. O estilo arquitetural de microsserviços exige ainda que as aplicações se tornem flexíveis, justamente para que possam ser migradas para diferentes localidades, independente de onde esteja a necessidade. Diferentes clouds (pública, privada ou híbrida) e, mais recentemente, edge computing deixam esta dependência ainda mais evidente.

Por outro lado, as mudanças obrigaram developers a se adaptar a uma nova realidade. Os times tiveram que se tornar mais ágeis, com profissionais poliglotas, aptos a atender as peculiaridades do negócio. Mais e mais linguagens de programação surgem dia após dia a fim de otimizar o processamento, o consumo de recursos computacionais e a produtividade, o que se tornou um diferencial entre as empresas. Ao mesmo tempo, trouxe um obstáculo para o dia a dia: tratar de forma homogênea e padronizada as comunicações entre os diferentes componentes da arquitetura.

Além disso, componentes criados com os microsserviços precisavam de uma arquitetura distribuída, por exemplo, para suportar escalabilidade horizontal, para atender públicos mais regionalizados e para disponibilizar níveis de serviço aceitáveis (MTTR, MTBF, por exemplo). Cada componente tem seu próprio ciclo de vida, que pode sofrer uma migração, ser subdividido ou até mesmo reescrito para fins de experimentação. Situações que exigem cuidados para não causar perdas no processo para o negócio.

Diante desta problemática surgiu mais um componente nativo cloud que gerencia o que chamamos de malha, antes invisível e de difícil controle que envolve as comunicações entre os microsserviços, a malha de serviços. Com ele, arquiteturas distribuídas podem ser implementadas de maneira mais inteligente, aumentando drasticamente a visibilidade, a segurança e o gerenciamento dessa malha. Isso simplifica ainda mais o trabalho de arquitetos, desenvolvedores e operadores na tentativa de domar este ecossistema vivo, imprevisível e muitas vezes caótico.