Arquitetura monolítica versus microsserviços: qual funciona melhor para você?

A abordagem monolítica é o modelo de software tradicional. Os microsserviços refletem mais tarde desenvolvimento de software, mas isso não tornou a arquitetura monolítica obsoleta.

Digamos que você tenha começado a trabalhar para uma startup de tecnologia e tenha sido encarregado de implementar um plano de TI para a nova empresa. Você enfrenta uma série de decisões, mas nenhuma é tão básica ou tão abrangente quanto optar por uma arquitetura monolítica ou de microsserviços. A escolha da arquitetura de software não deve ser feita no vácuo ou sem uma compreensão clara das necessidades iniciais e eventuais de processamento de dados da sua organização, pois qualquer abordagem de arquitetura escolhida terá efeitos profundos na capacidade da organização de executar de forma significativa seus objetivos de negócios.

Portanto, os riscos aqui são consideráveis. E como você é o recém-nomeado Diretor de TI, esta também é uma decisão importante para você pessoalmente — uma decisão que pode levá-lo a um caminho dourado de avanço na carreira sem precedentes, se você escolher sabiamente.

Qual você seleciona? Primeiro, vamos conhecer suas opções.

Como indicado, a arquitetura monolítica é o modelo tradicional de desenvolvimento de software. Nela, uma base de código realiza múltiplas funções (ou seja, funções de negócios). O kernel do computador controla todas as funções. Em aplicações monolíticas, todo o código necessário para essa aplicação inteira é mantido em um local central.

As aplicações monolíticas geralmente contêm os seguintes componentes:

• Interface de usuário (IU) do lado do cliente: "lado do cliente" está relacionado ao que é exibido no dispositivo de computação do usuário. A IU gerencia o que é visto pelo usuário, incluindo imagens, texto e qualquer outra coisa que possa ser transmitida pela tela da IU, como informações relacionadas às ações do navegador.

• Banco de dados: as arquiteturas monolíticas usam um sistema de gerenciamento de banco de dados relacional (RDMS), um tipo de banco de dados que organiza os dados em linhas e colunas. Essas linhas e colunas formam uma tabela onde os pontos de dados estão relacionados entre si.

• Aplicação do lado do servidor: uma aplicação do lado do servidor lida com os recursos do servidor, como memória, CPU e armazenamento.

O uso da arquitetura monolítica gera inúmeros benefícios:

• Desenvolvimento descomplicado de aplicações: Aplicações construídas com uma única base de código são mais simples de construir com desenvolvimento mais rápido.

• Implementação básica: a arquitetura monolítica funciona com um arquivo ou diretório executável, o que torna a implementação menos difícil. Uma arquitetura monolítica também é mais fácil de manter em virtude de usar menos componentes.

• Depuração simples: as operações de testes e depuração estão menos envolvidas com arquiteturas monolíticas. As operações de teste de ponta a ponta são executadas a partir de um sistema de registro central.

• Segurança reforçada: como uma arquitetura monolítica é um sistema fechado, suas atividades de processamento de dados são totalmente contidas e protegidas contra ameaças cibernéticas.

O uso da arquitetura monolítica também apresenta possíveis problemas:

• Resistência a novas tecnologias: como as aplicações monolíticas normalmente estão fortemente acopladas, pode ser difícil integrar novas tecnologias a elas.

• Escalabilidade reduzida: mesmo que a quantidade de escalonamento necessária seja relativamente pequena (como ajustar uma única função), pode ser necessário desmontar e reconstruir efetivamente o sistema para refletir a nova mudança. Isso pode ser demorado e trabalhoso.

O outro modelo de desenvolvimento de software — microsserviços — é um estilo arquitetônico nativo da nuvem. Com os microsserviços, uma aplicação é baseada em múltiplos componentes ou serviços individuais e fracamente acoplados. As aplicações de microsserviços têm sua própria stack de tecnologia, que é uma coleção de tecnologias que trabalham juntas para realizar um determinado trabalho.

A principal vantagem dos microsserviços é como o sistema pode ser facilmente atualizado para lidar com novos recursos de negócios dentro da aplicação sem afetar todo o sistema. Isso pode se traduzir em grandes economias de tempo e mão de obra.

