Na parte 01 deste artigo discutimos a arquitetura baseada em microservices. Foram apresentados os problemas encontrados em grandes projetos sob a perspectiva da complexidade e da inovação. Também foi apresentado o conceito de microservices e como microservices trata as dificuldades encontradas em grandes projetos.

Na parte 02, iremos tratar as vantagens e as limitações da arquitetura baseada em microservices.

3) As vantagens da abordagem de microservices

Complexidade

Escalabilidade e confiabilidade

A restrição de tamanho dos casos de uso de um sistema permite o conhecimento de todos os comportamentos de maneira mais detalhada.

O débito técnico é mantido sob controle, permitindo a evolução do software. A comunicação feita através de serviços com outras áreas formaliza as integrações.

Os contratos de interface são menores e permitem, de maneira mais simples, considerar todos os casos, inclusive casos de erro.

Escalabilidade horizontal

Com aplicações de tamanho limitado é mais fácil escalá-las. Mesmo que isso necessite de uma refatoração no código ou até mesmo uma reescrita.

Inovação

Inovação tecnológica

As bases de código e os times tornam-se independentes, o que permite escolhas técnicas de acordo com uma necessidade específica.

Inovação de negócio

Considerando que os sistemas são estruturados em serviços, é mais fácil começar um novo projeto e reutilizar os serviços conforme necessário. Caso o projeto não dê certo, é possível removê-lo sem afetar os serviços existentes.

4) Limitações e requisitos

Se a arquitetura de microservices tem muitas vantagens, pode-se dizer que tem-se também muitos pré-requisitos e algumas limitações

Como microservices são uma variação do SOA, tem-se as mesmas características, porém com um nível adicional de criticidade.

O sistema torna-se distribuído

As arquiteturas convencionais permitem garantir diferentes estados entre diferentes aplicações: cada uma é mestre de seu negócio.

Quando tem-se a arquitetura de microservices, os sistemas tornam-se amplamente distribuído. O que traz novas questões a serem consideradas.

O caso mais complicado está relacionado a transações: sempre que uma transação é compartilhada entre duas aplicações, deve-se gerenciá-las em duas fases ou gerenciar o cancelamento. Em sistemas baseado em serviços, atualmente, não há ferramentas que auxiliem nessa tarefa. O controle de transação deve ser feito manualmente.

Mesmo quando não há transação envolvida, tem-se comumente a referência a dados de outras aplicações. Consequentemente, há a necessidade da gestão de eventos assíncronos ou de uma estratégia de cache para garantir a consistência dos dados.

Também tem-se o caso da indisponibilidade de serviços externos. Usar os serviços de outras aplicações significa criar uma dependência com a outra aplicação. A aplicação do design voltado a falhas ajuda a controlar estes riscos, mas requer rigor técnico.

É, também, importante gerenciar os SLAs para diferentes aplicações.

Eventualmente, o sistema torna-se difícil de testar. Os testes de integração aumentam e necessitam de uma maior cuidado no preparo dos dados e cenários de erros técnicos e de negócio.

Serviços de valor agregado

Apesar de a abordagem REST propor serviços simples, há sempre um conjunto de serviços que envolvem múltiplas áreas de negócio.

Com relação ao microservices, isso significa chamadas entre diversas aplicações.

O que leva a um conjunto muito maior de casos de uso para gerenciar (problema de sistemas distribuído) e adiciona latência de rede.

Em muitos casos, isso leva a criação de novos serviços, específicos a uma necessidade, em diferentes aplicações ou adicionar cache.

Evoluções transversais

Com projetos separados e times independentes, torna-se mais difícil implementar evoluções transversais.

Isto leva a sincronização de diferentes grupos ou ao estabelecimento de um sistema de controle de ciclo de vida complexo.

Esse problema piora quando tem-se iterações curtas, pois requer a sincronização de todos a todo momento.

Para manter a flexibilidade, é natural isolar clusters de outros projetos e limitar a interconexão entre esses grupos . O risco é adição de um nó intermediário não diretamente ligado aos projetos.

Projetos agrupados e serviços específicos para integração de grupos.

DevOps e provisionamento

Múltiplas aplicações levam a múltiplos deploys.

Afim de evitar erros e custos excessivos, é necessário um processo muito eficiente e boas ferramentas, que permitam o maior grau de automação possível. Essa automação é ainda mais necessária em casos de testes ou provas de conceito, nos quais ambientes temporários são necessários.

Início de projeto e alocação de pessoas

Escolher as pessoas, alocá-las, estabelecer o orçamento, etc…: em empresas mais "tradicionais" criar um projeto requer tempo e dinheiro.

Como forma de ter múltiplo projetos, cada um tendo seu próprio ciclo de vida, faz-se necessário uma industrialização destes aspectos.

Em grandes projetos, a capacidade de produção pode ser realocada entre as diferentes partes, enquanto pequenos projetos são mais sensíveis a tais realocações. É necessário desenvolver uma capacidade de aumentar ou reduzir times de modo eficiente.

Não se trata apenas de gerenciar desenvolvedores como um pool de recursos ou movê-los entre projetos como simples profissionais, mas de ter certa flexibilidade. É preciso entender o valor de cada pessoa envolvida no projeto e estabelecer uma estratégia para gerenciar as alocações.

Monitoramento e operação

Serviços independentes requerem:

• Uma ferramenta de monitoramento de fluxo para identificar rapidamente os problemas
• Um bom nível de maturidade operacional, pois os desafios relacionados com indisponibilidades serão maiores
• Interface que mostre o estado atual dos serviços para os consumidores.

Tecnologia e manutenção

As escolhas tecnológicas se darão de maneira decentralizada, o que faz com que seja mais fácil cometer erros. O equilíbrio entre inovação e sustentabilidade torna-se mais difícil de gerenciar. Para permitir a inovação como forma de atender aos requisitos, precisa-se aceitar que erros serão cometidos.

Há ainda o risco de negligenciar boas práticas de desenvolvimento uma vez que o desafio de desenvolvimento é menor devido ao escopo mais limitado.

Finalmente, aplicações com escopo mais focados tendem a caírem em períodos de estagnação, os quais podem levar a um esquecimento por parte do time sobre a aplicação.

Estratégia e governança

Para grandes projetos relacionados a produtos de empresas, a visão estratégica é definida pela área de negócio. Há poucos parceiros e é um pouco simples avaliar demandas diferentes baseadas em seu valor para o negócio.

Com microservices, há inúmeros projetos técnicos ligados a um produto de negócio, havendo inúmeros interlocutores. Dessa forma, faz-se necessário bons mecanismos de comunicação, gestão e priorização.

Nesta parte 02 da nossa série "Microservices após o hype", apresentamos as vantagens e as limitações que uma arquitetura baseada em microservices pode trazer para as empresa sob diversas perspectivas.

Se você não leu a primeira parte desta série, pode conferi-la neste link.

A terceira parte desta série de artigos já está disponível, basta conferi-la neste link. Nela iremos discutir se precisamos mesmo de microservices e  como dar início a uma implementação ou restruturação de uma arquitetura para a arquitetura baseada em microservices.