Con il modello di architettura ambiente ibrido, mantieni l'ambiente di produzione di un carico di lavoro nel data center esistente. Poi utilizzi il cloud pubblico per gli ambienti di sviluppo e test o per altri ambienti. Questo pattern si basa sul deployment ridondante delle stesse applicazioni su più ambienti di calcolo. L'obiettivo del deployment è contribuire ad aumentare la capacità, l'agilità e la resilienza.
Quando valuti i carichi di lavoro di cui eseguire la migrazione, potresti notare casi in cui l'esecuzione di un'applicazione specifica nel cloud pubblico presenta delle sfide:
- Limitazioni di giurisdizione o normative potrebbero richiedere di conservare i 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, inclusi i sistemi di sviluppo, test e gestione temporanea. Spesso queste limitazioni si applicano all'ambiente di produzione e ai relativi dati. Potrebbero non essere applicabili ad altri ambienti che non utilizzano i dati effettivi. Rivolgiti al reparto di conformità della tua organizzazione o al team equivalente.
Il seguente diagramma mostra un tipico pattern di architettura ibrida dell'ambiente:
L'esecuzione di sistemi di sviluppo e test in ambienti diversi da quelli di produzione potrebbe sembrare rischiosa e potrebbe discostarsi dalle tue best practice esistenti o dai tuoi tentativi di ridurre al minimo le differenze tra gli ambienti. Sebbene questi dubbi siano giustificati, non si applicano se distingui le fasi dei processi di sviluppo e test:
Sebbene i processi di sviluppo, test e deployment siano diversi per ogni applicazione, in genere prevedono varianti delle seguenti fasi:
- Sviluppo: creazione di una release candidate.
- Test funzionali o test di accettazione da parte dell'utente: verifica che la release candidate soddisfi i requisiti funzionali.
- Test di prestazioni e affidabilità: verifica che la release candidata soddisfi i requisiti non funzionali. È noto anche come test di carico.
- Test di staging o deployment: verifica del funzionamento della procedura di deployment.
- Produzione: rilascio di applicazioni nuove o aggiornate.
Eseguire più di una di queste fasi in un unico ambiente è raramente pratico, quindi ogni fase richiede in genere uno o più ambienti dedicati.
Lo scopo principale di un ambiente di test è eseguire test funzionali. Lo scopo principale di un ambiente di staging è verificare se le procedure di deployment dell'applicazione funzionano come previsto. Quando una release raggiunge un ambiente di staging, i test funzionali dovrebbero essere completati. L'implementazione è l'ultimo passaggio prima di eseguire il deployment del software nel deployment di produzione.
Per assicurarti che i risultati dei test siano significativi e si applichino al deployment in produzione, l'insieme di ambienti che utilizzi durante il ciclo di vita di un'applicazione deve soddisfare, per quanto possibile, le seguenti regole:
- 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 di prestazioni e affidabilità, per lo staging e la produzione sono non funzionalmente equivalenti. In altre parole, il loro rendimento, la loro scalabilità e la loro configurazione, nonché il modo in cui vengono gestiti e mantenuti, sono uguali o differiscono solo in modo non significativo. In caso contrario, i test di prestazioni e di staging non hanno significato.
In generale, non è un problema se gli ambienti utilizzati per lo sviluppo e i test funzionali sono diversi da un punto di vista non funzionale rispetto agli altri ambienti.
Come illustrato nel seguente diagramma, gli ambienti di test e sviluppo vengono creati su Google Cloud. Un database gestito, come Cloud SQL, può essere utilizzato come opzione per lo sviluppo e i test in Google Cloud. Per lo sviluppo e il test è possibile utilizzare lo stesso motore e la stessa versione del database nell'ambiente on-premise, un motore funzionalmente equivalente o una nuova versione implementata nell'ambiente di produzione dopo la fase di test. Tuttavia, poiché l'infrastruttura di base dei due ambienti non è identica, questo approccio ai test di carico del rendimento non è valido.
I seguenti scenari possono adattarsi bene al pattern ibrido dell'ambiente:
- Raggiungi l'equivalenza funzionale in tutti gli ambienti facendo affidamento su Kubernetes come livello di runtime comune, ove applicabile e fattibile.
La versione Enterprise di Google Kubernetes Engine (GKE) può essere una tecnologia di base fondamentale per questo approccio.
- Garantire la portabilità dei carichi di lavoro e scorporare le differenze tra gli ambienti di calcolo. Con una mesh di servizi zero trust, puoi controllare e mantenere la separazione delle comunicazioni necessaria tra i diversi ambienti.
- Esegui ambienti di sviluppo e test funzionali nel cloud pubblico. Questi ambienti possono essere funzionalmente equivalenti agli altri, ma potrebbero differire per aspetti non funzionali, come le prestazioni. Questo concetto è illustrato nel diagramma precedente.
- Esegui ambienti di produzione, di staging e di prestazioni (test di carico) e di affidabilità nell'ambiente di calcolo privato, garantendo l'equivalenza funzionale e non funzionale.
Considerazioni sul design
- Esigenze aziendali: ogni strategia di deployment e rilascio per le applicazioni ha i suoi vantaggi e svantaggi. Per assicurarti che l'approccio selezionato sia in linea con i tuoi requisiti specifici, basa le tue scelte su una valutazione approfondita delle esigenze e dei vincoli della tua attività.
- Differenze di ambiente: nell'ambito di questo pattern, l'obiettivo principale dell'utilizzo di questo ambiente cloud è lo sviluppo e i test. Lo stato finale è 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. Sono incluse le dipendenze da altre applicazioni e dall'infrastruttura hardware, ad esempio i sistemi di sicurezza che eseguono l'ispezione del traffico.
- Governance: per controllare cosa è consentito alla tua azienda sviluppare nel cloud e quali dati può utilizzare per i test, utilizza una procedura di approvazione e governance. Questa procedura può anche aiutare la tua azienda ad assicurarsi di non utilizzare funzionalità cloud negli 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 controllo qualità del software per la tua organizzazione. Applica questi standard a qualsiasi applicazione che sviluppi e testi.
- Redundanza: anche se gli ambienti di sviluppo e test potrebbero non richiedere un'affidabilità pari a quella dell'ambiente di produzione, hanno comunque bisogno di funzionalità ridondanti e della possibilità di testare diversi scenari di errore. I requisiti relativi agli scenari di errore potrebbero portare il design a includere la ridondanza nell'ambiente di sviluppo e test.
Vantaggi
L'esecuzione di carichi di lavoro di sviluppo e test funzionali nel cloud pubblico offre diversi vantaggi:
- Puoi avviare e arrestare automaticamente gli ambienti in base alle esigenze.
Ad esempio, puoi eseguire il provisioning di un intero ambiente per ogni commit o pull request, consentire l'esecuzione dei test e poi disattivarlo di nuovo. Questo approccio offre inoltre i seguenti vantaggi:
- Puoi ridurre i costi arrestando le istanze di macchine virtuali (VM) quando non sono attive o eseguendo il provisioning degli ambienti solo su richiesta.
- Puoi velocizzare lo sviluppo e i test avviando ambienti effimeri per ogni pull request. In questo modo si riducono anche le spese generali di manutenzione e le incoerenze nell'ambiente di compilazione.
- L'esecuzione di questi ambienti nel cloud pubblico aiuta a familiarizzare con il cloud e gli strumenti correlati, il che potrebbe 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 container e Kubernetes, ad esempio utilizzando GKE Enterprise in più ambienti.
Best practice
Per implementare correttamente il pattern di architettura ibrida dell'ambiente, considera i seguenti consigli:
- Definisci i requisiti di comunicazione dell'applicazione, incluso il design ottimale della rete e della sicurezza. Quindi, utilizza il pattern di rete speculare per aiutarti a progettare l'architettura di rete in modo da impedire le comunicazioni dirette tra sistemi di ambienti diversi. Se è necessaria la comunicazione tra ambienti, deve avvenire in modo controllato.
La strategia di test e deployment dell'applicazione che scegli deve essere in linea con gli scopi e i requisiti della tua attività. Ciò potrebbe comportare l'implementazione graduale delle modifiche in un ambiente o gruppo di utenti specifico prima del rilascio su larga scala, senza tempi di inattività.
Per rendere i carichi di lavoro portabili e per astrarre le differenze tra gli ambienti, puoi utilizzare i container con Kubernetes. Per maggiori informazioni, consulta la architettura di riferimento dell'ambiente ibrido GKE Enterprise.
Stabilire una catena di strumenti comune che funzioni in tutti gli ambienti di calcolo per il deployment, la configurazione e il funzionamento dei carichi di lavoro. L'utilizzo di Kubernetes ti offre questa coerenza.
Assicurati che le pipeline CI/CD siano coerenti tra gli ambienti di calcolo e che lo stesso insieme di binari, pacchetti o contenitori venga implementato in tutti questi ambienti.
Quando utilizzi Kubernetes, utilizza un sistema CI come Tekton per implementare una pipeline di deployment che esegue il deployment nei cluster e funziona in diversi ambienti. Per ulteriori informazioni, consulta 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 ulteriori informazioni, consulta Pubblica e metti al sicuro la tua applicazione rivolta a internet in meno di un'ora utilizzando Dev(Sec)Ops Toolkit.
Utilizza gli stessi strumenti per il logging e il monitoraggio in tutti gli ambienti cloud esistenti Google Cloud. Valuta la possibilità di utilizzare sistemi di monitoraggio open source. Per ulteriori informazioni, consulta Pattern di logging e monitoraggio per cloud ibrido e multi-cloud.
Se team diversi gestiscono i carichi di lavoro di test e produzione, l'utilizzo di strumenti distinti potrebbe essere accettabile. Tuttavia, l'utilizzo degli stessi strumenti con autorizzazioni di visualizzazione diverse può contribuire a ridurre la complessità e lo sforzo di addestramento.
Quando scegli servizi di database, archiviazione e messaggistica per i test funzionali, utilizza prodotti con un equivalente gestito su Google Cloud. L'utilizzo di servizi gestiti consente di ridurre l'impegno amministrativo necessario per mantenere gli ambienti di sviluppo e test.
Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte le comunicazioni in transito. Se è richiesta la crittografia a livello di livello di connettività, sono disponibili varie opzioni in base alla soluzione di connettività ibrida selezionata. Queste opzioni includono i tunnel VPN, la VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.
La tabella seguente mostra i Google Cloud prodotti compatibili con i prodotti OSS comuni.
| Prodotto OSS | Compatibile con il prodotto Google Cloud |
|---|---|
| Apache HBase | Bigtable |
| Apache Beam | Dataflow |
| CDAP | Cloud Data Fusion |
| Apache Hadoop | Dataproc |
| MySQL, PostgreSQL | Cloud SQL |
| Cluster Redis, Redis, Memcached | Memorystore |
| Network File System (NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
| Kubernetes | GKE Enterprise |