No artigo de hoje vamos trazer as principais vantagens e desvantagens em se utilizar arquitetura monolítica e arquitetura de microservice.

Se analisarmos profundamente os padrões de arquitetura de software mais comuns presentes no mercado, vamos ver que na maioria dos casos, os desenvolvedores optam pelo padrão tradicional de desenvolvimento em camadas. Pois bem, isso cria camadas implícitas que separam os módulos do código-fonte em pacotes. E qual é o resultado? Um emaranhado de código difícil de compreender.

Isso geralmente é o resultado de um sistema ou arquitetura não estruturada que futuramente poderá ser difícil de dar manutenção além de apresentar fragilidades em termos de escalabilidade. 

Portanto, é muito importante prestar atenção à arquitetura de qualquer Aplicativo Mobile/ software que você pretende desenvolver.

Alguns especialistas podem se referir à arquitetura de software como um projeto de produto. Outros podem querer chamá-lo de um roteiro para o desenvolvimento de software.

Não importa como você deseja definir a arquitetura do seu aplicativo mobile/software, pois ela abrange o seguinte:

  • A estrutura central do sistema
  • As características / funcionalidades que o sistema deve suportar
  • As regras de como o sistema deve ser construído
  • Um conjunto adequado de diretrizes / princípios de design UI/UX

Existem no mercado de tecnologia de desenvolvimento mobile, vários padrões de arquitetura disponíveis para ajudar a definir as características básicas e o comportamento de um aplicativo. Por exemplo, alguns padrões de arquitetura gravitam naturalmente em direção a aplicativos altamente escaláveis, enquanto outros padrões de arquitetura tendem a aplicativos altamente ágeis.

Por esse motivo, é muito essencial entender os prós e os contras de cada padrão de arquitetura.

Alguns padrões de arquitetura comuns incluem:

  • A arquitetura em camadas / padrão de arquitetura “n” camadas
  • Arquitetura de micro-kernel
  • Arquitetura orientada a eventos
  • Arquitetura de microsserviços
  • Arquitetura baseada no espaço
  • Padrão de monólito

Como proprietário do produto que você vai desenvolver com alguma empresa especializada, você deve compreender ou, ao menos ter uma noção básica, desses padrões e certificar-se de ter razões sólidas para o padrão que pretende ser utilizado.

Muitos proprietários / fundadores de tecnologia enfrentam problemas quando se trata de escolher um padrão de arquitetura. Existe uma forma de escolher de maneira mais adequada o padrão correto chamado método do círculo dourado de Simon Sinek.

Este artigo discutiu a principal diferença entre a arquitetura de microsserviços e o padrão de monólito. Vamos começar.

O que são microsserviços?

Grandes empresas em todo o mundo, incluindo Amazon, Netflix, Etsy e Uber, vislumbraram imensos ganhos de negócios seguindo o caminho dos microsserviços. Tanto que, microsserviços, agora, é a arquitetura padrão de inúmeras empresas em todo o mundo.

Em 2022, 90% de todos os novos aplicativos apresentarão arquiteturas de microsserviços que melhoram a capacidade de projetar, depurar, atualizar e aproveitar o código de terceiros; 35% de todos os aplicativos de produção serão nativos da nuvem. (Soure:  IDC )

Mas o que exatamente é isso?

Deixe-me começar descrevendo um fato interessante sobre a Suécia.

Se você já esteve na Suécia ou permaneceu lá, encontrará variações das mesmas marcações e sinais de trânsito que são usados ​​em todo o mundo desenvolvido.

Então, como é que este país tem uma das menores taxas de acidentes rodoviários. Poderia ser motoristas melhores, a forma como as estradas são projetadas ou leis de trânsito rigorosas? Bem, esses fatores certamente desempenham um papel, mas o crédito vai para o programa “Visão Zero”.

Eu sei que você deve estar se perguntando o que a segurança no trânsito tem a ver com arquitetura de software ou microsserviços?

Espere um minuto. Você vai descobrir.

