Il termine “cloud” si è evoluto da quando è stato utilizzato per la prima volta all’inizio degli anni ’90. Si potrebbe sostenere che il Cloud 1.0 non fosse altro che un eufemismo per servizi hosted che hanno dato alle aziende la possibilità di eseguire app critiche fuori dal loro perimetro locale in un ambiente altamente sicuro.

Il Cloud 2.0 ha dato origine ad app ottimizzate per il web. In questa fase le app sono state realmente create per il cloud e hanno generato le aziende che hanno reso il cloud la loro piattaforma di elaborazione principale. Tuttavia, questa strategia cloud ruotava attorno a un singolo provider cloud e alle tradizionali architetture di app monolitiche. Anche le aziende che utilizzavano più cloud hanno creato l’app A su un cloud, l’app B su un altro, ecc. In questo caso, il multicloud consisteva in realtà in più cloud utilizzati come entità infrastrutturali separate e indipendenti.

Siamo ora entrati nell’era Cloud 3.0, che può essere considerata come un multicloud potenziato. L’aumento di microservizi e container ha consentito agli sviluppatori di creare applicazioni accedendo ai servizi di più provider cloud. La maggior parte delle app moderne e native del cloud vengono create in questo modo. L’edge computing è all’orizzonte, il che creerà più posizioni per gli sviluppatori di app alle quali estendere l’accesso ai dati e ai servizi delle app. Questo è il concetto del cloud distribuito, in cui il cloud non è più una singola posizione, ma un insieme di risorse distribuite.

Il cloud distribuito cambia la distribuzione delle app

L’evoluzione del cloud, e di conseguenza delle app native del cloud, ha avuto un profondo impatto sui servizi di rete e di sicurezza necessari per connettere i componenti dell’app ad altri componenti dell’app e per connettere le app agli utenti. Con il Cloud 1.0, i professionisti IT utilizzavano dispositivi fisici come bilanciatori o controller di distribuzione delle applicazioni e firewall per app web. Queste appliance venivano installate negli stessi data center che ospitavano l’infrastruttura dell’app. Con il Cloud 2.0, queste funzioni sono state virtualizzate e installate come risorsa cloud. Le architetture di rete e delle app erano sostanzialmente le stesse, ma l’infrastruttura è passata alle appliance virtuali residenti nel cloud.

Con il cloud distribuito (Cloud 3.0), i componenti delle app (ad esempio i microservizi) sono ora modulari e risiedono in container su più cluster. Ciò crea notevoli sfide operative e di implementazione per i team DevOps e i professionisti IT. La natura dinamica e distribuita dei carichi di lavoro e dei microservizi containerizzati non può essere supportata dall’infrastruttura fisica o anche virtuale tradizionalmente utilizzata per le app monolitiche, che si basano su controllo e visibilità centralizzati, al contrario del modello operativo dinamico necessario per cluster e carichi di lavoro altamente distribuiti .

Un carico di lavoro containerizzato può essere avviato e reso obsoleto in pochi minuti, anche secondi. Ciò significa che la rete di supporto e l’infrastruttura di sicurezza come i bilanciatori, i firewall delle app web e i gateway API devono essere attivati e disattivati altrettanto rapidamente.

cloud ibrido

Affrontare le sfide operative del cloud distribuito

Questa settimana il provider di infrastrutture di app cloud native Volterra ha annunciato l’ultima versione del suo servizio VoltMesh, che affronta molte delle sfide operative associate alla distribuzione e al funzionamento di app moderne in un modello cloud distribuito. L’azienda offre un’ampia gamma di quelli che normalmente vengono chiamati “servizi di distribuzione delle applicazioni” dal cloud, resi disponibili come un’unica offerta SaaS.

Invece di dover distribuire più appliance virtuali per cluster, su più cluster, VoltMesh offre uno stack di servizi integrato che può essere facilmente implementato su un cluster distribuito con gestione centralizzata, visibilità end-to-end e controllo delle policy. Sfruttando la velocità e l’ubiquità di un servizio basato su SaaS, DevOps può accelerare l’implementazione di applicazioni cloud native distribuite e semplificare le operazioni in corso, mentre gli sviluppatori possono ottenere una migliore integrazione del codice e agilità poiché hanno maggiore libertà su dove e come sviluppare. VoltMesh può essere distribuito in cluster in tutti i principali provider di cloud, nonché in cloud privati e siti perimetrali. Volterra offre anche la propria rete di distribuzione delle applicazioni (ADN) per migliorare le prestazioni e la sicurezza delle app native del cloud, ospitandole direttamente sulla rete privata di Volterra e più vicine agli utenti finali.

Tuttavia, l’approccio all’infrastruttura cloud-native che Volterra sta adottando va oltre la semplice velocità, poiché ci sono anche importanti implicazioni per la sicurezza. Mentre gli sviluppatori di app passano alla creazione di app native per il cloud su microservizi, nuove minacce stanno emergendo da API incorporate e invisibili. Il numero di API per app è esploso, creando più traffico all’interno dell’applicazione. Gli approcci alla sicurezza come la segmentazione e persino la microsegmentazione operano a livello di rete, quindi sono “ciechi” a livello di API. Ciò significa che i team DevOps e DevSecOps devono spostare il focus del loro modello zero-trust dalla rete al livello API, inclusa la capacità di “vedere” tutte le API e quindi applicare le policy su di esse.

Come parte di questa nuova versione, VoltMesh ha svelato la sua nuova funzionalità di rilevamento automatico delle API che può trovare automaticamente tutte le API in un’applicazione attraverso l’uso del suo motore di machine learning. Quindi applica automaticamente i criteri per inserire nella whitelist solo le API richieste e convalidate, rendendo inefficaci quelle non necessarie o non sicure. Ciò riduce notevolmente la superficie di attacco, aumentando la protezione e la conformità senza ritardare i cicli di rilascio delle app.

Il concetto di multicloud (o più cloud) sommato a quello di app monolitiche sta rapidamente cedendo il passo al cloud distribuito sommato alle app distribuite e questo cambierà il modo in cui forniamo loro l’infrastruttura di rete e di sicurezza. La tradizionale infrastruttura di distribuzione delle applicazioni deve evolversi per essere cloud-native e distribuita se i team DevOps e NetOps vogliono tenere il passo con l’agilità degli sviluppatori che oggi creano app moderne.