Stefan Zörner 05. Oktober 2021

Architekturstile und -prinzipien in Zeiten von Containern und der Cloud

Über einen Stil lässt sich reden. Über seinen angemessenen Einsatz diskutieren. © Adobe: Manolo Gargano / stock.adobe.com / 238011443 — © Adobe: Manolo Gargano

Container und Orchestrierungslösungen wie Kubernetes halten Einzug in Unternehmen und Organisationen, manche Experten bezeichnen die Cloud schon länger als "das neue Normal". Hat das Auswirkung auf den Anwendungsentwurf? Dieser Beitrag diskutiert etablierte und aufstrebende Architekturstile und -prinzipien im Licht der neuen technischen Möglichkeiten. Er zeigt zentrale Fragestellungen bezüglich Strukturierung und Technologieauswahl entlang eines Beispiels auf und unterstützt Sie und Ihr Team dabei, diese passend zu Ihren Zielen und Vorgaben zu beantworten.

Vergleiche zwischen Realarchitektur und Softwarearchitektur hinken in der Regel. Im Einzelfall versperren solche Analogien sogar den zeitgemäßen Blick darauf, wie Softwarelösungen heute entstehen, wachsen und sich weiterentwickeln. Das betrifft zum Beispiel die strikte Trennung zwischen Planungs- und Bauphase aus der klassischen Bauarchitektur. Oder auch damit verbundene Rollenverständnisse (Architektin/Bauarbeiter vs. Softwarearchitektin/-entwickler). Derartige Übertragungen fallen aus der Zeit.

Beim Begriff des Architekturstils (oder alternativ des Baustils) verhält es sich meiner Meinung nach jedoch anders. Wir benutzen ihn auch in der modernen Softwarearchitektur gern. Und wir tun es aus sehr ähnlichen Gründen wie in der "analogen" Architektur. Ich finde den Begriff "Stil" inklusive der Analogie zum Bauen nützlich. Lassen Sie mich kurz erklären, warum...

Barock, Moderne, Microservices …

Zunächst einmal sind Architekturstile ungemein praktisch für eine effiziente Kommunikation. Bei Wikipedia steht "Der Kölner Dom ist eine der größten Kathedralen im gotischen Baustil" und mit "gotisch" ist schon viel gesagt ("weitgehende Durchbrechung der Außenwandflächen durch Fenster mit Spitzbögen, Reduzierung der Wandstärken…") — vorausgesetzt der oder die Lesende weiß, was Gotik bedeutet.

Der Satz "Unsere neue Schaden-Anwendung ist eine Microservices-Lösung…" funktioniert ähnlich gut ("unabhängig deploybare, sehr lose gekoppelte Teile, große technologische Freiheiten in der Umsetzung…"). Aber auch hier natürlich nur, wenn der Architekturstil bekannt ist, und es ein einheitliches Verständnis dafür gibt.

Abb. 1: Ausgewählte Bücher zu Architekturstilen in Software und in echt. © Diverse

Über einen Stil lässt sich reden. Über seinen angemessenen Einsatz diskutieren. Neue Stile fördern den Austausch unter Softwareentwicklerinnen und -entwicklern in Form von Konferenzen, Blog-Beiträgen oder Büchern (s. Abb. 1).

Architekturstile in der Softwareentwicklung

Ganz ähnlich wie bei Bauwerken ist der Architekturstil in der Softwarearchitektur ein Trendthema. Gleichzeitig wechseln die Vorlieben hier naturgemäß etwas schneller. Beim Barock reden wir über Jahrhunderte, bei SOA eher über Jahrzehnte.

Aber was genau ist eigentlich ein Architekturstil in Software? Rozanski und Woods definieren den Begriff so: "Ein Architekturstil drückt ein grundlegendes Organisationsschema für Softwaresysteme aus. Er stellt eine Reihe vordefinierter Elementtypen bereit, spezifiziert ihre Verantwortlichkeiten und enthält Regeln und Richtlinien für die Organisation der Beziehungen zwischen ihnen." [1] Bei den Elementtypen kann es sich um Module, Teilsysteme, Schichten, Services handeln, bei den Regeln etwa um Prinzipien (dazu später mehr) oder Abhängigkeitsrichtungen.

