Kubernetes, Networking und die VMware von Cloud Native finden

Thomas Graf ist Mitgründer und CTO von Isovalent, und Schöpfer einer beliebten Open-Source- (und Cloud-nativen) Netzwerktechnologie namens Wimper. Cilium basiert auf einer Kernel-Level-Linux-Technologie namens eGMP.

In diesem Interview erörtert Graf die Rollen, die Cilium und eBPF im wachsenden Cloud-nativen Netzwerk-Ökosystem spielen, sowie einige breitere Trends rund um die Einführung und Entwicklung von Kubernetes. Er erklärt, wer Kubernetes in großen Unternehmen einsetzt und kauft, wo die Cloud-native Infrastruktur noch verbessert werden muss und wie der Wunsch nach Standardisierung Innovationen vorantreibt.

---

ZUKUNFT: Wie sollten wir über eBPF und Cilium im Kontext von Computern und Netzwerken im Allgemeinen und dann speziell im Kontext von denken? Cloud-natives Ökosystem?

THOMAS GRAF: Insgesamt ist eBPF die Technologie, und sie ist extrem niedrig. Es wurde für Kernel-Entwickler entworfen, und mein Hintergrund liegt in der Kernel-Entwicklung. eBPF ist für den Kernel, für das Betriebssystem, was JavaScript für einen Browser ist. Es macht das Betriebssystem programmierbar, genau wie JavaScript den Browser programmierbar macht. In der Vergangenheit mussten wir unsere Browserversionen aktualisieren, um bestimmte Websites tatsächlich nutzen zu können. Und dann kam JavaScript, und plötzlich konnten Anwendungsteams und Entwickler riesige Anwendungen erstellen – bis zu dem Punkt, an dem die beliebteste Textverarbeitungsanwendung durch eine In-Browser-Anwendung ersetzt wurde. Dies führte zu einer großen Innovationswelle. 

Dasselbe passiert mit eBPF, allerdings auf Betriebssystemebene, weil wir plötzlich Dinge auf Kernel- oder Betriebssystemebene tun können, wo wir alles sehen und alles kontrollieren können – was für die Sicherheit sehr wichtig ist – ohne den Kernel ändern zu müssen Quellcode. Wir können im Wesentlichen Programme in den Kernel laden, um seine Funktionalität zu erweitern und neue Fähigkeiten mitzubringen. Dies hat auch eine massive Innovationswelle ausgelöst. Hyperscaler wie Facebook, Google und Netflix nutzen dies selbst und direkt mit ihren eigenen Kernel-Teams. 

Was Cilium auf den Tisch bringt, ist, dass es diese Low-Level-eBPF-Technologie verwendet, um im Wesentlichen eine neue Welle von Softwareinfrastruktur bereitzustellen, insbesondere für die Cloud-Native-Welle. Stellen Sie sich das wie softwaredefinierte Netzwerke vor und was Nicira, das zu VMware NSX wurde, für die Virtualisierungsbranche getan hat. Das Gleiche tun wir für Cloud Native, bei der es sich um eine Mischung aus Cloud-Anbieter oder öffentlicher Cloud-Infrastruktur sowie lokaler Infrastruktur handelt. Und damit lösen wir Anwendungsfälle für Netzwerke, Sicherheit und Beobachtbarkeit auf der Infrastrukturebene.

Und das gerade veröffentlichte Cilium Service Mesh ist eine Weiterentwicklung dieser Fähigkeiten?

Was derzeit passiert, seit etwa einem Jahr, ist, dass die beiden Räume kollidieren. Was Cilium bisher gemacht hat, konzentriert sich auf Netzwerke, virtualisierte Netzwerke und dann Cloud-native Netzwerke – aber immer noch Netzwerke. Aber dann, von oben nach unten, haben sich die Anwendungsteams von Twitter und Google daran gemacht Service-Mesh Sachen – zuerst in der Anwendung und dann das Sidecar-basierte Modell, das Proxy-basierte Modell, das Projekte mögen Istio liefern. Und jetzt kommen sich diese beiden Schichten näher, weil Traditionelle Unternehmen kommen in die Cloud-native Welt und haben Anforderungen an Unternehmensnetzwerke, aber ihre App-Teams wollen auch ein Service-Mesh. 

