Anwendungsdienste für Kubernetes-Anwendungen: Alt und neu

Von der VMS VAX-Fehlerbehebung bis zum Schreiben serverloser Microservices ist es ein langer Weg (mit der Ankündigung der COBOL-Unterstützung in AWS Lambda bei re:Invent könnte jedoch die erste Runde der IT- Lemniskate abgeschlossen sein).

Im Laufe der Zeit hat sich viel verändert. Ich glaube mich zu erinnern, dass ich in der Lage war, Skripte in Perl zu hacken und mich über ein Betriebssystem geärgert habe, das es einem ermöglichte, in ein Verzeichnis zu wechseln, das nicht existierte (Bonus: man konnte es erstellen, sobald man dort war). Heutzutage scheint es, als könne man genauso viel Zeit darauf verwenden, über die genaue Vorgehensweise bei der Lösung eines Problems nachzudenken, wie auf die eigentliche Lösung. Und das ist fantastisch. Die Vielfalt der Architekturen, das Entwicklungstempo, die digitalen Möglichkeiten und die Entfaltung der Kreativität der Entwickler, die uns all diese neuen Spielzeuge bieten, sind großartig. Es spielt keine Rolle, auf welcher Seite des Proszeniumbogens Sie sich befinden, sowohl Entwickler als auch Verbraucher erfreuen sich an neuen und besseren Apps in einer Geschwindigkeit und mit einer Funktionalität, die vor nicht allzu langer Zeit noch Science-Fiction war.

Ein treffendes Beispiel sind Container und ihr wachsamer Kubernetes-Aufpasser. Die Containertechnologie war zweifellos ein entscheidender Motor für die explosionsartige Entwicklung der Anwendungsentwicklung.

Diese Woche treffen sich im sonnigen Seattle (Stand 10:46 Uhr am Tag des Schreibens [Update: um 13:36 Uhr immer noch sonnig]) über 8.000 Menschen, um über Kubernetes und andere Open-Source-Technologien zu reden, zuzuhören und mehr zu erfahren. Die Mischung aus Gesprächen, praktischem Lernen und Anregungen ist die Ursuppe der Innovation. Während Sie dies lesen, wurden Ihnen 12 großartige neue Ideen (und 37 schreckliche) ausgedacht.

Manche dieser Apps werden Leben verändern, manche werden die Architektur revolutionieren, manche werden Benutzeroberflächen weiterentwickeln und manche werden wahrscheinlich nur ein weiterer Weg sein, um zu verdeutlichen, wie weit ich von der Jugendkultur entfernt bin.

Doch diese unterschiedlichen Anwendungen und die von ihnen verwendeten Frameworks müssen durch einige Anforderungen miteinander verbunden werden. Die Lösungen können unterschiedlich aussehen, es gibt jedoch kritische Komponenten, für die jeder eine Lösung finden muss:

Maßstab – Wenn Sie es schaffen wollen, müssen Sie in der Lage sein, auf dem Weg dorthin (und vermutlich gelegentlich auch wieder zurück) groß zu werden.

Stabilität – Alle Apps benötigen ein angemessenes Maß an Stabilität – vom „Überstehen der Bühnendemo“ bis hin zu lebensgefährlichen Verfügbarkeitsanforderungen.

Sicherheit – Es gibt böse Menschen, und manchmal greifen sie Ihre Anwendungen an. Die Komplexität moderner Systeme scheint die Angriffsfläche, über die Sie sich Sorgen machen müssen, ständig zu vergrößern.

Beobachtbarkeit – Sehen heißt glauben, was bei Problemen doppelt wichtig ist. Wenn Sie die richtigen Informationen aus der OSI-Schicht schnell an die richtigen Personen übermitteln, können Sie weniger Fehler machen, sich schneller erholen und die Welt des „Sie bauen es, Sie betreiben es“ ein wenig komfortabler gestalten.

Diese Anforderungen sind nicht besonders einzigartig, aber sie bleiben die grundlegenden Anliegen, die von jeder gut konzipierten App berücksichtigt werden müssen, idealerweise bevor sie zu einem Problem werden und bevor eine einzige Codezeile geschrieben wird.

