Microservices – Organisatorische Sicht

26. Oktober 2016

Microservices scheinen heutzutage ein ganz wichtiger Trend in der IT-Branche zu sein. In sehr vielen Quellen wird das Thema nur aus der technologischen Perspektive besprochen. Die Thematik ist aber viel breiter. Microservices haben nicht nur Einfluss auf die angewandten Technologien, sondern auch auf die Organisation des Teams. Im folgendem Artikel wird der Schwerpunkt auf die Auswirkungen von Microservices auf die alltägliche Arbeit im Projekt gelegt. Als Grundlage für die Darstellung des Themas wird beispielhaft ein Projekt aus dem Bereich E-Commerce analysiert.

Beschreibung des Beispielprojektes

Das Ziel des Projekts ist die Implementierung eines kompletten IT-Systems für die Verwaltung eines Online-Shops. Das Team arbeitet mit der Scrum-Methodik. Die Anforderungen werden als User Stories definiert und später von dem gesamten Team geschätzt. In dem kommenden Sprint sollte folgende Story implementiert werden:

Als Kunde möchte ich Produkte bestellen, sodass ich diese später geliefert bekomme.

Eine vollständige User Story sollte ebenfalls Akzeptanzkriterien beinhalten:

  • Produkte aus dem Warenkorb werden in die Bestellung aufgenommen.
  • Die Bestellung wird im System registriert.
  • Der Kunde bekommt eine Bestätigung per E-Mail.

Das Scrum-Team hat eine Schätzung abgegeben, die 5 Story-Points beträgt. In sehr vielen Projekten werden die User Stories erst im Laufe der Implementierung präzisiert. In diesem Fall wurden zusätzliche Akzeptanzkriterien definiert, die eigentlich als eigenständige User Stories gelten könnten.

  • Eine Rechnung sollte zur Bestellung generiert werden.
  • Der Lagerservice sollte informiert werden.

Das Team hat sich bereit erklärt, die Story vollständig zu implementieren. Während der Entwicklung stellt das Team fest, dass die Story zu komplex ist und leider falsch eingeschätzt wurde.

Das Projekt ist ein monolithisches System, deswegen lässt sich die Arbeit sehr schlecht verteilen, z. B. wegen zahlreicher Codeabhängigkeiten und unklarer Abgrenzung der Fachlichkeiten. Das Ergebnis: die Anforderung war nur zu 75% fertiggestellt und konnte nicht produktiv eingesetzt werden.

Analyse

Aus dem obigen Beispiel resultiert die Frage, welche Fehler begangen wurden, sodass die Umsetzung der User-Story scheiterte?

Der Product Owner und/oder Architekt hätten feststellen können, dass diese Anforderung mehrere Domänen betrifft:

  • Die Bestellung wird im System registriert => Bestellprozess
  • Eine Rechnung sollte zur Bestellung generiert werden => Buchhaltung
  • Der Lagerservice sollte informiert werden => Logistik

Mit der Aufteilung der Domäne in kleinere Subdomänen lässt sich die Arbeit gut parallelisieren. Die Bestimmung von Subdomänen ist ein Ausgangspunkt für den Entwurf von Microservices.
Der Microservice-Ansatz setzt voraus, dass der Entwicklungsprozess von Subsystemen eigenständig verlaufen soll. Die folgenden Grafiken zeigen, wie die Arbeit in den unterschiedlichen architektonischen Ansätzen organisiert wird [1].

microservices6_test2

Abbildung 1: Aufteilung für monolithisches System

Bei der Entwicklung eines monolithischen Systems arbeitet das Team an einem gemeinsamen Backlog. Eine Anforderung kann also mehrere Domänen betreffen, die aber nicht klar definiert sind. Das heißt, die Anforderung betrifft das ganze System und deswegen lässt sich die Arbeit schlecht parallelisieren.

 

microservices7

Abbildung 2: Aufteilung für Microservices

In dem Microservices-Ansatz sieht das anders aus. Das Team wird in mehrere kleinere Teams geteilt, die für eigene Subsysteme (Microservices) verantwortlich sind. Selbst die Einführung eines neuen Teams sollte in dieser Architektur kein Problem sein. Die User-Story kann schon am Anfang nach Subdomänen gesplittet und danach jedem Team zugewiesen werden. Die Teams arbeiten damit unabhängig und effizient an den Anforderungen. Als Konsequenz ergibt sich eine bessere Schätzbarkeit und Planbarkeit. Dadurch sinkt auch das gesamte Risiko des Projekts. Die Features werden separat ausgeliefert, was einen signifikanten Vorteil hinsichtlich „Time to Market“ ausmacht. In dem monolithischen System müsste entweder alles oder nichts deployt werden.

Fazit

Microservices haben nicht nur einen Einfluss auf die technologische Basis des Projektes, sondern auch auf die Organisation der Arbeit. Ein großes Projekt wird durch kleinere Projekte, d. h. Microservices, ersetzt. Die Teams können eigenverantwortlich arbeiten und haben mehr Freiheit, wenn es um die Wahl der Technologie geht. Aus der Geschäftssicht wird weniger zentrale Koordinierung benötigt. Der Microservices-Ansatz steht eng im Zusammenhang mit Scrum, bei dem selbstorganisierte Teams im Vordergrund stehen.

Quellen

[1] E. Wolff: Microservices, Grundlagen flexibler Softwarearchitekturen, dpunkt Verlag

[2] Dev + Ops bei Otto.de: Why Microservices?