How to Scale Monoliths (Ansgar Brauner)

Workshop

Teamstruktur

Für die Verwaltung von Suddomänen werden Squads eingesetzt. Diese unterteilen sich in Teams, welche dann jeweils für einen Microservice zuständig sind.

Auch innerhalb der Teamstruktur sollten sich zentrale **Designziele **wiederspiegeln:

1. Dezentralisierung: Entscheidungen werden nicht zentral durch Management oder eine übergeordnetes Architekturinstanz getroffen, sondern durch die Softwareentwickler*innen innerhalb der Teams.
2. Vertikale Grenzen statt horizontalen Schichten: Anstatt Frontend- und Backendteams sollte eine vertikale Trennung vorgenommen werden, da dies mehr Unabhängigkeit zwischen den Teams fördert. In manchen Bereichen ist dies durch technische Einschränkungen allerdings schwierig (siehe Mobile Development).

Im Sinne von Conways Law sollen die Teamkompetenzen die gewünschte Architektur, die später entstehen soll, repräsentieren. Für die Zusammenstellung und Verwaltung der Teams ist es dabei hilfreich, die einzelnen Entwickler als T-shape Developer aufzufassen: Jeder Developer hat ein zumindest rudimentäres Grundverständnis für alle Schichten und Projektaufgaben, aber mindestens ein Gebiet in dem seine Stärken und gebündelte Fachkompetenz liegen.

Strategic Domain-Driven Design

Man unterscheidet verschiedene Typen von (Sub)Domänen.

1. Core Domains: Domäne mit entscheidendem Geschäftswert, die sehr spezialisiert ist und Alleinstellungsmerkmale gegenüber der Konkurrenz bietet.
2. Supportive Domains: Notwendige Unterstützungsdomäne ohne eigenen Geschäftswert, die jedoch ebenfalls zur Alleinstellung beitragen kann
3. Generic Domains: Kein Geschäftswert, Kein Alleinstellungsmerkmal gegenüber Konkurrenz. Bei Generischen Domains macht es Sinn zu untersuchen, ob man externe Standardlösungen einbinden kann anstatt hier selber zu entwickeln.

Für das Verständnis des Teamscopes kann es wertvoll sein, sich der Klassifizerung der eigenen Subdomäne bekannt zu sein. Vielleicht sollten wir das mal alle machen?

How to Guide Developers

Um die Entwickler erfolgreich zu lenken, greift man auf folgende dreischichtige Leit-Struktur zurück: Dem gesamten Entwicklungsprozess übergeordnet stehen die oben erläuterten Designziele Vertikale Grenzen und Dezentralisierung. Darunter reihen sich eine Reihe von zentralen Architekturprinzipien ein: Autonomie, Automatisierung, Technische Kommunikation und Richtlinien. Diese zentralen Architekturprinzipien sind im Folgenden kurz umrissen, da sie auch für unser Projekt Relevanz zeigen:

Autonomie

1. Unabhängiges Deployen: Die Microservices sollen unabhängig deploybar sein, aber die Unabhängigkeit kann auch zu weit getrieben werden. Nicht jedes Team kann einfach komplett selbstständig tun und lassen was es möchte.
2. Fehler isolieren
3. Implementierungsdetails von Microservices nicht offenbaren
4. Data Storage: Keine gemeinsame Datenbank, jeder Service greift auf eigene DB-Strukturen und -technologien zurück. Hieraus ergeben sich auch Herausforderungen:
5. Autonomous Teams: Bei neuen Features muss der Scope ggf. verringert werden, da hier in den einzelnen Teamkontexten gedacht werden muss
6. Data-integration Pattern: Service-Verhalten muss an die vorliegenden Daten angepasst werden
7. Evolving Implementations: Bei Implementierung neuer Technologien werden iterativ Verbesserungsvorschläge kommuniziert. Ein Pionierteam fängt an und hält Learnings für das nächste Team fest, was wiederum selber weitere Learnigns ergänzt und kommuniziert.

Automatisierung

1. Empfehlung: Jede Entwicklung und jedes Deployment: Immer zumindest zwei Instanzen dieses Services hochfahren. Es macht technisch oft einen großen Unterschied ob ein oder zwei Instanzen vorliegen, aber nicht ob 2 oder 20. Mehrere Instanzen nutzen die selbe Datenbank.
2. Es gilt wo sinnvoll so viel wie möglich zu automatisieren: Quality Assurance, VM-Erstellung, etc.

Technische Kommunikation

1. API soll RESTful Paradigmen befolgen. Dabei ist auch REST Maturity Level 2 akzeptabel. Level 3 (Businesslogik komplett aus Client ausbauen und in API einbauen) ist vom Implementierungsaufwand her oft komplex, und daher schwer zu fordern und es lohnt sich nicht immer.
2. Einsatz von standardisierten Kommunikationstechnologien wie XML, JSON, etc.
3. Soviel Kommunikation wie möglich asynchron abbilden. Dazu ist es nützlich viele Daten lokal zu halten und auch duplizierte Daten sind notwendig. Als Konsistenzklasse bietet sich Eventual Consistency an.
4. Jeder Service bietet eine REST-API, eine UI-API und eine Event-API an.
5. APIs sollten möglichst clientneutral erstellt werden. Das verringert den Änderungsaufwand wenn neue Clients hinzukommen.
6. Bei der fortführenden Entwicklung der APIs muss man Breaking Changes im Blick behalten.
7. Zugriff auf Microservices durch Gateways. Diese können Routing übernehmen, zuständige Services bestimmen, Requests authorisieren, Requests kombinieren und Requests clustern.
8. Probleme wie nicht erreichbare Services: Eventing und andere Techniken helfen

Richtlinien

Richtlinien unterstützen die Entwickler bei der Umsetzung der übrigen Ziele. Hier bieten sich handfeste Guides und Manuals zu Themen wie REST, Authentifizierung, etc. an.