Services: From micro to nano and back

Als Beispiel dient ein kleiner Versandhandel. Statt in einem Online-Shop wird per Telefon bestellt. Die Verkäufer greifen auf einen internen Produktkatalog zu und tragen Bestellungen in ein internes Bestellsystem ein. Eine Versandabteilung kümmert sich um das Verpacken und Versenden der Produkte.

Die Architektur besteht aus folgenden Microservices:

• ProductCatalogService: Verwaltet welche Produkte es gibt und wie viele davon auf Lager sind
• CustomerService: Beinhaltet Kundendaten wie Telefonnummer, Anschrift, Interessen
• OrderService: Verwaltet Bestellungen und deren Zustand (in Vorbereitung, versendet, …). Eine Bestellung referenziert Produkte aus dem ProductCatalogService und Kunden aus dem CustomerService
• SalesCampaignService: Für Rabatte, Kombo-Angebote und sonstiges. Referenziert Produkte aus dem ProductCatalogService

Die Services müssen stellenweise zusammenarbeiten. Zum Beispiel: Wenn Produkte aus dem Lager geholt wurden, um verpackt zu werden muss, als Gesamt-Transaktion, der Lagerbestand im ProductCatalogService verringert und der Bestellstatus im OrderService auf “in Vorbereitung” gesetzt werden.

A small mail order business serves as an example. Instead of an online store, orders are placed by telephone. Salespeople access an internal product catalog and enter orders into an internal ordering system. A shipping department takes care of packing and shipping the products.
 
The architecture consists of the following microservices: 

• ProductCatalogService: Manages which products are available and how many are in stock. 
• CustomerService: Contains customer data such as phone number, address, interests.
• OrderService: Manages orders and their state (in preparation, shipped, ...). An order references products from the ProductCatalogService and customers from the CustomerService.
• SalesCampaignService: For discounts, combo offers and other. References products from the ProductCatalogService. 

The services need to work together in places. For example: When products have been pulled from the warehouse to be packaged, as an overall transaction, the inventory in the ProductCatalogService needs to be decreased and the order status in the OrderService needs to be set to "in preparation". 

Looking at it from a different angle, weaknesses become apparent. In the architecture above, microservices reference data from other services, but they should be loosely coupled. The distributed transaction (packaging) can only be completed with the participation of multiple services. It is complex and tightly couples services.

Betrachtet man das Ganze aus einem anderen Winkel, zeigen sich Schwächen auf. In der obigen Architektur referenzieren Microservices Daten anderer Services, jedoch sollten sie lose gekoppelt sein. Die verteilte Transaktion (Verpackung) kann nur unter Beteiligung mehrerer Services abgeschlossen werden. Sie ist komplex und koppelt Services eng aneinander.

Ist das noch im Sinne von Microservices? Um das zu beurteilen, betrachten wir, wie ihre Eigenschaften zustande kommen.

When considering how the properties of microservices come about, it is helpful to look at the concept of bounded context.¹

Bei der Frage wie die Eigenschaften von Microservices zustande kommen ist es hilfreich das Konzept des Bounded Context zu betrachten.¹

Ein Bounded Context ist ein fachlicher Kontext, in dem Begriffe eine bestimmte Bedeutung haben und bestimmte Konzepte und Regeln gelten. Solche Kontexte gibt es immer, auch wenn sie nicht bewusst und nicht explizit definiert werden. Viele Missverständnisse (und Bugs) basieren darauf, dass man dieselben Begriffe benutzt, aber unbewusst nicht über dasselbe redet.

Der Versandhandel aus der Einleitung hat, beispielsweise, die zwei Bounded Contexts Verkauf und Versand. Der Begriff Kunde ist ein guter Kandidat für Missverständnisse. Er existiert in beiden Kontexten, aber in unterschiedlicher Bedeutung: Verkauf sieht einen Kunden als jemanden der für Angebote und Beratungen per E-Mail-Adresse und Telefonnummer erreichbar ist. In Versand hingegen ist ein Kunde jemand mit Lieferadresse der Produkte bestellt hat.

