Microsserviços versus arquitetura monolítica

As empresas podem se beneficiar da arquitetura monolítica ou de microsserviços, dependendo de vários fatores diferentes. Ao desenvolver usando a arquitetura monolítica, a principal vantagem é o desenvolvimento rápido devido à simplicidade de ter o aplicativo com base na base de código.

As vantagens da arquitetura monolítica incluem:

Fácil implementação — Um arquivo executável ou diretório facilita a implementação.

Desenvolvimento — Quando o aplicativo é construído com uma base de código, é mais fácil de desenvolver.

Desempenho — Na base de código e repositório centralizados, muitas vezes uma API pode executar a mesma função que várias APIs executam com microsserviços.

Testes simplificados — Como o aplicativo monolítico é a unidade única e centralizada, o teste de ponta a ponta pode ser realizado com mais rapidez do que com o aplicativo distribuído.

Fácil depuração — Com todo o código localizado em um só lugar, é mais fácil seguir a solicitação e encontrar o item.

Como no caso da Netflix, os aplicativos monolíticos podem ser bastante eficazes até ficarem muito grandes e a escalabilidade se tornar o desafio. Fazer alterações, mesmo que pequenas, em uma única função requer compilar e testar em toda a plataforma, o que vai contra a abordagem ágil que os desenvolvedores de hoje preferem.

As desvantagens do monólito incluem:

Velocidade de desenvolvimento mais lenta — O aplicativo grande e monolítico torna o desenvolvimento mais complexo e lento.

Escalabilidade — Não é possível dimensionar componentes individuais.

Confiabilidade — Se houver erro em qualquer módulo, isso pode afetar a disponibilidade de todo o aplicativo.

Barreira para adoção de tecnologia — Qualquer alteração na estrutura ou na linguagem afeta todo o aplicativo, tornando as alterações muitas vezes caras e demoradas.

Falta de flexibilidade — O monólito é limitado pelas tecnologias já usadas no monólito.

Implementação — Uma pequena alteração no aplicativo requer a reimplementação de todo o monólito.

A arquitetura de microsserviço, também conhecida como microsserviços, é o método arquitetônico que depende da série de serviços implantáveis com independência. Esses serviços têm sua própria lógica de negócios e banco de dados com objetivo específico. A atualização, o teste, a implementação e a escalabilidade ocorrem em cada serviço. Os microsserviços dissociam os principais problemas específicos dos domínios de negócios em bases de código independentes separadas. Os microsserviços não reduzem a complexidade, mas tornam qualquer complexidade visível e mais gerenciável, separando as tarefas em processos menores que funcionam independentes uns dos outros e contribuem para o todo.

A adoção do microsserviços muitas vezes anda de mãos dadas com o DevOps, pois eles são base para práticas de entrega contínua que permitem que as equipes se adaptem com rapidez aos requisitos do usuário.

A Atlassian seguiu o caminho para o microsserviços em 2018 depois que enfrentamos desafios de crescimento e escalabilidade com o Jira e o Confluence. Descobrimos que as arquiteturas monolíticas de locatário único executadas no local não seriam capazes de dimensionar para as necessidades futuras.

Decidimos rearquitetar o Jira e o Confluence e movê-los do sistema monolítico de locatário único para aplicativos de nuvem sem estado e multilocatários hospedados pela Amazon Web Services (AWS). Depois, os decomporíamos ao longo do tempo em microsserviços. O projeto foi batizado de Vertigo depois que um engenheiro sênior disse: "Eu gosto mesmo da ideia, mas está me dando vertigem". Foi o maior projeto de infraestrutura até o momento, levando dois anos para concluir a transição para a AWS, migrando mais de 100.000 clientes em pouco mais de 10 meses sem interrupções de serviço. Também nos comprometemos a decompor os serviços em microsserviços.

Os microsserviços não são de jeito nenhum a solução milagrosa, mas eles resolvem vários problemas para o crescimento de software de empresas. Como a arquitetura de microsserviço consiste em unidades que são executadas por conta própria, cada serviço pode ser desenvolvido, atualizado, implementado e dimensionado sem afetar os demais serviços. As atualizações de software podem ser realizadas com mais frequência, com maior confiabilidade, tempo de atividade e desempenho. Passamos de enviar atualizações uma vez por semana, para duas a três vezes por dia.

À medida que a Atlassian cresce, os microsserviços nos permitem escalar equipes e localizações geográficas com mais confiança, dividindo ao longo das linhas de propriedade do serviço. Antes de começarmos a Vertigo, a Atlassian tinha cinco centros de desenvolvimento diferentes no mundo. Essas equipes distribuídas eram restringidas pelo monólito centralizado e precisávamos apoiá-las com autonomia. Os microsserviços nos permitem fazer isso.

Os benefícios da Vertigo incluem maior velocidade de implementação, recuperação de desastres, custo reduzido e maior desempenho. Isso nos permite chegar ao objetivo com mais rapidez e, ao mesmo tempo, oferecer mais valor incremental para os clientes ao longo do caminho.

Além disso, em geral, os microsserviços tornam mais fácil para as equipes atualizar o código e acelerar os ciclos de lançamento com integração contínua e entrega contínua (CI/CD). As equipes podem testar o código e reverter se algo der errado.

