Kubernetes, netværk og finde VMware fra Cloud Native

Thomas Graf er medstifter og CTO af Isovalent, og skaberen af ​​en populær open source (og cloud native) netværksteknologi kaldet cilium. Cilium er bygget oven på en Linux-teknologi på kerneniveau kaldet eGMP.

I dette interview diskuterer Graf de roller, som Cilium og eBPF spiller i det voksende cloud-native netværksøkosystem, samt nogle bredere tendenser omkring Kubernetes-adoption og -evolution. Han forklarer, hvem der bruger og køber Kubernetes i store virksomheder, hvor cloud-native infrastruktur stadig skal forbedres, og hvordan ønsket om standardisering driver innovation.

---

FREMTID: Hvordan skal vi tænke på eBPF og Cilium i forbindelse med computing og netværk generelt, og så specifikt i forbindelse med cloud native økosystem?

THOMAS GRAF: Samlet set er eBPF teknologien, og den er ekstremt lavt niveau. Det er designet til kerneudviklere, og min baggrund er inden for kerneudvikling. eBPF er for kernen, for operativsystemet, hvad JavaScript er for en browser. Det gør operativsystemet programmerbart ligesom JavaScript gør browseren programmerbar. Tidligere var vi nødt til at opgradere vores browserversioner til rent faktisk at bruge bestemte websteder. Og så kom JavaScript, og lige pludselig kunne applikationsteams og udviklere bygge massive applikationer - til det punkt, hvor den mest populære tekstbehandlingsapplikation blev erstattet af en applikation i browseren. Det førte til en kæmpe bølge af innovation. 

Det samme sker med eBPF, dog på styresystemniveau, fordi vi pludselig kan gøre ting på kerne- eller styresystemniveau, hvor vi ser alt og kontrollerer alt - hvilket er meget vigtigt for sikkerheden - uden at skulle skifte kerne kildekode. Vi kan i det væsentlige indlæse programmer i kernen for at udvide dens funktionalitet og bringe nye muligheder med sig. Dette har også låst op for en massiv bølge af innovation. Hyperscalere som Facebook, Google og Netflix bruger dette på egen hånd, direkte, med deres egne kernehold. 

Hvad Cilium bringer til bordet, er, at det bruger den eBPF-teknologi på lavt niveau til i det væsentlige at levere en ny bølge af softwareinfrastruktur, især for den oprindelige cloud-bølge. Tænk på dette som softwaredefineret netværk, og hvad Nicira, der blev til VMware NSX, gjorde for virtualiseringsindustrien. Vi gør det samme for cloud native, hvor det er en blanding af cloud-udbyder eller offentlig cloud-infrastruktur, såvel som lokal infrastruktur. Og vi løser brugssager for netværk, sikkerhed og observerbarhed med det på infrastrukturlaget.

Og Cilium Service Mesh, som netop er blevet frigivet, er en udvikling af disse muligheder?

Det, der lige nu er sket, siden omkring et år siden, er, at de to rum støder sammen. Hvad Cilium har gjort indtil nu, er fokuseret på netværk, virtualiseret netværk og derefter cloud native netværk - men stadig netværk. Men når vi så det oppefra og ned, gjorde applikationsteams på Twitter og Google det servicenet ting - først i applikationen og derefter den sidevognsbaserede model, den proxy-baserede model, hvilket er hvad projekter kan lide Samme aflevere. Og nu kommer disse to lag tættere på pga traditionelle virksomheder kommer ind i cloud native-verdenen, og de har krav til virksomhedsnetværk, men deres app-teams vil også have et servicemesh. 

Gartner kalder dette nye lag for "serviceforbindelse" - vi vil se, om det udtryk fanger - men det er i bund og grund et lag, der inkluderer virksomhedens netværksdel og servicemesh-delen, der kommer fra applikationsteamene. Og fordi det er det, kunderne efterspørger, har vi tilføjet mulighederne i selve Cilium. Så i det væsentlige går Cilium opad fra virksomhedens netværksside, og servicemaskerne går nedad til mere af netværkssiden.

Hvorfor er der så meget fokus på netværks- og servicemesh-niveauet i Kubernetes-stakken?

For med ønsket om at køre i flere skyer og dele applikationer fra hinanden i containere, er forbindelseslaget blevet centralt. Hvad der før var måske inter-proces kommunikation og middleware er nu netværket, så netværket er ved at blive helt afgørende for, at applikationer kan tale sammen og for at data kan flyde. 