Andererseits gehören Begriffe wie Rabatt oder Paketgröße und Regeln wie “20% auf alles außer Tiernahrung” und Verpackungsrichtlinien zu jeweils nur einem der beiden Kontexte.

Bounded Contexts kommunizieren über Ereignisse miteinander. Zwei Beispiele sind: Eine Bestellung wurde abgeschlossen. Ein Warenpaket wurde versendet.

Gute Kontextgrenzen und Ereignisse sind immens wichtig. Dann sind Bounded Contexts eigenständig, lose gegenseitig gekoppelt und stark intern kohärent.

To relate microservices and bounded contexts, the following approach helps: "Micro" means a service relates to exactly one bounded context. "Service" means "business services" rather than technical ones such as CRUD operations.² A bounded context is the model, a microservice its implementation as an application.

For the application to be as self-contained as the model, it includes everything. Front-end, back-end, data storage, all resources and all data.³ From this point of view, for example, a database alone is not a microservice. It also follows that synchronous invocations, and REST interfaces in particular, do not make sense between microservices. A synchronous call would mean one service is waiting for confirmation or data from another. REST (and similar technologies, such as GraphQL) models data. Both of these conflict with the application owning everything it needs.

A microservice is therefore a complete application that provides all the business functions required for exactly one bounded context. According to this terminology, a monolith is an application that covers several bounded contexts. This explains typical problems with monoliths. For example, that a term has different meanings in different contexts, but must be reconciled in the implementation. This makes it complex and changes have to be coordinated with many stakeholders. Or that there is a danger that components that are actually technically independent of each other become technically dependent on each other, thus softening the modularization. For software smaller than a bounded context, as in the original example, we need also still another term.

More on that in a moment, before we look at another important factor: teams.

Um Microservices und Bounded Contexts in Beziehung zu setzen, hilft folgende Betrachtungsweise: “Micro” bedeutet, ein Service bezieht sich auf genau einen Bounded Context. “Service” bedeutet “fachliche Dienstleistungen”, statt technische wie etwa CRUD-Operationen.² Ein Bounded Context ist das Modell, ein Microservice dessen Umsetzung als Applikation.

Damit die Applikation so eigenständig ist wie das Modell, beinhaltet sie alles. Frontend, Backend, Datenhaltung, alle Ressourcen und alle Daten.³ Aus dieser Betrachtung ist, zum Beispiel, eine Datenbank alleine kein Microservice. Aus ihr folgt auch, dass synchrone Aufrufe, und insbesondere REST-Schnittstellen, zwischen Microservices keinen Sinn ergeben. Ein synchroner Aufruf würde bedeuten, ein Service wartet auf Bestätigung oder Daten eines anderen. REST (und ähnliche Technologien, wie GraphQL) modelliert Daten. Beides steht im Widerspruch dazu, dass die Applikation alles besitzt, was sie braucht.

Ein Microservice ist also eine vollständige Applikation, die alle fachlichen Funktionen zur Verfügung stellt, die für genau einen Bounded Context notwendig sind. Nach dieser Terminologie ist ein Monolith eine Applikation, die mehrere Bounded Contexts abdeckt. Daraus erklären sich typische Probleme mit Monolithen. Etwa, dass ein Begriff in verschiedenen Kontexten unterschiedliche Bedeutungen hat, aber in der Implementierung unter einen Hut gebracht werden muss. Sie wird dadurch komplex und Änderungen müssen mit vielen Stakeholdern koordiniert werden. Oder dass die Gefahr besteht, dass fachlich eigentlich unabhängige Komponenten technisch voneinander abhängen und so die Modularisierung aufweicht. Für Software kleiner als ein Bounded Context, wie im ursprünglichen Beispiel, brauchen wir auch noch einen Begriff.

