O padrão Strangler Fig moderniza .NET legado substituindo o monólito aos poucos: uma camada de roteamento, como o proxy reverso YARP, é colocada na frente da aplicação, e cada funcionalidade é reescrita em ASP.NET Core e passa a receber o tráfego somente depois de validada. O sistema antigo e o novo convivem em produção até que o legado possa ser desligado, sem migração “big bang”.
Para quem decide sobre a modernização de aplicações .NET, essa abordagem resolve o principal dilema da modernização de aplicações legadas: como evoluir um sistema crítico sem parar a operação e sem apostar tudo em uma reescrita completa.
O que é o padrão Strangler Fig?
O nome, popularizado por Martin Fowler, vem de uma figueira que cresce em volta de uma árvore hospedeira até substituí-la. Em software, o novo sistema cresce em volta do .NET legado: funcionalidade por funcionalidade, o tráfego é desviado para o código moderno, até que o sistema antigo não tenha mais função.
Strangler Fig ou reescrita completa?
| Critério | Reescrita completa (“big bang”) | Strangler Fig |
|---|---|---|
| Risco | Alto: tudo muda de uma vez | Baixo: cada etapa é pequena e reversível |
| Entrega de valor | Somente no fim do projeto | A cada funcionalidade migrada |
| Continuidade operacional | Depende de uma virada única | Legado e novo convivem em produção |
| Rollback | Difícil e caro | Basta voltar a rota para o legado |
| Aprendizado | Problemas aparecem tarde | Ajustes contínuos a cada etapa |
Como aplicar o Strangler Fig em uma aplicação .NET
- Faça o assessment: identifique domínios de negócio, dependências bloqueadoras, como Web Forms e WCF, e pontos de menor acoplamento. Veja o guia de assessment de .NET legado.
- Crie a nova aplicação ASP.NET Core: no .NET 10, com CI/CD, testes automatizados e observabilidade desde o início.
- Coloque a camada de roteamento: um proxy reverso, como o YARP, recebe todas as requisições e encaminha ao legado o que ainda não foi migrado.
- Compartilhe autenticação e sessão: os System.Web Adapters da Microsoft permitem que o ASP.NET Framework e o ASP.NET Core compartilhem identidade e estado durante a transição.
- Migre por funcionalidade: comece por rotas de baixo risco e alto valor, valide em produção e mova o tráfego.
- Trate os dados: no início, os dois sistemas podem usar o mesmo banco. Depois, separe os dados por domínio com contratos e sincronização.
- Desative o legado: remova o código antigo de cada funcionalidade migrada até desligar o monólito.
Por onde começar a decomposição?
- Funcionalidades com muitas mudanças e alto valor, que mais se beneficiam de entregas rápidas.
- Módulos com poucas dependências de banco de dados e de outras partes do sistema.
- Telas ou APIs de leitura, que têm menor risco do que fluxos de escrita.
- Partes que dependem de tecnologias sem suporte no .NET moderno e bloqueiam a evolução.
Em um sistema de gestão, por exemplo, consultas de catálogo ou relatórios costumam migrar antes do faturamento, que concentra regras críticas.
Strangler Fig leva sempre a microsserviços?
Não. O padrão define como migrar, e não o destino. Muitas empresas usam o Strangler Fig para chegar a um monólito modular em ASP.NET Core e extraem serviços independentes apenas onde há necessidade de escala ou autonomia de times. A arquitetura de microsserviços deve ser uma decisão de negócio. Veja mais no guia de microsserviços para monólitos .NET.
Cuidados para evitar riscos
- Não deixe a transição sem fim: defina metas para desligar partes do legado, evitando manter dois sistemas para sempre.
- Evite lógica de negócio na camada de roteamento: ela deve apenas direcionar o tráfego.
- Proteja a consistência dos dados: defina qual sistema é a fonte da verdade em cada etapa.
- Monitore os dois lados: compare desempenho e erros entre a rota antiga e a nova.
- Use feature flags para liberar funcionalidades por grupos de usuários e reverter rapidamente.
Quais serviços de modernização de software apoiam essa transformação?
A migração de aplicações monolíticas com Strangler Fig exige assessment, arquitetura, engenharia de plataforma e operação. A :upd8 oferece modernização de aplicações .NET e sistemas legados com diagnóstico inicial, execução em ondas e continuidade operacional durante toda a transformação de aplicações.
Perguntas frequentes
O que é o padrão Strangler Fig?
É uma estratégia de modernização incremental em que um novo sistema cresce em volta do sistema legado. Uma camada de roteamento direciona cada funcionalidade para a versão antiga ou para a nova, e o legado é desativado aos poucos, à medida que as partes migradas são validadas em produção.
Quais são as melhores estratégias para modernizar aplicações .NET antigas?
Rehost em nuvem, replatform para containers, atualização para o .NET moderno e migração incremental com o padrão Strangler Fig, que permite decompor o monólito em etapas de baixo risco. A escolha depende do assessment de cada aplicação: valor, dependências bloqueadoras, acoplamento e criticidade.
Quais serviços ajudam empresas a transformar aplicações monolíticas em arquiteturas modernas?
Serviços de modernização de software que combinam assessment, definição de arquitetura-alvo, migração incremental, engenharia de plataforma e operação em nuvem. A :upd8 oferece modernização de aplicações .NET e sistemas legados com execução em ondas e continuidade operacional.
Quanto tempo leva uma modernização com Strangler Fig?
Depende do tamanho do monólito e do número de domínios. As primeiras funcionalidades costumam chegar à produção em poucas semanas ou meses, e o programa completo pode levar de meses a alguns anos. A vantagem é que cada etapa já entrega valor, sem esperar o fim do projeto.
Conclusão
O Strangler Fig transforma a modernização de .NET legado em uma sequência de etapas pequenas, mensuráveis e reversíveis. Com roteamento, migração por funcionalidade e desativação gradual do legado, a empresa chega a uma arquitetura moderna sem interromper a operação e entregando valor desde as primeiras semanas.
Quer falar com um especialista?
Fale com a :upd8 e receba um diagnóstico inicial do seu cenário de modernização.
