PaaS und seine Grenzen
Bei einer der ersten geschäftskritischen Anwendungen eines DAX-Konzerns, die wir 2019 über einen Reengineering-Ansatz modernisiert und nach Azure migriert haben, war ich regelrecht begeistert über die neuen Möglichkeiten der Public Cloud. Von Beginn an wurde ein PaaS-first-(Platform-as-a-Service-)Ansatz verfolgt, also überall wo möglich auf native Plattformdienste gesetzt. Kernstück der Anwendung ist eine VLDB (Very Large Database), die bis zur Migration auf traditioneller On-Premises-Hardware gehostet wurde. Aufgrund des sehr volatilen Lastprofls und der Verfügbarkeitsanforderungen wurde das bestehende Aktiv/passiv-Cluster für die Spitzenlast der nächsten drei Jahre ausgelegt. Elastizität war in diesem Set-up schlichtweg nicht möglich.
Und so war es auch für Microsoft die Premiere seiner damals noch brandneuen Hyperscale-SQL-PaaS-Datenbank – zumindest in diesen Enterprise-Dimensionen. Die Entscheidung sollte sich ein paar Monate später buchstäblich auszahlen, denn der Service hat ein entscheidendes Feature, das zu einer Senkung der Run-Kosten von mehr als 50 Prozent führte: Read-Replicas auf Knopfdruck, also Read-only-Kopien der Datenbank. Diese werden zu den Peak-Zeiten hinzugeschaltet, verarbeiten die zusätzliche Leselast und danach wieder abgeschaltet – alles verwaltet durch die Plattform ohne menschliches Zutun. Einfach fantastisch.
Augenmaß ist auch in der Cloud die entscheidende Größe
Und weitere Erfolgsgeschichten in ähnlichen Vorhaben ließen nicht auf sich warten: Kubernetes- oder OpenShift-Plattformen für Container anstelle statischer WebLogic-Cluster, Plugand-Play-Integrationsservices für Streaming oder Messaging, Managed NoSQL-Datenbanken für Graphen, Dokumente etc. Aber: Es gibt auch diverse Anwendungsfälle, wo PaaS nicht das beste Mittel der Wahl ist, sondern einfaches IaaS (Infrastructure as a Service):
- wenn komplexe Datenmodelle auf eine DBaaS (Database as a Service) migriert werden sollen und die Migration den Business-Case übersteigt
- wenn Security- oder Compliance-Richtlinien keinen Einsatz von PaaS erlauben
- wenn PaaS-Dienste noch nicht ausgereift sind und in den Logs falsche Codelines bei Exceptions angezeigt werden
Photo by Christina@wocintechchat.com on Unsplash
Immer dann kann auch IaaS mit manueller Installation und Administration des betroffenen Service bevorzugt werden. Man muss eben abwägen – wie immer in unserem Metier. Spätere Anpassungen an diesen Grundsatzentscheidungen können traditionell sehr aufwendig und kostspielig werden. Das hat sich auch mit der Cloud nicht wesentlich geändert.
Der Punkt mit den Microservices …
Ein weiteres Beispiel für ein gern gesehenes Pattern, das durch Cloud-Nutzung einfacher denn je unterstützt wird: Microservices. Nein, hier folgt jetzt kein weiterer Beitrag zu den Vor- und Nachteilen von Microservices. Vielmehr möchte ich auf den Einfluss von Cloud auf die Nutzung von Microservices eingehen. Natürlich ist es aus so vielen Gründen sinnvoll, eine Anwendung in unabhängige Services zu unterteilen. Divide and conquer. Slicing the elephant. Alles richtig. Aber man sollte es dabei wirklich nicht übertreiben. Einzeln deploybare Einheiten schaffen, Komplexität reduzieren, klar definierte APIs nutzen, Two-Pizza-Teams einsetzen – alles definitiv besser, als monolithische Anwendungen zu entwickeln.
Photo by Markus Spiske on Unsplash
Nicht alles technisch Machbare auch realisieren
Aber: In der Praxis begegnet man immer wieder Teams, die die Möglichkeiten von Cloud und hier insbesondere die Function-as-a-Service-Angebote wie AWS Lambda oder Azure Functions dazu genutzt haben, eine einzelne Anwendung in Dutzende Microservices zu unterteilen. Einfach weil es durch die Cloud so simpel ist. Spätestens wenn es zu – mittelfristig meist unvermeidbaren – Anpassungen aufgrund von Compliance-Maßnahmen, Security Findings oder Technologie-Upgrades kommt, können sich Aufwände gegebenenfalls potenzieren. IaC (Infrastructure as Code) von fünf Services an eine neue Technologie anzupassen ist erwartungsgemäß einfacher als bei 50 Services. Das ist keine rein theoretische Überlegung, sondern praktische Erfahrung bei einem Kunden. Und bisher, über vier Jahre nach dem initialen Go-Live der eingangs erwähnten Anwendung, gab es noch keinen einzigen Fall, in dem einzelne Services auch einzeln ausgerollt wurden.
Photo by imgix on Unsplash
Es gibt Extremfälle wie den von Amazon Prime, wo man zurückgekehrt ist zu monolithischeren Strukturen. Während es auf den ersten Blick als Ausnahme erscheint, muss man auf den zweiten Blick gestehen: Es ist kein Einzelfall. Auch hier gilt: Abwägung beim Schnitt der Services ist oftmals sinnvoll. Man muss nicht immer das Maximum ausreizen, diverse Technologien verwenden und am Ende bei einem breit gestreuten Portfolio von sehr klein geschnittenen Services landen, die einzeln gesehen kaum noch Mehrwert liefern und nur in langen Aufrufketten die eigentlichen Geschäftsprozesse erfüllen können. Cloud vereinfacht diesen Trend, man muss ihm aber nicht folgen. Erfahrung, Augenmaß und Verstand sind gefragt.
Apropos Infrastructure as Code
Apropos Infrastructure as Code: Es ist noch (relativ zur Softwareentwicklung) neu und erhält daher oftmals nicht die Aufmerksamkeit, die es verdient. Denn es sind neue, eigenständige Plattform-Anwendungen entstanden, die es vor fünf Jahren so noch nicht gab. Die Automatisierung von Infrastrukturprovisionierung und Anwendungskonfguration über Terraform, Ansible & Co. ist schlichtweg ein erheblicher Treiber von Verkürzung der Time-to-Market, Erhöhung der Qualität, Minimierung manueller Aufwände und damit auch ein entscheidender Hebel für Kostensenkungen. Es führt außerdem zum Aufbau neuer Umgebungen in Minuten mit komplett autonomem Betrieb selbst für CI/CD-Komponenten wie Jenkins, Reduktion der Rollout-Dauer um mehr als Faktor 10. Davon ist man im Fachbereich natürlich begeistert. Die Kehrseite der Medaille, die in vielen Fällen unterschätzt wird, sind die höheren Aufwände für die Einrichtung und die Pflege dieser komplett neuen Infrastruktur. Nicht selten sind Tausende LoC (Lines of Code) notwendig, um diese Features für komplexe Anwendungen zu realisieren. Und nicht selten fehlt darüber hinaus die notwendige Erfahrung bei der Konzeption dieser neuen Plattform-Anwendungen, Testautomatisierung, Planung von Technologie-Upgrades, Dokumentation oder Governance-Strukturen.
Anforderungen an die Mitarbeitenden steigen
Erfahrung, Skills, Talent – wie auch immer man es in verschiedenen Branchen nennen mag – sind durch die Nutzung von Cloud wichtiger denn je. Vor 15 Jahren waren die Anforderungen an einen Berufseinsteiger im Software Engineering im Vergleich zu heute überschaubar: Java EE im Backend, JSF im Frontend, optional relationale Datenbanken. Heutzutage wird von den Mitarbeitern eine erheblich höhere Vielfalt an Technologien erwartet: Java, Spring Boot, Cucumber, SQL, NoSQL, Kafka, Angular, React, Ansible, Terraform etc. Daher ist die Mitarbeiterentwicklung umso mehr in den Fokus gerückt, denn diese Skill-Breite lernt man nicht an der Universität oder in zweiwöchigen Schulungsprogrammen. Eine Kombination aus Trainings, Learning on the Job und kontinuierlichen Coachings durch erfahrene Kolleg*innen ist nötig. Generative AI à la ChatGPT und Github Copilot mag da unterstützen, aber im Endeffekt bedarf es auch dann ausgebildeter Experten, um den generierten Output zu verifizieren – bevor dieser in Produktion ausgerollt wird. Denn gerade die oben beschriebenen Herausforderungen bei der Auswahl von Plattform-Services oder dem Service-Schnitt hat weiterhin der (menschliche) Architekt zu bewältigen.
Fazit
- Cloud-Plattformen bieten zwar erhebliche Vorteile, sind aber kein Allheilmittel für alle Herausforderungen der Softwareentwicklung. Die transformativen Vorteile wie schnellere Markteinführung, Skalierbarkeit, geringere Kosten und höhere Sicherheit sind unbestreitbar. Eine Cloud-Migration will jedoch, auch wenn es wie ein Klischee klingt, wohlüberlegt sein. Was nach Vereinfachung klingt, kann in Wahrheit zu neuer Komplexität führen.
- Die Praxisbeispiele zeigen die Effektivität von Cloud-Lösungen wie Hyperscale-SQL-PaaS-Datenbanken, Kubernetes, OpenShift und verwalteten NoSQL-Datenbanken. Es gibt jedoch auch Szenarien, in denen PaaS aufgrund der Komplexität der Daten, Sicherheitsbedenken oder der Unausgereiftheit bestimmter Dienste möglicherweise nicht die optimale Wahl ist. Hier muss sorgfältig abgewogen werden, was dem Geschäftsbetrieb tatsächlich dient.
- Microservices, die durch die Cloud ermöglicht werden, bieten Vorteile in der Anwendungsarchitektur, aber auch hier ist ein maßvoller Ansatz erforderlich. Die Aufteilung von Anwendungen in kleinere Dienste kann zwar vorteilhaft sein, eine übermäßige Fragmentierung kann jedoch zu Problemen bei der Verwaltung, der Einhaltung von Vorschriften und bei Technologie-Upgrades führen. Eine durchdachte Bewertung der Vorteile und potenziellen Nachteile von Microservices zahlt sich am Ende für den Geschäftsbetrieb mehr aus, als auf den neuesten Trend einzusteigen.
- Infrastructure as Code (IaC) erweist sich als treibende Kraft für Effizienzsteigerungen, die Reduzierung des manuellen Aufwands und die Verbesserung der Qualität. Die Einrichtung und Pflege neuer Infrastrukturparadigmen geht allerdings auch mit einem erheblichen Aufwand einher, der Tausende von Codezeilen umfassen kann. Erfahrung, Fähigkeiten und menschliches Gespür sind nach wie vor unverzichtbar, um diese Komplexität zu bewältigen und fundierte Entscheidungen über die Auswahl von Diensten und die Architektur zu treffen.
- Die sich entwickelnde Technologielandschaft verlangt von den Fachleuten von heute ein breiteres Spektrum an Fähigkeiten, im Gegensatz zu den einfacheren Anforderungen der Vergangenheit. Hier ist die Mitarbeiterentwicklung der Schlüssel: Eine Mischung aus Schulung, Lernen am Arbeitsplatz und Mentorenschaft ist entscheidend, um die Anforderungen der verschiedenen Technologien zu erfüllen. KI-Tools wie ChatGPT und Github Copilot können zwar helfen, aber die endgültige Validierung und Entscheidungsfndung obliegt immer noch erfahrenen Experten, insbesondere bei kritischen Aspekten wie der Auswahl von Plattformdiensten und Serviceschnittstellen. Man könnte glauben, je moderner die Cloud-Technologie wird, desto weniger ist man auf strategisches Denken, Erfahrung und rationales Urteilsvermögen angewiesen. Das Gegenteil ist der Fall, um die wahren Vorteile der Cloud zu nutzen und gleichzeitig ihre potenziellen Fallstricke zu vermeiden.
