Kontext-getriebene Architektur
Eine gute Architektur ist Kontext-getrieben
Kontext-getriebene Architektur am Beispiel von Microservices
Qualität von Architektur zeigt sich, wenn sie im Spannungsfeld der Ziele besteht
und über die Zeit anpassbar ist an Neuerungen der Technologie und der Fachlichkeit.
Gute Architektur kommt nicht von der Stange, sondern passt zum Kontext. Dies erläutern wir nachfolgend am Beispiel Microservices.
Orientierung an Ziel und Zweck
Eine Architektur muss zuallererst die Umsetzung der gegebenen Anforderungen zuverlässig gewährleisten, sonst würde sie ihren Zweck verfehlen. Qualitätsziele – sogenannte Non-Functional Requirements (NFR) wie Performanz oder Skalierbarkeit – sind dann ebenfalls zu erfüllen. Als Analogie hilft das Bild einer Brücke: Sie ist nicht um ihrer selbst willen gebaut, sondern um einen konkreten Nutzen zu erbringen, nämlich funktionale Requirements. Sie muss hierbei auch die Last zuverlässig tragen und ausreichend Sicherheitsreserven bereitstellen, sprich nicht-funktionale Requirements (NFR) erfüllen. Unzerstörbarkeit und das neueste Material alleine reichen nicht – wenn man sie nicht sicher überqueren kann, ist es keine Brücke
Beispiel Microservices
Die Komplexität beherrschen
Microservices haben sich in den letzten Jahren als de-facto Standard bei der Realisierung neuer Systeme etabliert. Durch die Betrachtung aller für eine Architektur relevanten Aspekte kommt man zu einer fundierten Einschätzung, ob Microservices für den aktuellen Kontext der richtige Ansatz sind – und welche Trade-offs dabei in Kauf genommen werden.
Um einen Microservice zu bauen, kommen spezialisierte Frameworks zum Einsatz wie z.B. Spring Boot, Quarkus, die grundlegende Funktionalitäten bereitstellen. Entscheidender ist jedoch die Frage, wie die Komplexität eines Verbundes von Microservices beherrschbar betrieben werden kann. Hierfür benötigt man eine Infrastruktur, die das Monitoring der Service-Instanzen, sowie deren Skalierung unterstützt (wie z.B Kubernetes, Open Shift). Für die Qualität sind u.a. Architektur-Pattern relevant, welche die Resilienz sicherstellen (wie z.B. Bulkheads, Circuit breaker), denn in verteilten Systemen kann man sich nicht darauf verlassen, dass der Schnittstellen-Partner immer verfügbar ist.
Wir empfehlen folgende Quellen zu Microservices:
Martin Fowler: https://martinfowler.com/microservices/
Sam Newman: https://samnewman.io/talks/principles-of-microservices/
Spannende Artikel zu Microservices finden Sie auf unserer Medien-Seite.
Nachhaltigkeit durch Änderbarkeit
Dass sich Anforderungen (und damit auch Qualitätsziele) im Lauf der Zeit ändern, darf als gegeben vorausgesetzt werden. Eine gute, Kontext-getriebene Architektur antizipiert dies, und zeichnet sich durch Anpassbarkeit (siehe Sylvia Stuurman: „Design for Change“) aus. Nachhaltige Stabilität bedeutet, dass die Lösung mit veränderter Nutzung, neuen Rahmenbedingungen oder anderen Anwendern umgehen kann. Bleibt die Lösung stabil, auch wenn sich der Traffic erhöht? Trägt sie auch noch in 10 Jahren, ohne wie ein „Kartenhaus“ zusammenzufallen?
Beispiel Microservices
Isolierte Changes – sofern der Schnitt gut ist
Ein einzelner Microservice ist sehr schnell änderbar, da er für sich betrachtet wenig komplex ist („micro“) und mit separatem Deployment in einem getrennten Container betrieben wird. Allerdings betrifft dies nicht den Schnitt des Systems in Microservices, hierfür gilt: „Cutting is easier than glueing“. Will man den Schnitt von Microservices nachträglich ändern, muss man potenziell mit viel Aufwand rechnen. Eine stabile, Kontext-getriebene Architektur führt direkt zu einem Schnitt/Aufbau, der nachhaltig und damit auch wartbar ist.
Es geht primär um Struktur, nicht um Technologie
Technologien ändern sich im Laufe der Zeit. Was vor einigen Jahren noch SOAP Web-Services und JEE Application Server waren, sind heute REST Services und Spring Boot Applikationen. Und morgen?
Architektur geht über die reine Technologiefrage hinaus: entscheidend ist eine klare Struktur, nicht mit welcher Schnittstellen-Technologie ein Service Adapter bereitgestellt wird.
Eine Architektur wird nachhaltig, indem sie solche Abhängigkeiten minimiert, und einen „Lock-In“ auf eine bestimmte Plattform oder ein Framework vermeidet (siehe z.B. Wikipedia: Vendor Lock-In)
Deutlich wird das u.a. bei Frontend-Architekturen, die heute in unterschiedlichsten Geschmacksrichtungen daherkommen. Hat man sich allerdings einmal z.B. für Angular entschieden, ist der spätere Wechsel zu einem anderen Framework nur unter hohen Kosten und Risiken zu realisieren. So schnell, wie sich Frontend-Technologien ändern, ist das heiße Ding von heute schnell der Klotz am Bein von morgen.
Beispiel Microservices
Strukturierung in Vertical Components
Zur Reduzierung der Komplexität werden große Systeme in kleine Komponenten zerlegt. Diese sogenannten „Vertical Components“ sind nach fachlichen Gesichtspunkten geschnitten, die jeweils eine möglichst in sich abgeschlossene fachliche Domäne kapseln. Die primäre Struktur folgt also keinen technischen Schichten (Presentation, Service, Persistence), vielmehr trägt jeder Microservice diese Schichten in sich. Hat man die fachliche Struktur erst einmal gefunden, wird es möglich, in den separaten Microservices unabhängige Technologieentscheidungen zu treffen und damit die Gefahr eines Lock-in deutlich zu reduzieren.
Architektur passt zur Organisation
Für eine nachhaltige, Kontext-getriebene Architektur sollten auch Aspekte wie Organisation, Team und Kultur im Blick behalten werden. Schon „Conway‘s Law“ beschreibt die Abhängigkeit von Architektur und Organisation: Es bezeichnet die Beobachtung, dass Informationssysteme gleichartig zu der sie erzeugenden Umwelt gegliedert sind: in Organisation wie Systemlandschaften finden sich „dieselben Silos“.
Beispiel Microservices
Kleine Teams bauen kleine Services
Da Microservices unabhängig und in sich abgeschlossen sein sollen, sind für ihre Realisierung agile, selbststeuernde und autarke Teams am besten geeignet. Die Verantwortung dieser Teams geht durchgängig von Design über Entwicklung bis hin zum Betrieb (DevOps).
Hier wird deutlich, dass dieser Ansatz der Kontext-getriebenen Architektur mehr ist als „nur Technik“. Aus „Conway‘s Law“ wird hier eine „service-orientierte Organisation“ abgeleitet, nämlich kleine autarke Teams, die kleine autarke Microservices bauen und betreiben. Dieser Anspruch muss zur Organisation insgesamt passen und auch mit dem Management und den Entscheidungsprozessen durchführbar sein. Zusätzlich sind die Mitarbeiter gefordert, sich in eine solche Organisationsform einzupassen.
Alles hat seinen Preis - Trade-Off Entscheidungen
Wie zuvor beschrieben gibt es Anforderungen und Rahmenbedingungen u.a. aus den Aspekten Technologie, Struktur und Organisation, die bei der Kontext-getriebenen Architektur zu berücksichtigen sind. Es steht zu erwarten, dass diese Anforderungen nicht immer in die gleiche Richtung laufen und sich sogar widersprechen können.
Es ist die Aufgabe des Architekten, widerstreitende Ziele in Einklang zu bringen. Fordert man von Software einfache und schnelle Anpassbarkeit, muss man dafür spezielle Mechanismen entwerfen und implementieren. Das führt zu höherer Komplexität und damit auch zu Mehrkosten. Also sind sorgfältige Trade-Off Entscheidungen darüber notwendig, wo genau welcher Grad der Anpassbarkeit benötigt wird.
Beispiel Microservices
Vor- und Nachteile abwägen
Sind Microservices das einzig Wahre? Hier gilt es, befreit von Hypes die Vor- und Nachteile abzuwägen. Im Gegensatz zu einer „klassisch“ monolithischen Anwendung bringen Microservices als hoch-verteilter System-Verbund eine deutlich gestiegene Komplexität mit sich. Allein die Schnittstellen zwischen den Services sind zu definieren und zu orchestrieren. Zusätzlich erhält man mehr deploybare Einheiten, die durch sichere Mechanismen abgeschottet und vor Ausfällen der anderen Komponenten bewahrt werden müssen. Hinzu kommt die Aufgabe der Integration in der UI-Schicht, sowie die Aufrechterhaltung der Konsistenz auf der Datenebene.
Auf der anderen Seite bekommt man auch etwas dafür: die kleineren Services lassen sich schneller anpassen, und unabhängig voneinander in Produktion bringen. Man gewinnt also Schnelligkeit und Flexibilität im Trade-off mit mehr Komplexität.
Als die Industrialisierung Fahrt aufnahm, gab es einen neuen Trend: Hosen in einer Standardgröße von der Stange. Inzwischen hat man gelernt, dass verschiedene Größen eine sehr gute Idee sind. Wenn das für Ihre Hose gilt, wieso denken sie dann, dass eine „Standard-Architektur“ eine gute Idee ist?
Maßgeschneidert für den Kontext
Im Unternehmenskontext gibt es eine Vielzahl von Anwendungen, die sich alle in unterschiedlichen Phasen ihres Lebenszyklus befinden. Eine nachhaltige Enterprise Architektur zeichnet sich durch eine differenzierte Betrachtung anstatt eines „one size fits all“ Ansatzes aus und ist damit eine Kontext-getriebene Architektur. Es ist z.B. fragwürdig eine Legacy Komponente „auf links zu drehen“, nur um ohne fachliche Notwendigkeit deren technische Basis auszutauschen.
Stattdessen sollten die Fragen lauten: Ist die Architektur noch „gesund“? Sind Stabilität und Integration in die Systemlandschaft hinreichend gegeben? „Alt“ heißt nicht zwingend „schlecht“ – genauso wenig heißt „neu“ nicht zwingend „gut“. Die gewählte Technologie muss auch in 5 Jahren noch relevant sein. „Alt“ kann veralten, d.h. es findet keine Pflege und Weiterentwicklung mehr statt, und es gibt keine Upgrade-Pfade mehr. „Neu“ kann sich nicht durchsetzen, was heute Hype ist, hat oft keine hinreichende Marktabdeckung. Auch wird man in Zukunft Mitarbeiter benötigen, die sie einsetzen können (und wollen). Somit ist auch die Frage der Skills, der Weiterbildung und der Marktentwicklung von Interesse. Um zu überprüfen, ob eine Architektur noch den aktuellen Anforderungen entspricht, hat sich der Ansatz eines Architektur-Audits bewährt.
Beispiel Microservices
Wo passen Microservices?
Die Microservice-Architektur dient genau dazu, schnell auf sich ändernde Anforderungen reagieren zu können, und zwar dort wo Kosten und Komplexität eines stark verteilten Systems tolerierbar sind. Der Kontext ist eine service-orientierte Organisation, die in agile DevOps Teams gegliedert ist.
Immer in dem Kontext, in dem man rapide sich ändernde Anforderungen hat (auf die man auch schnell reagieren möchte) und wenn eine Aufteilung der Fachdomäne in fachlich unabhängige Services gut möglich ist, kann eine Microservice-Architektur sinnvoll sein. Dem muss man gegenüber halten, dass die gestiegenen Kosten und die höhere Komplexität vertretbar und managebar sein müssen.
Diese Bedingungen sind mit Sicherheit nicht überall gegeben. Daher: „No silver bullet“– auch das Microservices Paradigma passt nicht überall.
Fazit
Architektur ist nicht nur die Suche nach den richtigen Komponenten und den passenden Technologien: sie umfasst viele verschiedene (siehe Bild rechts) Aspekte – den Kontext. Die passgenaue Ausrichtung auf diesen in Teilen widersprüchlichen Kontext ist es, was eine ausgewogene und vollständige Architektur ausmacht, und somit zu einer Kontext-getriebenen Architektur führt.
Allein schon aus diesem Grund ist eine „Standardarchitektur“ – was auch immer das sein mag – häufig keine gute Idee. Denn eine solche Standardarchitektur ist blind für den speziellen Kontext. Sie weiß nichts von den Zielen des aktuellen Projekts und kennt nicht dessen individuelle Anforderungen.
Um den Kontext mit der Architektur in Einklang zu bringen, sind Trade-off-Entscheidungen nötig. Diese Entscheidungen bewusst zu fällen, zu begründen und zu dokumentieren ist eine wichtige Aufgabe des Architekten. Dabei sind aktuell angesagte Paradigmen zu hinterfragen, genauso wie Althergebrachtes und das, was man glaubt gut verstanden zu haben.
