Kubernetes, nätverk och hitta VMware från Cloud Native

Thomas Graf är medgrundare och CTO för Isovalent, och skapare av en populär nätverksteknik med öppen källkod (och molnbaserad) som kallas cilium. Cilium är byggt ovanpå en Linux-teknik på kärnnivå som kallas eGMP.

I den här intervjun diskuterar Graf rollerna som Cilium och eBPF spelar i det växande molnbaserade nätverksekosystemet, samt några bredare trender kring införandet och utvecklingen av Kubernetes. Han förklarar vem som använder och köper Kubernetes inom stora företag, där molnbaserad infrastruktur fortfarande behöver förbättras, och hur önskan om standardisering driver innovation.

---

FRAMTID: Hur ska vi tänka på eBPF och Cilium i samband med datoranvändning och nätverk, i allmänhet, och då specifikt i samband med inbyggt moln ekosystem?

THOMAS GRAF: Sammantaget är eBPF tekniken och den är extremt låg. Det var designat för kärnutvecklare, och min bakgrund är inom kärnutveckling. eBPF är för kärnan, för operativsystemet, vad JavaScript är för en webbläsare. Det gör operativsystemet programmerbart precis som JavaScript gör webbläsaren programmerbar. Tidigare var vi tvungna att uppgradera våra webbläsarversioner för att faktiskt använda vissa webbplatser. Och så kom JavaScript, och helt plötsligt kunde applikationsteam och utvecklare bygga enorma applikationer – till den punkt där den mest populära ordbehandlingsapplikationen ersattes av en applikation i webbläsaren. Det ledde till en enorm våg av innovation. 

Samma sak händer med eBPF, fast på operativsystemnivå, eftersom vi helt plötsligt kan göra saker på kärn- eller operativsystemnivå där vi ser allt och kontrollerar allt – vilket är väldigt viktigt för säkerheten – utan att behöva byta kärna källkod. Vi kan i princip ladda program i kärnan för att utöka dess funktionalitet och föra med sig nya funktioner. Detta har också låst upp en massiv våg av innovation. Hyperscalers som Facebook, Google och Netflix använder detta på egen hand, direkt, med sina egna kärnteam. 

Vad Cilium ger till bordet är att det använder den lågnivån eBPF-teknik för att i huvudsak tillhandahålla en ny våg av mjukvaruinfrastruktur, särskilt för den inbyggda molnvågen. Tänk på detta som mjukvarudefinierat nätverk och vad Nicira, som blev VMware NSX, gjorde för virtualiseringsindustrin. Vi gör samma sak för cloud native, där det är en blandning av molnleverantör eller offentlig molninfrastruktur, såväl som lokal infrastruktur. Och vi löser användningsfall för nätverk, säkerhet och observerbarhet med det på infrastrukturlagret.

Och Cilium Service Mesh, som just släpptes, är en utveckling av dessa funktioner?

Det som för närvarande händer, sedan ungefär ett år tillbaka, är att de två utrymmena kolliderar. Vad Cilium har gjort hittills är fokuserat på nätverk, virtualiserat nätverk och sedan molnnative nätverk – men fortfarande nätverk. Men sedan, uppifrån och ner, gjorde applikationsteam på Twitter och Google det servicenät saker — i applikationen först, och sedan den sidovagnsbaserade modellen, den proxybaserade modellen, vilket är vad projekt gillar Samma leverera. Och nu kommer dessa två lager närmare pga traditionella företag kommer in i molnets värld och de har krav på företagsnätverk, men deras appteam vill också ha ett servicenät. 

Gartner kallar det här nya lagret för "tjänstanslutning" – vi får se om den termen slår fast – men det är i huvudsak ett lager som inkluderar företagets nätverksdel och servicenätdelen som kommer från applikationsteamen. Och eftersom det är vad kunderna efterfrågar har vi lagt till funktionerna i själva Cilium. Så i huvudsak går Cilium uppåt från företagsnätverkssidan och servicenäten går neråt till mer av nätverkssidan.

Varför är det så mycket fokus på nätverks- och servicenätnivån i Kubernetes-stacken?

För med önskan att köra i flera moln och att dela isär applikationer i behållare, har anslutningslagret blivit centralt. Det som tidigare var kanske kommunikation mellan processer och mellanprogram är nu nätverket, så nätverket blir helt nödvändigt för att applikationer ska kunna prata med varandra och för att data ska flöda. 

