Arquitetura de software monolítica vs microsserviços

Resumo

Esta semana voei para Gotemburgo para me encontrar com pessoas de uma grande empresa internacional de transporte marítimo, para falar sobre o desenvolvimento de software empresarial. Na reunião estavam vários especialistas e um deles perguntou-me como escolher a arquitetura de software certa (para apps grandes, complexas e de nível empresarial). Uma ótima pergunta, que merece um artigo no blogue.

Texto completo

Arquitetura de software

Quando concebes apps, não deves pensar só no aspeto e na sensação de utilização: um bom design abrange também a forma como tudo funciona em conjunto. A arquitetura de software refere-se às estruturas fundamentais de um sistema de software; cada estrutura inclui elementos, as relações entre eles e as propriedades dos elementos e das suas relações.

É análoga à arquitetura de um edifício. Depois de uma arquitetura estar definida e implementada, mudá-la fica caro. Por isso é boa ideia escolher a arquitetura de software certa antes de começares a construir.

Para apps simples a arquitetura pode ser óbvia, mas à medida que a aplicação cresce em tamanho e funcionalidade, o número de estruturas num sistema pode aumentar depressa. Isto pode acontecer ao longo do tempo, à medida que crescem as necessidades dos teus clientes. Quanto mais estruturas, mais relações entre elas, mais complexo se torna.

Lidar com um design de software complexo

Se esperas que o teu software trate de muitas coisas diferentes, é provável que tenhas de lidar com complexidade. Do ponto de vista arquitetónico, há várias abordagens para lidar com essa complexidade.

Arquitetura monolítica

A melhor descrição da arquitetura monolítica é “um grande bloco”. Aqui, tudo o que a tua app faz faz parte da mesma base de código.

Numa “arquitetura monolítica” o software é muitas vezes organizado em camadas, cada uma com diferentes tipos de componentes:

• camada de apresentação: responsável pela interface de utilizador e/ou de programação de aplicações (UI / API).
• lógica de negócio: é onde se definem as regras de negócio propriamente ditas. É o núcleo da aplicação, muito próximo dos processos reais da empresa.
• camada de acesso a objetos de dados: oferece uma interface comum entre a aplicação em execução e os armazenamentos persistentes de backend.
• base de dados e sistema de ficheiros: é onde ficam todos os dados e recursos estáticos (ficheiros, imagens, etc).

Quanto maior a aplicação, maior cada camada. Isto torna mais difícil escalar uma arquitetura monolítica; a certa altura as coisas ficam simplesmente demasiado grandes e complexas.

Cada vez que alteras a aplicação, toda a base de código é afetada. Para aplicações (muito) grandes isto dificulta a manutenção do software, porque exige uma compreensão total da aplicação inteira.

Como a aplicação inteira é interdependente, os problemas numa parte afetam muitas vezes o sistema todo. A comunicação entre as diferentes partes do sistema faz-se internamente, ao nível do código. Isto significa que as diferentes partes têm de ser programadas na mesma linguagem de programação (ou em linguagens compatíveis). É uma barreira à adoção de novas tecnologias (no futuro), porque não podes mudar facilmente a linguagem de programação de uma parte do sistema.

Arquitetura de microsserviços

Em vez de construíres uma grande aplicação monolítica, podes dividir a aplicação em serviços mais pequenos e interligados. Cada microsserviço é uma pequena aplicação por si só, com a sua própria arquitetura (mas mais pequena e simples), lógica de negócio e camadas de dados.

Os diferentes serviços comunicam entre si através de APIs definidas independentemente da tecnologia usada, muitas vezes numa “estrutura de API” comum como REST, JSON, Redis e XML. Isto permite que a combinação de microsserviços funcione como “um só sistema”.

Ao decompor a aplicação “de um grande bloco” em serviços mais pequenos, fica mais fácil compreender as diferentes partes do sistema. Isso facilita a manutenção, porque cada microsserviço pode ser desenvolvido de forma independente. Reduz também a barreira à adoção de novas tecnologias, porque és livre de escolher a tecnologia mais adequada a cada serviço. Uma parte do sistema pode ser programada numa linguagem diferente das outras. Isto permite que equipas diferentes (com competências diferentes) trabalhem em conjunto.

A arte e a perícia de acertar na arquitetura de microsserviços vêm da capacidade de definir corretamente um microsserviço. Demasiado amplo ou demasiado granular pode destruir a arquitetura. Podes usar processos de negócio, uma separação hierárquica ou por domínio para definir cada microsserviço.

O desafio da arquitetura de microsserviços é que acrescenta complexidade ao sistema inteiro, por exigir um mecanismo de comunicação distribuída. As diferentes APIs que se ligam entre si podem ser difíceis de testar e depurar. Torna-se mais difícil implementar alterações que abrangem vários serviços.

Definir, conceber e implementar as diferentes APIs entre serviços exige um acordo sobre os dados trocados, o que pode ser difícil de alcançar quando pretendes partilhar estruturas de dados extensas e não universais.

Monitorizar e implantar uma arquitetura de microsserviços pode ser complexo quando os serviços aumentam em número. Há simplesmente mais para gerir, o que exige mais planeamento e coordenação para cada um dos serviços.

Escolher a arquitetura certa

O meu falecido pai disse-me uma vez que “se ganha mais com as coisas que não se fazem”. Construir aplicações complexas é difícil por natureza; o melhor que podes fazer é tentar simplificar, simplesmente não fazendo tudo. Foca-te nas coisas que realmente importam e faz essas bem.

Se a tua aplicação é simples e leve, a arquitetura monolítica é o caminho. Desenvolvimento, implementação, manutenção, tudo é mais fácil quando as coisas são pequenas.

Se não consegues escapar à complexidade, então deves mesmo considerar a arquitetura de microsserviços. Pergunta a ti próprio:

• Consegues definir uma “linguagem comum” entre os teus microsserviços?
• Existem processos de negócio claramente distintos?
• Até que ponto são interdependentes esses processos de negócio?
• Como esperas que a tua aplicação evolua com o tempo: esperas que cresça ou que encolha?
• Quantas tecnologias de programação diferentes pensas usar? Esperas que isso mude no futuro?
• Quem vai construir e manter o software? Essas pessoas têm experiência a gerir uma arquitetura destas?

Conclusão

Não existe uma “bala de prata” para a pergunta sobre qual é a arquitetura de software certa. Ambas as abordagens têm vantagens e desvantagens.

O melhor que podes fazer é tomar uma decisão consciente, bem ponderada, e apostar tudo nela!