Og især i cloud native, multi-cloud er ved at blive helt afgørende. Alle cloud-udbydere har deres egne netværkslag, men selvfølgelig skræddersyet til deres egne skyer. De har on-prem-tilbud, men de er ikke rigtig multi-cloud. Cilium og eBPF bringer det agnostiske lag med flere skyer til bordet. Det opfører sig nøjagtigt det samme on-premises, som det gør i den offentlige sky. Flere af de offentlige cloud-udbydere bruger Cilium under hætten til deres administrerede Kubernetes-tilbud, og teleselskaber bruger det til on-prem 5G-infrastruktur. Det handler om at tale begge sprog og forbinde disse verdener sammen.

Det er derfor, der er så meget fokus på dette: fordi en af ​​de nemmeste måder for cloud-udbydere at låse kunder på er at eje det forbindelseslag. Jeg tror fra et strategisk infrastrukturperspektiv, ligesom virtualiseringslaget var nøglen, nu er forbindelses- og netværkslaget absolut nøglen.

Kilden til [fremtidig] innovation vil være open source, og kunderne og brugerne, der driver efterspørgslen, vil være virksomheder et niveau ned fra hyperscalerne - allerede store virksomheder, der stadig er stærkt disruptive.

Kubernetes er ret bredt accepteret og vedtaget på dette tidspunkt, men der er stadig tale i nogle kredse om, at det er overdrevet. Hvem tror du, Kubernetes og det overordnede cloud-native økosystem er for?

Det er til moderne applikationsteams. Jeg tror, ​​at erkendelsen er skudt i gang, at hvis du vil tiltrække moderne applikationsteams og være i stand til at have hurtige gå-på-markedstider, skal du give dem cloud-native infrastruktur. Vi ser ofte prototyper – indledende, før-MVP, endda bevise konceptet eller sælge internt – på serverløs, noget som Lambda. Og så på Kubernetes, fordi app-teamene kan eje infrastrukturen direkte. Og så, efterhånden som det bevæger sig ind i produktionen, går de til virksomhedens, lokale Kubernetes-distributioner. Men det er faktisk en relativt lille del af hele infrastrukturen, måske en enkelt eller lav tocifret procentdel. 

Det bliver dog klart den nye standard. Ligesom virtualiseringsvedtagelse var meget langsom i starten, og folk sagde, at det var overdrevet - men med tiden begyndte det selvfølgelig at erstatte de fleste ting - vi vil se det samme her. Eller bare som med moderne sprog. Folk sagde, at Java var overkill, og det er det sikkert stadig for mange applikationer, men der var engang, hvor det blev meget svært at lave applikationsudvikling uden for Java, fordi det var det, størstedelen af ​​applikationsudviklere kunne skrive i. Det samme vil være sandt for moderne applikationsteams: de vil forvente at have Kubernetes rundt for at udvikle mere agilt og bringe produktet til markedet hurtigt.

På infrastruktursiden er det måske lidt overkill, men hvis alternativet er at omskrive en applikation fra serverløs til on-prem, er det en massiv opgave. Så Kubernetes er mellemvejen der, hvilket er meget attraktivt. 

Hvad med tanken om, at Kubernetes stadig har brug for en bedre udvikleroplevelse?

Hvis vi ser på den originale OpenShift, før den rebaserede på Kubernetes, var det dette. Det var endnu tættere på applikationsteamet og var en endnu bedre applikationsudvikleroplevelse. Du kunne skubbe til Git, og det ville automatisk implementere. Heroku prøvede også dette, men SaaS-baseret. 

Kubernetes tog et skridt tilbage og sagde: "Vi er nødt til at beholde nogle operationelle aspekter i det og gøre det lidt tættere på, hvad en sysadmin også ville forvente. Vi kan ikke kun skræddersyes til applikationer.” Det er mellemvejen: Den skal have tilstrækkelig tiltrækningskraft for applikationsteams, men det skal stadig være muligt at køre den app uden for et specifikt miljø og få den administreret af andre end applikationsudviklere.

Jeg vil sige, at det største skridt mellem Docker og Kubernetes var, at Docker handlede om udvikleroplevelse. Det løste den del, men løste ikke den offentlige sky-økosystemdel.

Hvordan er vi nået til dette punkt? Var dette den naturlige udvikling fra platform-as-a-service (PaaS) og applikationscontainere?

