Dienst- oder Umgebung-Orientierung?

Vor einigen Monaten habe ich bereits erklärt, warum dienstspezifische Artefakte, wie beispielsweise Einstellungen, nicht zentral, sondern bei dem jeweiligen Dienst abgelegt werden sollten (Zentrale Service-Einstellungen?). Solange unsere Teams nach Diensten und nicht nach Umgebungen aufgeteilt sind, sollten auch unsere Artefakte nach Diensten partitioniert werden. Dienst-Orientierung ist die einzig sinnvolle Struktur für Microservices.

Personen die primär an der Infrastruktur arbeiten, sehen das eventuell anders. Aus ihrer Sicht ist die Umgebung das primäre Produkt. Das schnelle und automatisierte Erstellen neuer und sogar kurzlebiger Umgebungen ist ein Feature, das ihnen wichtig erscheint. Es stellt sich diesemal also ganz allgemein die Frage, welche Rollen Service Ownership und Environment Ownership einnehmen sollten.

Service Ownership oder Environment Ownership?

Alle Aspekte, die einen Dienst betreffen, fallen primär in den Bereich der Service Ownership. DevOps passiert hier aus dem Team heraus, welches für diesen Dienst verantwortlich zeichnet. Andernfalls würden wir eine neue künstliche und zusätzliche Barriere einführen, die zwischen den Personen, die wissen wie der Dienst läuft, und den Personen, die ihn lauffähig machen müssen, trennen würde. Diese neue Barriere müssten wir dann erstmal wieder mit viel Schnittstellen, Kommunikation und organisatorischer Kopplung überbrücken.

Natürlich muss es auch Environment Owner geben, aber nur für Dienst-übergreifende und Dienst-unabhängige Infrastruktur-Aspekte. Die Dienste bestimmen wie die Infrastruktur aussehen muss. Die Infrastruktur muss sich nach den Diensten richten, nicht andersrum.

Services are King, Infrastructures are Servers.

Damit sind die Rollen definiert. Es bleibt noch eine Frage zu beantworten.

Wie kann ich technisch eine neue Umgebung ausrollen?

Das System besteht aus vielen autarken Diensten, die alle durch ihr eigenes Team entwickelt und betrieben werden. Wenn jetzt eine neue Umgebug in einem anderen Land oder in einer speziellen Teststellung entstehen soll, stellt sich die Frage nach der technischen Umsetzung.

Zunächst müssen zwei Arten von Umgebungen unterschieden werden. Es gibt die permanenten Umgebungen und die kurzlebigen Umgebungen. Permanente Umgebungen sind meist prominent, selten und müssen betreut und auf dem aktuellen Stand gehalten werden. Kurzlebige Umgebungen sind häufig, weniger wichtig und müssen daher einfach nur erstellt werden können.

Beide Arten von Umgebungen müssen mit dem selben Mechanismus erstellt werden können. Eine Automatisierung würde also folgendermaßen vorgehen:

  1. Die Umgebung und allgemeine Dinge werden eingerichtet (zentral).
  2. Alle Services werden aufgefordert, ihre Einrichtung vorzunehmen, indem der richtige Branch (master) ausgecheckt und ein beim Service liegendes Script aufgerufen wird (dezentral).

Die automatisierte Erstellung der Umgebung (zentral) gibt also für die Einrichtung des Dienstes in dieser neuen Umgebung die Kontrolle an den Dienst weiter (dezentral), weil dieser die Hoheit und Verantwortung über die Subdomäne hat.

Ein Dienst richtet sich in einer neuen Umgebung zunächst Default-Einstellungen ein, die er definiert und dafür vorgesehen hat. Wenn es sich bei der neuen Umgebung um eine permanente Umgebung handelt, müssen die Dienste noch zusätzliche Dinge einrichten. Damit der Dienst in der neuen Umgebung auch auf dem akteuellen Stand bleibt, müssen neue Deployment Targets und Release Pipelines erstellt werden. Zusätzlich werden die Dienst-Einstellungen für die neue Umgebung angepasst und separat archiviert.

Auf diese Art und Weise bleiben die Dienste autark und autonom. Sie bilden technische und organisatorische Bounded Contexts und können ihre Einstellungen, Interna und Implementierungsdetails eigenständig und unabhängig voneinander weiterentwickeln und verwalten. Services are King. 👑