Dazu gleich mehr, vorher betrachten wir einen weiteren wichtigen Faktor: Teams.

Wenn es um Teams geht, kommt man um das Gesetz von Conway nicht herum. Es besagt: Organisationen entwerfen Systeme, die die Kommunikationsstrukturen der Organisation abbilden.⁴ Kurz: “You’re gonna ship your org chart”.

Angenommen, eine Organisation trennt ihre Mitarbeiter nach technischem Fachgebiet: Frontend-Team, Backend-Team, Datenbank-Team, … Das fördert z.B. die Kommunikation der Frontend-Mitarbeiter unter sich, sodass sie sich informell austauschen und eng zusammenarbeiten. Es schottet sie aber von den Backend-Mitarbeitern ab, mit denen sie sich daher viel über Dokumentation und Spezifikation abstimmen. Was dazu führt, dass die Software genau so strukturiert wird: Strikt voneinander getrennte, aber sehr breite Schichten. Diese Organisation produziert auf ganz “natürliche” Weise Monolithen.

Das bedeutet: Wenn Microservices alles von Frontend bis Datenhaltung abdecken sollen, dann gehört es zu den Grundvoraussetzungen, dass alle Fachgebiete im Team zusammenarbeiten. Das sind sogenannte “cross-funktionale Teams”.

Interessanterweise gilt das Gesetz von Conway auch umgekehrt: Die Struktur der Software bestimmt, wie Teams und ihre Mitglieder kommunizieren müssen.

Da Teamgrenzen die Kommunikation bremsen, ist es nicht sinnvoll mehrere Teams an einem Microservice gemeinsam arbeiten zu lassen. Beim umgekehrten Extrem, ein Microservice pro Entwickler, sind häufige Abstimmungen zwischen eigenständigen Services mit Dokumentation und Spezifikation notwendig. Dies bremst Teamwork effektiv aus, das Team wird zu einer Ansammlung von Ein-Personen-Silos.

Zusammengefasst kann man sagen: Für erfolgreiche Microservices sind alle drei Faktoren wichtig: Der Bounded Context, die Teamstruktur und auf Platz drei die Technik.

When it comes to teams, there's no getting around Conway's Law. It states: organizations design systems that map the organization's communication structures.⁴ In short, "You're gonna ship your org chart."

Back to the original, predominantly technical, example. Each service is a small CRUD backend that barely implements any independent technical concepts or rules. The two contexts of sales and shipping are distributed across service boundaries. There are two names for this. The more advantageous one is "Nanoservices".

Nanoservices cover individual technical functions. But the technical context is not gone! This leads to some problems. For example, the distributed transaction, which not only closely couples two services, but also introduces new sources of error.

The contradiction between domain-oriented context but technical separation leads to three things, among others:

1. Business contexts inevitably tightly couple nanoservices technically. Domain-specific changes usually entail modification, testing, and deployment of multiple nanoservices.
2. Domain-specific contexts are scattered, and nanoservices have weak cohesion as a result. To understand cohesion, you open more code bases, read more logs, etc.
3. All the problems of distributed systems (asynchronous clocks, events in different order, unreliable network, partial failures) are brought into the system at very deep level.

Another view is that this architecture combines the bad features of monoliths with those of distributed systems. The less advantageous name is therefore "distributed monolith".

Zurück zum ursprünglichen, vorwiegend technisch geschnittenen Beispiel. Jeder Service ist ein kleines CRUD-Backend, dass kaum eigenständige fachliche Konzepte oder Regeln umsetzt. Die beiden Kontexte Verkauf und Versand sind über Servicegrenzen verteilt. Dafür gibt es zwei Namen. Der vorteilhaftere ist “Nanoservices”.

Nanoservices decken einzelne technische Funktionen ab. Der fachliche Zusammenhang ist aber nicht weg! Das führt zu einigen Problemen. Zum Beispiel zur verteilten Transaktion, die nicht nur zwei Services eng koppelt, sondern auch neue Fehlerquellen einführt.