Visão Zero tem tudo a ver com a redução de mortes relacionadas a acidentes de trânsito a zero. Seu objetivo é conseguir isso projetando sistemas viários que priorizem a segurança acima de todos os outros fatores, embora ainda reconheçam a importância de manter o tráfego em movimento. Em outras palavras, um sistema viário projetado antes de mais nada com a segurança em mente.

A crença central é – que a segurança de pedestres e motoristas é mais valiosa do que a necessidade de se deslocar de um lugar para outro o mais rápido possível.

Os projetistas de tráfego aplicam limites de velocidade, sinais de trânsito e padrões de movimento do tráfego de uma forma que beneficia a segurança geral do sistema. Por exemplo, embora seja necessário garantir o movimento dos carros na estrada, a velocidade é limitada a um nível que o corpo humano possa suportar em uma colisão, de acordo com os padrões técnicos dos veículos e estradas existentes.

Embora os limites de velocidade possam afetar a capacidade dos motoristas de chegar ao destino o mais rápido possível, a decisão do projeto é sempre orientada pela necessidade de proteger a vida humana.

Em vez de depender apenas de motoristas qualificados que sabem como evitar erros comuns, os projetistas do Vision Zero criam estradas responsáveis ​​pelos erros e erros de cálculo que muitos motoristas humanos inevitavelmente cometem. Embora seja responsabilidade do motorista cumprir as regras da estrada, os projetistas do sistema devem fazer o melhor para proteger os humanos, mesmo em situações em que os motoristas não cumpram.

(Fonte: Livro de Arquitetura de Microsserviços, O’Reilly)

Semelhante aos sistemas de tráfego, os produtos de software se tornam complexos à medida que aumentam na forma de escopo, volume e interações do usuário. Portanto, assim como os projetistas de estradas, os arquitetos de software devem saber como encontrar o equilíbrio entre velocidade e segurança.

As empresas usam a arquitetura de microsserviço para entrega mais rápida e, ao mesmo tempo, prestam atenção à segurança.

Como uma variante do estilo estrutural da arquitetura orientada a serviços, os microsserviços organizam um aplicativo como uma coleção de serviços fracamente acoplados. Em uma arquitetura de microsserviços, os serviços são refinados e os protocolos são leves.

Benefícios do uso de microsserviços

  • Independente por natureza – os microsserviços melhoram a escala e a robustez dos sistemas de software. Você pode misturar e combinar tecnologia usando-o. Traga mais desenvolvedores para resolver problemas sem que nenhum deles interrompa uns aos outros.
  • Foco – ajuda os desenvolvedores a se concentrarem em apenas uma parte de cada vez, pela qual eles são responsáveis.
  • Opções de tecnologia variadas – como os microsserviços funcionam isoladamente, você pode formar sua própria combinação certa de tecnologia, dependendo das necessidades de negócios. Misture e combine linguagens de programação, estilos, plataformas de implantação e bancos de dados.
  • Flexibilidade – talvez a maior vantagem de usar microsserviços. Você tem muitas opções quando se trata de resolver problemas.
  • Capacidade de substituição – A ideia de substituir componentes em vez de manter os existentes está no cerne desta abordagem.
  • Implantações de produção em tempo real – os microsserviços têm a capacidade de realizar implantações de produção em tempo real, reduzindo significativamente a necessidade de implantações de produção tradicionais mensais ou finais de semana. Como a mudança geralmente é isolada para componentes de serviço específicos, apenas os componentes de serviço que mudam precisam ser implantados.

Problemas de uso de microsserviços

  • Problemas de rede e latência – precisamos levar em consideração as latências porque a comunicação entre os computadores nas redes não é instantânea. Latências que superam em muito as latências que vemos nas operações locais em processo. O comportamento do sistema pode ser imprevisível quando as latências variam. As redes falham, os cabos são desconectados e os pacotes são perdidos.
  • Depuração complexa e teste de integração – Quando você tem vários serviços em execução, você tem vários logs, o que significa que é difícil e demorado ir até a origem do problema. Além disso, os componentes distribuídos significam que um sistema não pode ser totalmente testado por meio de uma única máquina.
  • APIs – cada microsserviço usa sua própria API. Você pode trabalhar independentemente em um microsserviço sem afetar todo o sistema. Mas se você fizer alterações em uma API, todos os microsserviços que usam essa API serão afetados (se as alterações não forem compatíveis com versões anteriores).
  • Caro – Para que os sistemas de software baseados em microsserviços sejam executados com eficiência, é necessário investir substancialmente em infraestrutura e engenheiros experientes para fazer o trabalho de manutenção e tecnologia necessário (devido a várias linguagens de programação e estruturas). Isso é especialmente verdadeiro quando uma empresa migra de sistemas baseados em monólito.

