Jornada para Microsserviços

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.

Em Resumo
  • O fato

    Em um processo de transformação de um monólito em microsserviços, cada sucesso na extração de funcionalidades representa "código morto" no sistema original.
  • O insight

    Todo "código morto" deve ser eliminado ASAP, eventualmente aumentando, temporariamente, a pressão sobre a rede. Para isso, é essencial adotar práticas de DevOps e garantir que a estrutura dos times reflita a estrutura de comunicação dos diversos componentes.
  • Os benefícios

    A nova estrutura dos componentes do software "puxa" práticas a cultura ágil e o amadurecimento das relações. Além disso, a organização dos times passa a ser mais "direta", impactando o velocity positivamente.

Elemar Júnior

Microsoft Regional Director e Microsoft MVP. Atua, há mais de duas décadas, desenvolvendo software e negócios digitais de classe mundial. Teve o privilégio de ajudar a mudar a forma como o Brasil vende, projeta e produz móveis através de software. Hoje, seus interesses técnicos são arquiteturas escaláveis. bancos de dados e ferramentas de integração. Além disso, é fascinado por estratégia e organizações exponenciais.

Talvez você goste também

Carregando posts…

Mais posts da série Jornada para Microsserviços

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *