Kubernetes, nettverk og finne VMware fra Cloud Native

Thomas Graf er medgründer og CTO for Isovalent, og skaperen av en populær åpen kildekode (og skybasert) nettverksteknologi kalt cilium. Cilium er bygget på toppen av en Linux-teknologi på kjernenivå kalt eGMP.

I dette intervjuet diskuterer Graf rollene som Cilium og eBPF spiller i det voksende skybaserte nettverksøkosystemet, samt noen bredere trender rundt Kubernetes-adopsjon og -evolusjon. Han forklarer hvem som bruker og kjøper Kubernetes i store bedrifter, hvor skybasert infrastruktur fortsatt må forbedres, og hvordan ønsket om standardisering driver innovasjon.

---

FREMTID: Hvordan bør vi tenke på eBPF og Cilium i sammenheng med databehandling og nettverk, generelt, og da spesifikt i sammenheng med skybasert økosystem?

THOMAS GRAF: Totalt sett er eBPF teknologien, og den er ekstremt lavt nivå. Den ble designet for kjerneutviklere, og min bakgrunn er innen kjerneutvikling. eBPF er for kjernen, for operativsystemet, hva JavaScript er for en nettleser. Det gjør operativsystemet programmerbart akkurat som JavaScript gjør nettleseren programmerbar. Tidligere måtte vi oppgradere nettleserversjonene våre for å faktisk bruke bestemte nettsteder. Og så kom JavaScript, og plutselig kunne applikasjonsteam og utviklere bygge massive applikasjoner – til det punktet hvor den mest populære tekstbehandlingsapplikasjonen ble erstattet av en nettleserapplikasjon. Det førte til en enorm bølge av innovasjon. 

Det samme skjer med eBPF, men på operativsystemnivå, fordi vi plutselig kan gjøre ting på kjerne- eller operativsystemnivå der vi ser alt og kontrollerer alt – noe som er veldig viktig for sikkerheten – uten å måtte bytte kjerne kildekode. Vi kan i hovedsak laste programmer inn i kjernen for å utvide funksjonaliteten og bringe nye muligheter med seg. Dette har også låst opp en massiv bølge av innovasjon. Hyperscalere som Facebook, Google og Netflix bruker dette på egen hånd, direkte, med sine egne kjerneteam. 

Det som Cilium bringer til bordet, er at det bruker den eBPF-teknologien på lavt nivå for å gi en ny bølge av programvareinfrastruktur, spesielt for den innfødte skybølgen. Tenk på dette som programvaredefinert nettverk og hva Nicira, som ble VMware NSX, gjorde for virtualiseringsindustrien. Vi gjør det samme for cloud native, der det er en blanding av skyleverandør eller offentlig skyinfrastruktur, så vel som lokal infrastruktur. Og vi løser brukstilfeller for nettverk, sikkerhet og observerbarhet med det på infrastrukturlaget.

Og Cilium Service Mesh, som nettopp ble utgitt, er en videreutvikling av disse egenskapene?

Det som har skjedd for et år siden, er at de to rommene kolliderer. Det Cilium har gjort så langt er fokusert på nettverk, virtualisert nettverk, og deretter cloud native nettverk - men fortsatt nettverk. Men så, fra toppen og ned, gjorde applikasjonsteamene på Twitter og Google det servicenett ting — i applikasjonen først, og deretter den sidevognsbaserte modellen, den proxy-baserte modellen, som er hva prosjekter liker Samme levere. Og nå kommer disse to lagene nærmere pga tradisjonelle bedrifter kommer inn i den skybaserte verden, og de har krav til bedriftsnettverk, men appteamene deres vil også ha et tjenestenettverk. 

Gartner kaller dette nye laget «tjenestetilkobling» – vi får se om det begrepet slår inn – men det er i hovedsak et lag som inkluderer bedriftsnettverksdelen og servicenettverket som kommer fra applikasjonsteamene. Og fordi det er det kundene etterspør, har vi lagt til egenskapene i selve Cilium. Så i hovedsak går Cilium oppover fra bedriftsnettverkssiden, og tjenestenettene går nedover til mer av nettverkssiden.

Hvorfor er det så mye fokus på nettverks- og servicemesh-nivået til Kubernetes-stakken?

For med ønsket om å kjøre i flere skyer og dele applikasjoner fra hverandre i containere, har tilkoblingslaget blitt sentralt. Det som før var kanskje interprosesskommunikasjon og mellomvare er nå nettverket, så nettverket blir helt avgjørende for at applikasjoner skal snakke sammen og for at data skal flyte. 

