Kubernetes, networking e ricerca di VMware nel cloud nativo

Thomas Graf è il co-fondatore e CTO di isovalentee creatore di una popolare tecnologia di rete open source (e nativa del cloud) chiamata Ciglio. Cilium è costruito su una tecnologia Linux a livello di kernel chiamata eGMP.

In questa intervista, Graf discute i ruoli che Cilium ed eBPF svolgono nel crescente ecosistema di rete cloud-native, nonché alcune tendenze più ampie relative all'adozione e all'evoluzione di Kubernetes. Spiega chi utilizza e acquista Kubernetes all'interno delle grandi aziende, dove l'infrastruttura nativa del cloud deve ancora essere migliorata e come il desiderio di standardizzazione stia guidando l'innovazione.

---

FUTURO: Come dovremmo pensare a eBPF e Cilium nel contesto dell'informatica e delle reti, in generale, e poi specificamente nel contesto del ecosistema nativo del cloud?

TOMMASO GRAF: Nel complesso, eBPF è la tecnologia ed è di livello estremamente basso. È stato progettato per gli sviluppatori del kernel e il mio background è nello sviluppo del kernel. eBPF sta al kernel, al sistema operativo, come JavaScript sta ad un browser. Rende il sistema operativo programmabile proprio come JavaScript rende programmabile il browser. In passato dovevamo aggiornare le versioni del nostro browser per poter utilizzare effettivamente determinati siti web. Poi è arrivato JavaScript e all'improvviso i team e gli sviluppatori delle applicazioni hanno potuto creare applicazioni di grandi dimensioni, al punto che l'applicazione di elaborazione testi più popolare è stata sostituita da un'applicazione integrata nel browser. Ha portato a un’enorme ondata di innovazione. 

Lo stesso sta accadendo con eBPF, anche se a livello di sistema operativo, perché all'improvviso possiamo fare cose a livello di kernel o di sistema operativo dove vediamo tutto e controlliamo tutto – il che è molto importante per la sicurezza – senza dover cambiare kernel. codice sorgente. Possiamo essenzialmente caricare programmi nel kernel per estenderne le funzionalità e portare con sé nuove capacità. Ciò ha anche sbloccato una massiccia ondata di innovazione. Gli hyperscaler come Facebook, Google e Netflix lo utilizzano da soli, direttamente, con i propri team del kernel. 

Ciò che Cilium porta in tavola è che utilizza la tecnologia eBPF di basso livello per fornire essenzialmente una nuova ondata di infrastruttura software, in particolare per l'onda nativa del cloud. Pensa a questo come al networking definito dal software e a ciò che Nicira, che è diventata VMware NSX, ha fatto per il settore della virtualizzazione. Stiamo facendo lo stesso per il cloud nativo, dove si tratta di un mix di provider cloud o infrastruttura cloud pubblica, nonché infrastruttura locale. E stiamo risolvendo casi d'uso di rete, sicurezza e osservabilità a livello di infrastruttura.

E il Cilium Service Mesh, appena rilasciato, è un'evoluzione di queste funzionalità?

Ciò che sta accadendo attualmente, da circa un anno fa, è che i due spazi stanno entrando in collisione. Ciò che Cilium ha fatto finora si concentra sul networking, sul networking virtualizzato e quindi sul networking nativo del cloud, ma pur sempre sul networking. Ma poi, procedendo dall'alto verso il basso, sono stati i team applicativi di Twitter e Google a farlo rete di servizi roba: prima nell'applicazione e poi nel modello basato su sidecar, il modello basato su proxy, che è ciò che piace ai progetti Istio consegnare. E ora questi due strati si stanno avvicinando perché le aziende tradizionali stanno entrando nel mondo cloud-native e hanno requisiti di rete aziendale, ma anche i team che si occupano delle applicazioni desiderano una rete di servizi. 

Gartner chiama questo nuovo livello “connettività di servizio” – vedremo se questo termine prenderà piede – ma è essenzialmente un livello che include la parte di rete aziendale e la parte di rete di servizi che proviene dai team applicativi. E poiché questo è ciò che i clienti richiedono, abbiamo aggiunto queste funzionalità allo stesso Cilium. Quindi, in sostanza, Cilium sta andando verso l'alto dal lato della rete aziendale e le mesh di servizi stanno andando verso il basso verso il lato della rete.

Perché c'è così tanta attenzione sul livello di rete e di mesh di servizi dello stack Kubernetes?

Perché con il desiderio di funzionare su più cloud e di suddividere le applicazioni in contenitori, il livello di connettività è diventato centrale. Ciò che una volta era forse la comunicazione tra processi e il middleware ora è la rete, quindi la rete sta diventando assolutamente essenziale affinché le applicazioni possano comunicare tra loro e affinché i dati possano fluire. 

