Kubernetes löst nur die Hälfte des Problems der Anwendungsmodernisierung. Die nächste Etappe wird die Schließung der Lücke zwischen Kubernetes und Anwendungen sein. [...]
„Langweilig.“ Das ist eines der besten Komplimente, die man einer Infrastrukturtechnologie machen kann. Niemand will seine unternehmenskritischen Anwendungen „spicy!“ betreiben. Aber langweilig? Langweilig ist gut.
Langweilig bedeutet, dass eine Technologie ein gewisses Maß an Allgegenwart und Vertrauen erreicht hat, dass sie gut verstanden und leicht zu handhaben ist. Kubernetes, das in 78 Prozent der Unternehmen in der Produktion eingesetzt wird, hat diesen Punkt wohl überschritten und ist inzwischen weithin als „einfach funktionierendes“ Standard-Cloud-Enabling-System anerkannt.
Oder, anders ausgedrückt, ist „langweilig“ geworden.
Auch wenn die Cloud Native Computing Foundation bei der Koordinierung der Entwicklung einer Reihe anderer Projekte hilft, um die Lücken zu füllen, die Kubernetes auf der Infrastrukturebene hinterlassen hat, hat sich das Thema Kubernetes allmählich auf die Ereignisse weiter oben verlagert. Im April beobachtete Kelsey Hightower, dass Kubernetes bei der Modernisierung von Anwendungen nur die Hälfte des Problems löst, wenn überhaupt:
„Es gibt tonnenweise Anstrengungen, um Anwendungen auf der Infrastrukturebene zu „modernisieren“, aber ohne gleiche Investitionen auf der Anwendungsebene, bei den Think Frameworks und den Anwendungsservern lösen wir nur die Hälfte des Problems.“
Was tun wir dagegen?
Die Lücke zwischen Anwendungen und Infrastruktur füllen
„Es gibt eine große Lücke zwischen der Infrastruktur und der Entwicklung einer vollständigen Anwendung“, erklärte Jonas Bonér, CTO und Mitbegründer von Lightbend, in einem Interview. Bonér half beim Start des Open-Source-Projekts Akka, das darauf abzielt, ein komplexes Problem zwischen der Infrastruktur und der Anwendung zu lösen, oberhalb von Kubernetes auf dem Stack. Wie Bonér es ausdrückte:
„Es ist eine Herausforderung für den Programmierer, diese riesige Lücke zu füllen, nämlich die Frage, was es eigentlich bedeutet, dem Unternehmen SLAs zur Verfügung zu stellen, all die Dinge, die in verteilten Systemen schwierig sind, die aber von der Anwendungsschicht benötigt werden, um Kubernetes und sein Ökosystem von Werkzeugen optimal zu nutzen.“
Hier braucht ein Unternehmen Dinge, die zwischen der Anwendung und der Infrastruktur angesiedelt sind und dafür sorgen, dass alles funktioniert, fuhr Bonér fort. Es geht nicht darum, irgendetwas zu ersetzen, sondern vielmehr darum, weitere Tools in die Toolbox hinzuzufügen und das Infrastrukturmodell der Isolierung und der durch das Netzwerk auferlegten Einschränkungen auf die App selbst auszudehnen – und zwar in einem intuitiven, flexiblen und leistungsstarken, aber dennoch einfachen Programmiermodell.
Wie zwei Tesla-Ingenieure auf einer Konferenz im vergangenen Jahr diskutierten, verlässt sich Tesla auf „digitale Zwillings“-Fähigkeiten, die sein Stromnetz versorgen, was durch die Kombination von Akka und Kubernetes möglich wurde. „Die meisten unserer Mikrodienste laufen in Kubernetes, und die Kombination von Akka und Kubernetes ist wirklich fantastisch“, kommentierte der Tesla-Ingenieur Colin Breck. Er erklärte:
„Kubernetes kann grobkörnige Fehler bei der Skalierung bewältigen, so dass dies Dinge wie das Hoch- oder Herunterskalieren von Gondeln, das Ausführen von Lebensdauersonden oder das Neustarten einer ausgefallenen Gondel mit einem exponentiellen Back-off wären. Dann verwenden wir Akka für die Behandlung feinkörniger Fehler wie das Unterbrechen von Stromkreisen oder das erneute Ausführen einer individuellen Anfrage und die Modellierung des Zustands einzelner Entitäten wie die Tatsache, dass eine Batterie geladen oder entladen wird.“
Laut Bonér gibt es drei allgemein ungelöste Bereiche, die sich oberhalb von Kubernetes auf dem cloud-nativen Stack noch immer entwickeln, was zu neuen Abstraktionen führt, die von Technologien wie Akka angeboten werden: Zusammensetzung der Anwendungsschicht, Stateful Use Cases und Data-in-Motion Use Cases.
Ermöglichen einer deklarativen Zusammensetzung der Anwendungsschicht
„Die Menschen verwenden allzu oft alte Tools, Gewohnheiten und Muster, die oft von den traditionellen (monolithischen dreistufigen) Designs herrühren, die das von Kubernetes gelieferte Cloud-Modell hemmen und einschränken“, bemerkte Bonér. Wir müssen das „erstaunlich gute“ Modell von Containern, Service-Meshes und Orchestrierung bis hinauf zur Anwendungs-/Geschäftslogik ausweiten, damit wir das Beste daraus machen können und gleichzeitig End-to-End-Garantien im Namen der Anwendung erhalten, sagte er.
Serverless weist den Weg, indem es das Abstraktionsniveau anhebt und ein deklaratives Modell bereitstellt, bei dem so viel wie möglich von Boilerplate, Infrastruktur und Operationen entfernt und von der Plattform verwaltet wird, so dass der Entwickler mit dem Wesentlichen zurückbleibt: der Geschäftslogik und ihrem Workflow.
Verbesserte Unterstützung für zustandsbehaftete Anwendungsfälle
Der größte Teil des Cloud-Ökosystems befasst sich hauptsächlich mit so genannten 12-Faktoren-Anwendungen, d.h. mit zustandslosen Anwendungen. Manchmal könnte das alles sein, was man braucht. Aber nicht-triviale Anwendungen sind in der Regel eine Mischung aus zustandslosen und zustandsbehafteten Anwendungsfällen.
„Wir brauchen mehr und bessere Tools, um State-Fälle gut anzugehen“, bemerkte Bonér. „Der Wert liegt heutzutage oft in den Daten, und es sind oft die zustandsbehafteten Anwendungsfälle, in denen der größte geschäftliche Wert liegt – dafür zu sorgen, dass Sie schnell auf diese Daten zugreifen können, und gleichzeitig die Korrektheit, Konsistenz und Verfügbarkeit sicherzustellen.“
In der Cloud, es sei denn, Sie haben ein wirklich gutes Modell und die Tools, die es unterstützen, sind Sie gezwungen, wieder auf die Drei-Schichten-Architektur zurückzugreifen, bei der jedes Mal alles in die Datenbank hinuntergeschoben wird, egal ob es sich um Kommunikation, Koordination oder langfristige Speicherung des Zustands handelt.
Wichtig ist auch, dass Sie gute Zustandsmodelle brauchen, um den zustandslosen Ansatz zu ergänzen, damit Sie mehr Optionen in der Toolbox haben. Das Ausmaß, in dem Kubernetes heute mit zustandsbehafteten Anwendungsfällen umgeht, wird eigentlich nur durch die StatefulSets-Funktion unterstützt, aber StatefulSets sind für die Leute gedacht, die Infrastrukturen wie Datenbanken implementieren, wie Bonér feststellte, und nicht für die App-Entwickler.
„Es gibt hier also immer noch eine große Lücke“, sagte Bonér. „Hier kommt Akka ins Spiel.“
Umgang mit schnellen Daten oder Data-in-Motion-Anwendungsfällen
Wahrscheinlich bietet das Ökosystem Kubernetes noch keine große Unterstützung für Streaming und ereignisbasierte Anwendungsfälle. Service-Meshes wie Istio sind auf einem Anfrage-Antwort-Modell aufgebaut und „können im Weg stehen“, meinte Bonér. Streaming ist auch oft zustandsbehaftet, wobei Stufen Daten im Speicher aggregieren und gleichzeitig verfügbar sein müssen, was an die obige Diskussion anknüpft. In der Knative Community wird daran gearbeitet, dieses Problem anzugehen, aber wir fangen gerade erst an, wie Bonér andeutete.
Ein großer Teil der Schubkraft dieser neuen Richtungen scheint in den Low-Code- / No-Code- / „Entkopplung von Front-End und Back-End“-Konzepten zu liegen, die unter der serverlosen Bewegung aufkommen.
„Serverless bringt uns dem Problem der Erweiterung des Kubernetes-Modells in die Anwendung selbst näher“, meinte Bonér. „Darum dreht sich alles. Es geht darum, so viel wie möglich zu abstrahieren und zu einem deklarativen Konfigurationsmodell anstelle von Kodierung überzugehen, bei dem man definiert, was man tun soll, und nicht, wie man es tut.“
Anwendungsinfrastruktur, die ‚einfach funktioniert‘
Da sich der „cloud-native stack“ über der Ebene der Kubernetes-Infrastruktur weiter entwickelt, wird es interessant sein zu sehen, wie sich diese Konzepte auf der Anwendungsebene für bestimmte Sprachentwickler auswirken. Während viele der schwierigsten Herausforderungen der Anwendungsarchitektur lange Zeit die Domäne der serverseitigen Java-Entwicklung waren, scheinen wir uns in Richtung einer Jamstack-Architektur zu bewegen, bei der es zunehmend die JavaScript-Entwickler sind, die erwarten, dass der Zugriff auf die Anwendungsinfrastruktur einfach funktioniert, insbesondere da sich die Endpunkte exponentiell vervielfachen.
Das soll nicht heißen, dass die Backend-Infrastruktur nicht wichtig ist. Vielmehr soll damit, wie Ian Massingham argumentiert hat, anerkannt werden, dass die Zahl der Front-End-Entwickler die der Back-End-Entwickler bei weitem übersteigt, und das aus gutem Grund: Es müssen weit mehr Anwendungen erstellt werden, als es eine Infrastruktur gibt, die für das Hosting der Anwendungen geschaffen werden muss. Die Überbrückung der beiden Welten durch Open-Source-Projekte wie Akka wird mit der Zeit immer wichtiger.
*Matt Asay schreibt unter anderem für InfoWorld.com
Be the first to comment