Pianificare le piattaforme applicative moderne

  • Articolo

La metodologia Piano dell'Cloud Adoption Framework consente di creare un piano di adozione cloud complessivo per guidare i programmi e i team coinvolti nella trasformazione digitale basata sul cloud. Queste linee guida offrono modelli per creare il backlog e i piani per lo sviluppo delle competenze necessarie nei team in base alle attività che si vogliono eseguire nel cloud.

L'applicazione della metodologia per il piano è incentrata sulle cinque R di razionalizzazione dell'ambiente digitale. Il percorso più comune per il cloud è incentrato sulla velocità, l'efficienza e la ripetibilità dei processi di migrazione e modernizzazione. Tra le cinque R, la pianificazione assegna in genere la priorità alle opzioni di rehosting con supporto parallelo limitato per le opzioni di riprogettazione e ricompilazione.

Digital estate

Durante la pianificazione del proprio ambiente digitale, di procederà alla raccolta dei dati di inventario e alla razionalizzazione dell'ambiente. In un piano di adozione del contenitore è fondamentale che tutte le risorse, ad esempio le macchine virtuali, i dati e le applicazioni, siano raggruppate in base al carico di lavoro supportato. Dopo aver eseguito il raggruppamento e la razionalizzazione di base, è possibile valutare i carichi di lavoro per scegliere il pacchetto e le opzioni di rehosting o riprogettazione.

Il modello di piano di adozione del cloud standard prevede i tipi di lavoro necessari in un tipico processo di adozione del cloud. Sarà tuttavia necessario aggiungere attività al piano per l'inserimento del carico di lavoro in contenitori e l'orchestrazione del provisioning dei contenitori.

Attenzione

Questo articolo presuppone che il lettore segua già le procedure consigliate descritte nella serie di articoli sulla creazione di un piano di adozione del cloud in Azure DevOps. Se si sta tracciando il piano di adozione del cloud in un foglio di calcolo o in altri strumenti di rilevamento dei progetti, le sezioni seguenti sono ancora valide ma è necessario modificare i passaggi operativi per aggiungere dati al piano.

Avviso

L'integrazione di una strategia di piattaforma applicativa moderna nei processi di migrazione standard (o in una factory di migrazione) richiederà un'implementazione matura delle attività associate alla progettazione di architetture del carico di lavoro prima della migrazione. Se si continua con questa strategia senza queste attività, l'attività di migrazione potrebbe essere ritardata e portare a decisioni per l'architettura non corrette per gli host contenitore distribuiti e per i carichi di lavoro di supporto.

Identificare i carichi di lavoro candidati

Nello scenario della piattaforma applicativa moderna i rendimenti a più lungo termine, che richiedono un maggior investimento iniziale, sono prioritari rispetto ai processi di migrazione più efficienti. Gli investimenti a lungo termine sono rappresentati in parti specifiche del piano come maggiore attenzione all'abilitazione dell'innovazione e alla semplificazione delle operazioni per gruppi specifici di carichi di lavoro.

Per iniziare a allineare la strategia e il piano, identificare tutti i carichi di lavoro che potrebbero essere interessati dall'aggiunta di piattaforme applicative moderne nella strategia di adozione del cloud. Questi presupposti verranno verificati prima di implementare eventuali modifiche tecniche. Per facilitare l'identificazione dei potenziali candidati, cercare i criteri seguenti all'interno del portfolio di carichi di lavoro:

  • Sviluppo attivo o investimenti in DevOps: una percentuale di carichi di lavoro di produzione verrà sottoposta allo sviluppo attivo. Alcuni carichi di lavoro possono anche essere gestiti tramite procedure DevOps in corso.
  • Portabilità del carico di lavoro: alcuni carichi di lavoro sono interessati da conformità, protezione dati o vincoli operativi che potrebbero richiedere la portabilità nel cloud privato, nella rete perimetrale o persino in più provider di servizi cloud pubblico.
  • Consolidamento del carico di lavoro: numerosi carichi di lavoro (in particolare i carichi di lavoro a basso utilizzo) possono essere candidati al consolidamento in host contenitori riducendo di conseguenza il numero di server/macchine virtuali e i costi operativi.
  • Carichi di lavoro legacy: i carichi di lavoro legacy possono bloccare gli aggiornamenti ai sistemi operativi e persino impedire la migrazione al cloud. I carichi di lavoro legacy che non sono compatibili con le funzionalità di Azure potrebbero essere candidati alla migrazione in un host contenitore.