Och i molnbaserad, i synnerhet, multi-cloud blir absolut nödvändigt. Alla molnleverantörer har sina egna nätverkslager, men, naturligtvis, skräddarsydda för sina egna moln. De har erbjudanden på plats, men de är inte riktigt multimoln. Cilium och eBPF ger bordet det agnostiska lagret med flera moln. Det beter sig exakt samma lokalt som det gör i det offentliga molnet. Flera av de offentliga molnleverantörerna använder Cilium under huven för sina hanterade Kubernetes-erbjudanden, och teleföretag använder det för lokal 5G-infrastruktur. Det handlar om att prata båda språken och koppla samman dessa världar.

Det är därför det är så mycket fokus på detta: eftersom ett av de enklaste sätten för molnleverantörer att låsa in kunder är att äga det anslutningslagret. Jag tror ur ett strategiskt infrastrukturperspektiv, precis som virtualiseringslagret var nyckeln, nu är anslutnings- och nätverkslagret absolut nyckeln.

Källan till [framtida] innovation kommer att vara öppen källkod, och kunderna och användarna som driver efterfrågan kommer att vara företag en nivå ned från hyperscalers – redan betydande företag som fortfarande är mycket disruptiva.

Kubernetes är ganska allmänt accepterad och antagen vid det här laget, men det talas fortfarande i vissa kretsar om att det är överdrivet. Vem tror du att Kubernetes, och det molnbaserade ekosystemet överlag, är till för?

Det är för moderna applikationsteam. Jag tror att insikten har slagit in att om du vill attrahera moderna applikationsteam och kunna ha snabba marknadstider, måste du tillhandahålla dem en molnbaserad infrastruktur. Vi ser ofta prototyper - initial, pre-MVP, till och med bevisa konceptet eller sälja internt - på serverlös, något som Lambda. Och sedan på Kubernetes, eftersom appteamen kan äga infrastrukturen direkt. Och sedan, när det går in i produktion, går de till företag, lokala Kubernetes-distributioner. Men det är faktiskt en relativt liten del av hela infrastrukturen, kanske en enstaka eller låg tvåsiffrig procentandel. 

Men det kommer helt klart att bli den nya standarden. Precis som att antagandet av virtualisering gick väldigt långsamt till en början och folk sa att det var överdrivet – men med tiden började det naturligtvis ersätta det mesta – vi kommer att se detsamma här. Eller precis som med moderna språk. Folk sa att Java var överdrivet, och det är det förmodligen fortfarande för många applikationer, men det fanns en tid då det blev väldigt svårt att göra någon applikationsutveckling utanför Java eftersom det är vad majoriteten av applikationsutvecklare kunde skriva i. Samma kommer vara sant för moderna applikationsteam: de förväntar sig att ha Kubernetes runt för att utveckla mer smidigt och snabbt få ut produkten på marknaden.

På infrastruktursidan kan det vara lite överdrivet, men om alternativet är att skriva om en applikation från serverlös till on-prem är det en enorm uppgift. Så Kubernetes är medelvägen där, vilket är väldigt attraktivt. 

Hur är det med tanken att Kubernetes fortfarande behöver en bättre utvecklarupplevelse?

Om vi ​​tittar på den ursprungliga OpenShift, innan den återbaserades på Kubernetes, var det detta. Det var ännu närmare applikationsteamet och var en ännu bättre upplevelse för applikationsutvecklare. Du kan trycka till Git och det skulle distribueras automatiskt. Heroku provade också detta, men SaaS-baserat. 

Kubernetes tog ett steg bakåt och sa: "Vi måste behålla några operativa aspekter i det och göra det lite närmare vad en systemadministratör skulle förvänta sig också. Vi kan inte bara skräddarsys efter applikationer.” Det är mellanvägen: Den måste ha tillräckligt med attraktionskraft för applikationsteam, men det måste fortfarande vara möjligt att köra den appen utanför en specifik miljö och att få den hanterad av andra än applikationsutvecklare.

Jag skulle säga att det största steget mellan Docker och Kubernetes var att Docker handlade om utvecklarupplevelse. Det löste den delen, men löste inte ekosystemdelen av det offentliga molnet.

Hur kom vi till denna punkt? Var detta den naturliga utvecklingen från plattform-som-en-tjänst (PaaS) och applikationsbehållare?

