Arquiteturas de microsserviços versus monolíticas

O que é uma arquitetura monolítica?

Primeiramente, vamos comparar a arquitetura de microsserviços e a monolítica. Um aplicativo monolítico é desenvolvido como unidade única. Aplicativos corporativos são desenvolvidos em três partes:

• Um banco de dados — composto de várias tabelas, normalmente em um sistema de gerenciamento de bandos de dados relacional
• Uma interface de usuário do lado do cliente — que consiste de páginas HTML e/ou JavaScript em execução em um navegador
• Um aplicativo do lado do servidor — que vai tratar das solicitações HTTP, executar a lógica específica do domínio, recuperar e atualizar dados do banco de dados e preencher as visões HTML que serão enviadas ao navegador.

Isso é o que caracteriza uma arquitetura monolítica — é um executável lógico único. Para fazer alterações no sistema, um desenvolvedor precisa criar e implementar uma versão atualizada do aplicativo no lado do servidor.

O que é uma arquitetura de microsserviços?

Ao contrário de uma arquitetura monolítica, os recursos de microsserviços são expressos formalmente com APIs orientadas por negócios. Elas encapsulam um recurso corporativo essencial e a implementação do serviço — que pode envolver integrações com sistemas de registro — é completamente ocultada, pois a interface é definida puramente em termos de negócios.

Por serem considerados ativos valiosos para os negócios, os serviços são considerados implicitamente como adaptáveis para uso em vários contextos. O mesmo serviço pode ser reutilizado em mais de um processo corporativo, em diferentes canais de negócios ou pontos de contato digitais.

As dependências entre os serviços e respectivos consumidores diminuem com a aplicação do princípio de acoplamento flexível. Ao padronizar os contratos, conforme expresso pelas APIs orientadas por negócios, os consumidores não são afetados por mudanças na implementação dos serviços. Isso permite que seus proprietários alterem a implementação e modifiquem os sistemas de registro ou até mesmo as composições dos serviços — que estejam por trás da interface e os substituam sem nenhum impacto posterior.

Em que os processos de desenvolvimento de software da arquitetura de microsserviços são diferentes daqueles da arquitetura monolítica

Os processos tradicionais de desenvolvimento de software (cascata, ágil etc.) geralmente resultam em equipes relativamente grandes que trabalham em um único artefato de implementação monolítico. Gerentes de projeto, desenvolvedores e a equipe operacional podem alcançar graus variados de sucesso com esses modelos, liberando os aplicativos candidatos para verificação pela empresa, principalmente à medida que ela ganha experiência no uso de um software e de uma pilha de implementação específicos. No entanto, há alguns problemas à espreita nas abordagens tradicionais:

• Aplicativos monolíticos podem levar a uma situação em que nenhum desenvolvedor (ou grupo de desenvolvedores) entende o aplicativo na totalidade
• A reutilização limitada é realizada em aplicativos monolíticos
• O dimensionamento de aplicativos monolíticos pode ser um desafio
• É difícil alcançar rapidez operacional na implementação repetida de artefatos de aplicativos monolíticos.
• Por definição, os aplicativos monolíticos são implementados com o uso de uma pilha única de desenvolvimento, como JEE ou .NET, o que pode limitar a disponibilidade da "ferramenta certa para o trabalho".

Uma arquitetura de microsserviços — combinada com tecnologias de implementação em nuvem, API Management e tecnologias de integração — oferece uma abordagem diferente ao desenvolvimento de software. Em vez disso, o monólito é "dividido" em um conjunto de serviços independentes que são desenvolvidos, implementados e mantidos separadamente. Isso tem as seguintes vantagens:

• Há um incentivo para que os serviços sejam pequenos. O ideal é que sejam criados por um grupo pequeno de desenvolvedores.
• Os serviços podem ser consumidos e reutilizados por outros serviços e aplicativos sem conexão direta, por meio de associações de linguagem ou bibliotecas compartilhadas.
• Os serviços existem como artefatos de implementação independentes e podem ser dimensionados independentemente de outros serviços.
• Serviços desenvolvidos em separado permitem que os desenvolvedores usem a estrutura de desenvolvimento apropriada para a tarefa em questão.

Desvantagens da arquitetura de microsserviços e da arquitetura monolítica

A desvantagem dessa flexibilidade é a complexidade. O gerenciamento de uma infinidade de serviços distribuídos em escala é difícil por duas razões principais:

1. As equipes de projeto precisam descobrir facilmente quais serviços são possíveis candidatos à reutilização. Esses serviços devem fornecer documentação, consoles de teste etc., para que a reutilização seja consideravelmente mais fácil do que a criação do zero
2. As interdependências entre serviços precisam ser monitoradas com atenção. Downtime, interrupções e atualizações de serviços, entre outros, podem ter um efeito cascata, e esse impacto deve ser analisado proativamente

É importante que você se certifique de que a entrega de microsserviços seja cuidadosamente gerenciada e que o nível de automação do SDLC seja o mais alto possível. A falta de coordenação e automação da equipe nos moldes do DevOps pode levar sua iniciativa de microsserviços a trazer mais desvantagens do que benefícios.

Práticas recomendadas para a criação de microsserviços

Está pronto para começar a trabalhar com microsserviços? Leia nosso Guia sobre as práticas recomendadas para a criação de microsserviços.