Gartner nennt diese neue Ebene „Service-Konnektivität“ – wir werden sehen, ob sich dieser Begriff durchsetzt – aber es ist im Wesentlichen eine Ebene, die das Enterprise-Networking-Element und das Service-Mesh-Element umfasst, das von den Anwendungsteams kommt. Und weil die Kunden dies fordern, haben wir die Funktionen in Cilium selbst integriert. Im Wesentlichen geht Cilium also von der Seite des Unternehmensnetzwerks nach oben und die Servicenetze gehen nach unten in mehr Richtung der Netzwerkseite.

Warum liegt der Fokus so sehr auf der Netzwerk- und Service-Mesh-Ebene des Kubernetes-Stacks?

Denn mit dem Wunsch, in mehreren Clouds zu laufen und Anwendungen in Container aufzuteilen, ist die Konnektivitätsschicht zentral geworden. Was früher vielleicht die Kommunikation zwischen Prozessen und Middleware war, ist jetzt das Netzwerk, also wird das Netzwerk immer wichtiger, damit Anwendungen miteinander kommunizieren und Daten fließen können. 

Und insbesondere bei Cloud-nativen Multi-Cloud wird unabdingbar. Alle Cloud-Anbieter haben ihre eigenen Netzwerkschichten, aber natürlich auf ihre eigenen Clouds zugeschnitten. Sie haben On-Prem-Angebote, aber sie sind nicht wirklich Multi-Cloud. Cilium und eBPF bringen diese agnostische Multi-Cloud-Schicht auf den Tisch. Es verhält sich lokal genauso wie in der Public Cloud. Mehrere der Public-Cloud-Anbieter verwenden Cilium im Hintergrund für ihre verwalteten Kubernetes-Angebote, und Telekommunikationsunternehmen verwenden es für die lokale 5G-Infrastruktur. Es geht darum, beide Sprachen zu sprechen und diese Welten miteinander zu verbinden.

Aus diesem Grund wird darauf so viel Wert gelegt: Denn eine der einfachsten Möglichkeiten für Cloud-Anbieter, Kunden an sich zu binden, besteht darin, diese Konnektivitätsebene zu besitzen. Ich denke, aus strategischer Infrastrukturperspektive ist, so wie die Virtualisierungsebene der Schlüssel war, jetzt die Konnektivitäts- und Netzwerkebene absolut entscheidend.

Die Quelle [zukünftiger] Innovationen wird Open Source sein, und die Kunden und Benutzer, die die Nachfrage antreiben, werden Unternehmen sein, die eine Stufe unter den Hyperscalern liegen – bereits beträchtliche Unternehmen, die immer noch sehr disruptiv sind.

Kubernetes ist zu diesem Zeitpunkt ziemlich weit verbreitet und angenommen, aber in einigen Kreisen wird immer noch davon gesprochen, dass es übertrieben sei. Für wen ist Kubernetes und das Cloud-native Ökosystem insgesamt geeignet?

Es ist für moderne Anwendungsteams. Ich denke, die Erkenntnis hat eingesetzt, dass Sie, wenn Sie moderne Anwendungsteams anziehen und schnelle Markteinführungszeiten haben wollen, ihnen eine Cloud-native Infrastruktur bereitstellen müssen. Wir sehen oft Prototyping – anfänglich, vor dem MVP, sogar zur Erprobung des Konzepts oder zum internen Verkauf – auf Serverless, so etwas wie Lambda. Und dann auf Kubernetes, weil die App-Teams die Infrastruktur direkt besitzen können. Und dann, wenn es in die Produktion übergeht, gehen sie zu Enterprise-On-Prem-Kubernetes-Distributionen. Aber das ist eigentlich ein relativ kleiner Teil der gesamten Infrastruktur, vielleicht ein ein- oder niedriger zweistelliger Prozentsatz. 

Es wird jedoch eindeutig der neue Standard sein. So wie die Einführung der Virtualisierung anfangs sehr langsam war und die Leute sagten, sie sei übertrieben – aber im Laufe der Zeit begann sie natürlich, die meisten Dinge zu ersetzen – werden wir hier dasselbe sehen. Oder wie bei modernen Sprachen. Die Leute sagten, Java sei übertrieben, und das ist es wahrscheinlich immer noch für viele Anwendungen, aber es gab eine Zeit, in der es sehr schwierig wurde, Anwendungen außerhalb von Java zu entwickeln, weil die Mehrheit der Anwendungsentwickler darin schreiben konnte. Das gleiche wird gilt für moderne Anwendungsteams: Sie werden erwarten, Kubernetes zu haben, um agiler zu entwickeln und das Produkt schnell auf den Markt zu bringen.