O que é arquitetura de monólito? Quais são suas vantagens e desafios?

Funcionalidades implantadas juntas em uma única unidade são consideradas um monólito. Existem 3 tipos de estruturas de monólito – o sistema de processo único, o monólito distribuído e sistemas de caixa preta de terceiros.

Monólito para arquitetura de microsserviços Monolith to Microservices de Sam Newman

Implementação mais simples – Monoliths resultam em fluxos de trabalho de desenvolvedor muito mais simples. Conseqüentemente, monitoramento, solução de problemas e atividades como testes de ponta a ponta se tornam mais fáceis e simples.

Reutilização de código – você já quis reutilizar código em um sistema distribuído? Você sabe do que estou falando. Você pode ter que se perguntar sobre como quebrar bibliotecas, copiar código, empurrar funcionalidade compartilhada dentro de um serviço. Com uma arquitetura monolítica, o código existe apenas para ser usado.

Sem grandes re-arquiteturas – é muito mais fácil consertar sistemas baseados em monólito, pois eles têm uma implantação mais simples e única. Shopify, um dos mais conhecidos construtores de lojas de e-commerce, foi implantado usando uma arquitetura monolítica em seus primeiros dias. É baseado em Ruby on Rails. No entanto, eles agora mudaram para uma arquitetura de microsserviços com base em suas necessidades cada vez maiores de engenharia.

Manutenção fácil – Manter uma base de código inteira em uma única base definitivamente tem suas vantagens. Sem complexidades de qualquer espécie. Basta manter um repositório e pronto. Apenas um teste e pipeline de implantação precisam ser atendidos.

Não se preocupe com a API – Com os monólitos, os desenvolvedores podem chamar diferentes componentes diretamente em vez de usar APIs. Portanto, você não precisa manter essas versões e se preocupar com a compatibilidade com versões anteriores.

Aqui está uma conversa interessante que inclui por que os monólitos são o futuro.

Os desafios

Tomando o exemplo do Shopify mais adiante, sua arquitetura baseada em monólito não estava mais servindo ao seu propósito em 2016, quando a plataforma e a equipe cresceram.

Kirsten Westeinde, desenvolvedor da Shopify, explica em detalhes como –

A aplicação ficou extremamente frágil com o novo código tendo repercussões inesperadas. Fazer uma mudança aparentemente inócua pode desencadear uma cascata de falhas de teste não relacionadas.

Por exemplo, se o código que calcula nossa taxa de frete for chamado para o código que calcula as taxas de imposto, fazer alterações em como calculamos as taxas de imposto pode afetar o resultado dos cálculos da taxa de frete, mas pode não ser óbvio por quê. Isso era resultado do alto acoplamento e da falta de limites, o que também resultava em testes difíceis de escrever e muito lentos para executar em CI.

O desenvolvimento no Shopify exigia muito contexto para fazer alterações aparentemente simples. Por exemplo, um novo desenvolvedor que se juntou à equipe de remessa só precisa entender a implementação da lógica de negócios de remessa antes de começar a construir.

No entanto, a realidade é que eles também precisam entender como os pedidos são criados, como processamos os pagamentos e muito mais, já que tudo estava tão interligado. É muito conhecimento para um indivíduo ter que guardar na cabeça apenas para lançar seu primeiro filme. Aplicações monolíticas complexas resultam em curvas de aprendizagem íngremes.

O que considerar ao migrar da arquitetura de monólito para a arquitetura de microsserviços?

Sam Newman, um renomado consultor independente de microsserviços, diz que se deve responder às seguintes perguntas antes de seguir o caminho dos microsserviços.

