Kubernetes, netwerken en de VMware van Cloud Native vinden

Thomas Graf is medeoprichter en CTO van Isovalent, en maker van een populaire open source (en cloud-native) netwerktechnologie genaamd cilium. Cilium is gebouwd bovenop een Linux-technologie op kernelniveau genaamd eBPPF.

In dit interview bespreekt Graf de rollen die Cilium en eBPF spelen in het groeiende cloud-native netwerkecosysteem, evenals enkele bredere trends rond de acceptatie en evolutie van Kubernetes. Hij legt uit wie Kubernetes gebruikt en koopt binnen grote ondernemingen, waar de cloud-native infrastructuur nog moet worden verbeterd, en hoe de wens naar standaardisatie innovatie stimuleert.

---

TOEKOMST: Hoe moeten we denken over eBPF en Cilium in de context van computers en netwerken, in het algemeen, en dan specifiek in de context van de native cloud-ecosysteem?

THOMAS GRAAF: Over het algemeen is eBPF de technologie, en het is extreem laag niveau. Het is ontworpen voor kernelontwikkelaars en mijn achtergrond ligt in kernelontwikkeling. eBPF is voor de kernel, voor het besturingssysteem, wat JavaScript is voor een browser. Het maakt het besturingssysteem programmeerbaar, net zoals JavaScript de browser programmeerbaar maakt. In het verleden moesten we onze browserversies upgraden om bepaalde websites daadwerkelijk te kunnen gebruiken. En toen kwam JavaScript, en ineens konden applicatieteams en ontwikkelaars enorme applicaties bouwen - tot het punt waarop de meest populaire tekstverwerkingsapplicatie werd vervangen door een in-browser applicatie. Het leidde tot een enorme innovatiegolf. 

Hetzelfde gebeurt met eBPF, zij het op het niveau van het besturingssysteem, omdat we ineens dingen kunnen doen op het niveau van de kernel of het besturingssysteem waar we alles zien en alles controleren - wat erg belangrijk is voor de veiligheid - zonder de kernel te hoeven veranderen broncode. We kunnen in wezen programma's in de kernel laden om de functionaliteit uit te breiden en nieuwe mogelijkheden met zich mee te brengen. Dit heeft ook geleid tot een enorme innovatiegolf. Hyperscalers zoals Facebook, Google en Netflix gebruiken dit alleen, rechtstreeks, met hun eigen kernelteams. 

Wat Cilium op tafel brengt, is dat het die low-level eBPF-technologie gebruikt om in wezen een nieuwe golf van software-infrastructuur te bieden, met name voor de cloud-native wave. Zie dit als softwaregedefinieerde netwerken en wat Nicira, dat VMware NSX werd, deed voor de virtualisatie-industrie. We doen hetzelfde voor cloud native, waar het een mix is ​​van cloudprovider of openbare cloudinfrastructuur, evenals on-premises infrastructuur. En daarmee lossen we use-cases voor netwerken, beveiliging en observeerbaarheid op in de infrastructuurlaag.

En de Cilium Service Mesh, die net is uitgebracht, is een evolutie van deze mogelijkheden?

Wat er momenteel gebeurt, sinds ongeveer een jaar geleden, is dat de twee ruimtes met elkaar in botsing komen. Wat Cilium tot nu toe heeft gedaan, is gericht op netwerken, gevirtualiseerde netwerken en vervolgens cloud-native netwerken - maar nog steeds netwerken. Maar toen, van boven naar beneden, waren applicatieteams bij Twitter en Google aan het doen servicegaas dingen — eerst in de applicatie, en dan het op zijspan gebaseerde model, het op proxy gebaseerde model, dat is wat projecten leuk vinden Istio leveren. En nu komen deze twee lagen dichterbij omdat traditionele ondernemingen komen in de cloud-native wereld en ze hebben zakelijke netwerkvereisten, maar hun app-teams willen ook een servicemesh. 

Gartner noemt deze nieuwe laag "serviceconnectiviteit" - we zullen zien of die term aanslaat - maar het is in wezen een laag die het enterprise-netwerkdeel en het service-mesh-stuk omvat dat afkomstig is van de applicatieteams. En omdat dat is wat klanten eisen, hebben we de mogelijkheden aan Cilium zelf toegevoegd. Dus in wezen gaat Cilium omhoog van de kant van bedrijfsnetwerken en gaan de servicenetwerken naar beneden naar meer van de netwerkkant.

Waarom is er zoveel aandacht voor het netwerk- en servicemesh-niveau van de Kubernetes-stack?

Want met de wens om in meerdere clouds te draaien en applicaties op te splitsen in containers, is de connectiviteitslaag centraal komen te staan. Wat vroeger misschien interprocescommunicatie en middleware was, is nu het netwerk, dus het netwerk wordt absoluut essentieel voor applicaties om met elkaar te praten en om gegevens te laten stromen. 

