Effettuare il refactoring delle zone di destinazione

Una zona di destinazione è un ambiente per l'hosting dei carichi di lavoro, di cui è già stato effettuato il provisioning tramite codice. Poiché l'infrastruttura della zona di destinazione è definita nel codice, può essere sottoposta a refactoring in modo simile a qualsiasi altra codebase. Il refactoring è il processo con cui si modifica o si ristruttura il codice sorgente al fine di ottimizzare l'output del codice senza modificarne lo scopo o la funzione principale.

La metodologia Ready usa il concetto di refactoring per accelerare la migrazione e rimuovere gli ostacoli comuni. I passaggi nella panoramica su Ready illustrano un processo che inizia con un modello di zona di destinazione predefinito che si allinea meglio alla funzione di hosting. Si effettua quindi il refactoring del codice sorgente o vi si apportano aggiunte per espandere la capacità delle zone di destinazione di offrire tale funzione attraverso funzionalità di sicurezza, operative o di governance migliorate. L'immagine seguente illustra il concetto di refactoring.

Figura 1: Refactoring della zona di destinazione.

Ostacoli comuni

Quando i clienti adottano il cloud, le considerazioni sulla zona di destinazione sono l'ostacolo più comune all'adozione e ai risultati aziendali correlati al cloud. I clienti tendono frenarsi davanti a uno dei seguenti due ostacoli. Vari team spesso si piegano davanti a uno di questi due ostacoli, con conseguenti stalli culturali che rendono difficile l'adozione.

Entrambi gli ostacoli principali affondano le radici nella convinzione secondo cui l'ambiente cloud e i data center esistenti dovrebbero essere pari o quasi nelle funzionalità relative alle operazioni, alla governance e alla sicurezza. È un saggio obiettivo a lungo termine. Ma il problema deriva dal delicato equilibrio tra la tempistica per raggiungere tale obiettivo e la velocità necessaria per ottenere i risultati aziendali.

Ostacolo: agire troppo presto

Per raggiungere lo stato attuale della governance e delle operazioni di sicurezza nel data center corrente ci sono voluti anni e un notevole impegno. È stato necessario anche osservare, imparare e apportare personalizzazioni per soddisfare i vincoli specifici dell'ambiente. Per replicare queste stesse procedure e configurazioni servirà tempo. Il raggiungimento della parità completa delle funzionalità potrebbe anche produrre come risultato un ambiente che offre prestazioni inferiori al previsto nel cloud. L'approccio basato sulla parità comporta in genere anche un notevole esborso economico non pianificato nell'ambiente cloud. È bene non provare ad applicare i requisiti dello stato corrente a un ambiente futuro come punto di partenza della fase iniziale. Raramente questo approccio si rivela vantaggioso.

figura 2: agire troppo presto è un bloccante comune.

Nell'immagine precedente il cliente mira a eseguire 100 carichi di lavoro nel cloud. Per raggiungere tale obiettivo, il cliente probabilmente distribuirà il primo carico di lavoro e successivamente i primi dieci carichi di lavoro prima che sia pronto a rilasciarne uno nell'ambiente di produzione. Alla fine il cliente raggiungerà l'obiettivo del piano di adozione e avrà un portfolio solido nel cloud. La X rossa nell'immagine mostra tuttavia il punto in cui i clienti normalmente si bloccano. Attendere di raggiungere l'allineamento totale può ritardare il primo carico di lavoro di settimane, mesi o persino anni.

Ostacolo: agire troppo tardi

Agire troppo tardi, d'altra parte, può avere conseguenze significative a lungo termine sul successo delle attività di adozione del cloud. Se il team attende di raggiungere la parità delle funzionalità fino al completamento delle attività di adozione, incontrerà ostacoli inutili e serviranno diverse escalation per tenere il passo.

figura 3: agire troppo tardi è un blocco comune.

La situazione è simile a quando si agisce troppo presto. In questa immagine il cliente attende troppo tempo per raggiungere l'idoneità aziendale tra le zone di destinazione. Attendendo troppo tempo, il cliente sarà vincolato nella quantità di refactoring e di espansione che può eseguire nell'ambiente. Questi vincoli limiteranno la sua possibilità di promuovere un successo continuativo.

