Por que você deve usar microsserviços e contêineres? – IBM Developer

Por que você deve usar microsserviços e contêineres?

O que são microsserviços e contêineres?

Em primeiro lugar, o que são microsserviços? Uma arquitetura de microsserviços divide seu aplicativo em vários serviços que realizam funções detalhadas e fazem parte de seu aplicativo como um todo. Cada um dos microsserviços terá uma função lógica diferente no aplicativo.

Os aplicativos tradicionais têm arquiteturas monolíticas em que todos os componentes e funções ficam em uma só instância. Os microsserviços dividem os aplicativos monolíticos em partes menores. O diagrama abaixo compara as arquiteturas monolíticas e de microsserviços.

Diagrama que mostra a arquitetura de um aplicativo monolítico à esquerda e a arquitetura de um aplicativo de microsserviços à direita

Mas então, onde colocamos os microsserviços? Em contêineres.

Contêineres são pacotes de seu software que incluem todos os elementos que ele precisa executar, como códigos, dependências, bibliotecas, binários e muito mais. Docker e Kubernetes são as estruturas mais populares para organizar vários contêineres em ambientes empresariais. Em comparação com as máquinas virtuais (VMs), os contêineres compartilham o kernel do sistema operacional em vez de ter uma cópia completa dele, como criar várias VMs em um só host. Embora seja possível colocar seus microsserviços em várias VMs, nesse caso, geralmente você usaria contêineres, já que eles ocupam menos espaço e são inicializados mais rapidamente.

Por que usar uma arquitetura de microsserviços?

A arquitetura de microsserviços foi criada para resolver os problemas causados pelos aplicativos monolíticos. Os microsserviços já são bastante utilizados, e alguns websites de grande escala já transformaram seus aplicativos monolíticos em microsserviços.

Alguns benefícios de usar uma arquitetura de microsserviços são:

  • Os desenvolvedores trabalham com uma base de código menor, ao contrário da base maior usada nos aplicativos monolíticos. Quando os componentes do aplicativo são fracamente acoplados, os desenvolvedores entendem facilmente o código de origem e isso não atrasa o desenvolvimento. Sem falar que seu IDE será mais rápido se você trabalhar com menos linhas de código. Os desenvolvedores não precisarão lidar com as complexidades e as dependências das funções geralmente presentes em um aplicativo monolítico.
  • As responsabilidades dos desenvolvedores serão mais definidas. É possível designar uma equipe por componentes ou microsserviços do aplicativo. As análises de código serão mais rápidas. As atualizações serão mais ágeis e não seria necessário desenvolver e implementar tudo, como acontece em um aplicativo monolítico.
  • O conjunto de tecnologia do aplicativo pode variar entre os microsserviços. O aplicativo não precisará mais depender de uma linguagem ou biblioteca. Os microsserviços podem utilizar diferentes linguagens de programação conforme a preferência dos desenvolvedores. É possível ter microsserviços poliglotas, como os do diagrama abaixo.

    Diagrama dos microsserviços poliglotas, em que o serviço A em Node.js é o principal em relação ao Serviço B em Java ou ao Serviço C em Python

  • A entrega contínua será mais fácil. Em comparação com um aplicativo monolítico, não será necessário implementar tudo novamente só por causa de uma simples mudança nos microsserviços. É possível optar por recriar e implementar o único microsserviço que precisa ser atualizado. As atualizações frequentes serão mais rápidas.

  • A escalabilidade de cada microsserviço será independente. É possível escalar cada componente de seu aplicativo com base no recurso de que ele precisa. Não seria necessário criar várias instâncias de todos os elementos, como acontece em um aplicativo monolítico. Escalar os microsserviços fará um uso eficiente dos recursos disponíveis, em vez de ter várias cópias de todo o aplicativo em um aplicativo monolítico.

    Diagrama que mostra como cada microsserviço pode ser escalado de forma independente dos outros

  • Os dados podem ser descentralizados. É possível usar bancos de dados ou armazenamentos diferentes para seus microsserviços. Por exemplo, será possível usar um banco de dados NoSQL se ele se adaptar melhor a seu microsserviço que um banco de dados relacional. Um microsserviço também pode precisar apenas de um simples banco de dados de valores-chave, como Redis. Como no diagrama abaixo, é possível usar uma combinação de bancos de dados Cloudant, MySQL e MongoDB. Diferentes bancos de dados podem ser aproveitados para armazenar diferentes tipos de dados.

    Diagrama que mostra como cada serviço pode usar um banco de dados diferente dos outros serviços

  • Isole as falhas. Um erro ou um bug de um microsserviço não desativa o sistema inteiro. Quando você tem componentes fracamente acoplados e um microsserviço de seu aplicativo trava ou gera erros, há menos chances de que os outros microsserviços sejam afetados, já que eles estão em seus próprios contêineres e não dependem totalmente uns dos outros. Um aplicativo monolítico poderá desativar todo o processo de seu aplicativo se o bug ou o erro não for detectado corretamente.