Det var Docker-bilder och förpackningsaspekten av Docker. Den gamla skolan var hur man distribuerade till virtuella maskiner, och det fanns all sorts automatisering runt det. Och så var det vad Facebook gjorde med Tupperware – väldigt specialbyggt och för riktigt stor skala. Och sedan kom Docker och tillhandahöll i huvudsak den här containerbilden och alla kunde behandla den som en miniatyr VM. Jag kan nu distribuera min app och istället för en virtuell bild på 600 MB är den nu en behållare på 10 MB. Men du kan behandla den på samma sätt, den har allt den behöver. 

Det låste upp möjligheten att ta in en orkestrator som Kubernetes som fortfarande låter dig behandla applikationer som mini-VM, men sedan också ta ett steg längre och faktiskt behandla dem som mikrotjänster. Det låter dig göra båda.

Jag skulle säga att det största steget mellan Docker och Kubernetes var att Docker handlade om utvecklarupplevelse. Det löste den delen, men löste inte ekosystemdelen av det offentliga molnet. Den hade inte, eller ville nödvändigtvis, nära integration med molnleverantörerna. Kubernetes löste det. 

Vem ser du som driver Kubernetes i företag? Är det individuella ansökningsteam?

Det finns ett intressant skifte som hände med cloud native, vilket är att vi har framväxten av "plattformsteamet", kallar jag det. De är inte applikationsingenjörer. De har lite kunskap om nätverksoperationer och de har en hel del säkerhetskunskap. De har SRE-kunskap och de vet hur man gör molnautomation. De tillhandahåller plattformen för applikationsteam och behandlar dessa applikationsteam som sina kunder.

Plattformsteam är de som köper Kubernetes och relaterade teknologier, som de använder eftersom de har till uppgift att tillhandahålla nästa generations infrastruktur för att göra moderna appteam nöjda.

Jag tror att det definitivt finns ett utrymme för serverlöst, i synnerhet för mycket snabb applikationsutveckling. Men i företag ser vi cloud native som det nya lagret ovanpå virtualisering

Är det en nätny köpare eller ett nätnytt team? Eller är plattformsteam som något som finns på platser som Google eller Facebook och som nu går till mainstream?

De är mest ett nytt lag. Jag tror att de till viss del är som SRE-teamen på Google och Facebook. Applikationsteamen äger dock förmodligen mer av app-distributionen i företag, eftersom företag inte har den här tydliga skillnaden mellan mjukvaruingenjörer och SRE som Google och Facebook har. Jag skulle säga att den här utvecklingen är väldigt lik hur du hade virtualiseringsteam, och sedan migrerade massor av nätverksoperationer från – eller utvecklades eller avancerade från – att handla om nätverk hårdvara att handla om nätverk virtualiserings. Och dessa team, till exempel, började använda VMware NSX. Samma sak händer här. 

Även om det inte nödvändigtvis är en ny budget. Vi ser att budgetar flyttas från säkerhet och nätverk till detta plattformsteam, till exempel, eftersom molnutgifterna ökar och mindre spenderas på nätverkshårdvara. De arbetar ofta med säkerhetsteamet och med nätverksoperationsteamet för att få buy-in, men de äger faktiskt en ganska stor budget.

Hur ser du på Cloud Native Computing Foundation utvecklas, och kommer Kubernetes alltid att vara i centrum för det - eller i den molnbaserade rörelsen överlag?

Kubernetes var det som utlöste CNCF, och under de första åren handlade det om Kubernetes och det offentliga molnet. Vad vi har sett sedan ungefär ett år tillbaka är att det nu inte längre bara handlar om Kubernetes, det handlar faktiskt mer om molninbyggt Principerna. Detta betyder faktiskt att det inte nödvändigtvis är moln längre heller, inte ens privat moln. Det är ofta till och med traditionella företagsnätverk, tråkig lokal infrastruktur, servrar av barmetall och allt det där, men med inbyggda molnbaserade principer. 

Den nya normen är nu hybrid och inkluderar flera offentliga molnleverantörer, såväl som lokal infrastruktur. Företag vill tillhandahålla samma flexibilitet för applikationsutvecklare, eller tillhandahålla observerbarhet med moderna molnbaserade verktyg, eller göra säkerhet med moderna molnbaserade verktyg – till exempel autentisering, istället för bara segmentering eller identitetsbaserad tillämpning – alla dessa nya molnbaserade koncept på befintlig infrastruktur. 

