Approcci architettonici per adottare un'architettura ibrida o multi-cloud

Last reviewed 2025-01-23 UTC

Questo documento fornisce indicazioni su approcci e considerazioni comuni e comprovati per eseguire la migrazione del tuo carico di lavoro nel cloud. Espande le indicazioni riportate in Creare una strategia di architettura ibrida e multi-cloud, che illustra diversi passaggi possibili e consigliati per progettare una strategia per l'adozione di un'architettura ibrida o multi-cloud.

Un modo comune per iniziare a utilizzare il cloud pubblico è l'approccio cloud-first. In questo approccio, esegui il deployment dei nuovi carichi di lavoro nel cloud pubblico, mentre i carichi di lavoro esistenti rimangono invariati. In questo caso, valuta la possibilità di un deployment classico in un ambiente di calcolo privato solo se un deployment in cloud pubblico è impossibile per motivi tecnici o organizzativi.

La strategia cloud-first presenta vantaggi e svantaggi. Il lato positivo è che è orientato al futuro. Puoi eseguire il deployment di nuovi carichi di lavoro in modo modernizzato, evitando (o almeno riducendo al minimo) le complessità della migrazione dei carichi di lavoro esistenti.

Sebbene un approccio cloud-first possa offrire determinati vantaggi, potrebbe potenzialmente comportare opportunità perse per migliorare o utilizzare i carichi di lavoro esistenti. I nuovi carichi di lavoro potrebbero rappresentare una frazione dell'intero panorama IT e il loro effetto sulle spese e sulle prestazioni IT può essere limitato. L'allocazione di tempo e risorse per la migrazione di un carico di lavoro esistente potrebbe potenzialmente portare a vantaggi o risparmi sostanziali rispetto al tentativo di adattare un nuovo carico di lavoro all'ambiente cloud.

Inoltre, seguire un approccio cloud-first rigoroso rischia di aumentare la complessità complessiva del tuo ambiente IT. Questo approccio potrebbe creare ridondanze, ridurre il rendimento a causa di una potenziale comunicazione eccessiva tra ambienti o generare un ambiente di calcolo non adatto al singolo carico di lavoro. Inoltre, la conformità alle normative di settore e alle leggi sulla privacy dei dati può limitare le aziende nella migrazione di determinate applicazioni che contengono dati sensibili.

Tenendo conto di questi rischi, ti consigliamo di utilizzare un approccio cloud-first solo per carichi di lavoro selezionati. L'utilizzo di un approccio cloud-first ti consente di concentrarti sui carichi di lavoro che possono trarre il massimo vantaggio da un deployment o una migrazione nel cloud. Questo approccio prende in considerazione anche la modernizzazione dei carichi di lavoro esistenti.

Un esempio comune di architettura ibrida cloud-first è quando le applicazioni e i servizi legacy che contengono dati critici devono essere integrati con nuovi dati o applicazioni. Per completare l'integrazione, puoi utilizzare un'architettura ibrida che modernizza i servizi legacy utilizzando interfacce API, che li sblocca per il consumo da parte di nuovi servizi e applicazioni cloud. Con una piattaforma di gestione delle API cloud, come Apigee, puoi implementare questi casi d'uso con modifiche minime all'applicazione e aggiungere sicurezza, analisi e scalabilità ai servizi legacy.

Migrazione e modernizzazione

Il multicloud ibrido e la modernizzazione IT sono concetti distinti collegati in un circolo virtuoso. L'utilizzo del cloud pubblico può agevolare e semplificare la modernizzazione dei carichi di lavoro IT. La modernizzazione dei carichi di lavoro IT può aiutarti a ottenere di più dal cloud.

Gli obiettivi principali della modernizzazione dei workload sono i seguenti:

  • Ottieni una maggiore agilità per adattarti ai requisiti in evoluzione.
  • Riduci i costi dell'infrastruttura e delle operazioni.
  • Aumenta l'affidabilità e la resilienza per ridurre al minimo i rischi.

Tuttavia, potrebbe non essere possibile modernizzare contemporaneamente tutte le applicazioni nel processo di migrazione. Come descritto in Migrazione a Google Cloud, puoi implementare uno dei seguenti tipi di migrazione o anche combinarne più di uno, se necessario:

  • Rehosting (lift and shift)
  • Replatforming (trasferimento e ottimizzazione)
  • Refactoring (sposta e migliora)
  • Riprogettazione dell'architettura (continua a modernizzare)
  • Ricostruisci (rimuovi e sostituisci, a volte chiamata elimina e sostituisci)
  • Riacquisto