Ein Stil etabliert also (Strukturierungs-)begriffe und (Bau-)prinzipien. Das klingt im ersten Moment strikt, kann gleichzeitig aber auch einen Rahmen für eine verteilt agierende, zielgerichtete Entwicklung schaffen. Denken Sie an Trendthemen wie Microservices oder Conway’s Law. Abb. 2 zeigt eine kleine Stilkunde für Softwaresysteme und nennt Elementtypen und Architektur-Ikonen. Was der Kölner Dom für die Gotik ist oder das Opernhaus in Sydney für die Moderne, das ist Netflix für Microservices.

Abb. 2: Architekturstile für Softwaresysteme im Überblick. © embarc

Das deutsche Corona-Warn-App-System

Von abstrakten Stilbegriffen zu einer konkreten, zeitgenössischen Softwarelösung: Das deutsche Corona-Warn-App-System (im Folgenden kurz CWA) ging im Juni 2020 vorrangig mit dem Ziel an den Start, Infektionsketten des SARS-CoV-2 (COVID-19-Auslöser) nachzuverfolgen und zu unterbrechen. Die nativen iOS- und Android-Apps basieren auf Technologien mit einem dezentralisierten Ansatz und informieren Personen, wenn sie mit einer infizierten Person in Kontakt standen [2].

Die CWA besteht nicht nur aus den recht prominenten Apps, die Sie vielleicht auch auf Ihrem Smartphone installiert haben. Zur Umsetzung wichtiger Use Cases wie der Benachrichtigung bei (positiven) Testergebnissen, beim Warnen oder dem Austausch mit Warn-Systemen anderer Länder, gehört auch eine vielteilige Server-Lösung. Die CWA wird Open Source entwickelt, neben dem Quelltext liegt auch einiges an Dokumentation offen, von Anforderungen (z. B. User Journey und Epics) bis hin zu detaillierten Ablaufdiagrammen. Jeder kann sie einsehen. Abb. 3 zeigt einen informellen Architekturüberblick über das Gesamtsystem, der bei uns im Rahmen eines Architektur-Reviews entstanden ist [3].

Abb. 3: Corona-Warn-App-System im Überblick, Stand April 2021. © embarc

Die Zerlegung in Abb. 3 wirft die Frage auf, um was für einen Stil es sich bei der CWA handelt. Mit etwas Abstand betrachtet können wir von einer Client-Server-Architektur sprechen, mit den nativen Apps für die Smartphones als Clients und dem Backend als Server. Ein Blick auf die Vertikalen im Backend (Block "Public Cloud") legt Microservices nahe, und tatsächlich fällt dieser Begriff in Diskussionen zur CWA häufiger. Handelt es sich beim CWA-Backend tatsächlich um Microservices?

Architekturstile und -prinzipien am Beispiel Microservices

James Lewis und Martin Fowler definierten Microservices bereits 2014 in einem gemeinsamen Blogbeitrag so: "Kurz gesagt, der Microservice-Architekturstil ist ein Ansatz zur Entwicklung einer einzelnen Anwendung als einer Familie kleiner Services, die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren." [4]

Im Verlauf des Beitrags benennen die beiden Autoren eine Reihe von Eigenschaften oder Merkmalen als charakteristisch für den Architekturstil, und führen sie weiter aus – die Prinzipien von Microservices:

Zerlegung in Services
Organisiert um Geschäftsfähigkeiten
Produkte, nicht Projekte
Intelligente Endpunkte, "dumme" Verbindungen
Dezentrale Steuerung
Dezentrales Datenmanagement
Infrastruktur-Automatisierung
Design für Störungen
Evolutionäres Design

Nicht alle Microservice-Architekturen weisen alle diese Merkmale auf. James Lewis und Martin Fowler erwarten aber, dass die meisten Microservice-Architekturen die meisten der obigen Merkmale zeigen. Schauen wir uns das Backend des CWA-Systems in diesem Sinne einmal an! Entspricht es dem Microservices-Stil?

Abb. 4 hält die Backend-Architektur der CWA gegen die charakteristischen Eigenschaften und bewertet in Form einer Spinnennetzgraphik, zu welchem Grad die CWA sie jeweils einhält.

Abb. 4: Abgleich des CWA-Backends gegen Merkmale von Microservices. © embarc

Eine ganze Reihe der charakteristischen Eigenschaften sind für das Backend der CWA klar erfüllt. Hierzu zählt insbesondere die fachliche Zerlegung in Services. Einzelne Punkte sind für die CWA von außen bzw. nur mit dem Blick auf die öffentliche Dokumentation und den Quelltext schwer zu bewerten.

