La maggior parte delle organizzazioni utilizza sia data center on-premise, sia servizi IaaS basati sul cloud, spesso impiegando più piattaforme IaaS. Alcuni hanno scelto questa realtà multicloud come parte di una migrazione costante e unidirezionale verso il cloud e potrebbero aver intenzionalmente mantenuto le loro reti cloud distinte come parte di questo obiettivo, mentre altri potrebbero preferire una strategia aziendale per mantenerle distinte, ad esempio per fornire servizi a una divisione indipendente o a una particolare area geografica.

Di conseguenza, quasi sicuramente stanno già collegando in qualche modo le loro reti di infrastrutture on-premises e cloud o stanno per farlo. Quelli con un’integrazione limitata tra le loro reti hanno spesso a che fare con un mosaico di soluzioni che si sono evolute in modo casuale, man mano che i sistemi cloud passavano da essere sperimentali e isolati a essere sviluppati e periferici e, infine, a essere centrali e in produzione. Per chi sta pianificando di riunire queste reti o cerca di architettare e progettare la loro attuale infrastruttura in modo più intenzionale, ci sono alcuni punti fondamentali da considerare.

Trattare i cloud esterni separatamente o insieme?

Un modello per l’adozione del cloud considera ogni cloud esterno come un altro data center distinto, collegato solo come destinazioni WAN aggiuntive. Ciò significa solo connessioni a livello di routing, con gestione e controlli di rete separati per ciascuno di essi. L’altro modello prevede un’integrazione più profonda, che include il tunneling dei protocolli Layer 2 e la centralizzazione del controllo non solo tra i data center on-premise e il cloud, ma anche tra i vari cloud.

Adottare un modello “separato” ha certamente i suoi pregi:

• Isolamento di rete più semplice dei carichi di lavoro per motivi di sicurezza e conformità
• Implementazione più semplice delle policy di rete all’interno di ciascun ambiente, grazie a un ambito di applicazione più limitato
• Minori competenze richieste agli ingegneri di rete che si concentrano su un singolo ambiente

Tuttavia, questa soluzione presenta anche degli svantaggi significativi:

• Minore agilità
• Minore portabilità tra gli ambienti
• Opzioni di integrazione più limitate
• Maggiore complessità nell’implementazione delle policy di rete e di sicurezza tra gli ambienti, con un maggiore rischio di errore

La maggior parte delle organizzazioni sembra seguire la strada di unire tutti gli ambienti, dalla rete in su. In ogni caso, si trovano di fronte a una seconda importante considerazione: se e come rendere gli ambienti il più simili possibile in termini di ciò che si può fare sulle reti al loro interno o se permettere che rimangano diversi.

Consentire tutte le funzionalità o solo quelle comuni a tutti i cloud?

Quando le soluzioni vengono distribuite su più piattaforme che non hanno le stesse funzionalità, l’IT ha scelto da tempo una di queste due soluzioni:

• Utilizzare ogni piattaforma separatamente e sfruttare tutte le caratteristiche “speciali” di ciascuna per ottenere le migliori prestazioni possibili
• Aggiungere un livello di astrazione tra i carichi di lavoro IT e le piattaforme sottostanti e rinunciare alle funzioni non comuni per ottenere la massima coerenza e portabilità

L’aspetto positivo del fatto che ogni cloud sia un’isola distinta di funzionalità rispetto ai data center on-premise è che il il team di networking ha meno da fare in ognuno di essi. Inoltre, le modalità di interazione tra i cloud e i data center on-pre sono ben comprese. L’aspetto negativo del multicloud è che ogni cloud è diverso dall’altro. I responsabili IT che gestiscono questi ambienti sviluppano set di competenze personalizzate e la capacità di avere una copertura trasversale è minore. Di conseguenza, ogni ambiente ha un’assistenza più limitata e una minore resilienza a livello di personale. In caso di turnover, anche le competenze in ambito multicloud richieste ai sostituti sono più specializzate.

I team che si occupano di applicazioni e di cybersecurity devono anche comprendere le differenze tra gli ambienti per consentire sia la collocazione flessibile dei carichi di lavoro al loro interno, sia lo spostamento dei carichi di lavoro tra di essi. Nell’era della containerizzazione e dei microservizi, la portabilità è considerata una virtù fondamentale. I team possono perdere di vista le differenze fondamentali, come ad esempio il fatto che un ambiente abbia come impostazione predefinita “nega tutto” o “permetti tutto” sulle connessioni tra le reti, con il rischio di un disastro.

Per questi motivi, alcune organizzazioni decidono di minimizzare le differenze negli ambienti rivolti alle applicazioni implementando strumenti per astrarre le differenze. A volte l’aggiunta di un livello di coerenza, tramite un overlay o un nuovo standard, amplifica enormemente la potenza di una tecnologia. SQL è un buon esempio di approccio basato sugli standard, così come TCP/IP. SD-WAN è un ottimo esempio di approccio overlay per standardizzare le funzionalità di rete al di sopra di diversi strati sottostanti.

L’implementazione di uno standard in tutti gli ambienti consente l’interoperabilità, definisce un insieme di competenze comuni e rende più semplici la progettazione e l’implementazione di applicazioni che sfruttino tali standard. Le estensioni al di là di uno standard sono possibili, così come il supporto di standard concorrenti. In questo modo, le funzionalità “segrete” di un ambiente possono ancora essere prese in considerazione e le implementazioni di uno standard possono variare, in modo che i fornitori possano competere sulle prestazioni.

Un approccio importante ed efficace in ambito multicloud per fornire una piattaforma coerente e astratta in tutti gli ambienti è quello di proteggere i punti deboli. In altre parole, piuttosto che nascondere le funzionalità dal catalogo comune dei servizi di rete o dalle opzioni di progettazione se non sono disponibili su tutte le piattaforme, si aggiungono le funzionalità mancanti alle piattaforme che ne sono sprovviste. Le soluzioni SD-WAN e le soluzioni di rete multicloud possono funzionare in questo modo.

La correzione dei punti deboli del catalogo di ogni piattaforma è diversa dal semplice porting di un ambiente estraneo in ogni piattaforma. In questo modo si mantiene ogni ambiente il più vicino possibile al suo stato nativo, per sfruttarne i punti di forza e ridurre la quantità di sviluppo una tantum necessario per adattarvi l’ambiente standard.

La rete multicloud è già una realtà o è in fase di realizzazione per la maggior parte delle organizzazioni, che nel considerare la prossima fase della loro strategia e architettura di rete dovrebbero tenere a mente queste domande fondamentali e assicurarsi di avere ben chiaro come rispondere e perché, in modo che le risposte possano guidare il resto delle loro decisioni.