Por que os microsserviços podem ser finalizados quando os monólitos voltam com força total

A mudança em direção aos microsserviços começou a ganhar impulso no início da década de 2010, à medida que as empresas de tecnologia reconheceram as limitações das arquiteturas monolíticas. No entanto, muitas empresas como Amazon (Prime Video), Invision, Istio e Segmento eles retornam à arquitetura monolítica. Este artigo explorará por que muitas organizações não conseguem fazer a transição para uma arquitetura de microsserviços.

O que é um monólito?

Uma arquitetura monolítica é simples: o usuário solicita dados e toda a lógica e dados de negócios residem em um único serviço. No entanto, os sistemas monolíticos enfrentam desafios como escalabilidade limitada, dificuldade na implementação de atualizações e vulnerabilidade a pontos únicos de falha.

Para resolver esse problema, muitas organizações tentaram migrar para uma arquitetura baseada em microsserviços para aproveitar vantagens como abstração e encapsulamento, implantação mais rápida, manutenção mais fácil e alinhamento mais próximo de cada serviço com a propriedade da equipe.

Por que microsserviços?

Numa arquitetura de microsserviços ideal, cada domínio de negócios atua como seu próprio serviço independente com seu próprio banco de dados. Essa configuração oferece benefícios como melhor escalabilidade, flexibilidade e resiliência. Considere o diagrama abaixo.

Fato

No entanto, as tendências recentes mostram que muitas empresas estão a afastar-se disto e a aderir a uma arquitectura monolítica. Isso ocorre porque é difícil atingir esse nível de harmonia no mundo real. A realidade muitas vezes se parece com a imagem abaixo.

Sabe-se que a mudança para uma arquitetura de microsserviços causa interações complexas entre serviços, chamadas circulares, problemas de integridade de dados e, francamente, é quase impossível livrar-se completamente do monólito. Vamos discutir por que alguns desses problemas ocorrem após a migração para uma arquitetura de microsserviços.

Limites de domínio incorretos

Idealmente, um único serviço deve encapsular um ou mais domínios de negócios completos, de modo que cada domínio seja autocontido dentro do serviço. Um domínio nunca deve ser dividido entre vários serviços, pois isso pode levar a interdependências entre serviços. O diagrama a seguir mostra como um único serviço pode conter um ou mais domínios inteiros para manter limites claros.

Em sistemas complexos do mundo real, definir limites de domínio pode ser um desafio, especialmente quando os dados são tradicionalmente conceituados de uma forma específica. O diagrama a seguir mostra a aparência dos sistemas reais em uma arquitetura de microsserviços quando os limites não são predefinidos ou quando os engenheiros adicionam novos serviços independentemente dos limites do domínio.

Se os domínios não estiverem bem definidos, a dependência de outros serviços aumenta, levando a muitos problemas:

• Dependências circulares ou chamadas excessivas: Quando os serviços são interdependentes, requerem trocas frequentes de dados.
• Problemas de integridade de dados: a divisão de um único domínio entre serviços faz com que dados profundamente interconectados sejam divididos em vários serviços.
• Propriedade vaga da equipe: Várias equipes podem precisar trabalhar juntas em domínios sobrepostos, levando a ineficiências e confusão.

Dados e funcionalidades profundamente conectados

Em uma arquitetura monolítica, os clientes muitas vezes ignoram as interfaces designadas e acessam o banco de dados diretamente porque é difícil impor o encapsulamento em uma única base de código. Isso pode levar os desenvolvedores a usar atalhos, especialmente se as interfaces não forem claras ou parecerem complicadas. Com o tempo, será criada uma rede de clientes intimamente ligados a tabelas de bancos de dados e lógicas de negócios específicas.

Ao migrar para uma arquitetura de microsserviços, cada cliente deve ser atualizado para funcionar com as novas APIs de serviço. No entanto, como os clientes estão tão ligados à lógica de negócios do monólito, é necessário refatorar sua lógica durante a migração.

Remover essas dependências sem interromper a funcionalidade existente leva tempo. Algumas atualizações de clientes costumam ser atrasadas devido à complexidade do trabalho, portanto, alguns clientes ainda usam um banco de dados monolítico após a migração. Para evitar isso, os engenheiros podem criar novos modelos de dados no novo serviço, mas manter os modelos existentes no monólito. Quando os modelos estão profundamente acoplados, isso leva ao particionamento de dados e funcionalidades entre serviços, causando múltiplas chamadas entre serviços e problemas de integridade de dados.

Migração de dados

A migração de dados é um dos elementos mais complexos e arriscados da migração para microsserviços. É essencial transferir de forma precisa e completa todos os dados relevantes para os novos microsserviços. Muitas migrações param nesta fase devido à complexidade, mas uma migração de dados bem-sucedida é fundamental para obter os benefícios dos microsserviços. Os desafios comuns incluem:

• Integridade e consistência de dados: Erros durante a migração podem levar à perda ou inconsistência de dados.
• Volume de dados: a transferência de grandes quantidades de dados pode consumir muitos recursos e muito tempo.
• Tempo de inatividade e continuidade dos negócios: a migração de dados pode exigir tempo de inatividade e potencialmente interromper as operações comerciais. Uma transição tranquila com impacto mínimo para os usuários é crucial.
• Teste e validação: testes rigorosos são necessários para garantir que os dados migrados sejam precisos, completos e funcionem bem no novo serviço.

Conclusão

Uma arquitetura de microsserviços pode parecer tentadora, mas a transição de um monólito é desafiadora. Muitas empresas se encontram em uma situação intermediária, aumentando a complexidade do sistema e causando problemas de integridade de dados, dependências cíclicas e propriedade pouco clara da equipe. A incapacidade de aproveitar ao máximo os microsserviços no mundo real é o motivo pelo qual muitas empresas recorrem a uma abordagem monolítica.

Supriya Lal é líder técnica do grupo para organização de plataforma de negócios na empresa Yelp.