Arquitetura Micro Serviços: como isso pode ajudar sua empresa (Parte 2)?

Se está chegando agora, recomendamos que leia a Parte 1 deste artigo.

Vamos detalhar agora por quais motivos a migração de um sistema monolítico para a nuvem é um tanto quanto complicada.

Motivo 1: Falhas isoladas impactam grande parte do sistema

Pelo fato dos sistemas monolíticos terem muitas interdependências e um escopo de negócio muito grande as mudanças em alguma funcionalidade podem gerar alguns efeitos colaterais indesejados. Por definição, os sistemas monolíticos são construídos e publicados como um pacote único. Não há separação física entre diferentes áreas do sistema. Assim não há garantia de que uma nova versão irá afetar apenas uma área para a qual foi construída. Mesmo com um teste de regressão completo não há garantia de um completo isolamento e efeitos colaterais indesejados poderão acontecer.

Motivo 2: Dificuldades em escalar

Escalar “partes” de uma aplicação monolítica é muito difícil e requer muito mais recursos do que efetivamente aquela “parte” demanda. Na maioria dos casos o único caminho para escalar uma aplicação monolítica é fazer a publicação em múltiplas instâncias de toda a aplicação resultando em mais memória e recursos computacionais. Por exemplo: você precisa melhorar a velocidade do módulo de processamento de pedidos de um site de e-commerce. Você poderá neste caso criar e publicar uma(ou várias) instância(s) adicional(ais) de toda a aplicação e configurar um balanceamento de carga ou então aumentar o poder de processamento da VM/Server (mais memória e mais processadores). E isso não necessariamente resolve o problema. O primeiro caso pode causar problemas de bloqueio no banco de dados e cada vez em que se adicionam mais instâncias isso pode se tornar pior. Enfim: escalar partes de uma aplicação monolítica requer o aumento no uso de recursos o que é o oposto do que estamos procurando.

Motivo 3: Publicações são complicadas e demoradas

Quanto maior o sistema e mais complexas as regras de negócios maior serão os ciclos de desenvolvimento e testes (QA). O modelo monolítico é de certa forma até inconveniente se você precisa fazer modificações frequentes. Para incluir pequenas modificações em um único componente ou adicionar apenas uma nova funcionalidade você tem que re-compilar, executar um teste completo de regressão e fazer a publicação (deploy) de toda a aplicação. Como resultado, atualizar as aplicações monolíticas consome bastante tempo e requer uma coordenação apropriada de toda a equipe envolvida no projeto o que contribui para evitar um ciclo de releases mais rápido.

Motivo 4: Mudança de Tecnologia

A arquitetura monolítica está propensa a requerer um comprometimento de longo prazo com uma tecnologia em particular. As separações entre camadas nem sempre é tão grande. Geralmente utiliza-se sempre o mesmo conjunto de tecnologias em toda a aplicação. Por exemplo: Arquitetura .net com SQL Server + C# + RazorPages ou Oracle + Java + JavaScript + Angular ou Mysql + PHP + Vue Js etc. A cada nova versão você indiretamente está aumentando o seu comprometimento com aquele conjunto de tecnologias escolhido. Quanto mais código desenvolvido mais difícil fica para os desenvolvedores e arquitetos mudarem ou experimentarem outras tecnologias assim que forem sendo criadas. Nem preciso dizer o quanto as novas tecnologias são importantes num mundo de constantes mudanças.

Agora que entendemos alguns dos principais problemas dos sistemas monolíticos vamos descobrir no próximo artigo como a arquitetura de micro serviços pode nos ajudar.

Sem comentários

Publique um comentário