En met name in cloud-native, multi-cloud wordt absoluut essentieel. Alle cloudproviders hebben hun eigen netwerklagen, maar uiteraard afgestemd op hun eigen clouds. Ze hebben wel on-prem-aanbiedingen, maar ze zijn niet echt multi-cloud. Cilium en eBPF brengen die multi-cloud, agnostische laag naar de tafel. Het gedraagt ​​zich on-premises precies hetzelfde als in de public cloud. Verschillende van de openbare cloudproviders gebruiken Cilium onder de motorkap voor hun beheerde Kubernetes-aanbiedingen en telco's gebruiken het voor on-prem 5G-infrastructuur. Het gaat erom beide talen te spreken en deze werelden met elkaar te verbinden.

Daarom is hier zoveel aandacht voor: omdat een van de gemakkelijkste manieren voor cloudproviders om klanten in te sluiten, is om die connectiviteitslaag te bezitten. Ik denk dat vanuit een strategisch infrastructuurperspectief, net zoals de virtualisatielaag de sleutel was, nu de connectiviteits- en netwerklaag absoluut essentieel is.

De bron van [toekomstige] innovatie zal open-source zijn, en de klanten en gebruikers die de vraag aansturen, zullen bedrijven zijn die een niveau lager liggen dan de hyperscalers - al omvangrijke bedrijven die nog steeds zeer ontwrichtend zijn.

Kubernetes wordt op dit moment vrij algemeen geaccepteerd en geadopteerd, maar in sommige kringen wordt er nog steeds over gesproken dat het overdreven is. Voor wie denk je dat Kubernetes, en het cloud-native ecosysteem in het algemeen, bedoeld is?

Het is voor moderne applicatieteams. Ik denk dat het besef is begonnen dat als je moderne applicatieteams wilt aantrekken en snel naar de markt wilt, je ze een cloud-native infrastructuur moet bieden. We zien vaak prototyping - initieel, pre-MVP, zelfs het concept bewijzen of intern verkopen - op serverloos, zoiets als Lambda. En dan op Kubernetes, omdat de app-teams direct eigenaar kunnen worden van de infrastructuur. En dan, terwijl het in productie gaat, gaan ze naar zakelijke, on-prem Kubernetes-distributies. Maar dat is eigenlijk een relatief klein deel van de hele infrastructuur, misschien een enkel of laag dubbelcijferig percentage. 

Het zal echter duidelijk de nieuwe standaard worden. Net zoals de acceptatie van virtualisatie aanvankelijk erg traag was en mensen zeiden dat het overdreven was - maar na verloop van tijd begon het natuurlijk de meeste dingen te vervangen - we zullen hier hetzelfde zien. Of net als bij moderne talen. Mensen zeiden dat Java overdreven was, en dat is het waarschijnlijk nog steeds voor veel applicaties, maar er was een tijd dat het erg moeilijk werd om applicatie-ontwikkeling buiten Java te doen, omdat de meeste applicatieontwikkelaars daarin konden schrijven. geldt voor moderne applicatieteams: ze zullen Kubernetes verwachten om agile te kunnen ontwikkelen en het product snel op de markt te kunnen brengen.

Aan de infrastructuurkant is het misschien een beetje overkill, maar als het alternatief is om een ​​applicatie te herschrijven van serverloos naar on-prem, is dat een enorme taak. Dus Kubernetes is daar de middenweg, wat erg aantrekkelijk is. 

Hoe zit het met het idee dat Kubernetes nog steeds een betere ontwikkelaarservaring nodig heeft?

Als we kijken naar de originele OpenShift, voordat het opnieuw werd gebaseerd op Kubernetes, was het dit. Het was nog dichter bij het applicatieteam en het was een nog betere ervaring voor applicatieontwikkelaars. Je zou naar Git kunnen pushen en het zou automatisch worden geïmplementeerd. Heroku heeft dit ook geprobeerd, maar dan op SaaS-basis. 

Kubernetes deed een stap achteruit en zei: "We moeten enkele operationele aspecten erin houden en het ook een beetje dichter maken bij wat een systeembeheerder zou verwachten. We kunnen niet alleen worden toegespitst op toepassingen.” Het is de middenweg: het moet voldoende aantrekkelijk zijn voor applicatieteams, maar het moet nog steeds mogelijk zijn om die app buiten een specifieke omgeving te draaien en te laten beheren door andere mensen dan applicatieontwikkelaars.

Ik zou zeggen dat de grootste stap tussen Docker en Kubernetes was dat Docker draaide om de ervaring van ontwikkelaars. Het loste dat deel op, maar loste het deel van het openbare cloud-ecosysteem niet op.

Hoe zijn we op dit punt gekomen? Was dit de natuurlijke evolutie van platform-as-a-service (PaaS) en applicatiecontainers?