E nel cloud nativo, in particolare, il multicloud sta diventando assolutamente essenziale. Tutti i fornitori di servizi cloud hanno i propri livelli di rete, ma, ovviamente, adattati ai propri cloud. Hanno offerte on-premise, ma non sono veramente multi-cloud. Cilium ed eBPF mettono in campo quel livello multi-cloud e agnostico. In locale si comporta esattamente come nel cloud pubblico. Molti fornitori di cloud pubblico utilizzano Cilium dietro le quinte per le loro offerte gestite Kubernetes, mentre le società di telecomunicazioni lo utilizzano per l’infrastruttura 5G on-premise. Si tratta di parlare entrambe le lingue e connettere insieme questi mondi.

Ecco perché c'è così tanta attenzione su questo aspetto: perché uno dei modi più semplici con cui i fornitori di servizi cloud possono vincolare i clienti è possedere quel livello di connettività. Penso che dal punto di vista dell'infrastruttura strategica, proprio come il livello di virtualizzazione era fondamentale, ora il livello di connettività e rete è assolutamente fondamentale.

La fonte dell’innovazione [futura] sarà open source e i clienti e gli utenti che guideranno la domanda saranno aziende a un livello inferiore rispetto agli hyperscaler: aziende già considerevoli che sono ancora altamente dirompenti.

Kubernetes è ormai ampiamente accettato e adottato, ma in alcuni ambienti si parla ancora che sia eccessivo. A chi pensi che sia rivolto Kubernetes e l'ecosistema nativo del cloud in generale?

È per i team delle applicazioni moderne. Penso che si sia capito che se si desidera attrarre team di applicazioni moderne ed essere in grado di avere tempi di immissione sul mercato rapidi, è necessario fornire loro un'infrastruttura nativa del cloud. Spesso vediamo la prototipazione (iniziale, pre-MVP, anche la dimostrazione del concetto o la vendita interna) su serverless, qualcosa come Lambda. E poi su Kubernetes, perché i team app possono possedere direttamente l'infrastruttura. E poi, quando si passa alla produzione, si passa alle distribuzioni Kubernetes aziendali e on-premise. Ma in realtà si tratta di una porzione relativamente piccola dell'intera infrastruttura, forse una percentuale a una o due cifre. 

Sarà chiaramente il nuovo standard, però. Proprio come inizialmente l'adozione della virtualizzazione è stata molto lenta e la gente diceva che era eccessiva, ma col tempo, ovviamente, ha iniziato a sostituire la maggior parte delle cose, vedremo la stessa cosa qui. O proprio come con le lingue moderne. La gente diceva che Java era eccessivo, e probabilmente lo è ancora per molte applicazioni, ma c'è stato un tempo in cui è diventato molto difficile sviluppare qualsiasi applicazione al di fuori di Java perché è quello in cui la maggior parte degli sviluppatori di applicazioni poteva scrivere. essere vero per i team applicativi moderni: si aspetteranno di avere Kubernetes in giro per svilupparsi in modo più agile e portare rapidamente il prodotto sul mercato.

Dal punto di vista dell'infrastruttura, potrebbe essere un po' eccessivo, ma se l'alternativa è riscrivere un'applicazione da serverless a on-premise, si tratta di un compito enorme. Quindi Kubernetes è la via di mezzo, il che è molto interessante. 

Che ne dici dell'idea che Kubernetes abbia ancora bisogno di una migliore esperienza per gli sviluppatori?

Se guardiamo all'OpenShift originale, prima che si basasse su Kubernetes, era questo. È stato ancora più vicino al team dell'applicazione ed è stata un'esperienza di sviluppo dell'applicazione ancora migliore. Potresti inviare a Git e verrà distribuito automaticamente. Anche Heroku ci ha provato, ma basato su SaaS. 

Kubernetes ha fatto un passo indietro e ha detto: “Dobbiamo mantenere alcuni aspetti operativi e renderlo un po’ più vicino a ciò che un amministratore di sistema si aspetterebbe. Non possiamo adattarci solo alle applicazioni”. È la via di mezzo: deve avere sufficiente attrattiva per i team applicativi, ma deve comunque essere possibile eseguire l'app al di fuori di un ambiente specifico e gestirla da persone diverse dagli sviluppatori di applicazioni.

Direi che il passo più importante tra Docker e Kubernetes è stato che Docker era incentrato sull'esperienza degli sviluppatori. Ha risolto quella parte, ma non ha risolto la parte dell’ecosistema del cloud pubblico.

