Con il pattern di architettura ibrido dell'ambiente, mantieni l'ambiente di produzione di un carico di lavoro nel data center esistente. Puoi quindi usare il cloud pubblico per i tuoi ambienti di sviluppo e test o altri ambienti. Questo pattern si basa sul deployment ridondante delle stesse applicazioni in più ambienti di computing. L'obiettivo del deployment è contribuire ad aumentare capacità, agilità e resilienza.
Durante la valutazione di quali carichi di lavoro eseguire la migrazione, potresti notare alcuni casi in cui l'esecuzione di un'applicazione specifica nel cloud pubblico presenta alcune sfide:
- I vincoli giurisdizionali o normativi potrebbero richiedere la conservazione dei dati in un paese specifico.
- I termini di licenza di terze parti potrebbero impedirti di utilizzare determinati software in un ambiente cloud.
- Un'applicazione potrebbe richiedere l'accesso a dispositivi hardware disponibili solo localmente.
In questi casi, prendi in considerazione non solo l'ambiente di produzione, ma tutti gli ambienti coinvolti nel ciclo di vita di un'applicazione, compresi i sistemi di sviluppo, test e gestione temporanea. Queste restrizioni spesso si applicano all'ambiente di produzione e ai suoi dati. Potrebbero non applicarsi ad altri ambienti che non utilizzano i dati effettivi. Verifica con il reparto per la conformità della tua organizzazione o con il team equivalente.
Il seguente diagramma mostra un tipico modello di architettura ibrida dell'ambiente:
L'esecuzione di sistemi di sviluppo e test in ambienti diversi da quelli dei sistemi di produzione può sembrare rischioso e potrebbe discostarsi dalle best practice esistenti o dai tentativi di minimizzare le differenze tra i tuoi ambienti. Sebbene queste preoccupazioni siano giustificate, non si applicano se distingui le fasi del processo di sviluppo e di test:
Sebbene i processi di sviluppo, test e deployment siano diversi per ogni applicazione, di solito prevedono variazioni delle seguenti fasi:
- Sviluppo: creazione di una release candidata alla release.
- Test funzionali o test di accettazione degli utenti: verifica che la release candidata soddisfi i requisiti funzionali.
- Test di prestazioni e affidabilità: verifica che il candidato alla release soddisfi i requisiti non funzionali. È anche noto come test di carico.
- Test di gestione temporanea o deployment: verifica del funzionamento della procedura di deployment.
- Produzione: rilascio di applicazioni nuove o aggiornate.
L'esecuzione di più di una di queste fasi in un singolo ambiente è raramente pratica, per cui ogni fase di solito richiede uno o più ambienti dedicati.
Lo scopo principale di un ambiente di test è eseguire test funzionali. Lo scopo principale di un ambiente di gestione temporanea è verificare se le procedure di deployment dell'applicazione funzionano come previsto. Nel momento in cui una release raggiunge un ambiente gestione temporanea, i test funzionali dovrebbero essere completati. La gestione temporanea è l'ultimo passaggio prima di eseguire il deployment del software nel deployment di produzione.
Per garantire che i risultati dei test siano significativi e che si applichino al deployment in produzione, il set di ambienti che utilizzi durante il ciclo di vita di un'applicazione deve soddisfare le seguenti regole, ove possibile:
- Tutti gli ambienti sono funzionalmente equivalenti. In altre parole, l'architettura, le API e le versioni dei sistemi operativi e delle librerie sono equivalenti e i sistemi si comportano allo stesso modo in tutti gli ambienti. Questa equivalenza evita situazioni in cui le applicazioni funzionano in un ambiente, ma non in un altro, o in cui i difetti non sono riproducibili.
- Gli ambienti utilizzati per i test delle prestazioni e dell'affidabilità, la gestione temporanea e la produzione sono non funzionalmente equivalenti. In altre parole, le prestazioni, la scalabilità, la configurazione e il modo in cui vengono gestiti e gestiti sono uguali o diversi solo in modo irrilevante. In caso contrario, i test del rendimento e della gestione temporanea diventano privi di significato.
In generale, va bene se gli ambienti utilizzati per lo sviluppo e i test funzionali differiscono in modo non funzionale dagli altri ambienti.
Come illustrato nel diagramma seguente, gli ambienti di test e sviluppo sono basati su Google Cloud. Un database gestito come Cloud SQL può essere usato come opzione per lo sviluppo e il test in Google Cloud. Sviluppo e test possono utilizzare lo stesso motore del database e la stessa versione nell'ambiente on-premise, una che sia funzionalmente equivalente o una nuova versione implementata nell'ambiente di produzione dopo la fase di test. Tuttavia, poiché l'infrastruttura sottostante dei due ambienti non è identica, questo approccio ai test di carico delle prestazioni non è valido.
I seguenti scenari possono adattarsi bene al pattern ibrido dell'ambiente:
- Ottieni l'equivalenza funzionale in tutti gli ambienti affidandoti a Kubernetes come livello di runtime comune, ove applicabile e fattibile.
La versione Google Kubernetes Engine (GKE) Enterprise può essere una tecnologia chiave per l'abilitazione di questo approccio.
- Garantisci la portabilità dei carichi di lavoro e astratta le differenze tra gli ambienti di computing. Con un mesh di servizi Zero Trust, puoi controllare e mantenere la separazione delle comunicazioni richiesta tra i diversi ambienti.
- Esegui ambienti di sviluppo e test funzionali nel cloud pubblico. Questi ambienti possono essere equivalenti dal punto di vista agli ambienti rimanenti, ma potrebbero differire per aspetti non funzionali, come le prestazioni. Questo concetto è illustrato nel diagramma precedente.
- Esegui ambienti per la produzione, la gestione temporanea e i test delle prestazioni (test di carico) e di affidabilità nell'ambiente di computing privato, garantendo l'equivalenza funzionale e non funzionale.
Considerazioni sul design
- Esigenze aziendali: ogni strategia di deployment e rilascio per le applicazioni presenta vantaggi e svantaggi specifici. Per assicurarti che l'approccio scelto sia in linea con i tuoi requisiti specifici, basa le selezioni su una valutazione approfondita delle esigenze e dei vincoli aziendali.
- Differenze di ambiente: nell'ambito di questo modello, l'obiettivo principale dell'utilizzo dell'ambiente cloud è per lo sviluppo e i test. Lo stato finale prevede l'hosting dell'applicazione testata nell'ambiente on-premise privato (produzione). Per evitare di sviluppare e testare una funzionalità che potrebbe funzionare come previsto nell'ambiente cloud e non funzionare nell'ambiente di produzione (on-premise), il team tecnico deve conoscere e comprendere le architetture e le funzionalità di entrambi gli ambienti. Ciò include dipendenze da altre applicazioni e dall'infrastruttura hardware, ad esempio i sistemi di sicurezza che eseguono l'ispezione del traffico.
- Governance: per controllare ciò che la tua azienda può sviluppare nel cloud e quali dati può utilizzare per i test, utilizza un processo di approvazione e governance. Questo processo può anche aiutare la tua azienda a fare in modo che non utilizzi funzionalità cloud nei tuoi ambienti di sviluppo e test che non esistono nell'ambiente di produzione on-premise.
- Criteri di successo: devono essere presenti criteri di successo dei test chiari, predefiniti e misurabili in linea con gli standard di garanzia della qualità del software della tua organizzazione. Applica questi standard a qualsiasi applicazione che sviluppi e test.
- Ridondanza: anche se gli ambienti di sviluppo e test potrebbero non richiedere molta affidabilità rispetto all'ambiente di produzione, necessitano comunque di funzionalità ridondanti e della capacità di testare diversi scenari di errore. I requisiti dello scenario di errore potrebbero portare alla progettazione di includere la ridondanza nell'ambiente di sviluppo e test.
Vantaggi
L'esecuzione di carichi di lavoro per lo sviluppo e i test funzionali nel cloud pubblico presenta numerosi vantaggi:
- Puoi avviare e arrestare automaticamente gli ambienti in base alle esigenze.
Ad esempio, puoi eseguire il provisioning di un intero ambiente per ogni richiesta di commit o pull, consentire l'esecuzione dei test e quindi disattivarla di nuovo. Questo approccio offre inoltre i seguenti vantaggi:
- Puoi ridurre i costi arrestando le istanze di macchine virtuali (VM) quando sono inattive o eseguendo il provisioning degli ambienti solo on demand.
- Puoi accelerare sviluppo e test avviando ambienti temporanei per ogni richiesta di pull. In questo modo si riducono anche i costi di manutenzione e le incoerenze nell'ambiente di build.
- L'esecuzione di questi ambienti nel cloud pubblico consente di acquisire familiarità e fiducia nel cloud e negli strumenti correlati, il che può essere utile per la migrazione di altri carichi di lavoro. Questo approccio è particolarmente utile se decidi di esplorare la portabilità dei carichi di lavoro utilizzando i container e Kubernetes, ad esempio utilizzando GKE Enterprise nei vari ambienti.
Best practice
Per implementare correttamente il pattern dell'architettura ibrida, considera i seguenti suggerimenti:
- Definisci i requisiti di comunicazione dell'applicazione, inclusa la progettazione di rete e sicurezza ottimale. Quindi, utilizza il pattern di rete con mirroring per progettare la tua architettura di rete in modo da evitare comunicazioni dirette tra sistemi di ambienti diversi. Se è necessaria la comunicazione tra ambienti, deve avvenire in modo controllato.
La strategia di deployment e test dell'applicazione dovrebbe allinearsi ai tuoi obiettivi e requisiti aziendali. Ciò potrebbe comportare l'implementazione di modifiche senza tempi di inattività o l'implementazione graduale delle funzionalità in un ambiente o un gruppo di utenti specifico prima di rilasciare l'app su larga scala. Per ulteriori informazioni, vedi Strategie di deployment e test delle applicazioni.
Per rendere portabili i carichi di lavoro e per astrarre le differenze tra gli ambienti, puoi utilizzare i container con Kubernetes. Per ulteriori informazioni, consulta Architettura di riferimento dell'ambiente ibrido di GKE Enterprise.
Stabilisci una catena di strumenti comune che funzioni in tutti gli ambienti di computing per il deployment, la configurazione e il funzionamento dei carichi di lavoro. Kubernetes offre questa coerenza.
Assicurati che le pipeline CI/CD siano coerenti tra gli ambienti di elaborazione e che venga eseguito il deployment dello stesso esatto insieme di programmi binari, pacchetti o container in questi ambienti.
Quando utilizzi Kubernetes, usa un sistema CI come Tekton per implementare una pipeline di deployment che esegue il deployment su cluster e funziona in diversi ambienti. Per maggiori informazioni, vedi Soluzioni DevOps su Google Cloud.
Per aiutarti con il rilascio continuo di applicazioni sicure e affidabili, incorpora la sicurezza come parte integrante del processo DevOps (DevSecOps). Per maggiori informazioni, vedi Distribuisci e proteggi la tua applicazione per internet in meno di un'ora utilizzando Dev(Sec)Ops Toolkit.
Usa gli stessi strumenti per il logging e il monitoraggio in Google Cloud e negli ambienti cloud esistenti. Valuta l'uso di sistemi di monitoraggio open source. Per ulteriori informazioni, consulta Pattern di monitoraggio e logging ibridi e multi-cloud.
Se team diversi gestiscono i carichi di lavoro di test e produzione, potrebbe essere accettabile utilizzare strumenti separati. Tuttavia, l'utilizzo degli stessi strumenti con autorizzazioni di visualizzazione diverse può aiutare a ridurre le attività e la complessità dell'addestramento.
Quando scegli servizi di database, archiviazione e messaggistica per i test funzionali, utilizza prodotti che hanno un equivalente gestito su Google Cloud. L'uso di servizi gestiti consente di ridurre lo sforzo amministrativo per la manutenzione degli ambienti di sviluppo e test.
Per proteggere le informazioni sensibili, consigliamo di criptare tutte le comunicazioni in transito. Se è necessaria la crittografia a livello di connettività, sono disponibili varie opzioni basate sulla soluzione di connettività ibrida selezionata. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.
La tabella seguente mostra quali prodotti Google Cloud sono compatibili con i prodotti OSS più comuni.
| Prodotto OSS | Compatibile con il prodotto Google Cloud |
|---|---|
| Apache HBase | Bigtable |
| Apache Beam | Dataflow |
| Contratto di licenza con l'utente finale (CDAP) | Cloud Data Fusion |
| Apache Hadoop | Dataproc |
| MySQL e PostgreSQL | Cloud SQL |
| Cluster Redis, Redis, Memcached | Memorystore |
| File system di rete (NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
| Kubernetes | GKE Enterprise |