Die KubeCon / CloudNativeCon EU 2024 in Paris ist gerade zu Ende gegangen, und es war einfach phänomenal. Neben dem Hauptevent gab es einige herausragende spezifische Konferenzen wie ArgoCon, BackstageCon und Cilium + eBPF Day, um nur einige zu nennen. Mit über 300 Vorträgen auf den Hauptkonferenztracks gibt es viel nachzuholen oder wiederzuentdecken, und das kannst du genau hier auf YouTube machen. Mehr als 12.000 Leute haben live mit uns in der Paris Expo Porte de Versailles teilgenommen, was es zu einem wirklich tollen Erlebnis gemacht hat.

„Warum sollte man die KubeCon besuchen, wenn man ein SaaS oder eine WebApp entwickelt?“, fragst du dich vielleicht. Die Grenze zwischen Entwicklung und Betrieb verschwindet seit Jahren, und je kleiner dein Team ist, desto wichtiger wird es für Entwickler:innen, die Betriebsseite der Dinge zu verstehen. Aber selbst wenn dein Unternehmen groß genug ist, um dedizierte Entwicklungs- und Betriebsteams zu haben, ist es an der Zeit, DevOps zu erkunden. Dieser Ansatz hilft dabei, eure Arbeitsabläufe und Werkzeuge zu optimieren und eure Teams umzustrukturieren, um Zeit und Geld zu sparen und gleichzeitig die Agilität zu erhöhen. Die alte Mentalität des „Über-den-Zaun-Werfens“ zwischen Entwicklungs- und Betriebsteams sollte der Vergangenheit angehören.

In diesem Blogpost möchte ich nicht darauf eingehen, warum Containerisierung, Kubernetes und das Cloud-Native-Ökosystem entscheidend für eure SaaS- oder Cloud-Anwendung sind. Stattdessen möchte ich den aktuellen Stand der Dinge diskutieren und wohin die Reise im Cloud-Native-Landschaft gehen könnte. Meine Einblicke basieren auf meiner Erfahrung, Vorträgen von der KubeCon sowie Gesprächen mit verschiedenen Projekten und Teams.

Status Quo - Kubernetes für alle

Nach 10 Jahren Kubernetes und einer Verbreitung in verschiedenen Branchen und Unternehmen jeder Größe ist klar: Es ist gekommen um zu bleiben. Ursprünglich für große Systeme (1000+ Server, 10k+ Pods/Container) entwickelt, erfordert Kubernetes ein komplexes Systemmanagement, das anfangs für kleinere Systeme oder Startups wie Overkill wirkte. Doch seine Vielseitigkeit und Skalierbarkeit haben sich mittlerweile als unschätzbar wertvoll für Organisationen unabhängig von ihrer Größe erwiesen.

Ich denke, wir befinden uns an einem Punkt, an dem Kubernetes-Distributionen unkompliziert einzurichten und zu warten sind, was ihre inhärente Komplexität erheblich mildert. Das Ökosystem an Werkzeugen rund um Kubernetes hat sich ebenfalls deutlich weiterentwickelt und bietet nun ein robustes und gutes Entwicklererlebnis.

Für diejenigen unter euch, die eine SaaS- oder Webanwendung entwickeln, unabhängig davon, ob ihr mit einer Microservice-Architektur startet oder nicht, kann der Beginn der Reise auf einem Kubernetes-System ein reibungsloses Skalieren ermöglichen, ohne bedeutende Änderungen an Prozessen oder Werkzeugen zu erfordern, während euer Team und Unternehmen wachsen.

Noch vor ein paar Jahren hätte ich diese Empfehlung nicht an kleinere Teams oder Einzelunternehmer:innen gegeben. Heute jedoch sind die Vorteile der Einführung von Kubernetes, selbst gegenüber einfachen Docker- oder Docker-Compose-Setups, zu bedeutend, um sie zu ignorieren.

Man kann mit einem Einzel-Node-Cluster starten. Es handelt sich dabei nicht um eine Hochverfügbarkeitslösung, aber man erhaltet dennoch Deployments ohne Ausfallzeiten, Lastverteilung, Rollbacks sowie Konfigurations- und Secretverwaltung – und all das mit kaum mehr Aufwand als beim Ausführen von Docker Compose. Das Schöne daran ist, dass man dieselben Prinzipien später auf einen Multi-Node-Cluster mit hoher Verfügbarkeit anwenden könnt. Ich behaupte nicht, dass Kubernetes für jeden Anwendungsfall geeignet ist – ich denke, für das Hosting eines privaten WordPress-Blogs braucht man es wahrscheinlich nicht (obwohl man würde zumindest eine Menge daraus lernen, auch wenn es technischer Overkill ist).