Come siamo arrivati ​​a questo punto? È stata questa la naturale evoluzione dalla piattaforma come servizio (PaaS) e dai contenitori di applicazioni?

Si trattava delle immagini Docker e dell'aspetto del packaging di Docker. La vecchia scuola riguardava la distribuzione in macchine virtuali e attorno a questo c'erano tutti i tipi di automazione. E poi c'era quello che Facebook stava facendo con Tupperware: costruito su misura e su larga scala. E poi è arrivato Docker e essenzialmente ha fornito questa immagine del contenitore e tutti potevano trattarla come una VM in miniatura. Ora posso distribuire la mia app e invece di un'immagine virtuale da 600 MB, ora è un contenitore da 10 MB. Ma puoi trattarlo lo stesso, ha tutto ciò di cui ha bisogno. 

Ciò ha sbloccato la possibilità di introdurre un orchestratore come Kubernetes che consente comunque di trattare le applicazioni come mini VM, ma poi anche di fare un ulteriore passo avanti e trattarle effettivamente come microservizi. Ti permette di fare entrambe le cose.

Direi che il passo più importante tra Docker e Kubernetes è stato che Docker era incentrato sull'esperienza degli sviluppatori. Ha risolto quella parte, ma non ha risolto la parte dell’ecosistema del cloud pubblico. Non aveva, né necessariamente voleva, una stretta integrazione con i fornitori di servizi cloud. Kubernetes lo ha risolto. 

Chi vedi gestire Kubernetes all'interno delle aziende? Si tratta di team di applicazione individuali?

C'è un cambiamento interessante che si è verificato con il cloud nativo, ovvero che abbiamo assistito all'ascesa del "team della piattaforma", lo chiamerò così. Non sono ingegneri applicativi. Hanno un po' di conoscenza delle operazioni di rete e hanno una discreta conoscenza della sicurezza. Hanno conoscenze SRE e sanno come eseguire l'automazione del cloud. Forniscono la piattaforma per i team applicativi e li trattano come clienti.

I team di piattaforma sono quelli che acquistano Kubernetes e le tecnologie correlate, che utilizzano perché hanno il compito di fornire l'infrastruttura di prossima generazione per rendere felici i team di app moderne.

Penso che ci sia sicuramente spazio per il serverless, in particolare per lo sviluppo di applicazioni molto rapido. Ma nelle aziende, vediamo il cloud nativo come il nuovo livello oltre alla virtualizzazione

Si tratta di un nuovo acquirente o di un nuovo team? Oppure i team di piattaforma sono qualcosa che esiste all’interno di luoghi come Google o Facebook e che ora stanno diventando mainstream?

Sono per lo più una squadra nuova. Penso che siano, in una certa misura, come i team SRE di Google e Facebook. Tuttavia, i team applicativi probabilmente possiedono una parte maggiore della distribuzione delle app nelle imprese, perché le aziende non hanno questa distinzione molto chiara tra ingegneri del software e SRE come fanno Google e Facebook. Direi che questa evoluzione è molto simile a come c'erano i team di virtualizzazione, e quindi molte operazioni di rete sono migrate da - o si sono evolute o avanzate - dall'essere legate alla rete hardware occuparsi di rete virtualizzazione. E questi team, ad esempio, hanno iniziato a gestire VMware NSX. Lo stesso sta accadendo qui. 

Anche se non si tratta necessariamente di un nuovo budget. Vediamo, ad esempio, che i budget si spostano dalla sicurezza e dal networking al team di questa piattaforma, man mano che la spesa per il cloud aumenta e viene spesa meno per l’hardware di rete. Spesso collaborano con il team di sicurezza e con il team delle operazioni di rete per ottenere il consenso, ma in realtà dispongono di un budget piuttosto consistente.

Come vedi il Fondamenta del cloud nativo per il computing in continua evoluzione, e Kubernetes sarà sempre al centro di tutto ciò o del movimento cloud-native in generale?

Kubernetes è ciò che ha dato vita al CNCF e nei primi due anni tutto ruotava attorno a Kubernetes e al cloud pubblico. Ciò che abbiamo visto circa un anno fa è che ora non si tratta più solo di Kubernetes, ma in realtà più di cloud native principi. Ciò in realtà significa che non è più nemmeno necessariamente cloud, nemmeno cloud privato. Spesso si tratta anche di reti aziendali tradizionali, noiose infrastrutture locali, server bare metal e tutto il resto, ma con i principi nativi del cloud integrati. 

La nuova norma è ora ibrida e include più fornitori di cloud pubblici, nonché infrastrutture locali. Le aziende vogliono fornire la stessa agilità agli sviluppatori di applicazioni, o garantire l'osservabilità con moderni strumenti nativi del cloud, o garantire la sicurezza con moderni strumenti nativi del cloud, ad esempio l'autenticazione, invece della semplice segmentazione o applicazione basata sull'identità, tutti quei nuovi concetti nativi del cloud su infrastrutture esistenti. 