Darunter fällt beispielsweise die dezentrale Steuerung (engl.: Governance). Ein Indiz für technologische Freiheit könnte ein bunter Strauß verwendeter Technologien sein. Im Gegenteil sind die Services im Backend aber alle in Java mit Spring Boot realisiert, die Persistence ist stets PostgreSQL, es wird durchgängig mit Maven gebaut, und vieles mehr. Ob es klare Vorgaben (Governance) dazu für die Entwicklungsteams gab, ist mir nicht bekannt.

Bei der Infrastruktur-Automatisierung ist eine Einschätzung ebenfalls schwierig, weil über den Betrieb der CWA in der Open Telekom Cloud nur wenige Informationen vorliegen. Das Potential ist aufgrund der gewählten Technologien aber mehr als gegeben. Andere Merkmale sind leichter als gut erfüllt zu bewerten. Hierzu zählt das Design für Störungen. Es lassen sich im CWA-Backend Muster für Resilience verorten (z. B. Circuit Breaker [5]), das Aufbereiten von Daten zeitgesteuert per Batch, und deren Bereitstellung für die Clients mit Hilfe eines Content Delivery Networks.

Beim dezentralen Datenmanagement haben die einzelnen Server-Blöcke (Data Donation Server, Test Result Server…) jeweils ein eigenes Datenbankschema. Die Services im sogenannten CWA-Server (Submission Service, Distribution Service…) teilen sich aber beispielsweise eine gemeinsame Datenbank. Daher ist die Einschätzung dort nicht "voll erfüllt", sondern nur 7/10. Auch wenn die Definition von Lewis und Fowler nicht sonderlich scharf ist, und eine Bewertung bei einzelnen Merkmalen schwierig, so folgt das CWA-Backend meiner Einschätzung nach dem Microservices-Stil. Aber passen Microservices eigentlich zur Corona-Warn-App?

Stilfrage

Die Stile aus Abb. 2 unterscheiden sich vor allem in der Granularität – von einer einzelnen, großen Deployment-Einheit (Modulith) bis zu sehr kleinteiligen Lösungen (Serverless). Die Stile schließen sich nicht aus, sondern sind zu einem gewissen Grad kombinierbar. So hatten wir beim CWA-Gesamtsystem Client/Server und im Backend Microservices identifiziert.

Um den prägenden Stil für eine neue Anwendung auszuwählen, sind die maßgeblichen architekturrelevanten Anforderungen entscheidend. Hierzu zählen Vorgaben technischer und organisatorischer Art. Tabelle 1 zeigt hierzu exemplarisch ausgewählte Maßgaben an Entwicklung und Betrieb der CWA, sowie Informationen zum politischen Umfeld.

Tabelle 1: Ausgewählte Maßgaben für das Corona-Warn-App-System [6]

Vorgabe	Kategorie
Entwicklung von nativen, mobilen Clients für Android- und iOS-Smartphones	Technisch
Verfolgen eines dezentralen Ansatzes für die Datenspeicherung	Technisch
Einsatz des Exposure Notification Framework von Google und Apple	Technisch
Betrieb der Backend-Komponenten in der Open Telekom Cloud	Technisch
Auftraggeber: Deutsche Bundesregierung	Organisatorisch
Entwicklung und Betrieb durch ein Konsortium aus zwei Auftragnehmern (SAP und Deutsche Telekom)	Organisatorisch
Start der Entwicklung 04/2020, enger Zeitrahmen (Apps verfügbar ab 06/2020)	Organisatorisch
viele Parteien involviert (Ministerien, Behörden, RKI...)	Organisatorisch

Client/Server lässt sich aus den Vorgaben ableiten, aber direkt Argumente für Microservices im Backend fallen nicht ab. Im Gegenteil legt der enge Zeitrahmen für die Entwicklung eher eine möglichst einfach zu bauende und zu betreibende Lösung nahe. Beim Blick auf die Qualitätsziele, den neben den Vorgaben wichtigsten architekturrelevanten Anforderungen, der CWA in Tabelle 2 finden sich hingegen Argumente für Microservices.

Tabelle 2: Qualitätsziele für das Corona-Warn-App-System [6]

Qualitätsziel	Beschreibung
Höchster Datenschutz	Der Schutz der personenbezogenen Daten hat oberste Priorität.
Effektive Warnfunktionalität	Die App ist ein effektiver Baustein bei der Pandemie-Bekämpfung.
Attraktive Lösung für App-Nutzer	Die App ist leicht zu installieren sowie intuitiv und effizient zu bedienen.
Hohe Zuverlässigkeit	Die Lösung geht mit Lastspitzen wegen hoher Nutzer- oder Infektionszahlen ebenso souverän um, wie mit böswilligen Angriffen.
Gute Wartbarkeit	Die Software lässt sich leicht anpassen, wenn z. B. Nutzer:innen, Politik oder neue Forschungsergebnisse es erfordern.