Quando prendi decisioni strategiche sulle tue architetture ibride e multicloud, è importante valutare la fattibilità della tua strategia dal punto di vista dei costi e dei tempi. Ti consigliamo di prendere in considerazione un approccio di migrazione graduale, iniziando con il sollevamento e lo spostamento o il cambio di piattaforma e poi il refactoring o la riprogettazione come passaggio successivo. In genere, il lift and shift consente di ottimizzare le applicazioni dal punto di vista dell'infrastruttura. Una volta che le applicazioni sono in esecuzione nel cloud, è più facile utilizzare e integrare i servizi cloud per ottimizzarli ulteriormente utilizzando architetture e funzionalità cloud-first. Inoltre, queste applicazioni possono comunque comunicare con altri ambienti tramite una connessione di rete ibrida.

Ad esempio, puoi eseguire il refactoring o la riprogettazione di un'applicazione monolitica di grandi dimensioni basata su VM e trasformarla in diversi microservizi indipendenti, in base a un'architettura di microservizi basata su cloud. In questo esempio, l'architettura dei microservizi utilizza Google Cloud servizi container gestiti come Google Kubernetes Engine (GKE) o Cloud Run. Tuttavia, se l'architettura o l'infrastruttura di un'applicazione non è supportata così com'è nell'ambiente cloud di destinazione, ti consigliamo di iniziare con il replatforming, il refactoring o la riprogettazione della tua strategia di migrazione per superare questi vincoli, se possibile.

Quando utilizzi uno di questi approcci di migrazione, valuta la possibilità di modernizzare le tue applicazioni (se applicabile e fattibile). La modernizzazione può richiedere l'adozione e l'implementazione di principi di Site Reliability Engineering (SRE) o DevOps, pertanto potrebbe essere necessario estendere la modernizzazione delle applicazioni al tuo ambiente privato in una configurazione ibrida. Anche se l'implementazione dei principi SRE prevede l'ingegneria come elemento fondamentale, si tratta più di un processo di trasformazione che di una sfida tecnica. Di conseguenza, è probabile che richieda modifiche procedurali e culturali. Per scoprire di più su come il primo passo per implementare SRE in un'organizzazione sia ottenere l'approvazione del management, consulta Con SRE, non pianificare significa pianificare di fallire.

Combinare approcci di migrazione

Ogni approccio alla migrazione discusso qui presenta determinati punti di forza e di debolezza. Un vantaggio chiave dell'adozione di una strategia ibrida e multi-cloud è che non è necessario optare per un unico approccio. Puoi invece decidere quale approccio è più adatto per ogni carico di lavoro o stack di applicazioni, come mostrato nel seguente diagramma.

Diagramma di flusso che mostra diversi approcci per la migrazione dei workload dal tuo ambiente cloud.

Questo diagramma concettuale illustra i vari percorsi o approcci di migrazione e modernizzazione che possono essere applicati contemporaneamente a carichi di lavoro diversi, in base ai requisiti tecnici, agli obiettivi e alle esigenze aziendali specifici di ciascun carico di lavoro o applicazione.

Inoltre, non è necessario che gli stessi componenti dello stack dell'applicazione seguano la stessa strategia o lo stesso approccio di migrazione. Ad esempio:

  • Il database on-premise di backend di un'applicazione può essere sottoposto a una nuova piattaforma da MySQL auto-hosted a un database gestito utilizzando Cloud SQL in Google Cloud.
  • Le macchine virtuali frontend dell'applicazione possono essere sottoposte a refactoring per essere eseguite su contenitori utilizzando GKE Autopilot, in cui Google gestisce la configurazione del cluster, inclusi nodi, scalabilità, sicurezza e altre impostazioni preconfigurate.
  • La soluzione di bilanciamento del carico hardware on-premise e le funzionalità WAF del firewall delle applicazioni web possono essere sostituite con il Bilanciatore del carico di Google Cloud e Google Cloud Armor.

Scegli il rehosting (lift and shift) se una delle seguenti condizioni è vera per i carichi di lavoro:

  • Hanno un numero relativamente ridotto di dipendenze dal loro ambiente.
  • Non sono considerati meritevoli di refactoring o il refactoring prima della migrazione non è fattibile.
  • Si basano su software di terze parti.

Valuta la possibilità di eseguire il refactoring (sposta e migliora) per questi tipi di workload:

  • Hanno dipendenze che devono essere slegate.
  • Si basano su sistemi operativi, hardware o database che non possono essere supportati nel cloud.
  • Non utilizzano in modo efficiente le risorse di calcolo o di archiviazione.
  • Non possono essere implementati in modo automatico senza un certo impegno.

Valuta se la ricostruzione (rimozione e sostituzione) soddisfa le tue esigenze per questi tipi di carichi di lavoro:

  • Non soddisfano più i requisiti attuali.
  • Possono essere incorporate in altre applicazioni che forniscono funzionalità simili senza compromettere i requisiti aziendali.
  • Si basano su una tecnologia di terze parti che ha raggiunto la fine del suo ciclo di vita.
  • Richiedono tariffe di licenza di terze parti non più convenienti.

Il programma di migrazione rapida mostra in che modo Google Cloud aiuta i clienti a utilizzare le best practice, ridurre i rischi, controllare i costi e semplificare il percorso verso il successo nel cloud.