Erkennt der Normalsterbliche schon bei Cloud-Computing den Wald vor lauter Bäumen nicht, erweist er sich beim Thema Cloud-native erst recht als überfordert. Und auch selbsternannte Experten haben mitunter recht divergente Perspektiven. Das führt bei ahnungslosen Opfern meist zu Schweißperlen, sobald sie den ausschweifenden Erläuterungen aus Expertenmund folgen. Ich kann das aus eigener Erfahrung bestätigen, zumal ich mich ständig in der Grauzone zwischen dem Tal der Ahnungslosen und dem der Experten bewege. Zum Glück lässt sich in der Informatik jedes Problem hinter Türmen von Abstraktionsebenen verstecken.
Daher verwende ich im Folgenden genau dieses Entwurfsprinzip, um dem Schwerpunktthema der vorliegenden Ausgabe näher zu kommen, ohne dabei konvergieren zu müssen. Zum Glück kann ich mich auf die Vorarbeit zahlreicher Experten stützen, was bei Ihnen, liebe Mitwisser, einen besonders guten und nachhaltigen Eindruck hinterlassen dürfte.
Aber Schluss mit lustig! Lassen Sie uns einen Blick auf die vier Säulen von Cloud-native werfen.
Container: Sobald jemand seinen Hausmüll entsorgen will, wirft sie/er ihn in einen passenden Container. Von dieser Art Container ist hier natürlich nicht die Rede, obwohl sich ähnliche Praktiken durchaus in der Entwicklung Container-basierter Lösungen beobachten lassen. Sie haben es sicher geahnt – es geht in diesem Zusammenhang um Docker und verwandte Technologien. Für den Anbieter der Cloud-Infrastruktur haben Container den Vorteil, dass sie von außen alle gleich aussehen. Um deren Innenleben braucht sich die Infrastruktur nicht zu kümmern. Auf der anderen Seite lieben Entwickler Technologien à la Docker, weil sie es nur noch mit der gewohnten Zielumgebung zu tun haben, egal unter welcher physikalischen Infrastruktur die verschiedenen Container schlussendlich laufen. Und selbstredend sind Container insofern verführerisch, als der Absturz eines Containers im Normalfall andere Container unberührt lässt. Ganz zu schweigen von der Elastizität, die heutzutage nicht nur vielen Anforderungsspezifikationen, sondern auch den wolkigen Infrastrukturen innewohnt. Speziell dann, wenn ein guter Geist namens Kubernetes für die passende Orchestrierung sorgt.Services: Welche Art von Funktionalität sich in den einzelnen Containern verbirgt, blieb bislang unberücksichtigt. Einen Big-Ball-of-Mud hinter den dicken Mauern eines Containers zu verstecken, dürfte freilich wenig zielführend sein – Sie kennen sicher die Metapher vom „Schmutz unter den Teppich kehren”. Als wesentlich sinnvoller erweist sich die Bereitstellung individueller Funktionalitäten in Gestalt unabhängiger Microservices, selbstverständlich inklusive aller dafür benötigten Dienste. Jeder Microservice lebt dabei autark, friedlich und zurückgezogen in seinem abgeschotteten Container-Universum. Die Intimsphäre geht soweit, dass sich die Beziehungen zwischen Microservices und ihren Klienten durch komplette Transparenz und Zustandslosigkeit auszeichnen. Soweit zumindest die Theorie. Leider scheinen einige Entwickler gelegentlich zu vergessen, dass der Erfolg ihrer Elaborate stets mit derQualität der bereitgestellten APIs steht oder fällt. Merke: Das API ist die Visitenkarte eines anständigen Entwicklers oder Microservice!
Continuous Delivery gehört in einer Zeit ausufernder „Geiz ist geil & Zeit ist Geld”-Mentalität zu den wichtigsten Eckpfeilern der Anwendungsentwicklung. Der alte Sisyphos dürfte seine „Freude” damit haben, nicht nur weil der Steinbrocken inzwischen aus mehreren besteht, die immer schneller den Abhang herunter rollen. Softwareupdates und -patches müssen in ständig kürzer werdenden Zyklen bei gleichbleibend guter Qualität den Anwender erreichen – Downtime war gestern, es lebe die Singularität! Die zunehmende Ungeduld von Frau und Herrn Mustermann lässt sich exemplarisch bei Updates von Apple beobachten, die zurzeit alle paar Wochen über die Cloud auf unschuldige mobile Endgeräte strömen. Selbstredend eignen sich Container und Microservices prima dafür, diese kontinuierliche Integration und Auslieferung zu ermöglichen, wodurch sich der Kreis schließt.
Von Deaf Ops zu DevOps: Welche Entwicklerin kennt das nicht, früher das Warten auf das Christkind, heute das Warten auf den Systemadministrator, bis dieser sich genötigt fühlt, die neue Version der Software samt ihrer Abhängigkeiten auf Test- & Produktionsumgebung bereitzustellen. In der Ära des DevOpsizoikums pflegen Entwickler ihre Änderungen ins Versionsverwaltungssystem ein, was dem neugierigen CI-Server nicht verborgen bleibt, der „stante pede“ die weiteren Aktionen in der Deployment-Pipeline triggert. Das Zauberwort heißt Automatisierung. Immerhin lässt sich dadurch die bisherige Firewall zwischen Entwicklung und Betrieb zum Einsturz bringen. Und das Thema Agilität ärgert (=beschäftigt) endlich auch andere Organisationseinheiten statt immer nur die Entwicklungsabteilung. Take down the wall! Weil es so wahnsinnig viele DevOps-Werkzeuge gibt, droht das Problem sich allerdings zunehmend von der Konfiguration von Softwareartefakten auf die Konfiguration heterogener DevOps-Tools zu verschieben. Doch auch hier verspricht die Cloud Abhilfe dank DevOps as a Service. Hurra! Das waren sie also, die vier heiligen Säulen der Cloud-Natives, unter denen letztere dem Gott der Digitalisierung huldigen.
Ihr Prof. Dr. Michael Stal
