Azure: lift & shift, um caso de estudo de migração aplicacional

Suponhamos o seguinte caso:

O cliente tem uma aplicação que actualmente é executada localmente no seu próprio datacenter e o cliente não está já interessado em manter o seu próprio datacenter. Esta aplicação está a ser executada actualmente no Vmware, ESXi Hypervisor.
Por agora, eles querem apenas executar a aplicação no Azure sem quaisquer modificações.
A arquitectura local é de duas camadas: front-end e back-end. O front-end é um serviço na web (webservice) que comunica com um back-end, middle-tier que é quem faz realmente o processamento.

Para migrar esta arquitectura para o Azure pode usar-se simplesmente o Azure Site Recovery. O Site Recovery é primeiramente um serviço de recuperação após desastre (disaster recovery), ou seja, um DRaaS. Este serviço replica de forma assíncrona VMware, HyperV e servidores físicos, e tem o conceito de planos de recuperação para automatizar esse failover. Só cria as VMs no Azure quando há realmente uma recuperação após desastre, sendo, portanto, bastante económico. Também pode ser usado para migrações e é grátis durante os primeiros 31 dias.
Neste caso, pode usar-se o Azure Site Recovery para replicar as VMs VMware para o Azure e depois executar um failover. A migração é isto: uma replicação e um failover.

Para fazer desta migração mais do que apenas a recriação da aplicação no Azure, poder-se-ia usar, por exemplo, o Image2Docker para poder mover a aplicação para Azure como um contentor ao invés de mover todo o Sistema Operativo a partir das VMs VMware. Criar-se-ia uma imagem Docker a partir das VMs e executar-se-ia em contentores no Azure, Azure Container Instances.

Mudança para uma solução Azure

Futuramente, as VMs IaaS podem ser substituidas por aplicações web no Azure, as Azure Web Apps (PaaS), com poucas mudanças na aplicação. Pode fazer-se o DEPLOY desta aplicação numa Web App do Azure. Já o back-end pode vir a ser uma Azure Function, pode ser talvez substituido por um Service Fabric ou dar mesmo lugar a Azure Container. Neste caso, o back-end é substituido por uma instância do Azure Service Fabric com persistência de dados na base de dados Azure SQL Database.

As diferentes camadas podem ser migradas gradualmente. Primeiro a aplicação web (um webservice neste caso), para uma Web App do Azure, enquanto o back-end continuaria alojado em VMs IaaS. Nesta fase, a ligação entre a Web App e as VMs poderia ser assegurada pela VNET Integration usando uma ligação point-to-site.

O front-end é mudado para um Azure App Service Plan (PaaS) e o back-end é depois mudado para uma instância do Azure Service Fabric (PaaS).





mentor: John Savill

Licença CC BY-SA 4.0 Silvia Pinhão Lopes, 10.9.17