Project Pacific trasforma vSphere in una piattaforma nativa di Kubernetes

Nuova architettura di vSphere con un piano di controllo Kubernetes, per gli sviluppatori Project Pacific assomiglia a Kubernetes e per gli amministratori a vSphere.

project pacific

Per quanto le aziende possano voler modernizzare l’IT e passare al cloud, resta il fatto che il 95% della spesa IT rimane saldamente on-premises. Tutto ciò sta cambiando e rapidamente, ma i CIO hanno faticato ad aggiornare la loro tecnologia informatica per l’era del cloud. Nel tentativo di facilitare questa lotta, VMware ha annunciato oggi Project Pacific, una nuova architettura della sua piattaforma di virtualizzazione server vSphere che trasforma vSphere in una piattaforma nativa Kubernetes.

Cosa significa? In termini pratici significa che oggi i 70 milioni di carichi di lavoro di vSphere diventano immediatamente carichi di lavoro Kubernetes. Forse ancora più importante, significa che le 500.000 organizzazioni che utilizzano vSphere hanno improvvisamente le competenze necessarie per eseguire Kubernetes. O ancora, in breve, significa che un sacco di aziende improvvisamente hanno acquisito molta più esperienza nel cloud senza nemmeno provarci.

L’adozione del cloud pubblico è cresciuta del 10% all’anno per diversi anni e Forrester prevede un tasso di crescita annuale composto dal 20 al 25% fino al 2022. Sebbene questi numeri siano impressionanti, sarebbero ancora migliori se una serie di fattori non ostacolasse il meglio delle intenzioni del cloud, secondo il vice presidente di VMware Kit Colbert. Come ha dichiarato in un’intervista, “ci vuole un sacco di lavoro per raggiungere il cloud. Ogni app deve essere riscritta con nuovi strumenti operativi”.

Cosa fanno le aziende a questo punto? Dipende dal loro “appetito”. Per troppe di esse la prima opzione è non fare nulla. Il vantaggio di questo approccio è un costo inferiore. La seconda opzione è quella di affrontare la riscrittura delle app, cosa che può introdurre spese significative; le imprese spesso scelgono però di seguire proprio questa strada.

Project Pacific, afferma Colbert, consente alle aziende di “ottenere alcuni dei vantaggi del cloud e dei container ma senza tutto il lavoro che c’è dietro (o comunque con una minima parte)”. In un certo senso Project Pacific è simile per finalità strategiche a VMware Cloud su AWS, grazie al quale i clienti possono spostare carichi di lavoro non modificati in AWS utilizzando gli stessi strumenti operativi, gli stessi team, ecc. “Naturalmente l’app non può ridimensionarsi magicamente o altro, poiché la sua architettura non è cambiata”, osserva Colbert. “Ma offre alcuni vantaggi del cloud come un’infrastruttura più dinamica, pay-as-you-go, accesso alle regioni cloud, accesso a servizi cloud di livello superiore e altro ancora.” Ma cos’è esattamente Project Pacific? E cosa significa per l’IT aziendale?

Come il direttore senior di VMware Jared Rosoff ha descritto in un post sul blog, “Project Pacific è una ri-architettura di vSphere con Kubernetes come piano di controllo principale. Agli occhi di uno sviluppatore Project Pacific assomiglia a un cluster Kubernetes in cui si può utilizzare la sintassi dichiarativa di Kubernetes per gestire risorse cloud come macchine virtuali, dischi e reti. Per l’amministratore IT Project Pacific assomiglia a vSphere, ma con la nuova capacità di gestire un’intera applicazione invece di occuparsi sempre delle singole macchine virtuali che la compongono”.

container

Detto in altre parole, Project Pacific trasforma vSphere in una piattaforma nativa di Kubernetes, il che a sua volta significa che vSphere eredita l’ecosistema Kubernetes. Tutto quello straordinario coinvolgimento della community di Kubernetes? Improvvisamente vSphere ne diventa un partecipante, o almeno un felice beneficiario. Proprio come Kubernetes consente di gestire più container come un’unica applicazione, Project Pacific consente di gestire più VM a livello di applicazione.

Ciò significa anche che le 500.000 aziende che attualmente eseguono vSphere non necessitano di stack separati per le app native del cloud (Kubernetes) e per le app virtualizzate (vSphere). Sono la stessa cosa. Per questo motivo le aziende che stavano cercando modi per formare i propri team operativi per Kubernetes non devono più farlo. Se hanno saputo usare vSphere, improvvisamente sanno usare Kubernetes.

Colbert spiega: “L’idea è che potete prendere un’app non modificata e conteinerizzarla sfruttando tutti i vantaggi di Kubernetes, ma funziona ancora in un ambiente familiare con strumenti esistenti”. Con la VM in un’immagine container, un’azienda può improvvisamente sfruttare la sintassi dichiarativa di Kubernetes, semplificando così la gestione della configurazione.

È anche una questione di maggiore sicurezza, come sottolinea Colbert. Ora un’azienda può mantenere questa app con tutte le sue altre app: un posto, insomma, per tutti i tipi di app e un posto dove eseguire automaticamente la scansione CVE, migliorando così la sicurezza. Potete firmare l’immagine del container per provare crittograficamente che nessuno l’ha cambiata e potete applicare una policy per cui solo le immagini firmate sono in grado di essere eseguite nel vostro ambiente, favorendo nuovamente una migliore posizione di sicurezza.

In breve, anche se l’app basata su VM non è modificata, ottiene tutti i tipi i vantaggi dell’ecosistema container. Oppure, come conclude Colbert, “l’idea è che possiamo spostare in avanti l’intera flotta di app di un cliente, offrendo a tali app un po’ di cloud e alcuni vantaggi dei container a costi sostanzialmente nulli o molto bassi”.