1. O que você espera alcançar?

Deve ser um conjunto de resultados alinhados ao que a empresa está tentando alcançar e pode ser articulado de uma forma que descreva o benefício para os usuários finais do sistema.

2. Você considerou alternativas ao uso de microsserviços?

Freqüentemente, há muitas outras maneiras de obter alguns dos mesmos benefícios que os microsserviços trazem. Você já olhou para essas coisas? Se não, porque não? Freqüentemente, você pode obter o que precisa usando uma técnica muito mais fácil e entediante.

3. Como você saberá se a transição está funcionando?

Se você decidir embarcar nessa transição, como saberá se está indo na direção certa?

Quando usar a arquitetura de microsserviços?

  • Equipes autônomas – algumas empresas prosperam quando administradas por equipes autônomas. Se você está procurando funções bifurcadas, deseja permitir que pequenas equipes trabalhem de perto e criem tal cultura, esta arquitetura pode ser exatamente o que você precisa (é claro que deve haver uma lógica de tecnologia / negócios para isso). As empresas tentam conceder a propriedade de partes da base de código a pessoas com experiência em uma área específica. Por exemplo, John pode saber como os anúncios são exibidos da melhor forma, então ele é o proprietário disso. Julia pode saber melhor sobre o desempenho da consulta, então essa pode ser a parte dela. Quando você melhora a autonomia e adota uma abordagem de autoatendimento, elimina a necessidade de equipes centrais de operações terem de fornecer tickets para as atividades do dia a dia.
  • Adotando uma nova tecnologia – Os monólitos dificultam as escolhas de tecnologia devido ao padrão de implantação único. Quando você deseja desfrutar da flexibilidade de experimentar uma nova pilha com segurança, os microsserviços podem ser uma opção para você. Isso pode lhe dar uma vantagem competitiva, permitindo que você envie melhores recursos / funcionalidades para seus usuários. Sua equipe de desenvolvimento também pode ser capaz de aumentar suas apostas quando se trata de habilidades técnicas.
  • Reduza o tempo de colocação no mercado – com microsserviços, você pode implantar mudanças e escalar serviços individuais. Libere funcionalidades / recursos rapidamente para ganhar mais clientes / usuários.
  • Custo-benefício – os microsserviços permitem que você torne suas operações econômicas, pois você dimensionará as partes que estão enfrentando restrições. Você pode até diminuir quando for necessário. Os microsserviços podem ser desligados quando não são necessários. Muitas empresas de SaaS adotam essa abordagem porque reduz os custos operacionais.
  • Robustez – quando você não quer que todo o seu sistema entre em colapso devido a problemas em uma área, os microsserviços vêm em seu socorro. Isso é especialmente verdadeiro em aplicativos SaaS multilocatários. Você não quer que seus usuários enfrentem interrupções devido a pequenos problemas. Com microsserviços, você tem uma arquitetura mais robusta em vigor. Ele também oferece mais controle sobre as peças de missão crítica.

Quando evitar a arquitetura de microsserviços?

  • Apenas começando um novo negócio – as startups precisam pensar duas vezes antes de seguir o caminho dos microsserviços. A ideia deve ser estabelecer inicialmente uma adequação do produto ao mercado. Os microsserviços são mais adequados para startups focadas na expansão após terem validado sua ideia. Com um orçamento limitado e a necessidade de lançar um produto rapidamente, não se concentre muito nesses aspectos. Usar a arquitetura de microsserviços não evitará uma má ideia.
  • Os clientes precisam instalar seu produto – quando você cria um produto que os usuários precisam baixar e instalar, você deseja que seja simples e eficaz. Você não quer forçar muitas complexidades para eles. Você não pode esperar que seus clientes aprendam a gerenciar a arquitetura de microsserviços.
  • Sem visão / objetivos claros – Se você não tem ideia sobre o setor / domínio em que irá operar. Se você não tem ideia sobre a visão do produto ou o curso que ele tomará no futuro. Se você não tem expectativas ou objetivos claros a serem alcançados usando a arquitetura de microsserviços, é melhor ficar longe disso. Normalmente, quando se trata de implantar esse padrão, as empresas sabem os problemas que estão enfrentando e como os microsserviços ajudarão a eliminá-los.
  • Conhecimento / compreensão do domínio – você precisa conhecer dentro e fora do setor em que opera. Mover-se prematuramente de uma arquitetura monolítica e dividi-la em diferentes componentes pode ser caro. Você não toma decisões sobre algo como – ‘Se funcionar para o Uber, fará maravilhas para nós.’ Você precisa entender como os microsserviços ajudarão a eliminar os problemas do seu setor. Se isso não estiver claro, não mergulhe nisso.