Quais são as desvantagens?

Embora os microsserviços resolvam alguns dos problemas de uma arquitetura monolítica, eles têm seu próprio conjunto de problemas. Se você estiver tentando dividir seu aplicativo monolítico em microsserviços, o primeiro desafio será saber como fazer isso. É possível dividi-lo em funções de negócios, como um microsserviço para lidar com envios e outro para lidar com serviços de pagamento. No fim, seus componentes devem ter apenas um pequeno conjunto de funções ou responsabilidades.

Alguns problemas de uma arquitetura de microsserviços que eu identifico são:

  • Assim que o número de microsserviços aumenta, pode ser difícil monitorá-los. A configuração inicial da integração contínua e da entrega contínua (CI/DI) pode ser difícil, já que será preciso lidar com a complexidade adicional de ter esses vários microsserviços.
  • Complexidade. Os microsserviços precisariam de mais coordenação, principalmente quando há várias equipes envolvidas. Eles também introduziriam mais chamadas de rede quando precisarem interagir com outros microsserviços, o que não existe em um aplicativo monolítico. O processo não seria tão simples quanto implementar uma instância de um aplicativo. Outras coisas que também precisam ser consideradas são: como lidar com a comunicação entre os microsserviços, lidar com erros para evitar interromper os outros microsserviços e adicionar mais casos de teste em cada componente.
  • Encontrar e rastrear os bugs e erros de seu aplicativo. Seria mais fácil encontrá-los se seu microsserviço tivesse apenas uma rota, mas, se um microsserviço se comunica com vários outros microsserviços, pode ser um processo muito demorado procurar apenas esse erro.

    Diagrama de duas solicitações de rastreamento, em que uma exibe um erro

  • Rotear seus microsserviços exigirá mais. Você precisará dedicar seu tempo para configurar e controlar o fluxo de seus microsserviços. Também será necessário monitorar as versões de seus microsserviços e lidar com o roteamento deles.

    Diagrama do roteamento de microsserviços

  • Os microsserviços podem consumir mais recursos que um aplicativo monolítico. Embora uma das vantagens que mencionei foi que a escalabilidade e os recursos podem ser utilizados de uma forma melhor e mais eficiente, cada componente precisaria de sua própria instância e contêiner, possivelmente resultando em mais uso de memória e CPU.

Ferramentas que podem ajudar com os microsserviços

Kubernetes

Kubernetes é uma plataforma de organização de contêineres que permite implementar, escalar e gerenciar todos os seus contêineres. Ele permite automatizar a implementação de seus microsserviços conteinerizados. Isso facilita o gerenciamento de todos os componentes e microsserviços de seu aplicativo. Você deveria aprender a usar o Docker para conteinerizar seus microsserviços. A IBM tem uma oferta pública do IBM Cloud Kubernetes Service que gerencia o cluster para você.

Istio

O Istio resolve algumas das desvantagens dos microsserviços. Ele é uma malha de serviço que ajuda você a gerenciar seus microsserviços ainda mais. O Istio pode ser instalado no Kubernetes, onde pode ajudar você a rastrear e monitorar seus microsserviços. Além disso, ele pode ajudar você a rastrear rapidamente os erros e bugs de seu aplicativo, caso haja algum. O Istio também pode gerenciar o tráfego de seus microsserviços, gerenciando e controlando o fluxo. Com ele, é muito fácil configurar suas rotas. O Istio oferece segurança aos microsserviços, com TLS mútuo ou limitando o acesso aos serviços externos. Também é possível instalar o Istio no IBM Cloud Kubernetes Service.

Resumo

Em minha experiência, usar uma plataforma de organização de contêineres é essencial para desenvolver seu aplicativo com microsserviços. O Kubernetes é uma das opções preferidas dos desenvolvedores, já que ele leva o aplicativo rapidamente do desenvolvimento à produção. E, o que é ainda melhor, ele é open-source!

Os desenvolvedores que estão começando a criar aplicativos devem decidir se seria benéfico usar uma arquitetura de microsserviços em vez de uma monolítica. Eles devem pensar na usabilidade e escalabilidade do aplicativo em longo prazo. Não há problemas em começar com uma arquitetura monolítica, mas, assim que o aplicativo aumentar, ficaria cada vez mais difícil dividi-lo em microsserviços. Nesse caso, seria mais benéfico começar a usar microsserviços na fase de desenvolvimento inicial. Para os aplicativos monolíticos existentes, os desenvolvedores devem pensar em como e quais componentes eles desacoplariam do aplicativo.

Apesar das desvantagens, os microsserviços continuam sendo populares entre os desenvolvedores e as empresas, já que eles beneficiam muito as demandas de usuários e aplicativos. Devido à flexibilidade, os desenvolvedores e as empresas poderão realizar desenvolvimentos ou atualizações rápidos do aplicativo assim que tiverem o nível certo de microsserviços.