Analizzare le strategie per la migrazione di sistemi SAP in Microsoft Azure
La maggior parte dei clienti che valutano se distribuire carichi di lavoro SAP in Azure ha già un'implementazione SAP locale esistente. Il numero di distribuzioni "vergine" è relativamente piccolo.
In genere, le aziende hanno sistemi SAP per funzioni aziendali come gestione delle risorse aziendali (ERP), commercio globale, business intelligence (BI) e altre. All'interno di questi sistemi si trovano ambienti come sandbox, sviluppo, test e produzione.
Ogni riga orizzontale nella figura precedente è un ambiente. Ogni colonna è un sistema SAP per una funzione aziendale, ad esempio ERP e BI.
Le righe o i livelli nella parte inferiore sono ambienti a basso rischio e meno critici. Quelli verso l'alto sono ambienti più rischiosi e più critici. Salendo nello stack, il processo di migrazione comporta rischi maggiori. Di conseguenza, quello di produzione è l'ambiente più critico, mentre l'ambiente di test di accettazione utente, anch'esso usato per la continuità aziendale, e il secondo più critico.
I sistemi nella parte inferiore sono più piccoli, in quanto hanno meno risorse di calcolo, requisiti di disponibilità e dimensioni inferiori e una minore velocità effettiva. Tuttavia, hanno la stessa capacità di archiviazione del database di produzione.
Strategia orizzontale
Con una strategia orizzontale si inizia dalla parte inferiore dello stack, perché è un approccio sicuro per sperimentare e acquisire esperienza con Azure. È anche una strategia efficace da usare durante la ridefinizione dei processi operativi, di distribuzione e di approvazione. Questi processi cambiano quando si passa ad Azure. Ecco come funziona la strategia:
- Per limitare i rischi, iniziare con sistemi di training o sandbox a basso impatto. Se si verificano problemi, il pericolo di influire su molti utenti o su funzioni aziendali strategiche è minimo.
- Quindi, man mano che si acquisisce esperienza in esecuzione, hosting e amministrazione dei sistemi SAP in Azure, applicare le nozioni apprese al successivo livello verso l'alto dei sistemi nello stack.
- Per ogni livello, stimare i costi, i possibili risparmi, le prestazioni e il potenziale di ottimizzazione e apportare le eventuali modifiche necessarie.
Strategia verticale
Per acquisire esperienza con i sistemi di produzione in Azure, è possibile usare una strategia verticale con sistemi a basso rischio in parallelo alla strategia orizzontale. Questa strategia offre anche la possibilità di modificare i processi interni per Azure e formare i membri del team. Si tratta di un ottimo metodo per individuare i problemi nell'ambiente di produzione nelle prime fasi. Ecco come funziona la strategia:
- Esaminare l'impatto su costi, clienti, contratti di servizio (SLA) e requisiti legali. Per prima cosa, spostare i sistemi, dall'ambiente sandbox fino alla produzione, che comportano il rischio più basso, ovvero il sistema di governance, rischio e conformità e quindi il sistema di repository di eventi a livello di oggetto (OER, Object Event Repository). Spostare quindi quelli a rischio più elevato, come i sistemi BI ed ERP.
- Quando si possiede un nuovo sistema SAP, iniziare in Azure per impostazione predefinita anziché collocarlo in un ambiente locale e quindi spostarlo in un secondo momento. Nel diagramma il sistema OER è un esempio di questo scenario. Il sistema OER è un nuovo sistema a basso rischio. Dopo aver spostato alcuni degli altri sistemi in Azure con la strategia orizzontale, è possibile distribuire l'intero stack verticale OER in Azure, completamente, dalla sandbox fino alla produzione.
- Non spostare il sistema più critico per primo. L'ultimo sistema da spostare è quello più strategico e più ad alto rischio, ovvero il sistema di produzione ERP. Questo richiede gli SKU di macchine virtuali con le prestazioni più elevate e le risorse di archiviazione più grandi.
- Spostare per primi i sistemi autonomi. Alcuni sistemi sono strettamente associati ad altri sistemi, ad esempio i sistemi ERP e GTS. Tra i due avviene una grande quantità di traffico sincrono e in tempo reale. Se si sposta il sistema ERP in Azure ma si mantiene il sistema GTS in locale, le prestazioni subiranno un impatto negativo a causa della latenza di rete, di conseguenza è preferibile spostarli insieme.
- Se sono presenti più sistemi SAP diversi, cercare le dipendenze upstream e downstream da un sistema SAP all'altro o da SAP ad app esterne all'ecosistema SAP. Esaminare i modelli di traffico e le aree molto sensibili alla latenza.
- Se i sistemi sono strettamente connessi, eseguire un'analisi delle prestazioni per verificare quale sarebbe l'effetto se venissero spostati. Se l'impatto è esiguo, spostarli separatamente in Azure, ad esempio Business Warehouse indipendentemente da ERP. In caso contrario, creare gruppi di migrazione e spostarli insieme.
- In alcuni casi, valutare se attendere ancora. A volte non è consigliabile spostare determinati sistemi immediatamente in Azure. Il motivo può essere correlato a requisiti di dimensioni, in particolare quando i requisiti di elaborazione sono talmente elevati che le macchine virtuali non hanno ancora dimensioni sufficienti. Eseguire test per assicurarsi che lo spostamento di questi sistemi non influisca sui contratti di servizio con i clienti.