Ricerca di un equilibrio

Per evitare questi ostacoli comuni, è consigliabile adottare un approccio iterativo basato su un piano di adozione del cloud ben strutturato, che massimizzi le opportunità di apprendimento e riduca al minimo il tempo necessario a raggiungere il successo aziendale. Il refactoring e le attività parallele sono fondamentali per questo approccio.

Avviso

I team di adozione che hanno l'obiettivo a medio termine (entro 24 mesi) di ospitare più di 1.000 asset (applicazioni, infrastruttura o asset di dati) nel cloud hanno poche probabilità di riuscire usando l'approccio del refactoring. La curva di apprendimento è troppo alta e la sequenza temporale è troppo stretta per consentire approcci organici al raggiungimento delle competenze. Per raggiungere i propri obiettivi, sarebbe meglio scegliere un punto di partenza più completo che richieda meno personalizzazione. I propri partner di implementazione saranno in grado di suggerire un approccio migliore.

La parte restante di questo articolo sarà incentrata su alcuni vincoli chiave che possono incoraggiare l'uso di un approccio di refactoring, riducendo allo stesso tempo al minimo i rischi.

Teoria

Il concetto di refactoring di una zona di destinazione è semplice, ma l'esecuzione richiede protezioni appropriate. Il concetto illustrato sopra descrive il flusso di base:

• Quando è tutto pronto per creare la prima zona di destinazione, usare una zona di destinazione iniziale definita tramite un modello.
• Dopo che la zona di destinazione è stata distribuita, usare le indicazioni fornite nell'articolo nella sezione Enhance del sommario per effettuare il refactoring e l'aggiunta alla zona di destinazione iniziale.
• Ripetere il processo di revisione e di aggiunta fino a quando non si dispone di un ambiente pronto per l'organizzazione che soddisfi i requisiti avanzati dei team per la sicurezza, delle operazioni e della governance.

Approccio di sviluppo

Il vantaggio di un approccio basato sul refactoring è la possibilità di creare percorsi di iterazione paralleli per lo sviluppo. Nell'immagine seguente viene illustrato un esempio di due percorsi di iterazione paralleli: l'adozione del cloud e la piattaforma cloud. I due percorsi procedono in modo graduale e il rischio di bloccare le attività quotidiane dei due team è minimo. L'allineamento al piano di adozione e le protezioni di refactoring possono condizionare il contratto sulle attività cardine e la chiarezza sulle dipendenze future.

di destinazione Figura 4: Iterazione parallela della zona di destinazione.

Nei percorsi di iterazione dell'esempio precedente il team di adozione del cloud esegue la migrazione del portfolio di 100 carichi di lavoro nel cloud. In parallelo, il team della piattaforma cloud è concentrato sul piano di adozione del cloud affinché l'ambiente sia pronto per tali carichi di lavoro.

In questo esempio le iterazioni pianificate vengono eseguite come indicato di seguito:

• Il team della piattaforma cloud avvia le attività di sviluppo distribuendo una zona di destinazione iniziale. Tale zona di destinazione consente al team di adozione del cloud di eseguire la distribuzione e iniziare a testare il primo carico di lavoro.
• Per prepararsi alla distribuzione successiva di 10 carichi di lavoro del team di adozione del cloud, il team della piattaforma si occupa di effettuare il refactoring e aggiungere un ambiente connesso, considerando il cloud come rete perimetrale.
• Prima che il team di adozione possa rilasciare il primo carico di lavoro di produzione, il team della sicurezza richiede una verifica della sicurezza. Mentre il team di adozione distribuisce i primi 10 carichi di lavoro, il team della piattaforma si occupa di definire e implementare i requisiti di sicurezza.
• Quando il primo carico di lavoro viene rilasciato per la produzione, i due team devono avere le informazioni sufficienti per prepararsi a un modello di servizio condiviso a lungo termine. La centralizzazione delle architetture di servizi principali consente di allineare il team di governance e delle operazioni. La centralizzazione dei servizi principali consente di preparare il team di adozione al dimensionamento e al rilascio delle diverse successive ondate di carichi di lavoro di produzione.
• Man mano che il team si avvicina all'obiettivo di eseguire la migrazione di 100 carichi di lavoro, inizierà a spostarsi verso un modello di collaborazione e una struttura di team del centro di eccellenza cloud.