So trägt die Modularisierung in unabhängige Services zur Zuverlässigkeit und zur Erweiterbarkeit bei. Unterschiedliche Systemteile lassen sich bei Bedarf einzeln skalieren, Teilausfälle können gut aufgefangen werden. Und das Hinzufügen weiterer Funktionalität auf Serverseite durch weitere, unabhängige Services wurde seit Produktionsstart der CWA im Juni 2020 eifrig genutzt – die Datenspende oder der digitale Impfnachweis sind konkrete Beispiele.

Von besonderer Bedeutung für die Auswahl des Architekturstils ist neben den Qualitätszielen die Zielumgebung, d. h. der "Ort", wo die Software läuft. Bei der CWA waren Smartphones für die Apps und die Open Telekom Cloud für das Backend Vorgaben. Beim Vorhaben Ihres Teams kann das anders aussehen, und vielleicht haben Sie Entscheidungsspielraum. Den entscheidenden Unterschied machen meiner Erfahrung nach die Antwort auf folgende Fragen aus:

Betreiben wir die Software selbst, oder unser Kunde, oder – falls wir Standardsoftware herstellen – unsere vielen Kunden? (im eigenen Rechenzentrum, in einer Cloud, SaaS …)
Wie anpassbar muss unsere Software sein? – auch hier: nur für uns? Oder für unsere Kunden – ggf. sogar unterschiedlich? (Mandantenfähigkeit, Kleinteiligkeit)
Haben einzelne Systemteile signifikant andere Anforderungen als andere (z. B. bzgl. Lastschwankungen über die Zeit) und sollten sie daher separat skaliert und/oder technologisch völlig anders gebaut werden?

Das ist der Moment, wo bei Informationssystemen Container-Technologien, Orchestrierungs- und Cloud-Lösungen als Lösungsoptionen ins Spiel kommen. Besonders kleinteilige, verteilte und technologisch bunte Anwendungen sind ohne solche Ansätze und ein hohes Maß an Automatisierung kaum zu betreiben. Aber beherrschen unsere Kunden diese Technologien überhaupt? Sind wir selbst dazu in der Lage?

Wesentliche Fragen zur Zerlegung

Es reicht nicht aus, den prägenden Architekturstil zu benennen – Sie und Ihr Team müssen ihn präzisieren. Das ist allein schon deswegen nötig, weil die Stile nicht superscharf formuliert sind, wie wir das bei den Microservices ja gesehen haben. Sie lassen Spielraum – auch in den Zerlegungsbegriffen. Im Kern folgen Sie daher am besten Simon Brown, der bei seinen Ausführungen zum C4-Modell folgendes vorschlägt: "Einigen Sie sich im Team auf eine einfache Reihe von Abstraktionen, die das gesamte Team zur Kommunikation verwenden kann." [7]

Im Falle des CWA-Systems wären das auf oberster Ebene die Apps (iOS und Android) und das serverseitige Backend. Das Backend zerfällt in mehrere Server, die wiederum Services enthalten. Abb. 3 zeigt diese Struktur, wobei in der Zwischenzeit (seit April 2021) weitere Server und Services hinzugekommen sind. Für den sogenannten CWA-Server, der die Diagnoseschlüssel positiv getesteter entgegen nimmt ("Submission") und sie mit anderen Nutzern teilt ("Distribution"), sind auch die wesentlichen Services dargestellt.

Die Zerlegungsbegriffe bilden Sie im nächsten Schritt auf die technische Nomenklatur Ihrer Zielumgebung ab. In unserem CWA-Beispiel ist das bei den Apps einfach, sie landen auf den entsprechenden Smartphones. Für das Backend zeigt Abb. 5 zur Illustration ein grafisches Glossar mit der Begriffswelt von Kubernetes. Vom Backend der CWA wissen wir, dass es innerhalb der Open Telekom Cloud auf Kubernetes betrieben wird. Den Quelltexten (genauer: den Dockerfiles) entnehmen wir, dass ein Container stets einen CWA-Backend-Service enthält. Uns liegen keine detaillierteren Informationen zu Deployment und Betrieb der CWA vor, so dass ich die Zuordnung zu weiteren Kubernetes-Begriffen hier leider nicht wiedergeben kann. Die in GitHub vorliegenden Docker-Compose-Dateien dienen lediglich Testzwecken.

