Analisar as estratégias para migrar sistemas SAP para o Microsoft Azure
A maioria dos clientes que consideram a implantação de cargas de trabalho SAP no Azure já tem uma implementação SAP existente no local. O número de implantações greenfield é relativamente pequeno.
Geralmente, as empresas têm sistemas SAP para funções de negócios como o ERP (planejamento de recursos empresariais), comércio global, BI (business intelligence) e outros. Dentro desses sistemas, há ambientes de área restrita, desenvolvimento, teste e produção.
Cada linha horizontal da figura acima é um ambiente. Cada coluna é o sistema SAP de uma função comercial (por exemplo, ERP e BI).
As linhas ou camadas na parte inferior são ambientes de risco inferior e menos críticas. Aquelas em direção à parte superior são um risco maior e mais críticas. À medida que você move a pilha para cima, há um risco maior no processo de migração. Portanto, a produção é o ambiente mais crítico, e o ambiente para testes de aceitação do usuário (Teste), que também é usado para a continuidade dos negócios, é o segundo mais crítico.
Os sistemas na parte inferior são menores, uma vez que têm menos recursos de computação, requisitos de disponibilidade e tamanho menores e taxa de transferência menor. No entanto, eles têm a mesma quantidade de armazenamento que o banco de dados de produção.
Estratégia horizontal
Com uma estratégia horizontal, você começa na parte inferior da pilha porque é uma maneira segura de testar e obter experiência com o Azure. Essa também é uma boa estratégia para usar enquanto você redefine seus processos operacionais, de implantação e de aprovação. Esses processos serão alterados conforme você passar para o Azure. Veja como essa estratégia funciona:
- Para limitar o risco, comece com sistemas de baixo impacto de área restrita ou de treinamento. Se algo der errado, o risco de afetar vários usuários ou funções de negócios críticos é muito baixo.
- Depois, à medida que você ganha experiência com a execução, hospedagem e administração de sistemas SAP no Azure, aplique o que você aprendeu à próxima camada de sistemas na pilha.
- Para cada camada, estime os custos, o provável dinheiro economizado, o desempenho e a possibilidade de otimização e faça ajustes se necessário.
Estratégia vertical
Para ganhar experiência com sistemas de produção no Azure, você pode usar uma estratégia vertical com sistemas de baixo risco em paralelo à estratégia horizontal. Isso também dá a oportunidade de ajustar os processos internos do Azure e treinar os membros da equipe. Essa é uma ótima maneira de detectar problemas na produção logo no início. Veja como essa estratégia funciona:
- Analise o impacto sobre os custos, clientes, SLAs (contratos de nível de serviço) e requisitos legais. Primeiro, mova os sistemas — desde a área restrita até a produção — que tenham o menor risco: o sistema de governança, risco e conformidade e, em seguida, o sistema OER (repositório de eventos de objeto). Depois, mova os mais arriscados, como BI e ERP.
- Quando já tiver um novo sistema SAP, inicie no Azure por padrão em vez de colocá-lo no local e movê-lo mais tarde. No diagrama, o OER é um exemplo disso. O OER é um sistema novo e de baixo risco. Depois de mover alguns dos nossos outros sistemas para o Azure com a estratégia horizontal, você pode implantar toda a pilha vertical de OER no Azure, de ponta a ponta, desde a área restrita até a produção.
- Não mova o sistema mais crítico primeiro. O último sistema que deve ser movido é aquele mais crítico e com o maior risco: o sistema de produção de ERP. Você precisa dos SKUs de máquina virtual com o desempenho mais intensivo e com o maior armazenamento.
- Mova os sistemas autônomos primeiro. Alguns sistemas estão mais conectados a outros; por exemplo, nossos sistemas ERP e GTS. Há vários tráfegos síncronos e em tempo real entre os dois. Mover o ERP para o Azure mantendo o GTS no local afetará o desempenho devido à latência de rede. Portanto, mova os dois juntos.
- Se você tiver vários sistemas SAP, procure dependências upstream e downstream de um sistema SAP para outro ou do SAP para aplicativos fora do ecossistema SAP. Examine padrões de tráfego e áreas com alta sensibilidade à latência.
- Se você tiver sistemas altamente conectados, faça uma análise de desempenho para ver qual será o efeito de movê-los. Se o impacto não for muito grande, mova-os separadamente para o Azure (por exemplo, o Business Warehouse independentemente do ERP). Caso contrário, crie grupos de migração e os mova em conjunto.
- Em alguns casos, cogite aguardar. Às vezes, você não precisa mover determinados sistemas para o Azure imediatamente. Isso poderia estar relacionado aos requisitos de dimensionamento, ou seja, quando os requisitos de processamento são tão altos que as máquinas virtuais ainda não são grandes o suficiente. Execute testes para garantir que a transferência desses sistemas não afetará os SLAs dos clientes.