Em resumo, as vantagens dos microsserviços são:

Agilidade — Promova maneiras ágeis de trabalhar com equipes pequenas que implementam com frequência.

Escalabilidade flexível — Se os microsserviços atingirem a capacidade de carga, novas instâncias desse serviço vão poder ser implementadas com rapidez no cluster que o acompanha para ajudar a aliviar a pressão. Agora somos multilocatários e sem estado, com clientes espalhados por várias instâncias e podemos oferecer suporte a tamanhos de instância muito maiores.

Implementação contínua — Agora temos ciclos de lançamento mais rápidos e mais frequentes. Antes, lançávamos atualizações uma vez por semana e agora podemos realizar essa tarefa cerca de duas a três vezes por dia.

Bastante sustentável e testável — As equipes podem experimentar novas funções e reverter se algo não funcionar. Isso facilita a atualização do código e acelera o tempo de entrada no mercado para novas funções. Além disso, é fácil isolar e corrigir falhas e bugs em serviços individuais.

Implementável com independência — Como os microsserviços são unidades individuais, é permitida uma implementação independente rápida e fácil de funções individuais.

Flexibilidade tecnológica — As arquiteturas de microsserviços permitem que as equipes tenham a liberdade de selecionar as ferramentas que querem.

Alta confiabilidade — Você pode implementar alterações para o serviço específico, sem a ameaça de derrubar todo o aplicativo.

Equipes mais felizes — As equipes da Atlassian que trabalham com microsserviços são muito mais felizes pois são mais autônomas e podem criar e implementar sozinhas sem esperar semanas para que a pull request seja aprovada.

Quando passamos de um pequeno número de bases de código monolíticas para muitos outros sistemas e serviços distribuídos que alimentam os produtos, surgiu uma complexidade não intencional. De início, nos esforçamos para adicionar novos recursos com a mesma velocidade e confiança que tínhamos feito no passado. Os microsserviços podem aumentar a complexidade que leva à expansão do desenvolvimento ou ao crescimento rápido e não gerenciado. Pode ser desafiador determinar como diferentes componentes se relacionam entre si, quem tem o determinado componente de software ou como evitar interferir com componentes dependentes.

Com a Vertigo, construímos a funcionalidade comum que impulsionaria os produtos existentes e futuros produtos que adquirimos e criamos. Se você é uma empresa de produto único, os microsserviços podem não ser necessários.

As desvantagens dos microsserviços incluem:

Expansão do desenvolvimento — Os microsserviços adicionam mais complexidade em comparação com a arquitetura monolítica, já que há mais serviços em mais lugares criados por várias equipes. Se a expansão do desenvolvimento não for gerenciada de modo adequado, a velocidade de desenvolvimento fica mais lenta e o desempenho operacional ruim.

Custos exponenciais de infraestrutura — Cada novo microsserviço pode ter o custo próprio para o conjunto de testes, esquema tático de implementação, infraestrutura de hospedagem, ferramentas de monitoramento e mais.

Sobrecarga organizacional adicional — As equipes precisam adicionar outro nível de comunicação e colaboração para coordenar atualizações e interfaces.

Desafios de depuração — Cada microsserviço tem o conjunto de registros próprio, o que torna a depuração mais complicada. Além disso, o processo de negócios pode ser executado em várias máquinas, complicando ainda mais a depuração.

Falta de padronização — Sem a plataforma comum, pode haver a proliferação de linguagens, padrões de registro e monitoramento.

Falta de propriedade clara — À medida que mais serviços são introduzidos, o mesmo acontece com o número de equipes que executam esses serviços. Com o tempo, se torna difícil conhecer os serviços disponíveis que a equipe pode aproveitar e com quem entrar em contato para obter suporte.

Muitos projetos começam como o monólito a princípio e depois evoluem para a arquitetura de microsserviço. Conforme novas funções são adicionadas ao monólito, pode começar a ficar complicado ter muitos desenvolvedores trabalhando em uma única base de código. Os conflitos de código passam a ser mais frequentes, e o risco de atualizações da função introduzirem bugs na função não relacionada aumenta. Quando esses padrões indesejáveis aparecem, talvez seja a hora de considerar uma migração para os microsserviços.

Veja a seguir algumas das práticas recomendadas que aprendemos com a migração:

Em janeiro de 2016, tínhamos cerca de 15 microsserviços ao todo, e agora temos mais de 1.300. Mudamos 100 mil clientes para a nuvem, construímos a nova plataforma ao longo do caminho, transformamos a cultura e acabamos com novas ferramentas. Temos equipes autônomas, mais felizes e a cultura de DevOps melhor.

Microsserviços podem não ser para todos. Um monólito legado pode funcionar com perfeição e quebrá-lo pode não valer a pena. Mas à medida que as empresas crescem e a demanda por aplicativos aumentam, a arquitetura de microsserviço pode valer a pena.

Como a tendência para muitas empresas são os microsserviços com arquiteturas distribuídas, a Atlassian desenvolveu o Compass para ajudar as empresas a gerenciar a complexidade das arquiteturas distribuídas à medida que crescem. É a plataforma de experiência de desenvolvedor extensível que reúne informações desconectadas sobre todos os resultados de engenharia e colaboração da equipe em local central e pesquisável.