Padrão de figo Strangler

Migre incrementalmente um sistema legado, substituindo gradualmente peças específicas de funcionalidades por novas aplicações e serviços. À medida que você substitui recursos do sistema legado, o novo sistema eventualmente compreende todos os recursos do sistema antigo. Essa abordagem suprime o sistema antigo para que você possa descomissioná-lo.

Contexto e problema

À medida que os sistemas envelhecem, as ferramentas de desenvolvimento, a tecnologia de hospedagem e as arquiteturas de sistema nas quais são construídos podem se tornar obsoletas. À medida que novos recursos e funcionalidades são adicionados, esses aplicativos se tornam mais complexos, o que pode torná-los mais difíceis de manter ou ampliar.

É difícil substituir um sistema complexo inteiro. Em vez disso, pode migrar gradualmente para um novo sistema e usar o sistema antigo para funcionalidades não migradas. No entanto, se executar versões paralelas de uma aplicação, os clientes têm de acompanhar qual das versões contém cada funcionalidade. Quando migra uma funcionalidade ou serviço, deve direcionar os clientes para a nova localização. Para enfrentar estes desafios, adote uma abordagem que apoie a migração incremental e minimize as perturbações para os clientes.

Solução

Depois de identificar novos limites de serviço, utilize um processo incremental para substituir funcionalidades específicas por novas aplicações e serviços. Os clientes continuam a usar a mesma interface e desconhecem que uma migração está em curso.

Descarregue um ficheiro Visio desta arquitetura.

O padrão Strangler Fig fornece uma abordagem controlada e faseada para a modernização. Ele permite que o aplicativo existente continue funcionando durante o esforço de modernização. Uma fachada (proxy) intercepta as solicitações que se dirigem ao sistema legado do back-end. A interface encaminha essas solicitações para a aplicação legada ou para os novos serviços.

Esse padrão reduz os riscos na migração, permitindo que suas equipes avancem em um ritmo adequado à complexidade do projeto. À medida que você migra a funcionalidade para o novo sistema, o sistema herdado se torna obsoleto e você desativa o sistema legado.

1. O padrão Strangler Fig começa introduzindo uma fachada (proxy) entre o aplicativo cliente, o sistema legado e o novo sistema. A fachada funciona como intermediária. Ele permite que o aplicativo cliente interaja com o sistema legado e o novo sistema. Inicialmente, a interface encaminha a maioria dos pedidos para o sistema legado.

2. À medida que a migração progride, a interface muda progressivamente as solicitações do sistema herdado para o novo sistema. A cada iteração, você implementa mais partes de funcionalidade no novo sistema.

   Esta abordagem incremental reduz gradualmente as responsabilidades do sistema legado e expande o âmbito do novo sistema. O processo é iterativo. Ele permite que a equipe aborde complexidades e dependências em estágios gerenciáveis. Estas fases ajudam o sistema a manter-se estável e funcional.

3. Depois de migrar todas as funcionalidades e não houver dependências no sistema herdado, você poderá encerrar o sistema herdado. A interface direciona todos os pedidos exclusivamente para o novo sistema.

4. Você remove a fachada e reconfigura o aplicativo cliente para se comunicar diretamente com o novo sistema. Esta etapa marca a conclusão da migração.

Problemas e considerações

Considere os seguintes pontos ao decidir como implementar esse padrão:

• Considere como lidar com serviços e armazenamentos de dados que o novo sistema e o sistema herdado podem usar. Certifique-se de que ambos os sistemas podem acessar esses recursos ao mesmo tempo.

• Estruture novos aplicativos e serviços para que você possa intercetá-los e substituí-los facilmente em futuras migrações de figos estranguladores. Por exemplo, esforce-se para ter demarcações claras entre as partes da sua solução para que você possa migrar cada parte individualmente.

• Após a conclusão da migração, normalmente você remove a fachada de figo estrangulador. Em alternativa, pode manter a fachada como um adaptador para os clientes antigos usarem enquanto atualiza o sistema central para clientes mais recentes.

  Conceptualize isto como uma arquitetura de transição e equilibre os benefícios de mitigação de risco desta arquitetura com os seus custos temporários de infraestrutura.

• Certifique-se de que a fachada acompanha a migração.

• Certifique-se de que a fachada não se torne um único ponto de falha ou um gargalo de desempenho.

