O objetivo deste artigo é trazer pontos importantes sobre a migração de um monólito para microsserviços e quais recursos a Oracle Cloud fornece para suas aplicações.

Existem diversos pontos de atenção para esse trabalho, porém aqui irei elencar apenas cinco que não podem ser esquecidos de maneira alguma.

É Possível encontrar outros tópicos na internet, mas caso queira tirar alguma dúvida ou apenas conversar sobre o tema, sintam-se a vontade para me mandar mensagem =)

O que são aplicações monolíticas?

Monólito significa “obra construída em uma só pedra”, refere-se a forma de desenvolver um sistema, programa ou aplicação onde todas as funcionalidades e códigos estejam em um único processo.

Essas funcionalidades ficam em um mesmo código e em sua execução acabam compartilhando processamento, memória, banco e arquivos.

Como tudo está em um único bloco, desenvolver dessa forma acaba sendo mais ágil, se comparado com outras arquiteturas, sendo possível também desenvolver uma aplicação em menor tempo e com um menor nível de complexidade INICIAL. Sim, no início pode ser menos complexo, mas com o andar do desenvolvimento, isso pode mudar.

Vantagens e desvantagens de um Monólito.

Complexidade

Para aplicações novas ou a famosa POC, onde a ideia ainda precisa de uma validação, o sistema monolítico apresenta menor complexidade para desenvolvimento inicial. Muitas empresas optam por um caminho “híbrido”, onde desenvolvem e validam suas ideias construindo um monólito, mas já pensando e se preparando para uma possível migração para sistemas distribuídos, por exemplo.

Custos

O custo de uma aplicação pode ser uma vantagem ou uma desvantagem, dependendo do cenário em que o sistema se encontra. Para projetos iniciais o seu custo tende a ser uma vantagem, visto que você precisa apenas de uma máquina para rodar todo o sistema. Com o passar do tempo e com a sua aplicação escalando, ela pode se tornar uma desvantagem.

Escalabilidade

Como estamos na era da nuvem e custos por demanda, uma aplicação monolítica pode se tornar cara para ser escalada, por se tratar de um único código, todas as funcionalidades precisam ser escalada como um todo, normalmente escalada verticalmente, adicionando mais processador, memória e etc, para aplicação, ou horizontalmente por modelos de balanceador de carga.

Manutenibilidade

Conforme uma aplicação monolítica cresce, diversas funções são adicionadas a um mesmo código e processo, o que pode acarretar em quedas em cascata da aplicação como um todo. O código se torna complexo e difícil de dar manutenção, as entregas por sua vez acabam se tornam mais críticas, menos frequentes e até estáveis.

O que são microsserviços?

Os microsserviços consistem em uma abordagem arquitetônica nativa de cloud na qual um único aplicativo é composto de muitos componentes ou serviços menores que são implementáveis de forma independente e têm acoplamento fraco. Esses serviços normalmente:

• Têm a própria stack de tecnologia, incluindo o modelo de banco de dados e gerenciamento de dados;
• Comunicam-se sobre uma combinação de APIs de REST, fluxos de eventos e brokers de mensagens;
• São organizados por recurso de negócios, com a linha separando os serviços que, muitas vezes, são chamados de contexto delimitado.

Benefícios

Manutenibilidade

O código pode ser atualizado mais facilmente, novos recursos ou funcionalidades podem ser incluídos sem mudar nenhuma parte do aplicativo.

As equipes podem usar stacks e linguagens de programação diferentes para componentes diferentes.

É possível ajustar a escala dos componentes de forma independente, reduzindo o desperdício e o custo associado ao ajuste de escala de aplicativos inteiros, como nos casos em que há um único recurso sobrecarregado.

Resumindo

A abordagem da arquitetura monolítica é composta de um grande aplicativo com acoplamento forte, o que difere da arquitetura de microsserviços, na qual os microsserviços compõem um único aplicativo de muitos serviços menores com acoplamento fraco.

Migração

Agora que temos em mente o que são aplicações monolíticas e o que são microsserviços precisamos falar sobre o que você precisa fazer antes de por um microsserviço em produção. Para ficar mais fácil, separei esta etapa em cinco pontos.

Rate Limiting