Documentare i carichi di lavoro candidati

Nota

L'elenco di considerazioni seguente deve essere documentato solo per i candidati alla migrazione identificati dai criteri precedenti.

Quando si crea un piano di adozione del cloud, ogni carico di lavoro viene documentato seguendo le linee guida disponibili in Definire e classificare in ordine di priorità i carichi di lavoro. Tutti i carichi di lavoro candidati per lo scenario della piattaforma applicativa moderna richiederanno informazioni aggiuntive per guidare l'esecuzione del piano. Questo articolo evidenzia l'importanza di documentare gli input aziendali e tecnici per definire il carico di lavoro. Per i candidati alla piattaforma applicativa moderna, è necessario aggiungere i punti dati seguenti alla definizione del carico di lavoro.

Input aziendali

Di seguito sono riportati i punti dati correlati alle aziende che potrebbero influenzare la decisione di includere un carico di lavoro nella strategia moderna della piattaforma applicazione.

  • Fattori per la conformità: quali specifici criteri di conformità sono alla base delle considerazioni sull'ospitare il carico di lavoro in un cloud privato?
  • Fattori per la protezione dati: quali misure di protezione dati sono alla base delle considerazioni sull'ospitare il carico di lavoro in un cloud privato?
  • Vincoli operativi: quali vincoli operativi sono alla base delle considerazioni sull'ospitare il carico di lavoro in un cloud privato?
  • Risultati moderni della piattaforma applicazione: Quale dei seguenti è il driver dietro la valutazione di questo carico di lavoro come candidato contenitore? DevOps, portabilità, consolidamento, legacy o più di questi fattori.
  • Modello operativo: il carico di lavoro verrà gestito centralmente (da IT centrale/CCoE), decentralmente (dal team del carico di lavoro) con operazioni aziendali (supporto centrale e operazioni specifiche del carico di lavoro)?

Input tecnici

Di seguito sono riportati i punti dati dei team della tecnologia che possono influire sulla decisione di includere un carico di lavoro nella strategia della piattaforma applicativa moderna.

Considerazioni sulla posizione:

Considerazioni relative alla posizione in cui verrà ospitato il carico di lavoro.

  • Requisito di hosting su cloud pubblico: è presente uno specifico vincolo tecnico associato al requisito del cloud pubblico?
  • Requisito di hosting su cloud privato: è presente uno specifico vincolo tecnico associato al requisito del cloud privato?
  • Requisito di hosting su rete perimetrale: è presente uno specifico vincolo tecnico associato al requisito della rete perimetrale?
  • Requisito di portabilità: è presente uno specifico vincolo tecnico associato al requisito di portabilità cloud?

Considerazioni sulle operazioni:

Considerazioni relative alle operazioni della piattaforma, degli host e dei carichi di lavoro.

  • Piattaforma cloud primaria: le organizzazioni devono definire una piattaforma cloud primaria per fornire gli strumenti di gestione delle operazioni. Alcune organizzazioni potrebbero avere più di una piattaforma cloud primaria per gestire vari tipi di operazioni. Qual è la piattaforma cloud primaria per gestire questo carico di lavoro?
  • Piattaforme operative aggiuntive: il carico di lavoro verrà gestito anche da altre piattaforme operative?
  • Requisiti di hosting cloud: il carico di lavoro richiede una specifica strategia di hosting cloud? Cloud pubblico, cloud privato o portabilità cloud
  • Piattaforma di orchestrazione standardizzata: se l'azienda ha una soluzione standard per l'orchestrazione dei contenitori, inserire il nome della piattaforma standardizzata da considerare. Esempi: servizio Azure Kubernetes (AKS), motore AKS o Kubernetes.
  • Considerazioni sull'orchestrazione personalizzata: esiste un requisito per una piattaforma di orchestrazione di contenitori non standard? In tal caso, descrivere il requisito.
  • Operazioni host standardizzate: si presuppone che i carichi di lavoro non siano ostili e possano essere ospitati in contenitori condivisi supportati da operazioni host standardizzate. Il carico di lavoro è compatibile con questo approccio?
  • Considerazioni sulle operazioni host personalizzate: se il carico di lavoro non è compatibile con le operazioni standardizzate, quali requisiti specifici devono essere considerati quando si stabiliscono le procedure operative host per il carico di lavoro?

