Die cloud-native Revolution der Softwarearchitektur

Cloud-native Softwareentwicklung und Plattform-Engineering haben die Art und Weise revolutioniert, wie moderne Softwarearchitekturen gestaltet werden. Diese Transformation bringt jedoch eine paradoxe Dynamik mit sich. Während Plattform-Engineering Entwicklerinnen und Entwickler durch abstrahierte Tools und automatisierte Prozesse unterstützt, schränkt es zugleich ihre Entscheidungsfreiheit ein. Im Folgenden wird diese "komplizierte Liebesgeschichte" zwischen Cloud-Projekten und Plattform-Engineering beleuchtet, denn zwischen Automatisierung und Flexibilität müssen Unternehmen eine Balance finden, um maximal vom Plattform-Engineering zu profitieren.

Die ersten Schritte

Zu Beginn einer jeden Reise in die Cloud müssen die vorhandenen Entwickler und Entwicklerinnen darauf vorbereitet werden, wie sie in der neuen Welt agieren können. Hierzu werden Schulungen, Hands-On Labs und Zertifizierungen genutzt, um die Cloud Services und Konfigurationen kennenzulernen. Denn eines sollte klar sein – die Entwicklung in der Cloud bringt viele Neuerungen: Es existieren über 200 verschiedenen Services (vgl. AWS), die genutzt werden können, alles kann vollständig automatisiert werden und die meisten Anforderungen an Sicherheit, Resilienz und Skalierbarkeit können durch eine Konfiguration erfüllt werden.

Auf diese Weise verschiebt sich die Verantwortung für die Infrastruktur eines Systems auf die Seite der Software Engineers. Die dadurch gewonnene Gestaltungsfreiheit in Kombination mit der Vielzahl an verfügbaren Services spannt einen nahezu unbegrenzten Lösungsraum für die Systemarchitektur auf. Gleichzeitig führt diese Gestaltungsfreiheit automatisch auch zu heterogener Technologiewahl und Realisierung.

Mit dem Blick auf eine einzelne Anwendungs- oder Microservice-Landschaft, die von einem Team entwickelt wird, etablieren sich üblicherweise interne Standards und Best-Practices, welche Services, Programmiersprachen und Frameworks genutzt werden. Doch auf der nächsthöheren Ebene der Enterprise-Architektur wirkt die Systemlandschaft chaotisch.

Neue Herausforderungen

Eine heterogene Systemlandschaft wird immer dann herausfordernd, wenn querschneidende Belange entstehen. Die üblichen Verdächtigen in dieser Kategorie sind Sicherheit, Monitoring, Kosten, Entwicklungs-Performance und Qualität.

Jeder, der schonmal mit einem Security-Audit konfrontiert war, weiß, wie viel Aufwand bei der Härtung und anschließenden Dokumentation eines Systems entsteht. Alle genutzten Cloud Services, Automatisierungen und der Anwendungscode müssen geprüft und ggf. nachgebessert werden. Gleiches gilt für die Anbindung an zentrale Monitoring- und Kosten-Kontroll-Werkzeuge.

Diese und viele weitere zentrale Themen müssen in jedem Entwicklungsteam für das jeweilige System und die gewählten Technologien einzeln durchgeführt werden. Das reduziert die Entwicklungsgeschwindigkeit nachweislich um bis zu 40 Prozent. Zusätzlich kann die heterogene Entwicklung dazu führen, dass verschiedenen Teams die gleichen Fehler machen. Da unterschiedliche Technologien und Services genutzt werden ist es aber oftmals nicht möglich die gleiche Lösung wiederzuverwenden.

Somit kann die Flexibilität in der Entwicklung dazu führen, dass die Entwicklungsgeschwindigkeit und die vorhandene Softwarequalität mit steigender Komplexität des Systems kontinuierlich sinken.

Innovation durch Harmonisierung

Eine etablierte Methode, um die Heterogenität in den Griff zu bekommen, ist die Einführung von Plattform Engineering. Das Konzept basiert auf der Idee, alle Entwicklerteams durch eine zentrale Plattform bei ihrer Arbeit zu unterstützen. Die Plattform besteht aus verschiedenen Werkzeugen, deren Nutzung vorgeschrieben wird, um somit Einheitlichkeit herzustellen.

Die Einführung einer solchen Plattform ist eine Gratwanderung, da die Einschränkung der Freiheiten in der Entwicklung immer zu Spannungen führt. Es kommt darauf an, Werkzeuge und Unterstützungen zu schaffen, deren Mehrwert die Einschränkung übersteigt!

Als erstes bietet sich die Einführung von Architekturmodulen an, die einen oder mehrere Cloud Services bündeln. Als AWS-Beispiel könnte hier eine vorbereitete Kombination von API Gateway, Lambda-Funktion und DynamoDB dienen, welche einen Statefull-Serverless-Dienst ergeben. Das Architektur-Modul nutzt Infrastructure as Code (IaC), um die Services zu konfigurieren. Der Mehrwert entsteht, indem Sicherheit, Skalierbarkeit, Resilienz, Autorisierung, Compliance und Governance direkt und unveränderlich in der IaC-Konfiguration festgeschrieben sind. Das Entwicklerteam muss lediglich einen Namen und die Quelle des auszuführenden Codes festlegen. Für die Realisierung solcher Architekturmodule kann zum Beispiel das modular aufgebaute Terraform genutzt werden, das Abstraktion, Wiederverwendung und Versionierung bietet.

Das zweite Werkzeug für Plattform Engineering dreht sich um die Automatisierung. Hierzu werden CI/CD-Werkzeuge wie beispielsweise Gitlab und Github verwendet, deren Pipelines genutzt werden, um Software- und Cloud-Infrastrukturen zu bauen beziehungsweise zu provisionieren. Diese Pipelines basieren auf Skripten, die ebenfalls gerne von jedem Team unterschiedlich gehandhabt werden. Durch die Einführung und flächendeckende Nutzung von Pipeline-Templates kann dies jedoch vermieden werden. Gleichzeitig können beispielsweise Vorschriften zu CVE Checks, Copy-Left, Multi-Arch Builds oder ähnliches zentral festgelegt und propagiert werden. Templating wird von den meisten CI/CD-Tools unterstützt, sodass die Einführung erleichtert wird.

Durch die Zentralisierung von Architektur Modulen und Pipelines können bereits viele querschneidende Belange gelöst werden. Gleichzeitig wird die Möglichkeit geschaffen, neue Anforderungen (zum Beispiel an Sicherheit) an einer einzigen Stelle einzufügen und direkt global auszurollen.

Bild von DC Studio auf Freepik