Strangler fig, feito com honestidade

Strangler fig é o padrão de migração que todo mundo recomenda e quase ninguém termina. Você coloca uma fachada na frente do sistema legado, direciona funcionalidades novas para o sistema novo, move as antigas uma por uma, e um dia o legado não tem mais nada e você desliga.

O padrão é sólido. Recomendo o tempo todo. Mas já auditei sistemas meio-estrangulados o suficiente para saber onde a honestidade quebra, e é sempre nos mesmos três lugares.

A fachada também é um sistema

A primeira desonestidade é tratar a fachada como um remendo temporário. Um proxy que direciona alguns caminhos para o sistema antigo e outros para o novo é uma peça de infraestrutura com seus próprios modos de falha, sua própria latência, seu próprio pipeline de deploy e sua própria necessidade de observabilidade. Se ele cai, os dois sistemas ficam inacessíveis. Se direciona errado, o bug é invisível para os dois times, porque cada um só vê o próprio tráfego.

Então a fachada é construída direito ou a migração fracassa no terceiro mês. Ela precisa de regras de roteamento em configuração, não em código. Precisa de métricas por rota para você ver que porcentagem do tráfego já migrou. Precisa da capacidade de mandar a mesma requisição para os dois sistemas e comparar as respostas, porque essa comparação é a única prova real de que uma funcionalidade migrada se comporta igual. E precisa de um dono documentado, porque 'o time da migração' vai ser desfeito antes de a migração terminar.

O sistema antigo não vai morrer sozinho

A segunda desonestidade é acreditar que, quando as funcionalidades novas forem para o sistema novo, o antigo vai definhar. Ele não definha. Fica exatamente do tamanho que era, porque as funcionalidades que nunca foram importantes o bastante para migrar ainda são importantes o bastante para alguém depender delas.

A cauda longa é a migração. Os primeiros sessenta por cento do tráfego se movem no primeiro terço do projeto, porque são os fluxos grandes e bem entendidos. Os últimos dez por cento levam mais tempo do que tudo antes, porque são o job mensal de reconciliação, a exportação que ninguém documentou, o endpoint que um parceiro externo chama uma vez por trimestre. Cada um exige investigação para descobrir se ainda importa.

O plano honesto reserva orçamento para isso. Lista toda capacidade do sistema legado antes da primeira linha de código novo, incluindo as feias, e atribui a cada uma uma decisão: migrar, aposentar ou substituir por algo mais simples. 'A gente descobre no caminho' é como migrações chegam a oitenta por cento e param para sempre, com dois sistemas para operar em vez de um.

A parte difícil são os dados, não o código

A terceira desonestidade é planejar a migração em torno de caminhos de código e deixar os dados para depois. Todo strangler fig que vi sofrer, sofreu por dados. O sistema novo precisa do cadastro do cliente. O antigo é dono dele. Agora ou os dois escrevem nas mesmas tabelas, o que ressuscita todos os problemas de banco compartilhado, ou os dados são copiados, o que significa job de sincronização, política de conflito e um período em que os dois sistemas discordam.

A sequência honesta migra a propriedade dos dados como parte de cada fatia, não como fase separada. Quando a funcionalidade de 'endereços' se move, a tabela de endereços vai junto, e o sistema antigo passa a ler endereços pela API do sistema novo. É mais lento por fatia, e é a única abordagem em que o sistema antigo realmente diminui. Uma migração que move todo o código e nenhum dado não moveu nada.

Como fica a honestidade no cronograma

Peço quatro coisas antes de endossar um plano de strangler fig. Um inventário completo das capacidades do legado, com decisão explícita para cada uma. Uma fachada com métricas, execução em paralelo e dono nomeado. Um plano de propriedade de dados por fatia. E uma definição de pronto que inclua desligar o sistema antigo, com data, e um orçamento para a cauda longa pelo menos tão grande quanto o da primeira metade.

Com isso, o padrão entrega exatamente o que promete: entrega contínua de valor enquanto o sistema antigo encolhe. Sem isso, entrega um segundo sistema, um proxy sem dono e um legado agora mais difícil de aposentar do que no primeiro dia, porque a própria migração virou dependência.

A figueira estrangula a árvore, sim. Mas só se alguém continuar regando a figueira depois do primeiro ano, quando ela para de ser empolgante.