Mein geschätzter Arbeitgeber F5 Networks hat ein Multimilliarden-Dollar-Unternehmen aufgebaut, das diese Bedürfnisse erfüllt, und ehrlich gesagt sind wir ziemlich gut darin (aber das würde ich sagen). Die Dinge, die wir herstellen, um diese Bedürfnisse zu erfüllen, nennen wir Anwendungsdienste . Anwendungsdienste, die den Anwendungsverkehr sichern, prüfen und leiten. Anwendungsdienste, die Clients an die richtige Stelle weiterleiten, Anwendungsdienste, die wichtige Anwendungstelemetrie extrahieren, weiterleiten und anzeigen. Dabei handelt es sich um die Kerndienste, die dafür gesorgt haben, dass die Anwendungen unserer Kunden reibungslos laufen – und es sind die Dienste, die Anwendungen auch weiterhin benötigen, unabhängig davon, wo und wie sie erstellt werden.

Kommen wir zurück zu einem Verkaufsgespräch mit einem Verkäufer?

So weit, so weit: „Alter, mürrischer Typ, der versucht, mich davon zu überzeugen, dass seine Old-School-Technik immer noch relevant ist.“ OK, hier ist also, was sich umgedreht, in der Luft gedreht und kopfüber gelandet ist. Beginnen wir mit dem Wichtigsten: Die Art und Weise, wie die Dienste bereitgestellt werden.

Eine der Technologien, die die Einführung von Plattformen und Arbeitspraktiken ermöglichen, sind Systeme, die Absichten auf automatisierte und integrierte Weise mit Maßnahmen verknüpfen. Anwendungsdienste müssen Teil dieser Kette sein und dies stellt eine grundlegendere Veränderung dar als lediglich eine Änderung der Laufzeiten.

Manchmal müssen Dienste in vorhandene Komponenten eingefügt werden – wie beispielsweise die außergewöhnliche Sichtbarkeit und Kontrolle, die Aspen Mesh zu Istio hinzufügt. Alternativ können Verbindungstools wie der F5 Container Connector Umgebungen mit Diensten verknüpfen, sodass beim Hinzufügen oder Entfernen von Kubernetes-Pods diese gesichert, skaliert und beobachtet werden können.

Idealerweise muss der Code zum Erstellen der Anwendungsdienste im selben Repository vorhanden sein wie der Code für diese Anwendung und auf die gleiche Weise bereitgestellt werden. Anwendungsdienstdefinitionen – beispielsweise ein Web Application Firewall-Dienst – müssen als Code vorliegen und als Code behandelt werden, wobei eine Änderung und ein Commit der Dienstdefinition in der Quellcodeverwaltung ohne weitere menschliche Eingaben eine produktive Bereitstellung einer Web Application Firewall ermöglicht. In den neuesten Nachrichten beschrieb die schlagfertige Melaine Cebula von Airbnb genau dieses Modell in ihrer Keynote-Session am Mittwoch bei Kubecon , als sie beschrieb, wie alle Komponenten für einen Dienst – einschließlich Infrastrukturdefinitionen – in einem einzigen Projekt aufbewahrt werden können (sowie ungefähr fünfzig andere coole Dinge, die sie tun, um App-Entwicklern das Leben zu erleichtern).

Diese Änderung in der Service-Instanziierung (gepaart mit dem willkommenen Ende langer IT-Ticket-Warteschlangen) ist dramatisch und offensichtlich.

Die zweite Änderung ist vielleicht etwas banaler, aber dennoch entscheidend. Einer der Vorteile von Kubernetes und Containern ist die Portabilität zwischen Umgebungen. Ihr von Kubernetes verwalteter Microservice läuft überall, wo auch eine unterstützte Container-Engine läuft (Tipp: überall), und es sollten auch dort dieselben App-Dienste verfügbar sein, nicht „irgendwie gleich“ oder „macht dasselbe auf eine andere Art und Weise mit einer leicht anderen Schnittstelle“. Das gleiche. Dies bedeutet, dass die Zahl der Orte, die wir bereitstellen müssen, ständig wächst.

Die Notwendigkeit, auf die gleiche Weise und an den gleichen Orten zu arbeiten wie alle Ihre aktuellen und potenziellen Kubernetes-Bereitstellungen, ist zum Leitprinzip für F5 geworden.

Dies ist von entscheidender Bedeutung, da sich unsere Kunden nicht nur darauf verlassen, dass wir ihre vorhandenen Apps skalierbar und sicher halten, sondern auch darauf vertrauen müssen, dass wir die Apps schützen und überwachen, die – zum Zeitpunkt des Schreibens dieses Artikels – als bösartiges Koffeinmolekül gelten, das sich an einen glücklichen Adenosinrezeptor bindet, der nach dem Mittagessen einen Energieschub braucht.