Considerazioni sull'applicazione:

Considerazioni specifiche sul modo in cui l'applicazione viene sviluppata e verrà sviluppata in futuro.

  • Runtime PaaS (Platform as a Service): i provider di servizi cloud pubblico producono runtime di applicazioni coerenti, spesso chiamati PaaS (Platform as a Service). In Azure i runtime PaaS forniti dal Servizio app di Azure. Questa applicazione può funzionare in un runtime PaaS? Quale runtime è più compatibile?
  • Runtime standardizzato: se l'applicazione non è compatibile con un runtime PaaS, è disponibile un runtime standardizzato fornito dall'organizzazione? Su quale runtime verrà compilato questo carico di lavoro?
  • Considerazioni sul runtime personalizzato: quali considerazioni specifiche richiede un runtime personalizzato per questo carico di lavoro?
  • Vincoli di runtime: esistono vincoli imposti all'applicazione dal runtime scelto?
  • Dipendenze dell'applicazione: questo carico di lavoro dipende da sistemi esistenti che risiedono in una posizione specifica (pubblica o privata)? Ad esempio, un sistema ERP come SAP in esecuzione in una soluzione specifica.
  • Gravità dei dati: questo carico di lavoro dipende da un'origine dati che risiede in una posizione specifica (pubblica o privata)? Ad esempio, una dipendenza dai dati in SAP o in altre origini dati centralizzate.
  • Considerazioni sull'elenco approvati: le considerazioni sulle operazioni personalizzate sono approvate per l'uso all'interno della piattaforma cloud? Quali servizi approvati devono essere inclusi nella distribuzione?

Considerazioni sui contenitori iniziali

L'inserimento dei carichi di lavoro in contenitori è la prima attività da pianificare ed eseguire. La seconda è la pianificazione dell'hosting dei contenitori.

Soluzioni PaaS per runtime standardizzati, orchestrazione e operazioni

Alcuni carichi di lavoro sono altamente autonomi e non necessariamente traggono vantaggio dai controlli avanzati e dai requisiti di infrastruttura inclusi in una piattaforma di grandi dimensioni come Kubernetes. Il fatto che il carico di lavoro sia inserito in un contenitore non significa che deve essere distribuito in Kubernetes. Azure offre un'ampia gamma di soluzioni per eseguire carichi di lavoro all'interno del portfolio che non richiedono il livello di gestione e infrastruttura richiesto dal servizio Azure Kubernetes. Ognuna delle soluzioni seguenti segue questo approccio alla pianificazione:

È consigliabile usare una soluzione più leggera per i contenitori con carichi di lavoro di cui non si prevede un aumento della complessità e allineati agli scopi e ai limiti di queste soluzioni.

Orchestrazione standardizzata con runtime e operazioni personalizzati nel cloud pubblico

Per i carichi di lavoro che non possono essere eseguiti in una piattaforma PaaS completamente gestita e devono affidarsi ai controlli a livello di infrastruttura, usano funzionalità di distribuzione avanzate come quelle offerte dagli agenti di orchestrazione o che prevedono una crescita della complessità modulare, passare al servizio Azure Kubernetes (AKS). Il servizio Azure Kubernetes offre una soluzione per l'hosting in contenitori, ma offre anche opzioni complete per architettura, SRE, sicurezza, distribuzione, monitoraggio e infrastruttura.