Det var Docker-billeder og pakkeaspektet af Docker. Den gamle skole var, hvordan man implementerede i virtuelle maskiner, og der var alle mulige former for automatisering omkring det. Og så var der, hvad Facebook lavede med Tupperware - meget specialbygget og til virkelig stor skala. Og så kom Docker og leverede i det væsentlige dette containerbillede, og alle kunne behandle det som en miniature VM. Jeg kan nu distribuere min app, og i stedet for et 600 MB virtuelt billede, er det nu en 10 MB container. Men du kan behandle den på samme måde, den har alt, hvad den behøver. 

Det låste op for muligheden for at bringe en orkestrator som Kubernetes ind, der stadig giver dig mulighed for at behandle applikationer som mini VM'er, men så også tage et skridt videre og faktisk behandle dem som mikrotjenester. Det giver dig mulighed for at gøre begge dele.

Jeg vil sige, at det største skridt mellem Docker og Kubernetes var, at Docker handlede om udvikleroplevelse. Det løste den del, men løste ikke den offentlige sky-økosystemdel. Den havde ikke, eller ønskede nødvendigvis, tæt integration med cloud-udbyderne. Kubernetes løste det. 

Hvem ser du køre Kubernetes inde i virksomheder? Er det individuelle ansøgningsteams?

Der er et interessant skift, der skete med cloud native, som er, at vi har fremkomsten af ​​"platformsteamet", vil jeg kalde det. De er ikke applikationsingeniører. De har en smule viden om netværksoperationer, og de har en del sikkerhedsviden. De har SRE viden, og de ved, hvordan man laver cloud automation. De leverer platformen for applikationsteams og behandler disse applikationsteams som deres kunder.

Platformteams er dem, der køber Kubernetes og relaterede teknologier, som de bruger, fordi de har til opgave at levere den næste generations infrastruktur for at gøre moderne app-teams glade.

Jeg tror bestemt, at der er plads til serverløs, især til meget hurtig applikationsudvikling. Men i virksomheder ser vi cloud native som det nye lag ovenpå virtualisering

Er det en net-ny køber eller et net-nyt team? Eller er platformsteams som noget, der findes inde på steder som Google eller Facebook og nu bliver mainstream?

De er for det meste et nyt hold. Jeg tror, ​​de til en vis grad er ligesom SRE-holdene hos Google og Facebook. Imidlertid ejer applikationsteamene sandsynligvis mere af app-implementeringen i virksomheder, fordi virksomheder ikke har denne meget klare skelnen mellem softwareingeniører og SRE'er, som Google og Facebook gør. Jeg vil sige, at denne udvikling ligner meget, hvordan du havde virtualiseringsteams, og så migrerede masser af netværksoperationer fra - eller udviklede sig eller avancerede fra - at handle om netværk hardware at handle om netværk virtualisering. Og disse teams begyndte for eksempel at betjene VMware NSX. Det samme sker her. 

Selvom det ikke nødvendigvis er et nyt budget. Vi ser for eksempel, at budgetter flytter sig fra sikkerhed og netværk til dette platformsteam, efterhånden som skyudgifterne stiger, og der bruges mindre på netværkshardware. De arbejder ofte med sikkerhedsteamet og med netværksoperationsteamet for at få buy-in, men de ejer faktisk en ret betydelig størrelse af budgettet.

Hvordan ser du Cloud Native Computing Foundation udvikler sig, og vil Kubernetes altid være i centrum for det - eller i den cloud-native bevægelse generelt?

Kubernetes var det, der satte gang i CNCF, og i de første par år handlede det om Kubernetes og public cloud. Hvad vi har set siden omkring et år siden er, at det nu ikke længere kun handler om Kubernetes, det handler faktisk mere om cloud native principper. Dette betyder faktisk, at det heller ikke nødvendigvis er sky længere, ikke engang privat sky. Det er ofte endda traditionelt virksomhedsnetværk, kedelig on-prem-infrastruktur, bare-metal-servere og alt det, men med de indbyggede cloud-principper. 

Den nye norm er nu hybrid og inkluderer flere offentlige cloud-udbydere såvel som lokal infrastruktur. Virksomheder ønsker at give den samme applikationsudvikler-agility, eller give observerbarhed med moderne cloud-native værktøjer, eller gøre sikkerhed med moderne cloud-native værktøjer – for eksempel godkendelse i stedet for blot segmentering eller identitetsbaseret håndhævelse – alle de nye cloud-native-koncepter på eksisterende infrastruktur. 