As vantagens dos microsserviços são inúmeras. Eles acomodam tanto o crescimento constante dos negócios quanto as novas mudanças tecnológicas:

• Aumento da escalabilidade: os microsserviços se destacam na escalabilidade em comparação com as arquiteturas monolíticas. Os serviços individuais dentro de uma arquitetura de microsserviços são divididos em módulos, e uma única instrução para escalar pode ser transmitida a vários serviços simultaneamente. Além disso, os microsserviços são adequados para lidar com aplicações grandes e complexas.

• Prontos para automação: os microsserviços em uso permitem que as organizações automatizem o processo de integração contínua/entrega constante (CI/CD). Isso permite o desenvolvimento de atualizações de código que ocorrem de acordo com um cronograma contínuo.

• Operação independente: a arquitetura de microsserviços divide cada serviço em uma célula operacional. Com esse tipo de operação independente, não há perigo de fluxo de trabalho de uma aplicação de microsserviços interferir nos fluxos de trabalho de outras aplicações de microsserviços.

Os microsserviços oferecem benefícios definidos, mas a complexidade deles cria certos problemas:

• Obstáculos de testes: com os microsserviços, as operações dedepuração não começam até que as várias partes de uma aplicação tenham sido testadas. Isso inclui a verificação de dependências, atividades de cache e acesso a dados.

• Potencial de exposição de segurança: a troca de dados que ocorre entre vários processos em um sistema de microsserviços usa um gateway de interface de programação de aplicativos (API). Um API gateway pode criar vulnerabilidades de segurança na autenticação e em outras atividades críticas.

• Aumento de latência: os microsserviços aumentam aplicação de forma impressionante, mas isso pode criar problemas com atraso e latência adicionais. Sempre que o sistema expande para cima, ele aumenta a complexidade e a quantidade de dados que estão sendo transferidos, e isso pode retardar o processamento.

Antes de nossa comparação direta da arquitetura monolítica e da arquitetura de microsserviços, devemos detalhar a história com alguns detalhes históricos para fornecer um contexto mais amplo.

De certa forma, é difícil rastrear a origem da arquitetura monolítica até uma única data; quanto mais complicada a tecnologia, mais difícil pode ser identificar a entrega exata dessa tecnologia. O mesmo acontece com as arquiteturas monolíticas, que começaram a ser desenvolvidas por volta do meio do século XX.

A International Business Machines (IBM®) foi um dos principais players nesse desenvolvimento inicial crítico. De acordo com Pier-Jean Malandrino, colaborador da DZone, "... empresas como a IBM foram fundamentais na definição da arquitetura inicial de software por meio do desenvolvimento de computadores mainframe nas décadas de 1960 e 1970."¹

As arquiteturas monolíticas não eram perfeitas — elas eram muitas vezes escritas em linguagens ultrabaseadas e destinadas a serem lidas por uma única máquina. Como apenas uma máquina continha todo o sistema, todos os componentes do computador estavam fortemente acoplados. O dimensionamento era inexistente ou pouco possível, geralmente exigindo a reconstrução completa de um sistema.

Alternativamente, se a arquitetura monolítica parece primitiva em retrospectiva, é em parte porque estava lá primeiro, antes de qualquer outro sistema de arquitetura de software. E ele se mostrou consistentemente útil, até mesmo resiliente, ao longo do tempo. O fato de que arquiteturas monolíticas ainda estão sendo usadas sete décadas após sua introdução diz muito em um setor em que a única coisa que geralmente permanece é a mudança incessante.

A arquitetura monolítica resistiu, mas não é mais a única ameaça, pelo menos há algum tempo. Com o avançar da década de 1980, a engenharia de software experimentou um impulso em direção à modularidade e ao uso de linguagens de programação orientadas a objetos. Na década de 1990, o cenário havia sido montado para sistemas distribuídos que poderiam aproveitar os recentes avanços na computação em rede.