Falls Ihre Lösung auch auf Kubernetes läuft, sind insbesondere die Zuordnung ihrer Zerlegungsbegriffe zu Pod, Namespace und Deployment wichtig. Bei der CWA vermute ich, dass bestimmte Batch-Services als Job in Kubernetes laufen. Andere Zielumgebungen (z. B. ein Java EE-konformer Applikationsserver) konfrontieren Sie mit einer anderen Nomenklatur (Application, Module, Component, Library …), auf die Sie Ihre Zerlegungsbegriffe abbilden.

Abb. 5: Die Begriffswelt von Kubernetes als grafisches Glossar. © embarc

Wesentliche Fragen der Technik

Mit den Zerlegungsbegriffen im Gepäck sind Sie und Ihr Team nun in der Lage, das Konzept der Makro- und Mikro-Architektur anzuwenden. Hierbei geht es um die Idee, dass es in einem Softwaresystem zwei Ebenen von Architekturentscheidungen gibt. Eine Ebene beschreibt Aspekte, die für alle Teile der Lösung auf oberster Ebene gleich sind (Makro-Architektur). Innerhalb eines Teils kann das verantwortliche Entwicklungsteam andere Aspekte individuell entscheiden (Mikro-Architektur). Hier gibt es bestenfalls Vorschläge, keine Vorschriften.

Eine Voraussetzung für dieses Konzept ist offensichtlich: dass Sie und Ihr Team die Zerlegungsbegriffe für Ihr Vorhaben geklärt haben (s. o.).

Für die CWA gilt im Rahmen der Makro-Architektur beispielsweise, dass jeder Server ein eigenes GitHub-Repository besitzt, das die Services beinhaltet. Jeder Service ist ein eigener Prozess in einem eigenen Container. Möglicherweise gibt es noch mehr Vorschriften, da die Services technologisch alle sehr ähnlich gestrickt sind. Vielleicht sind das aber auch nur Vorschläge oder Vorlieben gewesen – das geht zumindest aus der Dokumentation nicht hervor.

Bei welchen Themen sollten Sie und Ihr Team (oder Ihre Teams) vereinheitlichen? Wo sollten sie Spielraum haben, um spezifische Lösungen und Innovation zu ermöglichen? Vielleicht reichen für bestimmte Themen auch Vorschläge, die den Start erleichtern, sich mit der Zeit entwickeln und durch neue ersetzt werden.

Im Einzelnen hängt das von Ihrem Vorhaben und Kontext ab. Gleichzeitig gibt es zu bestimmten Themen zumindest im Kontext von Microservices meiner Erfahrung nach sehr regelmäßig Diskussionen "ob und wenn ja, wie wir das zentral machen...". Drei besonders häufige Fragestellungen:

Trotz mehrerer Teile soll sich die Anwendung dem/der Nutzer/in "aus einem Guss" präsentieren. Wie realisieren wir ein UI?
Ein Service benötigt Funktionalität und/oder Daten eines anderen Service, um seine Aufgabe zu erledigen. Dürfen Services miteinander reden, und wenn ja, wie? (Und wenn nein – wie realisieren wir dann diese Anforderung?)
"Security sollte niemals ein nachträglicher Einfall bei Deiner Anwendungsentwicklung sein." [8] Welche Themen rund um Security adressieren wir in der Makro-Architektur? (und wie?)

Bei der ersten Frage müssen Sie klären, ob Ihre Services neben der fachlichen Logik jeweils auch UI-Anteile haben oder ob ein gemeinsames UI vorgeschaltet ist (es gibt auch Zwischenlösungen). Bei der CWA stellen die beiden Apps das wichtigste UI dar und kommunizieren über REST und Protocol Buffers mit verschiedenen UI-losen Services.

Bei der zweiten Frage finden wir bei der CWA verschiedene Kommunikationsformen vor. Einzelne Teile sind völlig entkoppelt von anderen. Teilweise sprechen Services direkt und synchron per REST miteinander, das Ganze dann über Circuit Breaker abgesichert. In einem Fall tauschen sich Services über eine gemeinsame Datenbank aus. Inwieweit es auf der Makro-Ebene Vorgaben gibt, ist mir nicht bekannt.

Die Antworten der CWA zur dritten Frage würden hier zu weit führen. Da höchster Datenschutz das wichtigste Qualitätsziel ist (vgl. Tabelle 1), gibt es einiges zu berichten. Einzelne Entscheidungen davon gehören zur Makro-Architektur.