• Planeie para dependências entre sistemas. Durante a migração, ambos os sistemas precisam de coexistir e comunicar. Por exemplo, o novo sistema pode precisar de chamar funcionalidades não migradas do sistema legado, e os componentes legados não migrados podem precisar de chamar funcionalidades migradas do novo sistema. Para gerir estas chamadas, utilize o padrão da Camada Anticorrupção. Uma camada anticorrupção atua como um adaptador que traduz pedidos entre os dois sistemas. Esta camada protege o design do novo sistema de semânticas legadas, para que o sistema legado possa aceder a novos serviços sem alterações significativas no código. Sem este adaptador, dependências entre sistemas podem quebrar componentes ou forçar o novo sistema a adotar convenções legadas.

Quando usar este padrão

Utilize este padrão quando:

• Você migra gradualmente um aplicativo back-end para uma nova arquitetura, especialmente quando a substituição de sistemas grandes, componentes-chave ou recursos complexos introduz riscos.

• O sistema original pode continuar a existir por um longo período de tempo durante o esforço de migração.

Este padrão pode não ser adequado quando:

• As solicitações para o sistema back-end não podem ser intercetadas.

• Não podes aceder ao código-fonte do sistema legado. Para desativar funcionalidades migradas e redirecionar chamadas internas, é necessário poder modificar o código-fonte do sistema legado.

• Você migra um sistema pequeno e substituir todo o sistema é simples.

• Você precisa desativar totalmente a solução original rapidamente.

Design da carga de trabalho

Avalie como usar o padrão Strangler Fig no design de uma carga de trabalho para abordar as metas e os princípios dos pilares do Azure Well-Architected Framework. A tabela a seguir fornece orientação sobre como esse padrão suporta as metas de cada pilar.

Considere quaisquer compensações em relação aos objetivos dos outros pilares que esse padrão possa introduzir.

Exemplo

Os sistemas legados normalmente dependem de uma base de dados monolítica centralizada que serve múltiplos domínios. Com o tempo, esta base de dados partilhada torna-se difícil de gerir e melhorar devido às suas dependências entre domínios. Para responder a este desafio, o padrão Strangler Fig extrai de forma incremental tabelas específicas de domínio, procedimentos armazenados e dados relacionados da base de dados monolítica para bases de dados de domínio isoladas. Cada base de dados contém apenas um domínio. Repete-se o processo de extração até que a base de dados monolítica esteja totalmente decomposta.

1. Introduzir um novo serviço de sistema, que começa a gerir pedidos para o seu domínio. O novo serviço de sistema ainda lê e escreve na base de dados monolítica das suas tabelas de domínio. O sistema legado continua a servir todos os outros domínios.

2. Introduzir uma base de dados de domínio isolada para o novo sistema. Migre as tabelas de domínio relevantes e os seus dados históricos para a nova base de dados utilizando um processo de extração, transformação e carregamento (ETL). Um processo de captura de dados de alteração (CDC) sincroniza os dados do domínio da base de dados monolítica para a nova base de dados do domínio. Durante esta fase, o sistema legado continua a ler e a escrever na base de dados monolítica, e o novo sistema escreve na nova base de dados do domínio. Valide a consistência entre ambas as bases de dados antes do cutover.

3. Após a validação, a nova base de dados de domínio é o sistema de registo desse domínio. O novo sistema realiza todas as operações de leitura e escrita na base de dados do domínio. Remover as respetivas tabelas de domínio, procedimentos armazenados e dependências da base de dados monolítica. Repete-se este processo para cada domínio até que a base de dados monolítica esteja totalmente decomposta.

   Pode voltar à base de dados monolítica durante a fase 2 e no início da fase 3, quando as tabelas de domínio e os processos de sincronização ainda existem na base de dados monolítica. Para voltar à base de dados monolítica depois de remover as tabelas de domínio, procedimentos armazenados e processos de sincronização da base de dados monolítica, é necessário restaurar esses objetos e reproduzir alterações de dados. No entanto, este processo aumenta significativamente o esforço e o risco. Trate a remoção de objetos legados como um passo final deliberado para cada domínio. Remover objetos legados apenas depois de o novo sistema estar validado.

Contributors

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

• Adnan Khan | Arquiteto Sénior de Soluções Cloud
• Ovais Mehboob Ahmed Khan | Arquiteto Sénior de Soluções Cloud

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximo passo

• Leia o artigo do Martin Fowler sobre a aplicação do padrão Strangler Fig

Recursos relacionados

• Padrão Ponte de Mensagens
• Planeie a migração da sua carga de trabalho da Amazon Web Services para Azure