Lesezeit: 2 Minuten

 

Teil 5 - Einfluss von Cloud-native auf die Architekturarbeit

Wie wir gesehen haben, bieten Cloud-native Architekturen neue Möglichkeiten Dinge zu tun, bzw. anders zu tun, als dies bislang möglich war und unterliegen einer eigenen Philosophie bezüglich des Designs und bei der Umsetzung passender Software-Architekturen. Dafür betrachten wir zum einen die technischen Aspekte, müssen uns andererseits aber auch um fachliche und organisatorische Facetten kümmern, um die neuen Möglichkeiten auch wirklich gewinnbringend nutzen zu können.

Verteilte Architekturen auf dem Vormarsch

Dank des zwischenzeitlich erreichten Reifegrads in Bezug auf die Technologien, haben Softwarearchitekten einen wesentlich größeren Werkzeugkoffer zur Hand, um die Qualität eines Systems beeinflussen zu können. Aufgrund der Betriebsaufwände früher noch undenkbar, werden in diesem Umfeld zunehmend verteilte Systeme entworfen, um einzelne Systembestandteile hinsichtlich besonderer nicht-funktionaler Anforderungen optimieren zu können.

Neben der klassischen, monolithisch geprägten Architektur entstehen mehr und mehr verteilte Architekturen (Microservice Architecture) bzw. ereignisbasierte Architekturen (Event Driven Architecture).

Man wählt diese Architekturen, um sowohl neue Systeme zu implementieren, als auch um bestehende Legacy-Systeme schrittweise zu modernisieren. Letzteres erreicht man z.B. durch den Einsatz des Strangler-Fig Pattern, um einzelne Systembestandteile zu separieren und neu entwickelte Cloud-native basierte Systeme zu ersetzen.
Dabei hat sich die Vorgehensweise etabliert, bei der Modernisierung im ersten Schritt Cloud-tauglich (Cloud-ready) und im zweiten Schritt Cloud-native zu werden.

Keine Scheu vor einem Re-Design

Die Architekturarbeit birgt allerdings auch diverse Tücken, wie der zunehmende Einfluss von Lean Product Management als Vorgehensmodell zeigt.

So macht es keinen Sinn, sich in frühen Phasen des Systemdesigns (Walking Skeleton, Prototyping) zu intensiv mit der Performance und der Skalierung zu beschäftigen, wenn damit die funktionale Reifung des Produkts verlangsamt wird.

Nach dem Initial Product Release bzw. in der MVP Phase ergeben sich in der Regel aber viele neue Erkenntnisse, die häufig ein Überdenken der Architektur (und ggf. auch Technologieänderungen) unumgänglich machen.

Die Rolle des Softwarearchitekten

Früher waren Softwarearchitekten ggf. noch vorrangig mit der Modularisierung und Strukturierung monolithischer Codebasen beschäftigt (u.a. durch Einsatz des UML-Standards). In einer zunehmend agilen Umgebung und damit einhergehend mit der sich stetig verändernden fachlichen Realität, müssen sich Softwarearchitekten weiterentwickeln und sich neuer Methoden bedienen. Oft gilt es, den idealen Service-Schnitt zu finden, den der auf Cloud-Technologien ausgerichtete Softwarearchitekt mit Hilfe von folgenden Kriterien und Methoden abwägen sollte:

• Domain-Driven-Design und Event-Storming Ziel des DDD ist der fachliche Schnitt des zu entwickelnden Softwaresystems. Damit ist in der Regel auch ein IT/Business-Alignment verbunden, dass man auch als Inverse Conway Manöver bezeichnet. Die Methode des Event-Storming dient dazu die Gemeinsame Sprache der Fachdomäne zu erschließen und wird auch dafür genutzt Subdomänen und Bounded Contexts zu identifizieren.
• Organisatorischer Schnitt
• Der oder die Serviceschnitte müssen zu den Teamgrößen passen. Hier lohnt es sich, sich mit Team-Topologien zu beschäftigen, um die Kognitive Last der Teams nicht zu überschreiten und sich zu überlegen, wie diese Teams dann zusammenarbeiten sollen.
• Sonstige Rahmenbedingungen
• Limitierungen durch die Technologiewahl, die Auswahl von 3rd Party Vendoren oder das Outsourcing mit Hilfe von APIs, usw. sind weitere Aspekte, die es abzuwägen gilt.

Die richtige API-Verwaltung

Neben dem optimalen Service-Schnitt spielt auch die Wahl der passenden Kommunikationsstile (synchron vs. asynchron) und der eingesetzten Protokolle eine wichtige Rolle.

Um Kommunikationsbeziehungen stabil zu halten, ist es sinnvoll, die entsprechenden APIs und deren Lebenszyklen bewusst zu verwalten (Provider und Consumer Prozess) und Änderungen der APIs angemessen zu kommunizieren.

Die Steuerung des API-Lebenszyklus, das Exponieren der Services über Gateways, aber auch das Provisionieren von API Keys sollten ohne manuelle Aufwände innerhalb von CI/CD Toolchains erfolgen. Für komplexe Service-Landschaften gibt es den Ansatz des Service Mesh (wie z.B. Consul, Linkerd oder Istio), mit denen sich die Verwaltung deutlich vereinfachen und vor allem gut dokumentieren lässt.

Der richtige organisatorische und prozessuale Umgang mit APIs ist das A und O beim Aufbau von verteilten Systemen und ein Garant für ein schnelles Wachstum des sinnvoll genutzten Portfolios an Services.

Das sechste und letzte Kapitel "Die Architektenrolle in DevOps-Teams/Organisationen" gibt es im nächsten Blogbeitrag am 5. Januar 2023 zu lesen.