Monolito para Microservice — Um pé de cada vez

Hoje vemos muitas discussões, apresentações, sobre microservice, sobre monolito, sobre como temos que mudar a arquitetura de monolito para microservice. Mas não é tão simples, para quem não é acostumado com microservice, entender o porque devemos mudar, o que vamos ganhar com a mudança e como iniciar essa mudança.

Vou tentar colocar aqui a minha experiência na conversão de um sistema complexo, e por onde começamos.

Entendendo os conceitos.

O que é Sistema Monolítico?

Sistema Operacional Monolítico é um termo oriundo dos estudos referentes a sistemas operacionais, que designa o modelo em que o sistema operacional é codificado por via de uma coleção de procedimentos, onde é permitido a qualquer um deles em qualquer parte do programa “chamar” outro procedimento.

A arquitetura monolítica é a mais usada a muito tempo. As empresas desenvolvem uma solução, comercializam, e todo o código está dentro do mesmo projeto.

O monolito tem vantagens e desvantagens. Uma das grandes desvantagens é que é muito difícil escalar o sistema. Muito comum que cada cliente que você tiver, vai ter que replicar/duplicar o servidor, isso duplicando o custo. Quando mais clientes tiver, mais servidor vai ser preciso, mais caro vai ficar.

Outra desvantagem é que o código fonte fica muito grande e dificulta muito a manutenção. Cada liberação de versão passa a ser muito complexa.

O que é Microservice?

Russ Mile define microservice como “um serviço com um único propósito e que execute bem a sua tarefa dentro de um nível de granularidade e suporte as mudanças do sistemas que são consideradas importantes tanto em tempo de projeto quanto em tempo de execução. O foco principal é tentar construir software que pode se adaptar e isto só é possível de ser feito se as partes forem pequenas suficientes para se ajustar às diferenças nas mudanças de sua arquitetura.”

Muito das empresas hoje estão migrando seus sistemas para a Cloud. A mais famosa, AWS Amazon. Netflix é um exemplo, entre outros, que converteram seu monolito para microservice e roda todo na Amazon.

Como o conceito de microservice é ter sistemas pequenos, ele revolve um dos problemas do monolito, que são sistemas grandes, com grande número de códigos, mas ele cria um complicador que não tínhamos. Fica muito mais difícil de monitorar os sistemas. Agora temos vários mini sistemas, integrados em sí, podendo rodar em servidores separados, gerando vários logs, podendo cair a qualquer hora, etc, etc, etc.

Antes de iniciarmos o desenvolvimentos, é interessante ter respostas para as seguintes perguntas.

1. Como vamos descobrir quais sistemas estão online?
2. Como vamos centralizar todos os logs dos sistemas?
3. Como vamos fazer para controlar todas as configurações de sistemas e ambientes?
4. Como vamos escalar?
5. Como vamos controlar quais sistemas estão fora? Os que caíram por algum problema?
6. Como vamos monitorar os erros?
7. Como vamos monitorar as funcionalidades que mais são executadas?

São tantas as perguntas que vamos focar nessas mais primordiais. Ao decorrer o post vamos respondendo as perguntas.

Bom, agora que entendemos os conceitos, por onde começar?

===============

Quer aprender microservices na prática? Todos os cursos são focados em microservices. Veja abaixo os principais.

• Hands-On. Seu primeiro microservice com Spring Boot
• Microservice inspirado no Spotify usando SpringCloud e Kafka
• Criando microservices linha a linha com Spring Boot e Kafka
• Comunicação entre microservices usando Spring Cloud
• Microservices inspirado no Netflix+ Minikube e Loadbalancer

Entre no site e aproveite os cupons de desconto.

https://www.alcateiadev.com.br/

=====

Primeira decisão: Antes de começar

Já definido como vai ser feito a conversão do sistema, precisamos agora chegar na definição de como vamos administrar e monitorar nossos microservices.
Decidimos criar o projeto cloud-infra. Neste projeto vamos configurar os sistemas que vamos usar para monitorar, e administrar nossos microservices.

• Discovery (Consul): Descobrir quais sistemas estão online;
• GrayLog: Centralizar todos os logs dos sistemas;
• Server-config (SSO Netflix): Centralizar todos as configurações dos microservices;
• Hystrix (SSO Netflix): Circuit Breaker;
• Eye: Monitorar as funcionalidades;
• Elasticsearch/Kibana: Visualizar o monitoramento;
• Jenkins: Integrações e deploy;
• API Gateway(Zull, Discovery Client): Roteamento;