Um ehrlich zu sein, das Einrichten eines kleinen Clusters ist heutzutage keine Raketenwissenschaft mehr, aber man muss trotzdem lernen, wie man mit Kubernetes arbeitet. Angesichts der leistungsstarken Features – wie Self-healing, Lastverteilung, Hochverfügbarkeit und Deployments ohne Ausfallzeiten – muss man zuerst die Herausforderungen verstehen, die diese Funktionen adressieren, bevor man die Möglichkeiten, die Kubernetes bietet, vollständig verinnerlichen kann.

Die eigentliche Herausforderung bei Kubernetes und dem gesamten Cloud-Native-Ökosystem liegt darin, zu entscheiden, welche Features und Werkzeuge wirklich vorteilhaft für die aktuelle Phase des Teams, des Unternehmens oder des Produkts sind.

Die Zukunft - LLM/KI, WebAssembly, Sicherheit

Der Status quo nach 10 Jahren Kubernetes ist bereits beeindruckend, aber die KubeCon hat auch addressiert wohin sich Kubernetes und das Cloud Native Ökosystem als Nächstes entwickeln möchte. Hier sind einige Schlüsselerkenntnisse von der Konferenz:

KI und LLMs

Wie man vielleicht vermutet hat, waren AI (Artificial Intelligence) und LLMs (Large Language Models) Teil des KubeCon Programms. Allerdings deutet das Feedback des Publikums während einer Keynote von Priyanka Sharma, der Geschäftsführerin der CNCF, auf die Frage , wie viele Organisationen derzeit Prototypen für KI-gestützte Funktionen entwickeln, darauf hin, dass KI (künstliche Intelligenz) Themen noch nicht zum festen Bestandteil unter DevOps- und Betriebsteams im Kubernetes-Ökosystem geworden sind.

Das überrascht mich nicht, da viele Unternehmen auch nach 10 Jahren Kubernetes sich noch mitten in der Umstellung auf Container und Kubernetes befinden oder gerade erst damit beginnen. Das auf der KubeCon ein Großteil der Teilnehmenden, gefühlt schon seit 10 Jahren Kubernetes als fixen Bestandteil der IT Infrastrukur sieht, spiegelt eben nicht die Realität für viele Unternehmen wider. Zudem sind LLMs, unabhängig vom Status ihrer Kubernetes-Migration, noch kein Standardteil der internen Infrastruktur der meisten Unternehmen, sondern finden sich häufiger in F&E-Teams als Proof of Concepts (POCs).

Ich glaube jedoch auch, dass Unternehmen, die darauf abzielen, ihre eigenen LLMs zu hosten, zu nutzen oder zu trainieren, statt APIs von externen LLM-Anbietern wie OpenAI zu nutzen, Kubernetes letztendlich als unverzichtbar für die Bereitstellung der notwendigen Infrastruktur ansehen werden. Diese Infrastruktur muss in der Lage sein, den Anforderungen des Skalierens, des dynamischen Managements der Rechenleistung und der Unterstützung lang laufender Trainingstasks für ihre LLM-Anwendungsfälle gerecht zu werden.

Die CNCF hat KI/LLMs stark in den Vordergrund gestellt und ihnen einen eigenen Track auf der KubeCon gewidmet. Obwohl Kubernetes eine solide und bewährte Wahl für Nicht-KI-Workloads ist, von einfachen Web-Apps bis hin zum Hosting von Diensten wie Google Docs in globalem Maßstab, befinden wir uns immer noch in einem frühen Stadium der Entwicklung von Werkzeugen und Unterstützung für die spezifischen Anforderungen des effizienten Trainierens und Hostens von LLMs.

Neben der Beherrschung der technischen Voraussetzungen müssen DevOps-Teams anfangen, eng mit Data-Science-Teams zusammenzuarbeiten, um die spezifischen Bedürfnisse und Arbeitsabläufe, die mit der Entwicklung, dem Training und dem Hosting von LLMs verbunden sind, zu verstehen. Diese Zusammenarbeit muss sicherstellen, dass die Infrastruktur und Prozesse optimal auf eine „Data-Science-Experience“ ausgerichtet sind. Nur dann kann man mit agilen Arbeitsmethoden ein effizientes Hosting von LLM-Workloads erreichen. Kubernetes ist dabei, die technische Grundlage für generative KI zu legen, aber die Erkenntnis, dass DevOps und Betrieb eine entscheidende Rolle bei der effizienten Entwicklung und dem Hosting von LLMs spielen, ist noch nicht vollständig bei vielen verinnerlicht.

Was die technische Grundlage betrifft, so stellt die DRA-API (Dynamic Resource Allocation), die sich derzeit in der Alpha-Phase befindet, einen signifikanten Fortschritt dar. Sie kommt den Anforderungen der generativen KI entgegen, indem sie zB ausreichende GPU-Leistung sicherstellt und gleichzeitig die Dynamik des Gesamtsystems erhält.