Auf der Infrastrukturseite mag es ein bisschen übertrieben sein, aber wenn die Alternative darin besteht, eine Anwendung von serverlos auf lokal umzuschreiben, ist das eine gewaltige Aufgabe. Kubernetes ist dort also der Mittelweg, was sehr attraktiv ist. 

Was ist mit der Idee, dass Kubernetes noch eine bessere Entwicklererfahrung benötigt?

Wenn wir uns das ursprüngliche OpenShift ansehen, bevor es auf Kubernetes umgestellt wurde, war es dies. Es war noch näher am Anwendungsteam und war eine noch bessere Erfahrung für Anwendungsentwickler. Sie könnten auf Git pushen und es würde automatisch bereitgestellt. Heroku hat das auch versucht, aber SaaS-basiert. 

Kubernetes trat einen Schritt zurück und sagte: „Wir müssen einige betriebliche Aspekte beibehalten und es auch ein bisschen näher an das heranführen, was ein Systemadministrator erwarten würde. Wir können nicht nur auf Anwendungen zugeschnitten sein.“ Es ist der Mittelweg: Es muss genug Attraktivität für Anwendungsteams haben, aber es muss immer noch möglich sein, diese Anwendung außerhalb einer bestimmten Umgebung auszuführen und sie von anderen Personen als Anwendungsentwicklern verwalten zu lassen.

Ich würde sagen, der größte Schritt zwischen Docker und Kubernetes war, dass es bei Docker ausschließlich um Entwicklererfahrung ging. Es hat diesen Teil gelöst, aber nicht den Teil des Public-Cloud-Ökosystems.

Wie sind wir an diesen Punkt gekommen? War dies die natürliche Entwicklung von Platform-as-a-Service (PaaS) und Anwendungscontainern?

Es waren Docker-Images und der Verpackungsaspekt von Docker. Die alte Schule war die Bereitstellung in virtuellen Maschinen, und es gab alle Arten von Automatisierung darum herum. Und dann war da noch das, was Facebook mit Tupperware machte – sehr maßgeschneidert und für wirklich großen Maßstab. Und dann kam Docker und stellte im Wesentlichen dieses Container-Image bereit, und jeder konnte es wie eine Miniatur-VM behandeln. Ich kann meine App jetzt verteilen und anstelle eines virtuellen 600-MB-Images ist es jetzt ein 10-MB-Container. Aber man kann es genauso behandeln, es hat alles was es braucht. 

Dadurch wurde die Möglichkeit freigeschaltet, einen Orchestrator wie Kubernetes einzuführen, der es Ihnen immer noch ermöglicht, Anwendungen wie Mini-VMs zu behandeln, aber dann auch einen Schritt weiter zu gehen und sie tatsächlich als Microservices zu behandeln. Es erlaubt Ihnen, beides zu tun.

Ich würde sagen, der größte Schritt zwischen Docker und Kubernetes war, dass es bei Docker ausschließlich um Entwicklererfahrung ging. Es hat diesen Teil gelöst, aber nicht den Teil des Public-Cloud-Ökosystems. Es hatte keine enge Integration mit den Cloud-Anbietern oder wollte dies unbedingt. Kubernetes hat das gelöst. 

Wen sehen Sie in Unternehmen, der Kubernetes betreibt? Sind es einzelne Bewerbungsteams?

Bei Cloud Native hat sich eine interessante Veränderung vollzogen, nämlich der Aufstieg des „Plattformteams“, ich nenne es mal. Sie sind keine Anwendungstechniker. Sie haben ein bisschen Netzwerkbetriebswissen und sie haben ziemlich viel Sicherheitswissen. Sie verfügen über SRE-Kenntnisse und wissen, wie man Cloud-Automatisierung durchführt. Sie stellen die Plattform für Anwendungsteams bereit und behandeln diese Anwendungsteams als ihre Kunden.

Plattformteams sind diejenigen, die Kubernetes und verwandte Technologien kaufen, die sie verwenden, weil sie die Aufgabe haben, diese Infrastruktur der nächsten Generation bereitzustellen, um moderne App-Teams glücklich zu machen.