Stiamo assistendo a una domanda molto forte di continuare a connettersi al vecchio mondo e a comunicare con MPLS, VLAN, sFlow e NetFlow: l'intero insieme esistente di requisiti aziendali. Nessuno di loro è andato via.

Dopo circa un decennio, lo spazio nativo del cloud non sembra essere una moda passeggera. Quanto spazio ha per continuare ad evolversi?

C'è stato sicuramente un momento in cui pensavo: "Oh, Kubernetes probabilmente avrà vita breve e il serverless sarà il livello successivo". Oppure: “Kubernetes è simile a OpenStack. Oppure: "Scomparirà e diventerà un dettaglio di implementazione". E questo non è successo. 

Penso che ci sia sicuramente spazio per il serverless, in particolare per lo sviluppo di applicazioni molto rapido. Ma nelle aziende, consideriamo il cloud nativo come il nuovo livello oltre alla virtualizzazione e crediamo che abbia una durata di conservazione simile a quella della virtualizzazione. Ciò significa che siamo all'inizio della migrazione nativa del cloud.

Quali grandi problemi devono ancora essere risolti a livello infrastrutturale?

Stiamo vedendo le aziende in una situazione in cui, all'improvviso, che lo vogliano o no, hanno bisogno di una strategia multi-cloud. Poiché dispongono anche di un'infrastruttura on-premise, ora hanno bisogno di una strategia di cloud ibrido in più. E devono capire come garantire la sicurezza e altre funzioni universalmente in questa infrastruttura senza rinchiudersi in un particolare cloud pubblico. 

Quindi questa è la prossima grande sfida: chi sarà quel livello agnostico per il multi-cloud e il cloud nativo, come quello che è diventato VMware? Chi sarà il VMware per il cloud nativo?

Penso che si sia capito che se si desidera attrarre team di applicazioni moderne ed essere in grado di avere tempi di immissione sul mercato rapidi, è necessario fornire loro un'infrastruttura nativa del cloud.

E sebbene l’adozione del cloud nativo possa essere stata relativamente facile per le moderne società web che sono state le prime ad adottarlo, la sfida dal tuo punto di vista è costruire nuove tecnologie che colmino il divario tra questo mondo moderno e gli strumenti e i sistemi aziendali esistenti?

La parte difficile è che i team delle app moderne sono abituati a far evolvere il livello dell’infrastruttura con la loro stessa rapidità. E questo ha costretto il livello dell’infrastruttura a essere ancora più programmabile, più regolabile. Ecco perché in realtà vediamo uno strato di rete e uno strato di sicurezza sopra lo strato di rete cloud. Ma ora stanno arrivando le imprese e stiamo assistendo a una domanda molto forte di continuare a connettersi al vecchio mondo e a parlare di MPLS, VLAN, sFlow e NetFlow: l'intero insieme esistente di requisiti aziendali. Nessuno di loro è scomparso, tutte le regole di rispetto sono sempre le stesse. E anche alcune delle moderne aziende SaaS ora affrontano queste sfide man mano che crescono e si preoccupano della conformità e così via. 

Dal punto di vista tecnologico, si tratta di come connettere il nuovo mondo nativo del cloud ai requisiti aziendali esistenti. Perché molti di questi problemi sono stati nascosti dai fornitori di cloud pubblici. I fornitori di cloud pubblici hanno risolto i problemi di conformità, ma non hanno reso open source né pubblicato nulla di tutto ciò; l'hanno risolto da soli. Fa parte del valore del cloud. Le aziende ora devono ricostruirlo e acquistarlo se non vogliono bloccarsi nelle offerte di cloud pubblico.

Da dove vedi arrivare la prossima ondata di innovazione nativa del cloud? Proviene ancora da un'azienda come Google o c'è un nuovo tipo di azienda che guida la carica?

È molto interessante. Direi che probabilmente non proviene da Google e Facebook. La fonte dell’innovazione sarà open source e i clienti e gli utenti che guideranno la domanda saranno aziende a un livello inferiore rispetto agli hyperscaler: aziende già considerevoli che sono ancora altamente dirompenti, come Adobe, Shopify o GitHub. Ma anche le aziende rischiano di essere sconvolte dalla tecnologia, come i servizi finanziari, le compagnie assicurative e le società di telecomunicazioni. Queste aziende hanno tutte un interesse comune nella standardizzazione delle infrastrutture con modelli di sviluppo e infrastruttura ripetibili.

Pubblicato il 26 luglio 2022