Het waren Docker-afbeeldingen en het verpakkingsaspect van Docker. De oude school was hoe te implementeren in virtuele machines, en daar was allerlei automatisering omheen. En dan was er wat Facebook deed met Tupperware - zeer op maat gemaakt en voor echt grote schaal. En toen kwam Docker langs en leverde in wezen deze container-image en iedereen kon het behandelen als een miniatuur-VM. Ik kan nu mijn app distribueren en in plaats van een virtuele afbeelding van 600 MB is het nu een container van 10 MB. Maar je kunt het hetzelfde behandelen, het heeft alles wat het nodig heeft. 

Dat ontgrendelde de mogelijkheid om een ​​orkestrator als Kubernetes in te schakelen waarmee je applicaties nog steeds als mini-VM's kunt behandelen, maar dan ook nog een stap verder kunt gaan en ze daadwerkelijk als microservices kunt behandelen. Het stelt je in staat om beide te doen.

Ik zou zeggen dat de grootste stap tussen Docker en Kubernetes was dat Docker draaide om de ervaring van ontwikkelaars. Het loste dat deel op, maar loste het deel van het openbare cloud-ecosysteem niet op. Het had of wilde geen nauwe integratie met de cloudproviders. Kubernetes heeft dat opgelost. 

Wie zie je binnen bedrijven Kubernetes runnen? Zijn het individuele sollicitatieteams?

Er is een interessante verschuiving opgetreden met cloud native, namelijk dat we de opkomst hebben van het 'platformteam', ik noem het. Het zijn geen applicatie-ingenieurs. Ze hebben een beetje kennis van netwerkoperaties en ze hebben behoorlijk wat kennis van beveiliging. Ze hebben SRE-kennis en weten hoe ze aan cloudautomatisering moeten doen. Ze bieden het platform voor applicatieteams en behandelen die applicatieteams als hun klanten.

Platformteams zijn degenen die Kubernetes en gerelateerde technologieën kopen, die ze gebruiken omdat ze de volgende generatie infrastructuur moeten leveren om moderne app-teams gelukkig te maken.

Ik denk dat er zeker ruimte is voor serverless, met name voor zeer snelle applicatie-ontwikkeling. Maar in ondernemingen zien we cloud-native als de nieuwe laag bovenop virtualisatie

Is dat een netto-nieuwe koper of een netto-nieuw team? Of zijn platformteams als iets dat bestaat binnen plaatsen zoals Google of Facebook en nu mainstream wordt?

Ze zijn meestal een nieuw team. Ik denk dat ze tot op zekere hoogte lijken op de SRE-teams bij Google en Facebook. De applicatieteams zijn echter waarschijnlijk meer eigenaar van de app-implementatie in bedrijven, omdat bedrijven dit zeer duidelijke onderscheid niet hebben tussen software-engineers en SRE's zoals Google en Facebook. Ik zou zeggen dat deze evolutie erg lijkt op hoe je virtualisatieteams had, en toen veel netwerkoperaties gemigreerd van - of geëvolueerd of geavanceerd van - over netwerk hardware om over netwerk te gaan virtualisatie. En deze teams gingen bijvoorbeeld aan de slag met VMware NSX. Hier gebeurt hetzelfde. 

Hoewel, het is niet per se een nieuw budget. We zien budgetten verschuiven van bijvoorbeeld beveiliging en netwerken naar dit platformteam, omdat de clouduitgaven toenemen en er minder wordt uitgegeven aan netwerkhardware. Ze werken vaak samen met het beveiligingsteam en met het netwerkops-team om buy-in te krijgen, maar ze bezitten in feite een behoorlijk aanzienlijk deel van het budget.

Hoe zie je de Stichting Cloud Native Computing evolueert, en zal Kubernetes er altijd in het middelpunt van staan ​​- of van de cloud-native beweging in het algemeen?

Kubernetes is de aanleiding voor de CNCF, en in de eerste paar jaar draaide het allemaal om Kubernetes en de publieke cloud. Wat we ongeveer een jaar geleden hebben gezien, is dat het nu niet langer alleen om Kubernetes gaat, het gaat eigenlijk meer om cloud-native principes. Dit betekent eigenlijk dat het ook niet meer per se cloud is, zelfs geen private cloud. Het zijn vaak zelfs traditionele bedrijfsnetwerken, saaie on-premises infrastructuur, bare-metal servers en dat alles, maar dan met ingebouwde cloud-native principes. 

De nieuwe norm is nu hybride en omvat meerdere openbare cloudproviders, evenals on-premises infrastructuur. Bedrijven willen dezelfde wendbaarheid voor applicatieontwikkelaars bieden, of waarneembaarheid bieden met moderne cloud-native tools, of beveiliging doen met moderne cloud-native tools - bijvoorbeeld authenticatie, in plaats van alleen segmentatie of identiteitsgebaseerde handhaving - al die nieuwe cloud-native concepten op bestaande infrastructuur. 

