Con il pattern di architettura ibrida dell'ambiente, 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 altri ambienti. Questo pattern si basa sul deployment ridondante delle stesse applicazioni in più ambienti di computing. L'obiettivo dell'implementazione è contribuire ad aumentare la capacità, l'agilità e la resilienza.
Quando valuti quali carichi di lavoro migrare, potresti notare casi in cui l'esecuzione di un'applicazione specifica nel cloud pubblico presenta delle sfide:
- Vincoli giurisdizionali o normativi 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, considera 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. Queste limitazioni spesso si applicano all'ambiente di produzione e ai relativi dati. Potrebbero non essere applicabili ad altri ambienti che non utilizzano i dati effettivi. Contatta il reparto conformità della tua organizzazione o il 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 best practice esistenti o dai tentativi di ridurre al minimo le differenze tra gli ambienti. Sebbene queste preoccupazioni siano giustificate, non si applicano se distingui le fasi dei processi di sviluppo e test:
Sebbene i processi di sviluppo, test e deployment varino per ogni applicazione, in genere prevedono variazioni delle seguenti fasi:
- Sviluppo: creazione di una release candidata.
- Test funzionali o test di accettazione utente: verifica che la release candidate soddisfi i requisiti funzionali.
- Test di prestazioni e affidabilità: verifica che la versione candidata soddisfi i requisiti non funzionali. È noto anche come test di carico.
- Test di staging o deployment: verifica che la procedura di deployment funzioni.
- Produzione: rilascio di applicazioni nuove o aggiornate.
L'esecuzione di più di una di queste fasi in un unico ambiente è raramente pratica, 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 è testare se le procedure di deployment dell'applicazione funzionano come previsto. Quando una release raggiunge un ambiente di staging, i test funzionali devono essere completati. Lo staging è 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 di produzione, l'insieme di ambienti che utilizzi durante il ciclo di vita di un'applicazione deve soddisfare le seguenti regole, per quanto possibile:
- Tutti gli ambienti sono funzionalmente equivalenti. ovvero l'architettura, le API e le versioni di sistemi operativi e 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à, lo staging e la produzione sono non equivalenti a livello funzionale. ovvero le loro prestazioni, la loro scalabilità e la loro configurazione, nonché il modo in cui vengono gestiti e mantenuti, sono uguali o differiscono solo in modi insignificanti. In caso contrario, i test di rendimento e di staging diventano privi di significato.
In generale, non ci sono problemi se gli ambienti utilizzati per lo sviluppo e i test funzionali differiscono in modo non funzionale dagli altri ambienti.
Come illustrato nel seguente diagramma, gli ambienti di test e sviluppo sono basati su Google Cloud. Un database gestito, come Cloud SQL, può essere utilizzato come opzione per lo sviluppo e il test in Google Cloud. Lo sviluppo e il test possono utilizzare lo stesso motore del database e la stessa versione nell'ambiente on-premise, una versione 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 al test di carico delle prestazioni non è valido.
I seguenti scenari si adattano 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 GKE Enterprise di Google Kubernetes Engine (GKE) può essere una tecnologia abilitante chiave per questo approccio.
- Garantire la portabilità dei carichi di lavoro e astrarre le differenze tra gli ambienti di computing. Con una service mesh zero trust, puoi controllare e mantenere la separazione della comunicazione richiesta 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 per la produzione, lo staging e i test delle prestazioni (test di carico) e di affidabilità nell'ambiente di calcolo privato, garantendo l'equivalenza funzionale e non funzionale.
Considerazioni sulla progettazione
- Esigenze aziendali: ogni strategia di deployment e rilascio per le applicazioni presenta vantaggi e svantaggi. Per assicurarti che l'approccio che scegli sia in linea con i tuoi requisiti specifici, basa le tue selezioni su una valutazione approfondita delle esigenze e dei vincoli della tua attività.
- Differenze tra gli ambienti: nell'ambito di questo pattern, lo scopo principale dell'utilizzo di questo ambiente cloud è lo sviluppo e il test. Lo stato finale è ospitare l'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 nell'ambiente di produzione (on-premise), il team tecnico deve conoscere e comprendere le architetture e le funzionalità di entrambi gli ambienti. Ciò include 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 sviluppare alla tua azienda 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 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 che siano in linea con gli standard di controllo qualità del software per la tua organizzazione. Applica questi standard a qualsiasi applicazione che sviluppi e testi.
- Ridondanza: sebbene gli ambienti di sviluppo e test potrebbero non richiedere la stessa affidabilità dell'ambiente di produzione, hanno comunque bisogno di funzionalità ridondanti e della possibilità di testare diversi scenari di errore. I requisiti dello scenario di errore potrebbero richiedere la ridondanza come parte dell'ambiente di sviluppo e test.
Vantaggi
L'esecuzione di carichi di lavoro di test funzionali e di sviluppo nel cloud pubblico presenta 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 anche 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 lo sviluppo e i test avviando ambienti effimeri per ogni richiesta pull. In questo modo si riducono anche le spese generali di manutenzione e le incoerenze nell'ambiente di build.
- L'esecuzione di questi ambienti nel cloud pubblico contribuisce a creare familiarità e fiducia nel cloud e negli strumenti correlati, il che potrebbe facilitare 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 tutti gli ambienti.
Best practice
Per implementare correttamente il pattern di architettura ibrida dell'ambiente, prendi in considerazione i seguenti consigli:
- Definisci i requisiti di comunicazione dell'applicazione, inclusi la progettazione ottimale di rete e sicurezza. Quindi, utilizza il pattern di rete mirroring per progettare l'architettura di rete in modo da impedire le comunicazioni dirette tra sistemi di ambienti diversi. Se è necessaria la comunicazione tra gli ambienti, questa deve avvenire in modo controllato.
La strategia di deployment e test delle applicazioni che scegli deve essere in linea con i 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 gruppo di utenti specifico prima del rilascio più ampio.
Per rendere i carichi di lavoro portabili e astrarre le differenze tra gli ambienti, puoi utilizzare i container con Kubernetes. Per saperne di più, consulta Architettura di riferimento dell'ambiente ibrido GKE Enterprise.
Stabilisci una catena di strumenti comune che funzioni in tutti gli ambienti di computing per il deployment, la configurazione e l'operazione dei carichi di lavoro. L'utilizzo di Kubernetes ti offre questa coerenza.
Assicurati che le pipeline CI/CD siano coerenti tra gli ambienti di computing e che lo stesso insieme esatto di file binari, pacchetti o container venga implementato in 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 tutti gli ambienti. Per saperne di più, consulta Soluzioni DevOps su Google Cloud.
Per aiutarti a rilasciare continuamente applicazioni sicure e affidabili, incorpora la sicurezza come parte integrante del processo DevOps (DevSecOps). Per maggiori informazioni, consulta Distribuire e proteggere 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 Google Cloud e negli ambienti cloud esistenti. Valuta la possibilità di utilizzare sistemi di monitoraggio open source. Per maggiori informazioni, vedi 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 separati potrebbe essere accettabile. Tuttavia, l'utilizzo degli stessi strumenti con autorizzazioni di visualizzazione diverse può contribuire a ridurre l'impegno 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'utilizzo di servizi gestiti contribuisce a ridurre l'impegno amministrativo di manutenzione degli ambienti di sviluppo e test.
Per proteggere le informazioni sensibili, ti 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 Google Cloud prodotti sono 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 |