Além da escalabilidade, uma das melhores características da arquitetura de microsserviços é que, caso um dos serviços falhe, outro será implantado em seu lugar.
No mercado hipercompetitivo de hoje, o caminho ideal para o seu negócio deveria ser óbvio. Em outras palavras, você deseja estar sempre à frente ou à frente da curva. Isso significa que seus desenvolvedores e sua equipe de TI estarão sempre aprendendo novas tecnologias e práticas recomendadas. À medida que você aprende novas habilidades e adota novas pilhas de software, você descobrirá que uma série de decisões devem ser tomadas.
Uma decisão importante que você enfrentará é optar pela arquitetura de microsserviços ou pela arquitetura monolítica. Faça a escolha certa para sua empresa e você obterá grandes ganhos. Faça a escolha errada e você se encontrará em uma batalha constante e difícil para manter seu data center funcionando perfeitamente.
Uma decisão tão errada pode ser um pesadelo para seus desenvolvedores, quer eles trabalhem com Java, JavaScript, Ruby ou .NET. Isso também pode afetar todo o processo de desenvolvimento de aplicativos. Portanto, é fundamental que aqueles em sua empresa que tomam decisões tão importantes entendam onde você está se metendo.
Então, quais são essas arquiteturas? Vamos examiná-los e ver qual pode ser o certo para você.
| Critério | Microsserviços | Monolítico |
|---|---|---|
| Estrutura | Divide a aplicação em serviços pequenos, pouco acoplados e independentes | Constrói o aplicativo como uma unidade única e indivisível |
| Desenvolvimento | Permite o desenvolvimento independente e a implantação de serviços | Todos os componentes estão interligados, portanto devem ser desenvolvidos em conjunto |
| Escalabilidade | Componentes individuais podem ser dimensionados conforme necessário | Toda a aplicação deve ser dimensionada mesmo que apenas uma função tenha aumentado a demanda |
| Pilha de tecnologia | Cada serviço pode usar uma pilha de tecnologia diferente | Todos os componentes devem usar a mesma pilha de tecnologia |
| Implantação | Permite implantação e integração contínuas | Todo o aplicativo precisa ser reimplantado para atualizações |
| Isolamento obrigatório | A falha em um serviço não afeta outros | Um único erro pode derrubar todo o aplicativo |
| Desempenho | Alto desempenho e velocidade devido a serviços leves | O desempenho depende do tamanho e da complexidade do aplicativo |
| Gestão de dados | Cada serviço pode ter seu próprio banco de dados | Um único banco de dados é usado para todo o aplicativo |
| Complexidade | Mais complexo devido aos desafios do sistema distribuído | Menos complexo inicialmente, mas pode se tornar difícil de gerenciar com o tempo |
| Velocidade de desenvolvimento | Inicialmente mais lento devido à necessidade de um planejamento cuidadoso | Mais rápido inicialmente devido à simplicidade |
| Modificação | Mais fácil de atualizar ou adicionar novos recursos sem interromper outros serviços | Atualizações ou modificações podem exigir alterações em todo o sistema |
| Teste e depuração | Mais fácil de testar e depurar serviços específicos de forma independente | Teste e depuração podem ser mais desafiadores devido à interconectividade do aplicativo |
| Comunicação entre serviços | Os serviços se comunicam por meio de APIs, o que pode adicionar latência | Os componentes interagem diretamente, geralmente oferecendo menor latência |
Arquitetura monolítica
Começamos com monolítico porque é o mais simples de entender. Por que? Porque a arquitetura monolítica já existe há muito tempo. Na verdade, aplicativos monolíticos são o que a maioria das pessoas entende como “software”.
Simplificando, um aplicativo monolítico é aquele criado como uma unidade única, embora isso não signifique necessariamente que tudo esteja incluído para fazer esse aplicativo ser executado. Vamos decompô-lo para que possamos entender melhor o que está acontecendo.
Sim, existem aplicativos instalados como clientes independentes. Tomemos, por exemplo, um pacote de escritório como LibreOffice. Este aplicativo não depende de nenhum software ou serviço externo ou de terceiros para ser executado. Tudo é executado na máquina cliente local.
Por outro lado, o WordPress a plataforma de blog requer o seguinte para funcionar:
- Um servidor de banco de dados
- Um aplicativo do lado do servidor
- Uma interface de usuário do lado do cliente
Cada um desses componentes é monolítico e trabalha em conjunto para criar o todo.
Confuso? Vamos simplificar olhando da perspectiva do desenvolvedor.
Digamos que sua empresa tenha implantado um sistema de gerenciamento de conteúdo monolítico desenvolvido internamente. Este sistema inclui um banco de dados, um aplicativo do lado do servidor e uma interface de usuário do lado do cliente. Funciona perfeitamente e sua equipe depende disso todos os dias.
Em algum momento, entretanto, seus desenvolvedores desejam adicionar novas funcionalidades ao componente do lado do servidor. Para fazer isso, os desenvolvedores terão que reconstruir e reimplantar todo o aplicativo do lado do servidor. Embora o resultado final possa valer o esforço, leva um tempo considerável para passar por todo o processo de desenvolvimento (design, desenvolvimento, testes de perguntas e respostas e implantação).
Arquitetura de microsserviços
Agora vamos examinar a arquitetura de microsserviços. Enquanto um aplicativo monolítico está contido em uma única unidade, os microsserviços o dividem em uma coleção de unidades independentes muito menores. Cada uma dessas unidades funciona para atender todos os serviços de aplicação que então se combinam como um todo unificado.
Um dos melhores exemplos de arquitetura de microsserviços são os contêineres.
Você poderia implantar um NGINX servidor como um serviço monolítico. Instale o NGINX em um servidor Linux e você estará pronto para servir seus sites. Você poderia adicionar um banco de dados ao mix instalando Maria DB. Existem, no entanto, dois grandes problemas com tal implantação.
Primeiro, se quiser atualizar seu servidor web, você deve atualizar cada componente como um todo – o servidor web e o banco de dados. Em segundo lugar, este tipo de implantação pode não ser capaz de ser dimensionado para atender às necessidades da empresa.
A outra rota seria implantar esse servidor web como uma coleção de microsserviços, por meio de contêineres. Você pode implantar um pod Kubernetes contendo o servidor web NGINX, um pod contendo o banco de dados e, em seguida, conectá-los a um serviço de rede e um volume de armazenamento para armazenar dados.
Quando você precisar aumentar a implantação, o Kubernetes pode implantar automaticamente mais contêineres NGINX e MariaDB no cluster.
Além da escalabilidade, uma das melhores características da arquitetura de microsserviços é que, caso um dos serviços falhe, outro será implantado em seu lugar. Portanto, o failover está integrado. E como todos os seus componentes são implantados de forma independente, a perspectiva de atualização é muito mais tranquila. Isto é especialmente verdade com contêineres, onde o tempo de inatividade induzido pela atualização é quase inexistente.
Qual é o melhor para sua empresa?
Isso pode ser respondido de forma bastante simples:
- Se sua empresa precisa de alta escalabilidade, failover e confiabilidade, você precisa usar uma arquitetura de microsserviços.
- Se sua empresa exige principalmente ferramentas baseadas em cliente (instaladas em desktops) ou se você não considera a expansão horizontal em nível empresarial, a arquitetura monolítica é a melhor opção.
A advertência
Isso vem com uma ressalva. A arquitetura de microsserviços não é tão fácil de implantar. O Kubernetes é um desafio em quase todos os níveis concebíveis. Portanto, se você estiver interessado em arquitetura de microsserviços, certifique-se de ter desenvolvedores e administradores de TI preparados para a tarefa, caso contrário, você se encontrará em constante estado de resolução de problemas.
Além disso, para ter uma implantação de microsserviços bem-sucedida, você precisa de recursos. Para realmente aproveitar a escalabilidade dos microsserviços, você precisa de um data center com potência suficiente para lidar com essa arquitetura. Na maioria das vezes, isso significa implantar em um host de nuvem de terceiros, como AmazonAWS, Google Nuvem, Linode, Rackspaceou Microsoft Azure. A menos que você tenha um data center local realmente impressionante, você não alcançará os níveis de escala que alcançaria com um desses hosts.
No final, a escolha é sua. Mas para a maioria das empresas que buscam crescer muito além de tudo o que já alcançaram, os microsserviços são o caminho a seguir.
Fonte: BairesDev
