HomeTecnologiaPiù cloud o un multi-cloud? La soluzione è il cloud distribuito

Più cloud o un multi-cloud? La soluzione è il cloud distribuito

Leggi le riviste ⇢

Ti potrebbero interessare ⇢

La Redazione

L’adozione di una strategia multi-cloud si è ormai ampiamente diffusa nelle aziende; secondo una ricerca di Propeller Insights, la maggior parte delle organizzazioni (75%) distribuiscono le proprie app su più cloud e, di queste, il 63% utilizza già tre o più cloud contemporaneamente.

Permane però una carenza di soluzioni capaci di affrontare in modo efficiente le numerose sfide delle organizzazioni che hanno scelto tale strategia. Complessivamente, infatti, oltre la metà delle aziende che ha adottato il multi-cloud (56%) ha difficoltà a gestire i carichi di lavoro tra diversi provider cloud, e indica tra le difficoltà principali gli aspetti legati alla sicurezza, all'affidabilità e, in generale, alla connettività.

Una delle sfide principali da affrontare riguarda proprio l'interconnessione sicura dei carichi di lavoro ospitati da più provider, un problema che cresce di intensità con l’aumento dei fornitori cloud.

Alcune di queste difficoltà possono essere attribuite alle diversità intrinseche dei modelli operativi delle aziende concorrenti. Ogni singolo cloud, infatti, offre servizi e API specifiche che sono unici per quel particolare provider e spesso richiedono ai clienti di conformarsi a definiti set di competenze, policy e approcci.

È vero che ogni cloud offre un'esperienza di un network software-defined, ma non esistono due diversi cloud in grado di offrire la medesima esperienza e questo spesso implica configurazioni incoerenti che influiscono sulla sicurezza e sulle prestazioni, soprattutto quando queste differenze tra ambienti paralleli non vengono correttamente valutate.

Le difficoltà dovute all’interconnettività si sono accentuate anche a causa dall'introduzione delle applicazioni cloud-native basate sui microservizi, che hanno necessariamente bisogno di un numero maggiore di connessioni cross-cloud. In questo contesto, la ricerca Propeller ci mostra come oltre il 70% degli intervistati ritenga che i problemi di sicurezza negli ambienti multi-cloud siano esasperati dalla presenza di differenti servizi di sicurezza forniti dai provider (77%), dal numero crescente di API (75%) e dalla prevalenza di app basate sui microservizi (72%).

Emerge quindi chiaramente la necessità di pensare a un nuovo approccio al networking multi-cloud.

La sfida del networking multi-cloud

Geng Lin, EVP e CTO di F5

Per semplificare la distribuzione delle applicazioni, il networking multi-cloud deve unificare due diversi approcci: da una parte, abbracciare l'internetworking software-defined dal basso verso l'alto, creando un overlay che astrae le differenze tra gli ambienti di rete e semplifica notevolmente le sfide legate all'utilizzo congiunto di più ambienti cloud. L'infrastruttura fisica viene utilizzata come un valido underlay con un piano di controllo cross-cloud standard che consente il networking virtuale dinamico.

Dall’altra, estendere la rete semplice dei container con una distribuzione sofisticata dall'alto verso il basso. Sebbene il settore abbia iniziato a standardizzare i carichi di lavoro dei container come unità applicativa de facto, la rete sottostante, relativamente poco sofisticata, deve essere estesa ad altri ambienti per abilitare un cloud distribuito in grado di accompagnare la gestione del traffico delle applicazioni tra gli ambienti.

La convergenza di questi due approcci ha già portato alla creazione di due livelli di astrazione nelle architetture applicative dei clienti: Kubernetes per facilitare la gestione del carico di lavoro di rete e l’SDN per semplificare l'internetworking. Il modo in cui questi due approcci attualmente convergono, purtroppo, causa ancora notevoli problemi ai clienti.