Il set di funzionalità della piattaforma include un requisito che prevede la conoscenza della piattaforma sia a livello di operatore del cluster che a livello di carico di lavoro. Pianificare la formazione dei team delle operazioni, dei team di architettura e dei team di progettazione dei carichi di lavoro nelle sequenze temporali della migrazione. Inoltre, poiché il servizio Azure Kubernetes è una piattaforma, assicurarsi che i team dei carichi di lavoro comprendano la separazione delle responsabilità all'interno di questa piattaforma rispetto alla disposizione di hosting corrente. Potrebbe essere simile per alcuni aspetti, ma probabilmente sarà una novità in altri.

Orchestrazione, runtime e operazioni personalizzati nel cloud pubblico

Per carichi di lavoro molto specializzati o requisiti aziendali specifici, Azure offre altre due piattaforme principali nello spazio di orchestrazione dei contenitori.

  • Azure Red Hat OpenShift
  • Azure Service Fabric

Se è necessario esplorare le alternative, assicurarsi che venga allocato del tempo per comprendere i vantaggi e i compromessi di tutte le opzioni di piattaforma. La soluzione predefinita di Azure è il servizio Azure Kubernetes e in questa documentazione si presuppone che il servizio Azure Kubernetes sia la tecnologia scelta.

Standardizzare le operazioni nelle piattaforme cloud

I clienti spesso distribuiscono agenti di orchestrazione diversi negli ambienti di cloud privato, rete perimetrale e cloud pubblico. Per standardizzare le operazioni in queste diverse piattaforme cloud, i clienti possono incorporare un approccio operativo unificato estendendo gli strumenti delle operazioni cloud a più piattaforme cloud.

In Azure le organizzazioni possono standardizzare le operazioni nei vari agenti di orchestrazione eseguendo l'onboarding di host contenitore diversi in Azure Arc per Kubernetes. Questo strumento garantisce monitoraggio, operazioni e governance coerenti in ogni host contenitore.

Runtime dell'applicazione in ambienti di cloud privato e rete perimetrale

Quando i carichi di lavoro devono essere eseguiti in un ambiente cloud privato o perimetrale, ma il carico di lavoro è supportato meglio da un runtime PaaS, sono disponibili alcuni strumenti che consentono agli sviluppatori di basarsi su runtime PaaS coerenti usando il Servizio app di Azure:

  • Azure Stack HCI: consente l'hosting del Servizio app di Azure in modo nativo in Azure Stack, gestito dall'operatore di Azure Stack.
  • Azure Stack HCI per il servizio Azure Kubernetes: consente l'hosting dei runtime personalizzati in esecuzione nel servizio Azure Kubernetes all'interno di Azure Stack, gestiti da operatori di Azure Stack e del servizio Azure Kubernetes per consentire la portabilità ad altre soluzioni Kubernetes.
  • Servizio app di Azure in Kubernetes con Azure Arc: consente a qualsiasi host Kubernetes di fornire servizi dell'applicazione in Azure. Tutti gli host diventano una piccola istanza del Servizio app di Azure. Poiché viene eseguito l'onboarding di ogni host anche in Azure Arc, gli host possono essere gestiti anche tramite operazioni host coerenti basate sul cloud.

Piano di preparazione della piattaforma applicazione moderna

Oltre al piano di competenze per l'adozione del cloud, i team di adozione del cloud potrebbero dover sviluppare competenze correlate al contenitore e a Kubernetes prima di eseguire il piano:

Assicurarsi che venga allocato del tempo ai team del carico di lavoro per documentare e testare i piani di migrazione. Potrebbe essere necessario modificare l'applicazione o il sistema esterno esistente (dipendenze e sistemi che dipendono dal carico di lavoro) con maggiore flessibilità per supportare l'impegno della migrazione. Questo vale sia per gli ambienti di preproduzione che per gli ambienti di produzione.

Passaggio successivo: verificare l'ambiente o la zona di destinazione di Azure

L'elenco di articoli seguente offre linee guida per punti specifici del percorso di adozione del cloud per consentire la riuscita nello scenario di adozione del cloud.