🤚🏾 🕵️ 🚭 Custos ocultos de mudar para microsserviços 👩🏻‍💼 👷🏻 👀

Em um mundo ideal, você poderia simplesmente pegar o código-fonte de um monólito, dividir seu código entre microsserviços e, conectando-os, obter o mesmo sistema, mas em uma nova arquitetura. Isso nunca acontece na vida. A vida traz muita complexidade a esta imagem perfeita. Quais são os desafios específicos que podem dobrar ou triplicar seu orçamento de migração de microsserviços?

Descreverei os fatores que estão atrasando a transição para microsserviços e tornando-a muito mais cara do que inicialmente esperado. Você receberá uma lista de verificação para avaliar esses fatores e será mais realista sobre seu orçamento de transição.

Falei com este tópico no ArchDays 2020 . Siga o link para encontrar slides e vídeos (a serem publicados em breve) da palestra https://blog.byndyu.ru/2020/12/archdays-2020.html .

Nº 1 Mudando a abordagem para trabalhar com dados mestre

Um monólito geralmente tem um ou dois grandes bancos de dados contendo dados mestre variegados. O próprio monólito contém o código que gerencia esses dados mestre. Por exemplo, se a parte "verde" do banco de dados for um diretório de endereços, o código monolítico "verde" controlará os endereços. Acontece que existem muitos dados mestres no banco de dados monolith e no código monolith existem muitos sistemas mestres:

Em microsserviços, os dados mestres são gerenciados de maneira diferente: há muitos bancos de dados, não é possível combinar dados mestres entre microsserviços e apenas um microsserviço pode gerenciar os dados mestres. Por exemplo, o microsserviço "verde" agora recebeu seu próprio banco de dados com endereços e só ele pode fazer alterações nesses dados mestre. Outros microsserviços podem ler dados com endereços, mas apenas por meio do microsserviço "verde":