Molte organizzazioni, infatti, sono alle prese con le difficoltà legate alla richiesta da parte di queste tecnologie di adottare configurazioni eccessivamente granulari per quanto riguarda le operation, così da ottenere un approccio di internetworking standardizzato quando sono coinvolti più cloud. L'approccio di un singolo provider cloud, anche per attività di rete estremamente semplici come la gestione della VLAN, è nettamente diverso da quello scelto da un altro provider... ed entrambi possono differire completamente dall'approccio adottato dall'azienda per il suo cloud privato.

Inoltre, il modo in cui le reti vengono fornite e gestite nei vari cloud porta spesso alla necessità di avvalersi in modo continuo di uno staff di esperti capace di comprendere le differenze tra gli ambienti solo per stare al passo con la standardizzazione della rete.

La soluzione è il cloud distribuito

Esiste un modo per avvicinare Kubernetes e SDN, affrontando le differenze tra gli ambienti ed eliminando la necessità di avvalersi di un esperto di rete per far sì che tutto questo accada. In F5, chiamiamo questo approccio "cloud distribuito".

I clienti generalmente faticano a utilizzare un approccio corretto a queste problematiche perché le loro decisioni di business e le loro esigenze in termini di app vengono valutate prima di selezionare la "rete/cloud migliore" per il proprio servizio.

Le decisioni vengono prese tenendo in considerazioni molti fattori a partire da costi, tempi e velocità di implementazione, o dalla necessità di trovarsi in una particolare area geografica; in pratica, qualsiasi elemento il cliente reputi fondamentale per il successo della propria applicazione. Raramente però durante questa prima fase di analisi l’azienda prende in considerazione fattori che riguardino la rete o l'interoperabilità con altri cloud e, sfortunatamente, è proprio questo a far emergere nuove criticità man mano che l'applicazione procede nel suo ciclo di vita e che altri aspetti del business portano a prendere decisioni diverse sull'utilizzo del cloud.

Credo che non ci sia nulla di intrinsecamente sbagliato da parte di una azienda nello scegliere di utilizzare le tecnologie cloud che si ritiene siano più adatte alle proprie esigenze, anche se questo implica l'utilizzo di più provider e ambienti; ma ritengo valga la pena impegnarsi per sviluppare una strategia comune a tutti i provider, implementando soluzioni build-to-scale che siano ragionevoli e alla portata delle competenze di rete che i clienti già oggi possiedono, rispettando le loro esigenze applicative e gli obiettivi di business: questa è l’essenza del "cloud distribuito".

Si tratta di un approccio che, a nostro avviso, è corroborato da tre importanti considerazioni.

La rete dovrebbe innanzitutto supportare un modello “anywhere, anytime”, senza che la qualità o la customer experience vengano penalizzate. In secondo luogo, qualsiasi cloud di internetworking dovrebbe essere per definizione semplice, completo e coerente, indipendentemente dal public cloud sottostante che l’organizzazione sceglie di usare. Infine, le aziende dovrebbero essere in grado di ottenere più valore attraverso l’implementazione di un unico control-plane che sia API-driven, semplice e chiaro.

L’idea è quella di poter offrire un cloud distribuito che porti con sé il concetto di flessibilità cross-cloud senza un incremento significativo di costi, di vincoli temporali o di richieste di cambiamenti profondi degli ambienti. Per questo F5 ha creato un ampio portafoglio di soluzioni per affrontare queste sfide, con un insieme congruente di tecnologie e best-practice che si possano estendere a ogni applicazione e architettura aziendale.

Il conclusione, il cloud distribuito è la risposta per poter supportare applicazioni sempre più adattive, e accompagnare le aziende nel compiere quella trasformazione che consentirà loro di spostare i carichi di lavoro con facilità tra più sedi, aree geografiche o adottando diversi modelli di costo, scegliendo in base all’efficienza ed efficacia e senza impiegare uno staff di maghi della rete che risolva le criticità per ogni singolo ambiente.

Di Geng Lin, Evp e Cto di F5

Più cloud o un multi-cloud? La soluzione è il cloud distribuito - Ultima modifica: 2021-12-01T09:24:39+01:00 da La Redazione