Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Esse padrão migra incrementalmente um sistema herdado substituindo gradualmente partes específicas da funcionalidade por novos aplicativos e serviços. À medida que você substitui os recursos do sistema herdado, 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 do sistema nas quais eles são criados 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 estender.
Substituir um sistema complexo inteiro é uma tarefa enorme. Em vez disso, muitas equipes preferem migrar para um novo sistema gradualmente e manter o sistema antigo para lidar com recursos não migrados. No entanto, a execução de duas versões separadas de um aplicativo força os clientes a acompanhar qual versão tem recursos individuais. Sempre que as equipes migram um recurso ou serviço, elas devem direcionar os clientes para o novo local. Para superar esses desafios, você pode adotar uma abordagem que dá suporte à migração incremental e minimiza as interrupções nos clientes.
Solução
Use um processo incremental para substituir partes específicas da funcionalidade por novos aplicativos e serviços. Os clientes podem continuar usando a mesma interface, sem saber que essa migração está ocorrendo.
O padrão Strangler Fig oferece uma abordagem de modernização controlada e em fases. Ele permite que o aplicativo existente continue funcionando durante o esforço de modernização. Uma fachada (proxy) intercepta as solicitações que vão para o sistema de back-end herdado. A camada de fachada roteia essas solicitações para o aplicativo legado ou para os novos serviços.
Esse padrão reduz os riscos na migração, permitindo que suas equipes avancem em um ritmo que atenda à complexidade do projeto. À medida que você migra a funcionalidade para o novo sistema, o sistema herdado torna-se obsoleto e você desativa o sistema herdado.
O padrão do Strangler Fig começa introduzindo uma fachada (proxy) entre o aplicativo cliente, o sistema herdado e o novo sistema. A fachada atua como um intermediário. Ele permite que o aplicativo cliente interaja com o sistema herdado e o novo sistema. Inicialmente, a fachada roteia a maioria das solicitações para o sistema herdado.
À medida que a migração progride, a interface gradativamente redireciona as solicitações do sistema legado para o novo sistema. A cada iteração, você implementa mais peças de funcionalidade no novo sistema.
Essa abordagem incremental reduz gradualmente as responsabilidades do sistema herdado e expande o escopo do novo sistema. O processo é iterativo. Ele permite que a equipe resolva complexidades e dependências em estágios gerenciáveis. Esses estágios ajudam o sistema a permanecer estável e funcional.
Depois de migrar toda a funcionalidade e não houver dependências no sistema herdado, você poderá desativar o sistema herdado. A fachada encaminha todas as solicitações exclusivamente para o novo sistema.
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. Verifique se ambos os sistemas podem acessar esses recursos ao mesmo tempo.
Estruture novos aplicativos e serviços de forma que você possa facilmente interceptá-los e substituí-los em futuras migrações do tipo strangler fig. Por exemplo, procure ter demarcações claras entre partes da sua solução para que você possa migrar cada parte individualmente.
Após a migração ser concluída, você de modo geral removerá a fachada strangler fig. Alternativamente, você pode conservar a fachada como um adaptador a ser usado por clientes herdados enquanto você estiver atualizando o sistema básico para os clientes mais recentes.
Certifique-se de que a fachada acompanhe a migração.
Verifique se a fachada não se torna um único ponto de falha ou um gargalo de desempenho.
Quando usar esse padrão
Use esse padrão quando:
Você migra gradualmente um aplicativo de 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.
O padrão pode não ser adequado nestes casos:
As solicitações ao sistema de back-end não podem ser interceptadas.
Você migra um sistema pequeno e substituir todo o sistema é simples.
Você precisa desativar totalmente a solução original rapidamente.
Design de carga de trabalho
Avalie como usar o padrão do 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 diretrizes sobre como esse padrão dá suporte às metas de cada pilar.
| Pilar | Como esse padrão apoia os objetivos do pilar |
|---|---|
| As decisões de design de confiabilidade ajudam sua carga de trabalho a se tornar resiliente ao mau funcionamento e a garantir que ela se recupere para um estado totalmente funcional após a ocorrência de uma falha. | A abordagem incremental desse padrão pode ajudar a reduzir os riscos durante uma transição de componente em comparação com fazer grandes alterações sistêmicas de uma só vez. - RE:08 Testes |
| A Otimização de Custos concentra-se na manutenção e na melhoria do ROI (retorno sobre o investimento) da carga de trabalho. | O objetivo dessa abordagem é maximizar o uso de investimentos existentes no sistema atualmente em execução, modernizando-se incrementalmente. Ele permite que você execute substituições de ALTA ROI antes de substituições com baixo ROI. - CO:07 Custos de componentes - CO:08 Custos ambientais |
| A Excelência Operacional ajuda a fornecer qualidade na carga de trabalho por meio de processos padronizados e coesão da equipe. | Esse padrão fornece uma abordagem de melhoria contínua. As substituições incrementais que fazem pequenas alterações ao longo do tempo são preferíveis a grandes alterações sistêmicas que são mais arriscadas de implementar. - OE:06 Cadeia de fornecimento para desenvolvimento de carga de trabalho - OE:11 Práticas de implantação segura |
Considere as compensações em relação às metas dos outros pilares que esse padrão pode introduzir.
Exemplo
Os sistemas herdados normalmente dependem de um banco de dados centralizado. Com o tempo, um banco de dados centralizado pode se tornar difícil de gerenciar e evoluir devido a suas muitas dependências. Para resolver esses desafios, vários padrões de banco de dados podem facilitar a transição para longe desses sistemas herdados. O padrão da figueira estranguladora é um desses padrões. Aplique o padrão do Strangler Fig como uma abordagem em fases para fazer a transição gradual de um sistema herdado para um novo sistema e minimizar a interrupção.
Você apresenta um novo sistema e o novo sistema começa a lidar com algumas solicitações do aplicativo cliente. No entanto, o novo sistema ainda depende do banco de dados herdado para todas as operações de leitura e gravação. O sistema herdado permanece operacional, o que facilita uma transição suave sem alterações estruturais imediatas.
Na próxima fase, você apresenta um novo banco de dados. Você migra o histórico de carga de dados para o novo banco de dados usando um processo de ETL (extração, transformação e carregamento). O processo ETL sincroniza o novo banco de dados com o banco de dados herdado. Durante essa fase, o novo sistema executa gravações sombra. O novo sistema atualiza os dois bancos de dados em paralelo. O novo sistema continua a ler do banco de dados herdado para validar a consistência.
Por fim, o novo banco de dados se torna o sistema de registro. O novo banco de dados assume todas as operações de leitura e gravação. Você pode começar a preterir o banco de dados herdado e o sistema herdado. Depois de validar o novo banco de dados, você pode desativar o banco de dados herdado. Essa aposentadoria conclui o processo de migração com interrupção mínima.
Próxima etapa
Leia a postagem no blog de Martin Fowler sobre o aplicativo de padrão Strangler Fig.