Ich denke, es gibt definitiv Raum für Serverless, insbesondere für die sehr schnelle Anwendungsentwicklung. Aber in Unternehmen sehen wir Cloud Native als die neue Ebene über der Virtualisierung

Ist das ein neuer Einkäufer oder ein neues Team? Oder sind Plattformteams wie etwas, das innerhalb von Orten wie Google oder Facebook existiert und jetzt zum Mainstream wird?

Sie sind meistens ein neues Team. Ich denke, sie sind in gewisser Weise wie die SRE-Teams bei Google und Facebook. Allerdings sind die Anwendungsteams wahrscheinlich eher für die App-Bereitstellung in Unternehmen verantwortlich, da Unternehmen diese sehr klare Unterscheidung zwischen Softwareentwicklern und SREs wie Google und Facebook nicht haben. Ich würde sagen, diese Entwicklung ist der Art und Weise sehr ähnlich, wie Sie Virtualisierungsteams hatten und dann viele Netzwerkoperationen von Netzwerken migrierten – oder sich weiterentwickelten oder weiterentwickelten Hardware um Netzwerk zu sein Virtualisierung. Und diese Teams haben zum Beispiel begonnen, VMware NSX zu betreiben. Dasselbe passiert hier. 

Obwohl es nicht unbedingt ein neues Budget ist. Wir sehen beispielsweise eine Verlagerung von Budgets von Sicherheit und Netzwerk zu diesem Plattformteam, da die Cloud-Ausgaben steigen und weniger für Netzwerkhardware ausgegeben wird. Sie arbeiten oft mit dem Sicherheitsteam und dem Netzwerkbetriebsteam zusammen, um Unterstützung zu erhalten, aber sie besitzen tatsächlich einen ziemlich großen Teil des Budgets.

Wie siehst du das? Cloud Native Computing Foundation entwickelt sich weiter, und wird Kubernetes immer im Mittelpunkt stehen – oder der Cloud-nativen Bewegung insgesamt?

Kubernetes hat die CNCF ausgelöst, und in den ersten Jahren drehte sich alles um Kubernetes und Public Cloud. Was wir seit etwa einem Jahr sehen, ist, dass es jetzt nicht mehr nur um Kubernetes geht, sondern eher um Cloud Native Grundsätze. Das bedeutet eigentlich, dass es auch nicht mehr unbedingt eine Cloud ist, nicht einmal eine private Cloud. Es sind oft sogar traditionelle Unternehmensnetzwerke, langweilige lokale Infrastrukturen, Bare-Metal-Server und all das, aber mit integrierten Cloud-nativen Prinzipien. 

Die neue Norm ist jetzt hybrid und umfasst mehrere öffentliche Cloud-Anbieter sowie lokale Infrastrukturen. Unternehmen möchten die gleiche Agilität für Anwendungsentwickler bieten oder Beobachtbarkeit mit modernen Cloud-nativen Tools bereitstellen oder Sicherheit mit modernen Cloud-nativen Tools – zum Beispiel Authentifizierung statt nur Segmentierung oder identitätsbasierte Durchsetzung – all diese neuen Cloud-nativen Konzepte bieten vorhandene Infrastruktur. 

Wir sehen eine sehr starke Nachfrage, sich weiterhin mit der alten Welt zu verbinden und über MPLS, VLAN, sFlow und NetFlow zu sprechen – die gesamten bestehenden Unternehmensanforderungen. Keiner von ihnen ist weggegangen.

Nach etwa einem Jahrzehnt scheint der native Cloud-Bereich keine Modeerscheinung zu sein. Wie viel Raum gibt es, um sich weiterzuentwickeln?

Es gab definitiv eine Zeit, in der es hieß: „Oh, Kubernetes ist wahrscheinlich nur von kurzer Dauer, und Serverless wird die nächste Schicht sein.“ Oder: „Kubernetes ähnelt OpenStack. Oder: „Es wird verschwinden und wird ein Implementierungsdetail sein.“ Und das ist nicht geschehen. 

