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 in più ambienti di calcolo. L'obiettivo del deployment è contribuire ad aumentare capacità, agilità e 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, considera non solo l'ambiente di produzione, ma anche gli ambienti coinvolti nel ciclo di vita di un'applicazione, 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. Se da un lato questi dubbi sono giustificati, non si applicano se distinguere tra le fasi del processo di sviluppo e di 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 candidata alla release.
- Test funzionali o test di accettazione dell'utente: verifica che l'elemento il candidato di release soddisfa 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. La lo scopo principale di un ambiente di gestione temporanea è verificare se l'applicazione le procedure di deployment funzionano come previsto. Quando una release raggiunge una fase temporanea dell'ambiente di lavoro, i test funzionali dovrebbero essere completi. 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, nella misura del possibile, le seguenti regole:
- Tutti gli ambienti sono equivalenti dal punto di vista funzionale. 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.
- Ambienti utilizzati per i test delle prestazioni e dell'affidabilità staging e produzione sono non funzionalmente equivalente. 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 del rendimento e della gestione temporanea diventano privi di 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 diagramma seguente, gli ambienti di test e sviluppo sono basate 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 sottostante dei due ambienti non sono identiche, ai test di carico delle prestazioni non è valido.
I seguenti scenari possono essere adatti al pattern ibrido dell'ambiente:
- Ottenere l’equivalenza funzionale in tutti gli ambienti affidandosi a
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 equivalenti dal punto di vista funzionale ambienti, 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 garantire che l'approccio scelto è in linea con i tuoi requisiti specifici, le tue selezioni su una valutazione approfondita delle esigenze e dei vincoli aziendali.
- Differenze di ambiente: nell'ambito di questo modello, l'obiettivo principale che utilizzano questo ambiente cloud per 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 potrebbero funzionare come previsto nell'ambiente cloud e non ambiente di produzione (on-premise), il team tecnico deve conoscere comprendere le architetture e le capacità di entrambi gli ambienti. Questo include dipendenze da altre applicazioni e dall'hardware dell'infrastruttura (ad esempio i sistemi di sicurezza che eseguono ispezioni del traffico).
- Governance: per controllare ciò che la tua azienda è autorizzata a sviluppare in nel cloud e ai dati che possono usare per i test, utilizzano un sistema di il processo di 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 chiari, predefiniti e misurabili. Testare i criteri di successo in linea con il software garanzia di qualità standard per la tua organizzazione. Applica questi standard a qualsiasi applicazione che sviluppi e test.
- 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
eseguire una richiesta di pull,
consentire l'esecuzione dei test e disattivarla 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.
- Per velocizzare lo sviluppo e i test, inizia ambienti temporanei per ogni richiesta di pull. 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 creare familiarità e la fiducia nel cloud e nei relativi strumenti, il che può aiutare 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, tieni in considerazione i seguenti consigli:
- Definisci i requisiti di comunicazione dell'applicazione, tra cui una progettazione 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 deployment e test delle applicazioni che scegli deve essere in linea con i tuoi requisiti e scopi commerciali. Ciò potrebbe comportare l'implementazione graduale delle modifiche in un ambiente o gruppo di utenti specifico prima del rilascio su larga scala.
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.
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 il computing ambienti e che lo stesso esatto insieme di file binari, pacchetti viene eseguito il deployment dei container 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 diversi ambienti. Per ulteriori informazioni, consulta Soluzioni DevOps su Google Cloud.
Per aiutarti con il rilascio continuo di soluzioni sicure e affidabili incorporano la sicurezza come parte integrante di 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 Google Cloud ambienti cloud esistenti e degli ambienti cloud. Valuta la possibilità di utilizzare il monitoraggio open source sistemi operativi. Per ulteriori informazioni, vedi Pattern di logging e monitoraggio ibridi 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ò aiutarti a ridurre lo sforzo e la complessità dell'addestramento.
Quando scegli i servizi di database, archiviazione e messaggistica per un funzionamento i test, utilizza prodotti che hanno 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 crittografare tutti le comunicazioni in transito. Se la crittografia è richiesta 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 prodotti Google Cloud 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 e PostgreSQL | Cloud SQL |
| Cluster Redis, Redis, Memcached | Memorystore |
| Network File System (NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
| Kubernetes | GKE Enterprise |