Og spesielt i nettskyen, multi-cloud blir helt avgjørende. Alle skyleverandørene har sine egne nettverkslag, men selvfølgelig skreddersydd til sine egne skyer. De har tilgjengelige tilbud, men de er ikke virkelig multi-skyer. Cilium og eBPF bringer til bordet det agnostiske laget med flere skyer. Det oppfører seg nøyaktig det samme på stedet som det gjør i den offentlige skyen. Flere av de offentlige skyleverandørene bruker Cilium under panseret for sine administrerte Kubernetes-tilbud, og teleselskaper bruker det for lokal 5G-infrastruktur. Det handler om å snakke begge språkene og koble disse verdenene sammen.

Det er derfor det er så mye fokus på dette: fordi en av de enkleste måtene for skyleverandører å låse kunder inne på er å eie det tilkoblingslaget. Jeg tror fra et strategisk infrastrukturperspektiv, akkurat som virtualiseringslaget var nøkkelen, nå er tilkoblings- og nettverkslaget helt nøkkelen.

Kilden til [fremtidig] innovasjon vil være åpen kildekode, og kundene og brukerne som driver etterspørselen vil være selskaper ett nivå ned fra hyperskalerne – allerede betydelige selskaper som fortsatt er svært disruptive.

Kubernetes er ganske allment akseptert og vedtatt på dette tidspunktet, men det er fortsatt snakk i noen kretser om at det er overkill. Hvem tror du Kubernetes, og det skybaserte økosystemet generelt, er for?

Det er for moderne applikasjonsteam. Jeg tror erkjennelsen har slått inn at hvis du vil tiltrekke deg moderne applikasjonsteam og kunne ha raske markedstider, må du gi dem skybasert infrastruktur. Vi ser ofte prototyping – innledende, pre-MVP, til og med bevise konseptet eller selge internt – på serverløs, noe som Lambda. Og så på Kubernetes, fordi appteamene kan eie infrastrukturen direkte. Og så, når det går over i produksjon, går de til bedriftsbaserte Kubernetes-distribusjoner. Men det er faktisk en relativt liten del av hele infrastrukturen, kanskje en enkelt eller lav tosifret prosentandel. 

Det vil helt klart være den nye standarden. Akkurat som virtualiseringsadopsjon var veldig treg i utgangspunktet og folk sa at det var overkill - men over tid begynte det selvfølgelig å erstatte de fleste ting - vi vil se det samme her. Eller akkurat som med moderne språk. Folk sa at Java var overkill, og det er det sannsynligvis fortsatt for mange applikasjoner, men det var en tid hvor det ble veldig vanskelig å gjøre applikasjonsutvikling utenfor Java fordi det var det flertallet av applikasjonsutviklere kunne skrive i. Det samme vil være sant for moderne applikasjonsteam: de vil forvente å ha Kubernetes rundt for å utvikle mer smidig og bringe produktet til markedet raskt.

På infrastruktursiden kan det være litt overkill, men hvis alternativet er å omskrive en applikasjon fra serverløs til on-prem, er det en enorm oppgave. Så Kubernetes er midtveien der, noe som er veldig attraktivt. 

Hva med ideen om at Kubernetes fortsatt trenger en bedre utvikleropplevelse?

Hvis vi ser på den originale OpenShift, før den ble rebasert på Kubernetes, var det dette. Det var enda nærmere applikasjonsteamet og var en enda bedre applikasjonsutvikleropplevelse. Du kan trykke til Git og den vil automatisk distribuere. Heroku prøvde også dette, men SaaS-basert. 

Kubernetes tok et skritt tilbake og sa: "Vi må beholde noen operasjonelle aspekter i det og gjøre det litt nærmere det en systemadministrator også ville forvente. Vi kan ikke bare skreddersys til applikasjoner.» Det er mellomveien: Den må ha nok attraktivitet for applikasjonsteam, men det må fortsatt være mulig å kjøre den appen utenfor et spesifikt miljø, og ha den administrert av andre enn applikasjonsutviklere.

Jeg vil si at det største steget mellom Docker og Kubernetes var at Docker handlet om utvikleropplevelse. Det løste den delen, men løste ikke den offentlige sky-økosystemdelen.

Hvordan kom vi til dette punktet? Var dette den naturlige utviklingen fra plattform-som-en-tjeneste (PaaS) og applikasjonsbeholdere?