Vi oplever en meget stor efterspørgsel efter stadig at forbinde til den gamle verden og tale MPLS, VLAN, sFlow og NetFlow – hele det eksisterende sæt af virksomhedskrav. Ingen af ​​dem er gået væk.

Omkring et årti inde i det ser det oprindelige cloud-rum ikke ud til at være et modefænomen. Hvor meget plads er der til, at det kan fortsætte med at udvikle sig?

Der var bestemt et tidspunkt, hvor det var sådan, "Åh, Kubernetes er sandsynligvis kortvarig, og serverløs bliver det næste lag." Eller "Kubernetes ligner OpenStack. Eller: "Det vil forsvinde, og det bliver en implementeringsdetalje." Og det er ikke sket. 

Jeg tror bestemt, at der er plads til serverløs, især til meget hurtig applikationsudvikling. Men i virksomheder ser vi cloud native som det nye lag oven på virtualisering, og vi mener, at det har en lignende holdbarhed som virtualisering. Hvilket betyder, at vi er helt i begyndelsen af ​​cloud-native migration.

Hvilke store problemer mangler stadig at blive løst på infrastrukturniveau?

Vi ser virksomheder i en situation, hvor de pludselig, uanset om de ønsker det eller ej, har brug for en multi-cloud-strategi. Fordi de også har on-premise infrastruktur, har de nu brug for en hybrid cloud-strategi oven i købet. Og de skal finde ud af, hvordan de udfører sikkerhed og andre funktioner universelt på tværs af denne infrastruktur uden at låse sig fast i en bestemt offentlig sky. 

Så dette er den næste store udfordring: Hvem skal være det agnostiske lag for multi-cloud og cloud-native, som hvad VMware blev til? Hvem skal være VMware for cloud native?

Jeg tror, ​​at erkendelsen er skudt i gang, at hvis du vil tiltrække moderne applikationsteams og være i stand til at have hurtige gå-på-markedstider, skal du give dem cloud-native infrastruktur.

Og selvom cloud native-adoption måske har været relativt let for de moderne webvirksomheder, der var early adopters, er udfordringen fra dit perspektiv at bygge nye teknologier, der bygger bro mellem denne moderne verden og eksisterende virksomhedsværktøjer og -systemer?

Den svære del er, at moderne app-teams er vant til at få infrastrukturlaget til at udvikle sig lige så hurtigt som dem. Og dette tvang infrastrukturlaget til at være endnu mere programmerbart, mere justerbart. Derfor ser vi faktisk et netværkslag og et sikkerhedslag oven på cloud-netværkslaget. Men nu har vi virksomheder, der kommer ind, og vi ser en meget stor efterspørgsel efter stadig at forbinde til den gamle verden og tale MPLS, VLAN, sFlow og NetFlow - hele det eksisterende sæt af virksomhedskrav. Ingen af ​​dem er gået væk, alle overholdelsesregler er stadig de samme. Og selv nogle af de moderne SaaS-virksomheder står nu over for disse udfordringer, efterhånden som de vokser sig større, og de bekymrer sig om overholdelse og så videre. 

Fra et teknologisk perspektiv handler det om, hvordan man forbinder den nye cloud-native verden til de eksisterende virksomhedskrav. Fordi mange af disse problemer blev skjult af de offentlige cloud-udbydere. Offentlige cloud-udbydere løste overholdelsesproblemerne, men de åbnede ikke kildekode eller offentliggjorde noget af det; det løste de på egen hånd. Det er en del af cloud-værdien. Virksomheder skal nu genopbygge og købe det, hvis de ikke vil låse sig ind i de offentlige cloud-tilbud.

Hvor ser du den næste bølge af cloud-native innovation komme fra? Kommer det stadig fra en virksomhed som Google, eller er der en ny type virksomhed, der leder anklagen?

Det er meget interessant. Jeg vil sige, at det nok ikke kommer fra Googles og Facebooks. Kilden til innovation vil være open source, og kunderne og brugerne, der driver efterspørgslen, vil være virksomheder et niveau ned fra hyperscalerne - allerede betydelige virksomheder, der stadig er meget disruptive, som Adobe, Shopify eller GitHub. Men også virksomheder, der risikerer at blive forstyrret af teknologi, såsom finansielle tjenester, forsikringsudbydere og teleselskaber. Disse virksomheder har alle en fælles interesse i at standardisere infrastruktur med gentagelige udviklings- og infrastrukturmodeller.

Offentliggjort 26. juli 2022