Isso acabou levando ao desenvolvimento de microsserviços, que passaram a ser amplamente utilizados após o início da computação em nuvem e das tecnologias de conteinerização na década de 2000. A arquitetura de microsserviços foi criada para melhorar o modelo monolítico, preparando-o para sistemas descentralizados e de rápida escalabilidade.

Agora, na década de 2020, o desenvolvimento de software gira em torno da arquitetura monolítica ou da arquitetura de microsserviços. Com base no que esperamos das mudanças tecnológicas, nosso pensamento inicial pode ser assumir que a tecnologia que chegou mais recentemente é superior e, em algumas circunstâncias, esse é definitivamente o caso.

No entanto, fazer esse tipo de declaração genérica é perigoso, em grande parte porque simplesmente não é verdade. Ainda há inúmeras situações de computação que têm benefício da simplicidade do modelo de arquitetura monolítica.

Ambas as arquiteturas de software têm suas vantagens e desvantagens, e as empresas precisam avaliar cuidadosamente ambos os tipos e considerar suas necessidades projetadas de desenvolvimento de aplicações antes de adotar um sistema ou outro.

Como a arquitetura monolítica e a arquitetura de microsserviços se comparam quando vistas através do prisma dos principais estágios operacionais?

• Criação: as principais diferenças entre os dois formatos arquitetônicos começam cedo, com a concepção do sistema desejado. Os sistemas monolíticos são mais simples de construir porque usam um projeto mais básico. Os microsserviços são consideravelmente mais complexos e exigem mais planejamento para serem executados.

• Estrutura: uma arquitetura monolítica é projetada e construída como uma unidade única. A arquitetura de microsserviços defende a ideia de modularidade usando uma coleção de aplicação menores e implementáveis que permitem a operação de serviços independentes.

• Complexidade: Quanto mais complicado um sistema se torna, mais adequado ele é para uma arquitetura de microsserviços. Os microsserviços modulares são receptivos a novas funcionalidades e novas Tecnologias que tendem a acompanhar a complexidade adicional.

• Crescimento: a arquitetura monolítica e a arquitetura de microsserviços podem ser eficazes durante o uso inicial. Mas o crescimento muda tudo, principalmente quando as organizações percebem que em breve se expandirão além de seu sistema inicial. Nesse ponto, as empresas precisam de um estágio maior de operações e os microsserviços oferecem isso, apresentando mais funcionalidades para escalar operações do que a arquitetura monolítica pode.

• Tempo de lançamento no mercado: essa métrica principal desempenha um papel fundamental no comércio, medindo o tempo necessário para fabricar mercadorias e colocá-las nos canais de distribuição. O tempo de lançamento no mercado é uma área em que a arquitetura monolítica se destaca além dos microsserviços. Por meio de um único código de base, os desenvolvedores evitam o tempo extra e o trabalho de incorporar software de várias fontes.

• Escalabilidade: a arquitetura de microsserviços é construída em serviços individuais que podem ser compartimentados em formas modulares e se beneficiam do acoplamento solto e intercomunicação alcançada usando APIs. Por outro lado, a arquitetura monolítica exibe menos adaptabilidade geral devido a ter uma estrutura central densamente composta e software fortemente acoplado.

• Depuração: a depuração é o processo de usar software para detectar e localizar problemas de codificação e, em seguida, corrigir esses problemas. A arquitetura monolítica lida com a depuração melhor do que os microsserviços porque é mais simples e direta. A depuração de uma arquitetura de microsserviços é consideravelmente mais lenta, mais envolvida e laboriosa.

Existe uma oferta quase ilimitada de casos de uso que pode ser alcançada usando uma arquitetura monolítica ou uma arquitetura de microsserviços. Aqui estão algumas das mais predominantes.

• Startups: empresas que estão começando precisam de duas coisas: flexibilidade e financiamento inicial (e muitos de ambos). Uma arquitetura monolítica é a melhor maneira de começar empresas iniciantes. Além disso, ele pode ser construído por equipes de desenvolvimento enxuta de maneira econômica que não impõe uma curva de aprendizado muito acentuada para essas equipes pequenas.

