Con il pattern di architettura ibrida dell'ambiente, mantieni la produzione di un carico di lavoro nel data center esistente. Quindi utilizzi il pubblico cloud per i tuoi ambienti di sviluppo e test o altri ambienti. Questo pattern si basa sul deployment ridondante delle stesse applicazioni in diversi ambienti di elaborazione. L'obiettivo del deployment è contribuire ad aumentare capacità, agilità e resilienza.
Durante la valutazione dei carichi di lavoro da migrare, potresti notare alcuni casi durante l'esecuzione di a un'applicazione specifica nel cloud pubblico presenta alcune sfide:
- I vincoli giurisdizionali o normativi potrebbero richiedere di mantenere in un determinato paese.
- 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. Queste restrizioni spesso si applicano dell'ambiente di produzione e dei suoi dati. Potrebbero non essere applicabili ad altri ambienti che non utilizzano i dati effettivi. Verifica la conformità reparto della tua organizzazione o dal team equivalente.
Il seguente diagramma mostra un tipico modello di architettura ibrida dell'ambiente:
Esecuzione di sistemi di sviluppo e test in ambienti diversi da quelli del tuo che potrebbero sembrare rischiosi e potrebbero discostarsi dalle best practice esistenti per ridurre al minimo le differenze ambienti cloud-native. 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 applicazione, di solito prevedono variazioni 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à. Verificare che la release del candidato soddisfa i requisiti non funzionali. È anche noto come test di carico.
- Test di gestione temporanea o deployment: verifica della procedura di deployment funziona.
- Produzione: rilascio di applicazioni nuove o aggiornate.
L'esecuzione di più di una di queste fasi in un singolo ambiente raramente quindi ogni fase richiede di solito 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. La gestione temporanea è l'ultima prima di eseguire il deployment del software nel deployment di produzione.
Per garantire che i risultati dei test siano significativi e che si applichino alla produzione il deployment, l'insieme di ambienti che usi durante del ciclo di vita deve soddisfare, per quanto possibile, le seguenti regole:
- Tutti gli ambienti sono funzionalmente equivalenti. Vale a dire che architettura, API e versioni di sistemi operativi e librerie sono equivalenti e i sistemi si comportano allo stesso modo in tutti gli ambienti. Questo l'equivalenza evita situazioni in cui le applicazioni funzionano in un ambiente ma non in un altro o se i difetti non sono riproducibili.
- Ambienti utilizzati per i test delle prestazioni e dell'affidabilità staging e produzione sono non funzionalmente equivalente. ovvero le prestazioni, la scalabilità, la configurazione e il modo gestiti e gestiti, sono uguali o differiscono solo in modo insignificante. 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 funzionali differiscono in modo non funzionale dagli 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 utilizzata come opzione per lo sviluppo e i test in Google Cloud. Sviluppo e i test possono utilizzare lo stesso motore del database e la stessa versione di servizio equivalente, o una nuova versione 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 adattarsi bene 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 Google Kubernetes Engine (GKE) Enterprise può essere una tecnologia chiave per l'abilitazione di questo
l'importanza di un approccio umile.
- Assicurati la portabilità dei carichi di lavoro e astraggono le differenze tra 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 funzionale ambienti, 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 le prestazioni (test di carico) e test di affidabilità nell'ambiente di computing privato, garantendo equivalenza funzionale e non funzionale.
Considerazioni sul design
- Esigenze aziendali: ciascuna 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. Il finale è ospitare l'applicazione testata in ambienti on-premise privati (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 a garantire che non utilizza funzionalità cloud nelle fasi di sviluppo e test esistenti nel tuo 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.
- Ridondanza: sebbene gli ambienti di sviluppo e test potrebbero non richiedono tutta l'affidabilità dell'ambiente di produzione, devono comunque e la capacità di testare diversi scenari di errore. I requisiti dello scenario di errore potrebbero portare la progettazione a includere ridondanza nell'ambiente di sviluppo e test.
Vantaggi
L'esecuzione di carichi di lavoro per lo sviluppo e i test funzionali nel cloud pubblico ha 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 sono inattivi o eseguendo il provisioning degli ambienti solo on demand.
- Per velocizzare lo sviluppo e i test, inizia ambienti temporanei per ogni richiesta di pull. In questo modo si riducono anche i costi di manutenzione riduce le incoerenze nell'ambiente di build.
- L'esecuzione di questi ambienti nel cloud pubblico aiuta a creare familiarità e la fiducia nel cloud e nei relativi strumenti, il che potrebbe aiutarti la migrazione di altri carichi di lavoro. Questo approccio è particolarmente utile se decidi di esplorare Portabilità del carico di lavoro usando container e Kubernetes, ad esempio usando GKE Enterprise tra ambienti diversi.
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. Poi utilizza Pattern rete con mirroring per progettare l'architettura di rete in modo da prevenire per le comunicazioni dirette tra sistemi di diversi ambienti. Se la comunicazione è necessaria tra gli ambienti, deve avvenire in un ambiente controllato in modo adeguato.
La strategia di deployment e test delle applicazioni che scegli deve essere in linea con i tuoi requisiti e scopi commerciali. Ciò potrebbe comportare le modifiche senza tempi di inattività o l'implementazione graduale di funzionalità un ambiente o un gruppo di utenti specifico prima di un rilascio più ampio. Per ulteriori informazioni informazioni, vedi Strategie di deployment e test delle applicazioni.
Per rendere portabili i carichi di lavoro e per astrarre le differenze potresti usare i container con Kubernetes. Per ulteriori informazioni le informazioni, vedi 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 il computing ambienti e che lo stesso esatto insieme di file binari, pacchetti viene eseguito il deployment dei container in questi ambienti.
Quando usi Kubernetes, usa un sistema CI come Tekton per implementare una pipeline di deployment che esegue il deployment nei cluster ambienti cloud-native. Per ulteriori informazioni, vedi 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, vedi Distribuisci e proteggi la tua applicazione per internet in meno di un'ora con 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 diversi. Per ulteriori informazioni, vedi Pattern di logging e monitoraggio ibridi e multi-cloud
Se team diversi gestiscono carichi di lavoro di test e produzione, utilizzando di archiviazione di Google Cloud potrebbero essere accettabili. Tuttavia, l'utilizzo degli stessi strumenti con le autorizzazioni di visualizzazione possono aiutare a ridurre le attività 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'affidamento ai servizi gestiti aiuta a ridurre lo sforzo amministrativo di e la manutenzione degli 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 connettività sono disponibili varie opzioni basate sul modello di connettività standard. Queste opzioni includono tunnel VPN, 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 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 |