Neben diesen drei Fragestellungen können für Themen rund um die Makro-Architektur bei Microservices und Self-contained Systems [9] Ihnen und Ihrem Team die ISA-Principles [10] als Impulsgeber dienen. Deren erstes von insgesamt neun Prinzipien fordert die Etablierung der Architekturebenen gemäß Makro- und Mikro-Architektur. Die übrigen Prinzipien adressieren dann die Makro-Architektur.

Abb. 6: Best Practices für Container nach Google. © embarc

Darüber hinaus unterstützen Sie weitere Best Practices und Mustersammlungen für konkrete Architekturstile und Technologien als Leitplanken und geben Ihnen und Ihrem Team Orientierung. Hier ein paar aus meiner Sicht besonders interessante Vertreter:

Das Buch [11] und die Webseite [5] zu Microservices Patterns.
Für das Bauen und Betreiben von Containern die Best Practices von Google [12], verdichtet dargestellt in Abb. 6.
Das Buch "Kubernetes Patterns" [13].
Für die Cloud-Technologien die Arbeiten der Cloud Native Computing Foundation (CNCF), als Einstieg speziell die Trail Map der Cloud Native Landscape [14].
für Cloud-Anwendungen die Prinzipien der Twelve-Factor-App [15] und das Buch "Beyond the Twelve Factor App" [8] verdichtet dargestellt in Abb. 7.

Beim Backend der Corona-Warn-App finden sich, soweit sich das anhand der Quelltexte und Build-Skripte beurteilen lässt, eine ganze Reihe der Best Practices zu Containern umgesetzt. So hat beispielsweise jeder Service seinen eigenen Container und Multi-Stage-Builds sorgen für kleinere Images.

Abb. 7: Prinzipien für Cloud-Anwendungen (nach [16]). © embarc

Ein Fahrplan statt eines Fazits

Ich habe aufgezeigt, wie sich Konzepte der "klassischen" Softwarearchitektur, nämlich Architekturstile und -prinzipien, zu aktuellen Trendthemen und -technologien verhalten. Zum Abschluss möchte ich Ihnen einen Fahrplan vorstellen, der Sie und Ihr Team zur ersten Vision für Ihre Lösungsarchitektur führt. Tabelle 3 stellt die insgesamt 6 Schritte vor. Sie lässt gleichzeitig diesen Beitrag, in dem Sie die Schritte illustriert mit dem Corona-Warn-App-System gesehen haben, Revue passieren.

Tabelle 3: Eine Vision für die Lösungsarchitektur in 6 Schritten

Schritt	Leitfragen	Zentrale Ergebnisse
Architekturrelevante Anforderungen initial sammeln und verstehen	Was bauen wir? Was müssen wir dabei beachten? Was müssen wir besonders gut können?	Kontextabgrenzung Rahmenbedingungen Qualitätsziele
Architekturstil benennen und präzisieren	Welcher Stil unterstützt unsere Qualitätsziele? Wie heißen Elemente unserer Anwendung? Welche Regeln gelten für diese?	Prägender Stil Zerlegungsbegriffe und -prinzipien
Zielsystem (technisch) skizzieren	Welche Plattform passt zu unseren Rahmenbedingungen und unserem Architekturstil?	Erstes Bild von Verteilung und Betrieb Grober Technologie-Stack
Mapping zwischen Zerlegung und Technik herstellen	Wie passen unsere Zerlegungsbegriffe zur Nomenklatur des Zielsystems	Zuordnung von Elementen zu Deployment-Begriffen
Makro- und Mikroarchitektur erkunden	Welche Aspekte sind für alle Elemente unserer Zerlegung gleich? Wo erlauben wir Freiheitsgrade?	Liste von Themen für die Makro-Architektur
Zentrale Fragen der Makro-Architektur bearbeiten	Wie beantworten wir die dringendsten Fragen zur Makro-Architektur. Welche Lösungen schlagen wir im Fall von Freiheitsgraden vor?	Übergreifende Konzepte Verfeinerter Technologiestack

Die Schritte sind dabei nicht sklavisch der Reihe nach abzuarbeiten. Das Ergebnis einer ersten Iteration ist eine erste Idee ("Candidate Architecture"), verschiedene Ergebnisse verfeinern Sie in folgenden Iterationen und lernen dazu. Nach den Prinzipien für Microservices folgen Sie damit einem Evolutionären Design.

Quellen