Esses sistemas juntos formaram nossa infraestrutura. Todos os microservices que foram criados deviam se integrar a nossa infraestrutura.
Com o Consul, era possível saber se o microservice estava em pé e quantas instâncias de cada microservice estavam em pé.
O API Gateway, através do componente Zull, usava essas informações para fazer automaticamente as rotas.

Segunda decisão: Refazer tudo ou fazer aos poucos?

Essa é a primeira questão importante que devemos resolver.
Particularmente, eu não gosto da frase: “Vamos refazer tudo na cloud”. Passar muito tempo refazendo um sistema inteiro pode ser um grande tiro no pé.
Assisti uma palestra do Roberto Marin, (pode ser visto aqui no infoq), que ele aborda este problema de refazer tudo ou ir incrementando as funcionalidades, e cita o exemplo da Nokia, que decidiu refazer todo o sistema operacional e acabou dando tudo errado até fazer parceria com a Microsoft.

Nossa primeira decisão foi usar a estratégia StranglerApplication e passar o sistema para a cloud aos poucos.

“Criar um novo sistema em torno do antigo, deixando-o crescer lentamente ao longo do tempo até o antigo sistema ser estrangulado.”
“Entregando funcionalidades valiosas para o negócio dá à equipe a credibilidade para ir mais longe.”

Iremos pegar as funcionalidades que mais sobrecarregam o sistema e retirar do monolito.
Esta abordagem é bem mais segura, podendo fazer funcionalidade menores, testar bem, facilitando a correção se algum problema, sem impactar diretamente no monolito.

Terceira decisão: Onde quebrar o sistema?

Nossa terceira decisão era identificar onde nós iríamos quebrar o sistema.
Conversando muito com a equipe, decidimos usar algo parecido com a abordagem a seguinte.
A pontuação é somente para ilustrar quais os pontos eram mais importante.

1. Funcionalidades que fazem o sistema cair: 8 pontos;
2. Processos assíncronos, Eventos: 7 pontos;
3. Agendamentos: 6 pontos;
4. Agendamento que fazer o sistema cair: 10 pontos;
5. Funcionalidades com muitos acessos: 6 pontos;

Trabalhando dessa forma, foi possível fazer correções, trabalhar em performance, melhorias e ainda deixar o monolito mais estável até que não sobre nenhuma funcionalidade.

Quarta decisão: Design for Data Separation

Livro “Modern Java EE Design Patterns”
“Considere um aplicativo tradicional monolítico que armazena dados em um único banco de dados relacional. Cada parte do aplicativo acessa os mesmos objetos de domínio e geralmente não há problemas em torno de transações ou separação de dados. A separação de dados é diferente com microservices. Se dois ou mais serviços operam no mesmo armazenamento de dados, você terá problemas de consistência. Existem maneiras possíveis de contornar isso (por exemplo, transações), mas geralmente é considerado um antipattern.”

Cada microservice deve usar seu próprio banco de dados. Parece bem simples, mas quando começa a estrangular o sistema, simplismente não conseguimos visualizar a separação do banco.
Normalmente as tabelas que vocẽ for trabalhar vai estar ligada a várias outras tabelas.
Vai ter vários pontos do sistema, que não necessariamente é o ponto que está trabalhando, que vai estar consultando essa tabela.
Remover ela e colocar em um banco novo, vai gerar problemas que você nem vai conseguir pegar rápido.

Na nossa experiência, acabamos usando o mesmo banco, sem fazer essa separação. Tivemos grandes problemas com conexões.

Problema:

Forma correta:

A solução é projetar um microservice com seu próprio banco, mas como é bem complexo, uma boa estratégia utilizar o Teiid.

O Teiid facilita nessa nova modelagem. Com ele podemos criar um banco virtual, ligado ao banco de produção.
Assim seu microservice se conecta ao banco virtual. O Teiid fica responsável por sincronizar os dados para o banco de produção.
Essa é um boa estratégia para ser usada, como primeiro passo para separação do sistema.
Depois de alterar todos os pontos do sistema para usar o novo microservice, podemos deixar de usar o banco virtual e transferir para um outro banco.

Este livro fala mais sobre o Teidd e outras técnicas para lidar com o banco de dados.

Resumo

Não é tão simples, mas também não é impossível fazer a migração.
É interessante analisar os casos de sucesso e insucesso, mas cada equipe ou empresa vai adaptar e encontrar a melhor forma de fazer o projeto.
O mais importante é entrar em pauta, discutir, e colocar o projeto para rodar, projetando benefícios a longo prazo.
No final, os ganhos valerão muito a pena.