Ich denke, es gibt definitiv Raum für Serverless, insbesondere für die sehr schnelle Anwendungsentwicklung. Aber in Unternehmen sehen wir Cloud Native als die neue Ebene über der Virtualisierung, und wir glauben, dass sie eine ähnliche Haltbarkeit wie die Virtualisierung hat. Das heißt, wir stehen ganz am Anfang der Cloud-nativen Migration.

Welche großen Probleme müssen auf Infrastrukturebene noch gelöst werden?

Wir sehen Unternehmen in einer Situation, in der sie plötzlich, ob sie wollen oder nicht, eine Multi-Cloud-Strategie brauchen. Da sie auch über eine On-Premise-Infrastruktur verfügen, benötigen sie jetzt zusätzlich eine Hybrid-Cloud-Strategie. Und sie müssen herausfinden, wie Sicherheits- und andere Funktionen universell in dieser Infrastruktur ausgeführt werden können, ohne sich an eine bestimmte öffentliche Cloud zu binden. 

Das ist also die nächste große Herausforderung: Wer wird diese agnostische Ebene für Multi-Cloud und Cloud-Native sein, wie sie aus VMware geworden ist? Wer wird VMware für Cloud Native sein?

Ich denke, die Erkenntnis hat eingesetzt, dass Sie, wenn Sie moderne Anwendungsteams anziehen und schnelle Markteinführungszeiten haben wollen, ihnen eine Cloud-native Infrastruktur bereitstellen müssen.

Und obwohl die Cloud-native Einführung für die modernen Webunternehmen, die Early Adopters waren, relativ einfach gewesen sein mag, besteht die Herausforderung aus Ihrer Sicht darin, neue Technologien zu entwickeln, die die Lücke zwischen dieser modernen Welt und bestehenden Unternehmenstools und -systemen schließen?

Der schwierige Teil ist, dass moderne App-Teams daran gewöhnt sind, dass sich die Infrastrukturschicht so schnell entwickelt wie sie. Und dies zwang die Infrastrukturschicht dazu, noch programmierbarer und anpassbarer zu sein. Aus diesem Grund sehen wir tatsächlich eine Netzwerkschicht und eine Sicherheitsschicht über der Cloud-Netzwerkschicht. Aber jetzt kommen Unternehmen hinzu, und wir sehen eine sehr starke Nachfrage, sich weiterhin mit der alten Welt zu verbinden und über MPLS, VLAN, sFlow und NetFlow zu sprechen – die gesamte bestehende Reihe von Unternehmensanforderungen. Keiner von ihnen ist verschwunden, alle Compliance-Regeln sind immer noch dieselben. Und Selbst einige der modernen SaaS-Unternehmen stehen diesen Herausforderungen gegenüber, wenn sie größer werden und sich um die Einhaltung von Vorschriften kümmern und so weiter. 

Aus technologischer Sicht geht es darum, diese neue Cloud-native Welt mit den bestehenden Unternehmensanforderungen zu verbinden. Denn viele dieser Probleme wurden von den Public-Cloud-Anbietern ausgeblendet. Public-Cloud-Anbieter haben die Compliance-Probleme gelöst, aber sie haben nichts davon als Open Source veröffentlicht oder veröffentlicht; das haben sie alleine gelöst. Es ist Teil des Cloud-Werts. Unternehmen müssen das jetzt neu aufbauen und kaufen, wenn sie sich nicht an die öffentlichen Cloud-Angebote binden wollen.

Woher sehen Sie die nächste Welle von Cloud-nativen Innovationen? Kommt es immer noch von einem Unternehmen wie Google oder gibt es eine neue Art von Unternehmen, die die Anklage führt?

Es ist sehr interessant. Ich würde sagen, es kommt wahrscheinlich nicht von den Googles und den Facebooks. Die Quelle der Innovation wird Open Source sein, und die Kunden und Benutzer, die die Nachfrage antreiben, werden Unternehmen sein, die eine Stufe unter den Hyperscalern liegen – bereits große Unternehmen, die immer noch sehr disruptiv sind, wie Adobe, Shopify oder GitHub. Aber auch Unternehmen, die Gefahr laufen, durch Technologie gestört zu werden, wie Finanzdienstleister, Versicherungsanbieter und Telekommunikationsanbieter. Diese Unternehmen haben alle ein gemeinsames Interesse an der Standardisierung der Infrastruktur mit wiederholbaren Entwicklungs- und Infrastrukturmodellen.

Veröffentlicht am 26. Juli 2022