--- title: "Arquitetura de software monolítica vs microsserviços" date: 2020-03-03 language: pt topics: ["cloud", "data", "design", "programming", "server", "work"] source_url: https://willem.com/pt/2020-03-03_arquitetura-de-software-monolitica-vs-microsservicos/ --- # Arquitetura de software monolítica vs microsserviços *Escolher o design certo para o desenvolvimento da tua app* > 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. ![De visita a uma grande empresa internacional de transporte marítimo para falar de software empresarial](https://willem.com/global/images/189c28c69d02.webp) ## 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. ![Exemplo de arquitetura de software simples: diferentes estruturas a compor um sistema, com diferentes relações entre elas](https://willem.com/global/images/b73d8bf569bc.webp) 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. ![Complexidade crescente à medida que aumenta o número de estruturas (e das suas relações)](https://willem.com/global/images/df6c62e25d7d.webp) ## 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. ![Arquitetura de software monolítica](https://willem.com/global/images/875d62aa72f8.webp) 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”. ![Arquitetura de software de microsserviços](https://willem.com/global/images/2705ce2c332c.webp) 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! ![“O céu é o limite” se dominares a arquitetura que escolheste (só não a mudes em pleno voo!)](https://willem.com/global/images/e50e134c3fb7.webp)