Det var Docker-bilder og pakkeaspektet til Docker. Den gamle skolen var hvordan man distribuerte til virtuelle maskiner, og det var all slags automatisering rundt det. Og så var det det Facebook gjorde med Tupperware - veldig spesialbygd og for virkelig stor skala. Og så kom Docker og ga i hovedsak dette containerbildet, og alle kunne behandle det som en miniatyr VM. Jeg kan nå distribuere appen min, og i stedet for et 600 MB virtuelt bilde, er det nå en 10 MB beholder. Men du kan behandle den på samme måte, den har alt den trenger. 

Det låste opp muligheten til å hente inn en orkestrator som Kubernetes som fortsatt lar deg behandle applikasjoner som mini-VM-er, men så også ta ett skritt videre og faktisk behandle dem som mikrotjenester. Det lar deg gjøre begge deler.

Jeg vil si at det største steget mellom Docker og Kubernetes var at Docker handlet om utvikleropplevelse. Det løste den delen, men løste ikke den offentlige sky-økosystemdelen. Den hadde ikke, eller ønsket nødvendigvis, tett integrasjon med skyleverandørene. Kubernetes løste det. 

Hvem ser du som driver Kubernetes i selskaper? Er det individuelle søknadsteam?

Det er et interessant skifte som skjedde med cloud native, som er at vi har fremveksten av "plattformteamet", vil jeg kalle det. De er ikke applikasjonsingeniører. De har litt kunnskap om nettverksoperasjoner og de har ganske mye sikkerhetskunnskap. De har SRE-kunnskap og de vet hvordan de gjør skyautomatisering. De tilbyr plattformen for applikasjonsteam, og behandler disse applikasjonsteamene som deres kunder.

Plattformteam er de som kjøper Kubernetes og relaterte teknologier, som de bruker fordi de har i oppgave å sørge for neste generasjons infrastruktur for å gjøre moderne app-team glade.

Jeg tror det definitivt er plass for serverløs, spesielt for veldig rask applikasjonsutvikling. Men i bedrifter ser vi cloud native som det nye laget på toppen av virtualisering

Er det en nett-ny kjøper eller et nett-nytt team? Eller er plattformteam som noe som eksisterer på steder som Google eller Facebook og nå går mainstream?

De er stort sett et nytt lag. Jeg tror de til en viss grad er som SRE-teamene på Google og Facebook. Imidlertid eier applikasjonsteamene sannsynligvis mer av app-distribusjonen i bedrifter, fordi bedrifter ikke har dette veldig klare skillet mellom programvareingeniører og SRE-er som Google og Facebook gjør. Jeg vil si at denne utviklingen er veldig lik hvordan du hadde virtualiseringsteam, og så har mange nettverksoperasjoner migrert fra – eller utviklet seg eller avansert fra – som handler om nettverk maskinvare å handle om nettverk virtualisering. Og disse teamene begynte for eksempel å betjene VMware NSX. Det samme skjer her. 

Selv om det ikke nødvendigvis er et nytt budsjett. Vi ser for eksempel budsjetter flytte fra sikkerhet og nettverk til dette plattformteamet, ettersom skyutgiftene øker og mindre brukes på nettverksmaskinvare. De opererer ofte med sikkerhetsteamet og nettverksoperasjonsteamet for å få buy-in, men de eier faktisk en ganske betydelig størrelse på budsjettet.

Hvordan ser du på Cloud Native Computing Foundation utvikler seg, og vil Kubernetes alltid være i sentrum av det - eller i den skybaserte bevegelsen generelt?

Kubernetes var det som utløste CNCF, og de første par årene handlet det om Kubernetes og offentlig sky. Det vi har sett siden for et år siden er at det nå ikke lenger bare handler om Kubernetes, det handler faktisk mer om skybasert prinsipper. Dette betyr faktisk at det ikke nødvendigvis er sky lenger heller, ikke engang privat sky. Det er ofte til og med tradisjonelle bedriftsnettverk, kjedelig lokal infrastruktur, bare-metal-servere og alt dette, men med de innebygde skybaserte prinsippene. 

Den nye normen er nå hybrid og inkluderer flere offentlige skyleverandører, så vel som lokal infrastruktur. Bedrifter ønsker å tilby den samme smidigheten for applikasjonsutviklere, eller gi observerbarhet med moderne skybaserte verktøy, eller gjøre sikkerhet med moderne skybaserte verktøy – for eksempel autentisering, i stedet for bare segmentering eller identitetsbasert håndhevelse – alle de nye skynative konseptene på eksisterende infrastruktur. 