• Projetos básicos: ter uma única base de código paga dividendos em conveniência, especialmente com projetos de escopo rudimentar. Quando o software consegue passar pelo processo de desenvolvimento sem precisar incorporar dados de várias fontes, é uma vitória para a organização.

• Plataformas de entretenimento: administrar uma plataforma de entretenimento internacional exige a capacidade de enfrentar a mudança da onda de cargas de trabalho, quer essa demanda se transforme em cargas de trabalho leves ou pesadas. No caso da Netflix, a gigante do streaming de vídeo fez a transição de uma arquitetura monolítica para uma arquitetura de microsserviços baseada em nuvem. O novo back-end da Netflix contém bastante compatibilidade com o balanceador de carga, o que auxilia seus esforços para otimizar as cargas de trabalho.

• Comércio eletrônico: Comércio eletrônico depende da arquitetura de microsserviços para dar vida à magia do mercado com uma experiência de usuário perfeita. Com varejistas ambiciosos como a Amazon (AWS) impulsionando as vendas com maior conveniência e entrega mais rápida, é fácil ver por que o mercado de vendas de comércio eletrônico em 2023 superou US$ 5,8 trilhões.²

• Trabalhos mais difíceis: o uso contínuo de microsserviços normalmente exige as habilidades de implementação e administração de equipes de DevOps treinadas, que podem criar os serviços específicos necessários para esse framework arquitetônico. Essas habilidades são especialmente úteis ao encontrar aplicações complexas.

Qualquer implementação em grande escala de arquitetura monolítica ou arquitetura de microsserviços será inevitavelmente mal orientada se seu projeto for concluído em um vácuo efetivo, sem primeiro considerar a parte mais importante da equação: as necessidades específicas de sua startup de tecnologia.

Como Diretor de TI, esta é a atividade mais crítica ao planejar suas decisões de infraestrutura de software. Saber quando usar um estilo arquitetônico é essencial, assim como entender o sistema mais adequado com base nos usos necessários.

O exercício de autoanálise é muito valioso porque é sua função não só selecionar o sistema arquitetônico ideal para sua organização, mas também estimar com precisão o sistema arquitetônico que sua empresa precisará nos próximos meses e anos. De certa forma, você está sendo encarregado da tarefa de prever o futuro.

Portanto, embora uma arquitetura monolítica possa parecer a ideal para a sua startup, cabe a você projetar o crescimento futuro. E se uma expansão desenfreada é esperada, pode ser mais sensato investir em uma arquitetura de microsserviços. Há inúmeras variáveis a serem consideradas:

• Lógica de negócios em uso: assim como a lógica computacional determina o que é e o que não é possível fazer com um computador, a lógica comercial baseia-se em business rules que determinam como uma empresa pode ou não ser operada. Tecnicamente, isso se traduz nos algoritmos que definem como as informações são transmitidas entre um banco de dados e uma interface de usuário.

• Desenvolvimento de front-end: desde o planejamento do front-end de sua arquitetura de software, você precisa definir qual abordagem de arquitetura está seguindo, pois cada uma tem uma estrutura única. Em uma arquitetura monolítica, a aplicação front-end se manifesta como uma grande base de código que abriga todo o código da aplicação. Em uma aplicação front-end de microsserviços, vários microsserviços que operam de forma independente podem ser colocados em operação.

• Tolerância a falhas: outra consideração que deve ser feita envolve a quantidade de tolerância a falhas que será necessária. A tolerância a falhas é um problema muito complicado, porque pode derrubar uma aplicação inteira se apenas um componente desse sistema falhar. Uma arquitetura monolítica não possui qualquer isolamento entre componentes, e isso pode agravar a falta de tolerância a falhas e levar a longos períodos de downtime.

• Taxa esperada de mudança: a escolha entre arquitetura monolítica e arquitetura de microsserviços não é apenas uma questão de arquitetura de software. É, na verdade, uma seleção entre duas mentalidades empresariais: uma que simplesmente quer entrar em operação e outra que insiste em alcançar um crescimento substancial nos negócios. O crescimento pode ser complicado, mas é bem suportado por atributos de arquitetura de microsserviços, como ciclos de desenvolvimento mais rápidos e escalabilidade aumentada.