Una strategia multicloud vincente richiede un'architettura disegnata sulle esigenze specifiche del portafoglio di workloads applicativi. Scopra i pattern di deployment distribuito e ridondante che possono fare la differenza.
Getti le basi del successo multicloud con il pattern di deployment giusto
Una strategia multicloud ben definita aiuta le aziende a centrare i propri obiettivi di business. Ma muoversi nel multicloud richiede un approccio architetturale accorto, in grado di garantire coesione tra i diversi servizi cloud. L'architettura va modellata sui requisiti del proprio portafoglio di workloads applicativi, ma fortunatamente è possibile affidarsi ad alcuni pattern ormai consolidati.
Questi pattern si basano su deployment distribuito o ridondante:
- I pattern di deployment distribuito eseguono le applicazioni nell'ambiente di calcolo più adatto, sfruttando le diverse proprietà e caratteristiche di ciascuno.
- I pattern di deployment ridondante prevedono il rilascio delle stesse applicazioni in più ambienti di calcolo, per aumentare capacità o resilienza.
Pattern di deployment distribuito
I pattern distribuiti puntano a trovare un equilibrio tra la gestione dei vincoli imposti dalle applicazioni esistenti e la valorizzazione del potenziale unico di ogni ambiente di calcolo. Nella scelta del pattern più adatto vanno considerati fattori come agilità, scalabilità, sicurezza e affidabilità.
Tiered hybrid
Con un pattern di deployment tiered hybrid, le applicazioni frontend esistenti vengono portate sul cloud pubblico caso per caso, mentre le applicazioni backend già in uso restano nell'ambiente di calcolo privato. Nel tempo, però, anche i backend potranno essere spostati sul cloud pubblico, dato che la quota di applicazioni rilasciate nel cloud è destinata a crescere.
Dare priorità ai frontend ha senso perché, mentre questi dipendono dai backend, non è vero il contrario. Avendo poche dipendenze, le applicazioni frontend sono in genere più semplici da isolare e da migrare rispetto ai backend. Portarle sul cloud pubblico è una scelta sensata: cambiano più spesso dei backend e possono trarre il massimo dalla flessibilità del cloud. Il cloud semplifica la configurazione di un processo di continuous integration/continuous deployment (CI/CD) per aggiornamenti automatizzati ed efficienti, mentre funzionalità come load balancing, deployment multiregionali e autoscaling migliorano le prestazioni.
Per i backend che gestiscono dati con requisiti di compliance stringenti, mantenerli in un ambiente di calcolo privato può essere una scelta prudente. Molti Paesi impongono la localizzazione dei dati, ovvero che le aziende archivino ed elaborino i dati a livello locale. Il Regolamento generale sulla protezione dei dati (GDPR) dell'UE, ad esempio, prevede disposizioni stringenti sulla conservazione dei dati personali, che possono essere soddisfatte al meglio con una soluzione on-premises.
Multicloud partizionato
Il pattern multicloud partizionato consente di spostare i workloads tra ambienti di cloud pubblico di vendor diversi. La portabilità dei workloads è essenziale per sfruttare la flessibilità di rilasciare le applicazioni nell'ambiente di calcolo più adatto. Occorre astrarre le differenze tra gli ambienti per poter spostare i workloads tra più ambienti di calcolo.
I pattern multicloud partizionati aiutano a evitare il vendor lock-in, perché non vincolano a un unico cloud service provider. Poter spostare i workloads in ambienti alternativi all'occorrenza protegge dal rischio di downtime dovuto a disservizi e permette di scegliere le funzionalità più rilevanti di ciascun provider.
Mantenere la portabilità dei workloads necessaria a sfruttare questo pattern consente anche di ottimizzare le operazioni nel passaggio da un ambiente all'altro. La portabilità ha però anche degli svantaggi: richiede un lavoro aggiuntivo di sviluppo, testing e operations. Progettare per la portabilità può inoltre ridurre l'utilità della piattaforma cloud scelta al minimo comune denominatore, impedendo ai workloads di sfruttare i servizi completamente gestiti dal cloud provider. Anche i costi di egress possono crescere in fretta.
La containerizzazione facilita la portabilità dei workloads, e Kubernetes ne amplia i benefici aiutando le aziende a evitare il vendor lock-in.
Hybrid e multicloud per analytics e ML
Con questo pattern, i sistemi transazionali restano on-premises, mentre i workloads analitici vengono rilasciati nel cloud e, se necessario, restituiscono i dati. I sistemi transazionali si occupano delle operazioni quotidiane in ambiti come finance, comunicazione e vendite. I workloads analitici comprendono le applicazioni che elaborano o visualizzano i dati per generare insight a supporto delle decisioni. Questo pattern sfrutta la separazione tra i due mondi per eseguire ciascun tipo di workload in un ambiente di calcolo distinto.
Eseguendo i workloads di analytics nel cloud, è possibile scalare dinamicamente le risorse di calcolo per elaborare in tempi rapidi grandi volumi di dati, senza il rischio di sovradimensionare le risorse. I principali cloud provider offrono inoltre servizi completi per gestire i dati, dall'acquisizione lungo l'intero ciclo di vita.
Edge hybrid
La connettività continua è un requisito per eseguire workloads nel cloud, ma non sempre è garantita. Luoghi come navi, supermercati e alcuni stabilimenti produttivi possono non avere un accesso a internet affidabile, ma sono al tempo stesso contesti chiave per l'Internet of Things (IoT), che richiede connettività affinché sensori e chip integrati possano trasmettere e ricevere dati di valore. È qui che entra in gioco il pattern edge hybrid: i workloads time-critical e business-critical vengono eseguiti localmente, all'edge della rete, mentre tutti gli altri restano nel cloud.
Eseguire localmente i workloads time-critical e business-critical favorisce bassa latenza e autosufficienza. Le transazioni importanti possono comunque essere portate a termine anche quando la connettività internet non è affidabile. Adottando questo pattern si continua a beneficiare del cloud per una quota significativa dei propri workloads. Per ottenere un'efficacia reale, è fondamentale ridurre al minimo le dipendenze tra i sistemi in esecuzione all'edge e quelli in esecuzione nel cloud.
Pattern di deployment ridondante
I pattern di deployment ridondante prevedono il rilascio delle stesse applicazioni in più ambienti di calcolo, per aumentare capacità o resilienza.
Ambiente hybrid
Un pattern hybrid environment può essere ridondante o distribuito. Utilizza ambienti di cloud pubblico per sviluppo, testing e UAT e mantiene i workloads di produzione in data center privati. I vincoli normativi e di compliance possono rendere complessa la migrazione al cloud degli ambienti di produzione e dei loro dati, ma non degli altri ambienti.
Usare il cloud pubblico per sviluppo e test funzionali significa poter creare e smantellare gli ambienti all'occorrenza. Permette inoltre di tenere i costi sotto controllo, fermando le istanze delle macchine virtuali quando non sono in uso o effettuando il provisioning degli ambienti solo on demand.
Business continuity hybrid e multicloud
La pianificazione del Disaster Recovery (DR) è fondamentale per ripristinare i sistemi compromessi da eventi naturali o causati dall'uomo. Un elemento chiave sono i backup frequenti dei dati in diverse aree geografiche, per minimizzare il recovery point objective (RPO). Mantenere sistemi di standby (cold, warm o hot, a seconda della latenza) in una seconda sede aiuta anche a ridurre il recovery time objective (RTO).
Un approccio più conveniente, però, è usare il cloud pubblico come ambiente DR: è il senso del pattern business continuity hybrid. Questo pattern può perfino ridurre l'Actual Recovery Time in caso di attivazione del DR, perché l'ambiente DR può essere creato più rapidamente con l'infrastructure as code.
Cloud bursting
Il costo di gestione di workloads soggetti a picchi (bursty) in ambienti on-premises può sfuggire rapidamente di mano, perché impone di sovradimensionare le risorse per coprire i momenti di carico intenso. Il pattern di deployment bursting si appoggia a un ambiente di calcolo privato per i carichi di base e ricorre al cloud solo quando serve scalare. Per questo motivo, è più adatto a workloads batch che a workloads interattivi. La portabilità dei workloads è cruciale.
Uno dei principali vantaggi di questo pattern è la possibilità di riutilizzare gli investimenti già effettuati negli ambienti on-premises. Si può anzi arrivare a un uso più efficiente degli ambienti di calcolo privati, perché non è più necessario sovradimensionare le risorse per assorbire i picchi di domanda.
I prossimi passi
Costruire una soluzione hybrid o multicloud comporta decisioni complesse, prima fra tutte la progettazione dell'architettura più adatta. Sarà necessario valutare la cultura aziendale, le pratiche DevOps e lo stack tecnologico prima di prendere qualsiasi decisione. Nessuna soluzione tecnologica da sola risponderà a tutti i requisiti specifici, ma la risposta può trovarsi in una variante dei pattern di deployment distribuito e ridondante di cui abbiamo parlato. Un partner cloud esperto può indicarLe l'approccio migliore per mettere il multicloud al servizio dei Suoi obiettivi di business.