Ao “extrair” um microsserviço de um monólito, elimine duplicação de “features” e estruture os times adequadamente

Uma vez que um time, transformando um monólito em microsserviços, tenha efetivamente, 1) adotado práticas e técnicas para desassociar os processos de deploy e release; 2) colocado um “primeiro” microsserviço imperfeito em produção e 3) controlado acessos a base de dados; devemos garantir que todo “código morto” no monólito seja eliminado e garantir que os times técnicos estejam devidamente estruturados para suportar a evolução.

Na prática, features originalmente providas pelo monólito, agora são providas pelo novo microsserviço e devem ser removidas do sistema original o quanto antes. O momento ideal é quando já houverem evidências de que a nova implementação já é confiável o suficiente.

Para reduzir a chance de “quebras” em outros sistemas, entretanto, é aconselhável não remover imediatamente o acesso às features fornecido pelas APIs internas do monólito. No lugar disso, é coerente modificar essas APIs para que consumam o novo microsserviço.

Importante indicar que todas as medidas adotadas até aqui aumentam consideravelmente a pressão sobre a rede. Entretanto, sistematicamente, estão sendo superadas etapas de transformação e a condição atual é intermediária. Daqui para frente, as medidas técnicas vão na direção de reduzir essa pressão. O processo de transformação de um monólito em microsserviços consiste na troca, contínua e sistemática, de dívidas técnicas mais caras por outras mais baratas.

A pressão sobre a infraestrutura “grita” pela adoção de práticas efetivas de DevOps. Não consideramos viável, nem mesmo responsável, adotar microsserviços sem reduzir as distâncias entre desenvolvimento e operação.

Em termos organizacionais, a evolução da arquitetura deve impactar na “forma” da área técnica. A mesma segmentação que for aplicada nos sistemas deve estar sendo replicada naturalmente nos times que precisam buscar operar da maneira mais independente possível. Geralmente, a parte do time que mantinha o código eliminado do monólito, agora deve se concentrar em manter o microsserviço da forma mais independente possível. É fundamental que seja compreendido que se a estrutura de comunicação da organização não refletir, da forma mais direta possível, a estrutura do software que ela produz, o fracasso é uma certeza!

Por outro lado, quanto maior a relação entre as estruturas de comunicação dos times técnicos e a estrutura de componentes do software sendo desenvolvido, maiores as chances de sucesso.

Todo acoplamento que persistir entre monólito e o novo microsserviço se refletirá em dificuldades de comunicação entre os times e isso é ótimo! Afinal, aumentará a urgência por revisões na arquitetura para “reduzir a dor”. Toda ação irá refletir em iniciativas para reduzir a “dependência”, sobretudo para o deploy, e o impacto sobre o velocity é potencialmente brutal.