Vi ser en mycket stark efterfrågan på att fortfarande ansluta till den gamla världen och prata MPLS, VLAN, sFlow och NetFlow – hela den befintliga uppsättningen av företagskrav. Ingen av dem har försvunnit.

Ungefär ett decennium in i det verkar det infödda utrymmet i molnet inte vara en modefluga. Hur mycket utrymme finns det för att det ska fortsätta att utvecklas?

Det fanns definitivt en tid då det var som, "Åh, Kubernetes är förmodligen kortlivad och serverlös kommer att bli nästa lager." Eller, "Kubernetes liknar OpenStack. Eller, "Det kommer att försvinna och det kommer att bli en implementeringsdetalj." Och det har inte hänt. 

Jag tror att det definitivt finns ett utrymme för serverlöst, i synnerhet för mycket snabb applikationsutveckling. Men i företag ser vi cloud native som det nya lagret ovanpå virtualisering, och vi tror att det har en liknande hållbarhetstid som virtualisering. Vilket betyder att vi är i början av den inbyggda molnmigrationen.

Vilka stora problem behöver fortfarande lösas på infrastrukturnivå?

Vi ser företag i en situation där de helt plötsligt, vare sig de vill det eller inte, behöver en strategi för flera moln. Eftersom de också har lokal infrastruktur behöver de nu en hybrid molnstrategi utöver det. Och de måste ta reda på hur man gör säkerhet och andra funktioner universellt i den här infrastrukturen utan att låsa sig till ett visst offentligt moln. 

Så det här är nästa stora utmaning: Vem kommer att bli det där agnostiska lagret för multimoln och molnbaserade, som vad VMware blev? Vem kommer att bli VMware för molnbaserad?

Jag tror att insikten har slagit in att om du vill attrahera moderna applikationsteam och kunna ha snabba marknadstider, måste du tillhandahålla dem en molnbaserad infrastruktur.

Och även om molnbaserad adoption kan ha varit relativt lätt för moderna webbföretag som var tidiga användare, är utmaningen ur ditt perspektiv att bygga ny teknik som överbryggar klyftan mellan denna moderna värld och befintliga företagsverktyg och system?

Det svåra är att moderna appteam är vana vid att infrastrukturlagret utvecklas lika snabbt som dem. Och detta tvingade infrastrukturlagret att bli ännu mer programmerbart, mer justerbart. Det är därför vi faktiskt ser ett nätverkslager och ett säkerhetslager ovanpå molnnätverkslagret. Men nu har vi företag som kommer in, och vi ser en mycket stark efterfrågan på att fortfarande ansluta till den gamla världen och prata MPLS, VLAN, sFlow och NetFlow — hela den befintliga uppsättningen av företagskrav. Ingen av dem har försvunnit, alla efterlevnadsregler är fortfarande desamma. Och även några av de moderna SaaS-företagen står nu inför dessa utmaningar när de växer sig större och de bryr sig om efterlevnad och så vidare. 

Ur ett teknikperspektiv handlar det om hur man kopplar den nya molnvärlden till de befintliga företagskraven. Eftersom många av dessa problem gömdes av de offentliga molnleverantörerna. Offentliga molnleverantörer löste efterlevnadsproblemen, men de öppnade inte källkod eller publicerade något av det; de löste det på egen hand. Det är en del av molnvärdet. Företag måste nu bygga om och köpa det om de inte vill låsa sig till det offentliga molnerbjudandet.

Var ser du nästa våg av molnbaserad innovation komma ifrån? Kommer det fortfarande från ett företag som Google, eller är det en ny typ av företag som leder ansvaret?

Det är väldigt intressant. Jag skulle säga att det förmodligen inte kommer från Googles och Facebooks. Källan till innovation kommer att vara öppen källkod, och kunderna och användarna som driver efterfrågan kommer att vara företag en nivå ned från hyperscalers - redan betydande företag som fortfarande är mycket störande, som Adobe, Shopify eller GitHub. Men också företag som riskerar att störas av teknik, som finansiella tjänster, försäkringsleverantörer och telekom. Dessa företag har alla ett gemensamt intresse av att standardisera infrastruktur med repeterbara utvecklings- och infrastrukturmodeller.

Upplagd 26 juli 2022