WebAssembly

Ich bin ein großer Fan von WebAssembly, und das nicht nur für die Audiobearbeitung in Web-Apps über den Browser, sondern auch für seine Anwendungen auf dem Server und in "Serverless"-Umgebungen.

Um einen schnellen Überblick über WebAssembly zu geben: Es ist unglaublich vielseitig, dient aber im Kern als Kompilierungsziel für verschiedene Programmiersprachen. Diese können dann von WebAssembly-Laufzeitumgebungen ausgeführt werden, die ebenso in vielen verschiedenen Programmiersprachen verfügbar sind. Im Wesentlichen bedeutet das, dass man ein Programm innerhalb eines anderen laufen lassen kann, was eine hochkonfigurierbare und sichere Ausführungsumgebung mit klaren Kommunikationsmethoden zwischen dem Hostprogramm und dem WebAssembly-Programm bietet. Zudem ist die Ausführung sehr schnell, und hat praktisch keinen Overhead.

Klingt bekannt? Etwas in etwas anderem ausführen lassen? Das ist im Grunde das, was Docker und Kubernetes auch macht. Ein Container führt ein Programm isoliert vom Hostsystem aus. Wenn wir dieses Programm innerhalb des Containers zu WebAssembly kompilieren, können wir es dann in einer WebAssembly-Laufzeitumgebung ausführen, und brauchen keinen traditionellen Container mehr. Im Grunde könnten wir die Container-Laufzeitumgebung in Docker oder Kubernetes durch eine WebAssembly-Laufzeit ersetzen.

Was ist der Vorteil? Kurz gesagt: Deutlich weniger Overhead im Vergleich zu einer Container-Umgebung. Die ausführliche Erklärung: Besonders in server-less Architekturen, wo "Cold-Start"-Zeiten ein Flaschenhals sind – weil Benutzer nicht mehrere Sekunden warten wollen, bis eine Webanwendung reagiert –, ist die Dauer, die eine serverlose Funktion zur Verarbeitung benötigt, entscheidend. Traditionell würde ein Container, der die serverlose Funktion (Programm) hostet, hochgefahren, um eine HTTP-Anfrage vom Endbenutzer zu bearbeiten. Allein die Startzeit des Containers könnte einige hundert Millisekunden dauern; mit dem Programm, das die Anfrage verarbeitet, kann es schon mal 1-2 Sekunden dauern, um eine Antwort zu erhalten, was für eine Live-Benutzerinteraktion unzumutbar ist. Mit WebAssembly (WASM) als Laufzeit können wir die Startzeit auf bis zu 1 Millisekunde(!) reduzieren, was sie etwa 1000 Mal schneller macht als containerbasierte serverlose Systeme. Das eröffnet ganz neue Möglichkeiten und Anwendungsbereiche.

Die Werkzeuge rund um WebAssembly verbessern sich täglich, und mit SpinKube haben wir endlich eine Lösung, die die Implementierung von WebAssembly in einem Kubernetes-Cluster erheblich vereinfacht. Und die großartige Nachricht ist, dass SpinKube während der KubeCon in die CNCF Sandbox eingereicht wurde.

Sicherheit der Software-Lieferkette

Dies ist ein äußerst relevantes Thema, da die Angriffe ständig zunehmen und Unternehmen zum Handeln zwingen. Obwohl die Implementierung immer dringender wird, sind die beteiligten Tools und Arbeitsabläufe komplex, insbesondere wenn man bedenkt, dass jeder Schritt von der Softwareentwicklung bis zur Bereitstellung gesichert werden muss. Es gab viele aufschlussreiche Gespräche zu diesem Thema, und wir sehen eine wachsende Landschaft von Werkzeugen, die entwickelt wurden, um diese Herausforderungen zu bewältigen. Die Einrichtung und Implementierung dieser Werkzeuge sind stark spezifisch für die derzeit verwendeten DevOps-Arbeitsabläufe und -Werkzeuge, was die Entwicklung allgemeiner Richtlinien fördert, die kontinuierlich verfeinert werden. Zum Beispiel haben wir das SLSA Framework und die Best Practices für die Software-Lieferkette (v1) von der CNCF TAG Security. Eine neue Version der Best Practices für die Software-Lieferkette (v2) ist bereits in Arbeit.

Fazit

Es war eine fantastische Konferenz, die ich allen empfehlen kann, die das große Ganze des Betriebs moderner Cloud-Anwendungen und SaaS-Systeme verstehen möchte.

Wenn auch dein Unternehmen sich durch die komplexe Welt von Kubernetes navigieren und das richtige Werkzeug und die richtigen Trainings suchen, um die Effizienz zu maximieren, gerne mit uns in Kontakt treten, wir helfen euch gerne weiter.

Kontaktiere uns