Der Widerspruch zwischen fachlichem Zusammenhang aber technischer Trennung führt, unter anderem, zu drei Dingen:

1. Fachliche Zusammenhänge koppeln Nanoservices zwangsläufig auch technisch eng. Fachliche Änderungen ziehen meistens Änderung, Test und Deployment mehrerer Nanoservices nach sich.
2. Fachliche Zusammenhänge sind verstreut, Nanoservices haben dadurch eine schwache Kohäsion. Um Zusammenhänge zu verstehen, öffnet man mehr Codebasen, liest mehr Logs, usw.
3. Alle Probleme verteilter Systeme (asynchrone Uhren, Events in verschiedener Reihenfolge, unzuverlässiges Netzwerk, Teilausfälle) werden auf ganz tiefe Ebene ins System hereingeholt.

Eine andere Sichtweise ist, dass diese Architektur die schlechten Eigenschaften von Monolithen mit denen verteilter Systeme vereinigt. Der weniger vorteilhafte Name ist daher “verteilter Monolith”.

If one wants to avoid the disadvantages of nanoservices, the question is how to proceed.

Suppose there is ambiguity about the three factors, for example at the beginning of projects. The greater the lack of clarity, the greater the risk of making decisions out of ignorance that later turn out to be suboptimal and difficult to reverse.

Here, it can help to focus first on working out bounded contexts and team structures, making decisions only as far as clarity allows or postponing some for the time being.⁵ One possible implementation of this is to start with a non-distributed, modular system. This is easier to adapt to the current state of knowledge and to separate later.⁶

If you are already in a situation where contradictions between the technical context and the technical separation lead to problems, the three factors described can serve as a "thinking framework". With their help, the contradictions can be identified and approaches to their elimination can be developed.

Wenn man die Nachteile von Nanoservices vermeiden möchte, stellt sich die Frage wie man vorgehen kann.

Angenommen, bei den drei Faktoren besteht Unklarheit, zum Beispiel zu Beginn von Projekten. Je größer die Unklarheit, desto größer die Gefahr, aus Unwissenheit Entscheidungen zu treffen, die sich später als suboptimal und schwer rückgängig zu machen herausstellen.

Hier kann es helfen, den Fokus zunächst darauf zu setzen Bounded Contexts und Teamstrukturen auszuarbeiten, Entscheidungen nur so weit zu treffen, wie die Klarheit es zulässt oder manche vorläufig zu vertagen.⁵ Eine mögliche Umsetzung davon ist, mit einem nicht-verteilten, modularen System anzufangen. Dieses lässt sich einfacher an den aktuellen Kenntnisstand anpassen und später trennen.

Falls man bereits in der Situation ist, dass Widersprüche zwischen fachlichem Zusammenhang und technischer Trennung zu Problem führen, können die beschriebenen drei Faktoren als “Denkrahmen” dienen. Mit ihrer Hilfe können die Widersprüche erkannt und Ansätze zur Behebung entwickelt werden.

Artikel von: Christian Harnisch

Article by: Christian Harnisch

[1] Domain-Driven Design: Tackling Complexity in the Heart of Software, Chapter 14: Maintaining Model Integrity
[2] Create Read Update Delete, Wikipedia
[3] Microservices, Martin Fowler
[4] Law of Conway, Wikipedia
[5] Lean Principles 4 Defer Commitment, 101 Ways
[6] MonolithFirst, Martin Fowler

[1] Domain-Driven Design: Tackling Complexity in the Heart of Software, Chapter 14: Maintaining Model Integrity
[2] Create Read Update Delete,, Wikipedia
[3] Microservices, Martin Fowler
[4] Law of Conway, Wikipedia
[5] Lean Principles 4 Defer Commitment, 101 Ways
[6] MonolithFirst, Martin Fowler