Microsserviço 3

Os microsserviços não são o fim, são o meio. A decisão de usá-los deve ser consciente e racional. Considere os microsserviços apenas se a arquitetura atual não puder evoluir ou apresentar limitações. Pense primeiro no simples: o que pode ser feito com o que temos atualmente antes de considerar a adoção dos microsserviços?

Migração Gradual

A migração para microsserviços deve ser feita de forma gradual. Uma abordagem "big bang" resultará em um big bang. Comece separando pequenas partes do monolítico, pois isso permitirá conhecer os microsserviços, limitar o impacto em caso de problemas e aprender com os erros.

Inicie com algo pequeno e evolua gradualmente.

Decompor um monolítico em microsserviços de forma prematura pode ser custoso, especialmente quando o domínio do negócio é novo para o time, pois a definição de fronteiras será um grande desafio. No entanto, decompor um sistema existente em microsserviços torna-se mais fácil do que adotar microsserviços desde o início do projeto.

Entendendo o contexto, um bom ponto de partida para a separação de funcionalidades do monolítico para microsserviços seria identificar as partes mais voláteis da base de código. Algumas funcionalidades podem estar tão acopladas ao monolítico que a separação torna-se impossível. A decisão sobre qual funcionalidade separar deve equilibrar a facilidade de extração e a vantagem de extrair o microsserviço.

Decomposição

Antes de migrar tudo, é necessária uma análise entre código e dados para verificar a viabilidade da migração. Se for possível migrar o código, mas não os dados, poderíamos ter um problema.

Os padrões que podem ser utilizados para decomposição são:

• estrangulamento (strangler fig): encapsula o sistema antigo e o novo, permitindo que o novo sistema assuma cada vez mais funcionalidades do antigo. Dependendo da funcionalidade solicitada, a chamada será interceptada e direcionada para o sistema antigo ou para o novo.
• execução paralela: executa tanto o monolítico quanto o microsserviço lado a lado, atendendo às mesmas requisições e comparando os resultados.
• feature flag: permite ativar ou desativar uma funcionalidade on-demand.

Ao decompor o sistema monolítico, alguns problemas se tornarão evidentes:

• desempenho: joins que antes eram feitos no banco de dados agora serão feitos dentro dos microsserviços, aumentando a latência. Pode ser necessário adotar estratégias de otimização, como caching.
• integridade dos dados: com os dados distribuídos em diferentes bancos de dados, não há como garantir a integridade e relacionamento dos dados como antes. Estratégias de soft delete serão necessárias.
• transações: com dados separados em diferentes bancos de dados, não há garantia de ACID nas transações.

Ao iniciar a adoção da arquitetura de microsserviços, tenha claro o que se espera alcançar. Crie um ciclo de alteração, faça o rollout, avalie e repita.