Sinais reveladores de que os microsserviços estão se tornando uma dor e suas soluções

  • Propriedade do código – Ao trabalhar com uma arquitetura de microsserviços, existem diferentes modelos para propriedade do código. Pode ser forte, fraco ou coletivo. Quando as equipes são pequenas (menos de 20 pessoas), uma propriedade coletiva do código pode ser ótima, em que todos têm permissão para alterar o código e fazer as alterações necessárias. No entanto, quando as equipes crescem, pode ser um desastre seguir o modelo coletivo. O resultado final será que todos tentarão fazer alterações, levando a uma tigela de peneira (usada para coar macarrão). Você não quer estar nessa situação. Uma solução é ter uma propriedade de código forte, o que exige que as pessoas enviem solicitações de mudança de código aos proprietários, que então decidem o que é permitido e o que não é.
  • Monitoramento e solução de problemas – Com a arquitetura monolith, o sistema está em pleno funcionamento ou totalmente inativo. Você saberá escolher os problemas facilmente. Mas com microsserviços, especialmente em um ambiente, onde centenas de processos estão sendo executados simultaneamente, você precisará prestar atenção e investimento extra. Uma bela manhã, você perceberá que há problemas na produção, mas o sistema está funcionando. Torna-se mais complicado e difícil dizer ‘está tudo indo bem? Você pode contar com um sistema de agressão de log para lidar com isso. Outra coisa a fazer é usar uma ferramenta de rastreamento de código aberto como o Jaeger para capturar informações para rastreamentos distribuídos e analisar o desempenho de chamadas individuais.
  • A experiência do desenvolvedor começa a ser afetada – ao executar mais serviços, você precisará de máquinas maiores. Há um limite para o número de serviços que você pode executar em uma única máquina. Quais são as repercussões? O desenvolvimento leva mais tempo. Conseguir máquinas maiores será apenas uma solução de curto prazo. Então, o que você faz? A telepresença é uma ferramenta que torna o fluxo de trabalho do desenvolvedor local / remoto híbrido mais fácil para os usuários do Kubernetes. Os desenvolvedores podem construir serviços localmente, mas a Telepresença pode fazer chamadas de proxy para outros serviços para um cluster remoto. Mesmo com as funções de nuvem do Azure. Eles também podem ser executados localmente, mas conectados a recursos de nuvem remotos, permitindo que os desenvolvedores criem serviços feitos de funções com um fluxo de trabalho de desenvolvedor local rápido, enquanto ainda os executam em um ambiente de nuvem potencialmente extenso.

Notas finais

Tanto a arquitetura monolítica quanto a de microsserviços são adequadas em circunstâncias específicas com base no negócio que você opera e em qual estágio ele está. Ao fazer microsserviços, certifique-se de ter clareza sobre os objetivos que está tentando alcançar. Isso não pode ser vago, senão pode ser um pesadelo para o seu negócio. Qual é a sua experiência com monólito e microsserviços? Você migrou? Sinta-se à vontade para compartilhar sua experiência e resultados com esses padrões de arquitetura de software.

Conta aí pra gente o que você achou desse artigo

Artigos Relacionados

Vantagens e desvantagens da tecnologia ionic para desenvolvimento mobile

Quando o Flutter é indicado para o desenvolvimento de aplicativos mobile?

O que é o FLoC e como essa tecnologia pode mudar o marketing digital

11 aplicativos de teste de penetração de aplicativos mobile para iOS