Vi ser en veldig sterk etterspørsel etter fortsatt å koble til den gamle verden og snakke MPLS, VLAN, sFlow og NetFlow – hele det eksisterende settet med bedriftskrav. Ingen av dem har gått bort.

Omtrent et tiår inn i det, ser det ikke ut til at det skybaserte rommet er en kjepphest. Hvor mye rom er det for å fortsette å utvikle seg?

Det var definitivt en tid hvor det var som, "Åh, Kubernetes er sannsynligvis kortvarig, og serverløs kommer til å bli det neste laget." Eller, "Kubernetes ligner på OpenStack. Eller, "Det vil forsvinne og det kommer til å være en implementeringsdetalj." Og det har ikke skjedd. 

Jeg tror det definitivt er plass for serverløs, spesielt for veldig rask applikasjonsutvikling. Men i bedrifter ser vi cloud native som det nye laget på toppen av virtualisering, og vi tror det har en lignende holdbarhet som virtualisering. Noe som betyr at vi er helt i begynnelsen av den skybaserte migrasjonen.

Hvilke store problemer må fortsatt løses på infrastrukturnivå?

Vi ser bedrifter i en situasjon der de plutselig, enten de vil eller ikke, trenger en multiskystrategi. Fordi de også har lokal infrastruktur, trenger de nå en hybrid skystrategi på toppen av det. Og de må finne ut hvordan de kan utføre sikkerhet og andre funksjoner universelt på tvers av denne infrastrukturen uten å låse seg inn i en bestemt offentlig sky. 

Så dette er den neste store utfordringen: Hvem kommer til å bli det agnostiske laget for multisky- og skybaserte, slik VMware ble? Hvem skal være VMware for cloud native?

Jeg tror erkjennelsen har slått inn at hvis du vil tiltrekke deg moderne applikasjonsteam og kunne ha raske markedstider, må du gi dem skybasert infrastruktur.

Og selv om skybasert adopsjon kan ha vært relativt enkelt for de moderne nettselskapene som var tidlige brukere, er utfordringen fra ditt perspektiv å bygge nye teknologier som bygger bro mellom denne moderne verden og eksisterende bedriftsverktøy og -systemer?

Den vanskelige delen er at moderne app-team er vant til å få infrastrukturlaget til å utvikle seg like raskt som dem. Og dette tvang infrastrukturlaget til å bli enda mer programmerbart, mer justerbart. Det er derfor vi faktisk ser et nettverkslag og et sikkerhetslag på toppen av skynettverkslaget. Men nå har vi bedrifter som kommer inn, og vi ser en veldig sterk etterspørsel etter å fortsatt koble til den gamle verden og snakke MPLS, VLAN, sFlow og NetFlow – hele det eksisterende settet med bedriftskrav. Ingen av dem har gått bort, alle etterlevelsesreglene er fortsatt de samme. Og selv noen av de moderne SaaS-selskapene møter nå disse utfordringene ettersom de vokser seg større og de bryr seg om overholdelse og så videre. 

Fra et teknologiperspektiv handler det om hvordan du kobler den nye skybaserte verdenen til de eksisterende bedriftskravene. Fordi mange av disse problemene ble skjult av de offentlige skyleverandørene. Offentlige skyleverandører løste samsvarsproblemene, men de åpnet ikke kildekode eller publiserte noe av det; de løste det på egenhånd. Det er en del av skyverdien. Bedrifter må nå bygge om og kjøpe det hvis de ikke vil låse seg inn i de offentlige skytilbudene.

Hvor ser du den neste bølgen av skybasert innovasjon komme fra? Kommer det fortsatt fra et selskap som Google, eller er det en ny type selskap som leder satsingen?

Det er veldig interessant. Jeg vil si at det sannsynligvis ikke kommer fra Google og Facebook. Kilden til innovasjon vil være åpen kildekode, og kundene og brukerne som driver etterspørselen vil være selskaper ett nivå ned fra hyperscalerne - allerede betydelige selskaper som fortsatt er svært forstyrrende, som Adobe, Shopify eller GitHub. Men også selskaper som risikerer å bli forstyrret av teknologi, som finansielle tjenester, forsikringsleverandører og teleselskaper. Disse selskapene har alle en felles interesse i å standardisere infrastruktur med repeterbare utviklings- og infrastrukturmodeller.

Lagt ut 26. juli 2022