La configurazione di un ambiente aziendale richiede tempo e questo approccio non esula da questa esigenza. Questo approccio è invece progettato per rimuovere i blocchi iniziali e creare opportunità perché i team della piattaforma e di adozione possano apprendere insieme.

Protezioni di refactoring delle zone di destinazione

Tutti i modelli di zona di destinazione iniziali presentano limitazioni. Le protezioni o i criteri durante il refactoring devono considerare tali limitazioni. Prima di iniziare un processo di refactoring della zona di destinazione, è importante comprendere i requisiti a lungo termine del piano di adozione del cloud e la classificazione dei carichi di lavoro candidati, rispetto alle limitazioni del modello iniziali.

Come esempio di definizione delle protezioni di refactoring, è possibile confrontare l'approccio di sviluppo nell'esempio precedente e il progetto di zona di destinazione per le migrazioni di Cloud Adoption Framework.

• In base ai presupposti del progetto di zona di destinazione per le migrazioni di Cloud Adoption Framework, questa zona di destinazione iniziale non è progettata per carichi di lavoro di dati sensibili o cruciali. Tali funzionalità dovranno essere aggiunte tramite il refactoring.
• In questo esempio si supponga che il portfolio dei 100 carichi di lavoro debba disporre di funzionalità di hosting di dati sensibili e dati cruciali.

Per soddisfare questi due requisiti contrastanti, il team di adozione e il team della piattaforma troveranno un accordo per operare alle condizioni seguenti:

• Il team di adozione del cloud privilegerà i carichi di lavoro di produzione che non hanno accesso a dati sensibili e non vengono considerati cruciali.
• Prima della versione di produzione, il team di sicurezza e delle operazioni convaliderà l'allineamento ai criteri precedenti.
• Il team della piattaforma cloud collaborerà con i team di sicurezza e governance per implementare una baseline di sicurezza. Dopo che il team di sicurezza ha approvato l'implementazione, il team di adozione potrà eseguire la migrazione dei carichi di lavoro che hanno accesso ad alcuni dati sensibili.
• Il team della piattaforma cloud collaborerà con il team delle operazioni per implementare una baseline di gestione. Dopo che il team della operazioni ha approvato l'implementazione, il team di adozione potrà eseguire la migrazione dei carichi di lavoro che hanno un livello di criticità più elevato.

Per questo esempio, l'insieme di condizioni concordate consentirà al team di adozione di iniziare l'attività di migrazione. Il team della piattaforma potrà anche definire le interazioni con altri team man mano che si crea un ambiente aziendale a lungo termine.

Soddisfare i requisiti a lungo termine durante il refactoring

La sezione della metodologia Ready relativa al miglioramento della zona di destinazione aiuterà a spostarsi verso i requisiti più a lungo termine. Man mano che il team di adozione del cloud procede con il piano di adozione, rivedere Espandere la zona di destinazione per indicazioni utili su come prendere decisioni ed effettuare il refactoring per soddisfare l'evoluzione dei requisiti dei vari team.

di destinazione parallela Figura 5: Metodologie più approfondite che supportano un'iterazione della zona di destinazione parallela.

In ogni sottosezione dell'articolo Espandere la zona di destinazione viene eseguito il mapping a una delle aggiunte descritte nell'immagine precedente. Oltre a queste espansioni di base, le metodologie più avanzate (ad esempio la regolamentazione e la gestione) di questo framework aiuteranno a superare le modifiche di base alla zona di destinazione per implementare discipline a lungo termine.

Passaggi successivi

In preparazione a un processo di refactoring, iniziare a usare le zone di destinazione di Azure.

Zone di destinazione di Azure