Todo Microsserviço precisa ficar funcionando o tempo todo, e em alguns momentos ele pode receber mais requisição do que ele foi configurado para receber. Quando isso acontece, rola um efeito dominó que acaba impactando todos os seus outros microsserviços(Um vai derrubando o outro). A explicação do por que isso acontece é bem simples.

Quando um microsserviço começa a ser bombardeado de requisições, ele começa a sofrer algumas lentidões e quando a chamada para ele fica lenta ele começa a deixar todos os outros serviços lentos também. Ou seja, é melhor um microsserviço que não responde ou que retorne algum erro, do que um lento.

Uma das formas para suportar essas cargas de requisiçoes para que ele não fique lente e nem atrapalhe os outros microsserviços é o rate limiting. Com ele, podemos definir quantas requisições por segundo nosso serviço vai receber e categorizar quais microsserviços que podem mais realizar consultas e isso acaba sanando essa dor que existia antes.

Retry

Em Determinados momentos podemos realizar uma requisição em algum microsserviço, e ele pode estar lento ou fora do ar por alguns momentos, pois um deploy está em andamento. Ao invés de largar essa requisição e retornar um erro de primeira, com o Retry, podemos realizar uma nova tentativa e isso pode salvar inúmeras transações.

Podemos implementar, por exemplo, quantas vezes e de quanto em quanto tempo ele vai tentar novamente até que enfim desista daquela transação. Uma dica que dou é, trabalhar com intervalos diferentes entre os microsserviços.

Comunicação assíncrona

Trabalhar com comunicação síncrona acaba se tornando muito arriscado quando estamos nos referindo a microsserviços. Se um serviço acaba ficando fora do ar por algum motivo, podemos perder diversas requisições. Quando trabalhamos com a comunicação assíncrona, garantimos que mesmo que algum serviço esteja fora do ar se alguma requisição for feita a ele, não perderemos, pois, estaremos utilizando um message broker com algum sistema de mensageria.

Então mesmo que um serviço esteja por um momento de indisponibilidade, quando retornar, teremos a certeza que ele receberá todas as mensagens enviadas durante essa pausa e processará tudo.

Idempotência

Em algum momento podemos receber uma requisição e nosso serviço estar um pouco lento. Por algum motivo meu microsserviço tentou novamente, pois a primeira requisição não foi processada, e ai temos duas requisições iguais que ou vão ser processadas, ou descartadas.

Independente da quantidade de mensagens que forem enviadas, precisamos ter em nossas aplicações a idempotência e garantir que somente uma das diversas requisições serão processadas e evitar que requisições iguais sejam processadas em simultaneamente.

Garantias de entrega

Quando trabalhamos de forma assíncrona, precisamos tomar muito cuidado e diversas pessoas acabam pecando um pouco nisso. Ao enviar uma mensagem pelo message broker, não podemos simplesmente enviar e esquecer disso, precisamos ter a garantia que o message broker realmente recebeu aquela mensagem.

Estude como sua equipe vai trabalhar com essas garantias de entregas e recebimentos de mensagem, pois é um ponto de extrema importância.

Microsserviços com a Oracle Cloud

A Oracle Cloud possui diversos recursos que ajudam tanto na criação de aplicações a partir da nuvem quanto na migração. Para os microsserviços temos diversos recursos que facilitam e já te entregam tudo que é necessário para colocar sua aplicação no ar.

Grande parte das vezes para cumprir os requisitos de uma aplicação microservice saudável, é necessário colocar diversas ferramentas diferentes para trabalhar em conjunto e nem sempre todas se comunicam muito bem. A Oracle Cloud já fornece todos os serviços necessários para facilitar o dia a dia de quem gerencia as aplicações.

Como um dos grandes beneficios da utilização do OCI, podemos observar no desenho de arquitetura acima, todos os recursos nativos sem a necessidade de por exemplo usar um Kong API, Docker e etc.

No próximo artigo, vamos abordar com mais detalhes cada um dos itens da arquitetura acima, entender quais ferramentas de mercado podemos substituir por features nativas na oracle cloud e como enxergar esses benefícios no dia a dia.

Caso tenha alguma dúvida sobre migração de aplicações ou sobre Oracle Cloud, entre em contato comigo!

Agradeço a todos e abraços.