We zien een zeer sterke vraag om nog steeds verbinding te maken met de oude wereld en te praten over MPLS, VLAN, sFlow en NetFlow - de hele bestaande reeks zakelijke vereisten. Geen van hen is weggegaan.

Ongeveer een decennium later lijkt de cloud-native ruimte geen modegril te zijn. Hoeveel ruimte is er om verder te evolueren?

Er was absoluut een tijd waarin het was als: "Oh, Kubernetes is waarschijnlijk van korte duur en serverloos wordt de volgende laag." Of: “Kubernetes is vergelijkbaar met OpenStack. Of: "Het zal verdwijnen en het wordt een implementatiedetail." En dat is niet gebeurd. 

Ik denk dat er zeker ruimte is voor serverless, met name voor zeer snelle applicatie-ontwikkeling. Maar in ondernemingen zien we cloud-native als de nieuwe laag bovenop virtualisatie, en we denken dat het een vergelijkbare houdbaarheid heeft als virtualisatie. Dat betekent dat we helemaal aan het begin staan ​​van de cloud-native migratie.

Welke grote problemen moeten er nog worden opgelost op infrastructuurniveau?

We zien ondernemingen in een situatie waarin ze plotseling, of ze het nu willen of niet, een multi-cloudstrategie nodig hebben. Omdat ze ook een on-premise infrastructuur hebben, hebben ze daar nu een hybride cloudstrategie voor nodig. En ze moeten uitzoeken hoe ze beveiliging en andere functies universeel kunnen uitvoeren in deze infrastructuur zonder zichzelf op te sluiten in een bepaalde openbare cloud. 

Dus dit is de volgende grote uitdaging: wie wordt die agnostische laag voor multi-cloud en cloud-native, zoals wat VMware werd? Wie wordt de VMware voor cloud-native?

Ik denk dat het besef is begonnen dat als je moderne applicatieteams wilt aantrekken en snel naar de markt wilt, je ze een cloud-native infrastructuur moet bieden.

En hoewel de acceptatie van cloud-natives relatief eenvoudig was voor de moderne webbedrijven die early adopters waren, is de uitdaging vanuit uw perspectief het bouwen van nieuwe technologieën die de kloof overbruggen tussen deze moderne wereld en bestaande bedrijfstools en -systemen?

Het moeilijke is dat moderne app-teams eraan gewend zijn dat de infrastructuurlaag net zo snel evolueert als zij. En dit dwong de infrastructuurlaag om nog meer programmeerbaar, meer aanpasbaar te zijn. Daarom zien we eigenlijk een netwerklaag en een beveiligingslaag bovenop de cloudnetwerklaag. Maar nu hebben we bedrijven die binnenkomen en we zien een zeer sterke vraag om nog steeds verbinding te maken met de oude wereld en te praten over MPLS, VLAN, sFlow en NetFlow - de hele bestaande reeks zakelijke vereisten. Geen van hen is verdwenen, alle nalevingsregels zijn nog steeds hetzelfde. En zelfs sommige moderne SaaS-bedrijven worden nu geconfronteerd met deze uitdagingen naarmate ze groter worden en ze zich bekommeren om naleving enzovoort. 

Vanuit technologisch perspectief gaat het erom hoe je die nieuwe cloud-native wereld kunt verbinden met de bestaande bedrijfsvereisten. Want veel van deze problemen werden verborgen door de public cloud providers. Publieke cloudproviders hebben de complianceproblemen opgelost, maar ze hebben de broncode niet geopend of gepubliceerd; dat hebben ze zelf opgelost. Het maakt deel uit van de cloudwaarde. Bedrijven moeten dat nu opnieuw opbouwen en kopen als ze zichzelf niet willen opsluiten in het openbare cloudaanbod.

Waar zie je de volgende golf van cloud-native innovatie vandaan komen? Komt het nog steeds van een bedrijf als Google, of is er een nieuw type bedrijf dat de leiding heeft?

Het is zeer interessant. Ik zou zeggen dat het waarschijnlijk niet van de Googles en de Facebooks komt. De bron van innovatie zal open source zijn, en de klanten en gebruikers die de vraag aansturen, zullen bedrijven zijn die een niveau lager liggen dan de hyperscalers - al omvangrijke bedrijven die nog steeds zeer ontwrichtend zijn, zoals Adobe, Shopify of GitHub. Maar ook bedrijven die het risico lopen te worden verstoord door technologie, zoals financiële diensten, verzekeraars en telco's. Deze bedrijven hebben allemaal een gedeeld belang bij het standaardiseren van infrastructuur met herhaalbare ontwikkelings- en infrastructuurmodellen.

Geplaatst op 26 juli 2022