You are on page 1of 5

{ AKTUELLES SCHLAGWORT* / MICROSERVICES

Microservices
Mehr als nur ein Hype?
Alexander Schwartz

Architekturparadigma der Internetriesen


Die Internetriesen Amazon, Netflix und Google ha-
ben gezeigt, wie Produkte erfolgreich auf den Markt
gebracht werden. Die Unternehmen sind gewachsen,
doch die anfängliche monolithische Softwarearchi-
tektur zeigte diesem Wachstum seine Grenzen auf.
Um die Softwareentwicklung der großen Systeme
wieder beherrschbar zu machen, setzten die Kon-
zerne auf kleine, unabhängige Teams. Jeff Bezos von
Amazon verwendete dafür 2002 den Begriff ,,Two Abb. 1 Kommunikationsbeziehung Plattform/Microservice,
Pizza Teams“: Ein Team sollte nur so groß sein, dass Plattform überspannt mehrere Rechnerknoten
es von zwei (amerikanischen) Pizzen satt werden
würde – dies ist eine Teamgröße von 5–10 Personen. unabhängig voneinander entwickelt und instal-
Jedes Team ist ,,cross-functional“ aufgestellt und liert werden. Sie laufen als eigenständige Prozesse
bringt damit alle notwendigen Kenntnisse und Fä- und können unabhängig voneinander skaliert
higkeiten mit, angefangen bei Fachlichkeit, UI/UX, werden [8].
Programmierung bis hin zu Test und Betrieb. Die Die Architektur teilt sich auf in die interne
Kommunikation findet hauptsächlich zwischen den Struktur der einzelnen Services (Mikroarchitektur),
Teammitgliedern statt, der Abstimmungsbedarf die Plattform für die Services (Makroarchitektur)
zwischen den Teams wird reduziert [1, S. 90ff.]. und die Schnittstellen eines Service zur Plattform
Gleichzeitig bekommt jedes Team die Verantwor- und zu anderen Services (Abb. 1).
tung, sein eigenes System zu betreiben. Werner Adam Wiggins, ein Mitgründer des Cloud-
Vogels von Amazon fasste dies mit den Worten ,,You Service-Providers Heroku, beschreibt mit ,,The
build it, you run it“ zusammen [2]. Twelve Factors“ unter anderem die folgenden Prin-
Melvin Conway beschrieb, dass Organisationen zipien: Jeder Service soll seine eigene Codebasis
Systeme entwickeln, die ihre eigene Struktur wider- haben und damit unabhängig von anderen Services
spiegeln (,,Conway’s law“) [3]. Entsprechend der
oben beschriebenen Organisationsstruktur entwi- DOI 10.1007/s00287-017-1078-6
© Springer-Verlag Berlin Heidelberg 2017
ckelte sich ein Architekturstil, der heute als ,,Micro-
Alexander Schwartz
services“ bezeichnet wird. Dabei ist ein Team für msg systems ag,
einen oder mehrere Microservices verantwortlich, Robert-Bürkle-Straße 1, 85737 Ismaning/München
E-Mail: alexander.schwartz@msg.group
jedoch nie mehrere Teams für einen Microservice.
*Vorschläge an Prof. Dr. Frank Puppe
<puppe@informatik.uni-wuerzburg.de>
Definition Microservices oder an Dr. Brigitte Bartsch-Spörl
<brigitte@bsr-consulting.de>
Microservices sind ein Architekturstil, bei dem Alle „Aktuellen Schlagwörter“ seit 1988 finden Sie unter:
die Anwendung in kleine Teile aufgeteilt wird, die http://www.is.informatik.uni-wuerzburg.de/as

590 Informatik_Spektrum_40_6_2017
weiterentwickelt werden können. Er verwaltet seine tierung der Microservices. Allerdings sind alle
Abhängigkeiten selbst, anstatt sie in seiner Laufzeit- Funktionen der Makroarchitektur zu Beginn eines
umgebung vorauszusetzen. Abhängige Ressourcen Projekts zwischen allen Nutzern abzustimmen, da-
wie Datenbanken und E-Mail-Services werden zur mit die Microservices so entwickelt werden, dass
Laufzeit konfiguriert. Services exportieren ihre APIs sie nach außen gleichartig erscheinen und effi-
über TCP- oder UDP-Ports. Sie bringen dafür zum zient betrieben werden können. Zu Beginn eines
Beispiel einen integrierten Webserver mit und sind Projekts liegen jedoch nur wenige Erfahrungen
idealerweise zustandslos in der Kommunikation [4]. und belastbare Anforderungen vor und der Ent-
In seiner Mikroarchitektur kann sich jedes scheidungsprozess selbst benötigt Zeit. Je mehr
Team für einen Service unabhängig von den an- Funktionalität in der Makroarchitektur vorgesehen
deren Services und Teams für Programmiersprache, ist, desto häufiger sind Aktualisierungen notwen-
Build-Tools und Datenbank entscheiden, um die dig, die dann auch zeitgleiche Änderungen an den
angebotenen Dienste optimal zu liefern. Diese Ent- Microservices bedingen.
scheidungen können auch geändert werden, ohne Je weniger Funktionen in der Makroarchitektur
dass andere Services davon betroffen sind. Wichtig vorgesehen sind, desto stabiler wird sie langfristig
ist, dass alle Schritte der Build- und Run-Phasen au- sein. Die Entscheidungen werden dann auf Micro-
tomatisiert werden, da manuelle Prozesse aufgrund serviceebene getroffen: Jedes Team bestimmt seinen
der Vielzahl von Microservices und deren Instanzen eigenen spätestmöglichen Zeitpunkt (,,last respon-
zu teuer wären. sible moment“), um die jeweilige Entscheidung zu
Die Plattform kann Instanzen eines Micro- treffen. Damit gewinnen die Teams Zeit, um mehr
service auf einem oder mehreren Rechnerknoten Informationen zu sammeln und können bessere
installieren und starten. Die Anzahl der Instanzen Entscheidungen treffen [7].
kann sich zur Laufzeit ändern. Mechanismen zur
Verteilung von Aufrufen (Loadbalancer) sind heut- Schneiden von Services
zutage meist Teil der Plattform. Über Health-Checks Systeme können entsprechend der nichtfunk-
kann die Plattform überwachen, ob ein Service tionalen Eigenschaften ihrer Komponenten in
korrekt funktioniert. Microservices geschnitten werden. Kriterien können
Die Aufgabenverteilung zwischen Plattform beispielweise Transaktionsvolumen, Verfügbar-
und Services ist eine wichtige Architekturentschei- keit, Datenschutz oder erwartete Änderungsrate
dung. Im Open-Source-Software-Stack von Netflix und damit Release-Zyklus der Komponente sein.
übernehmen die Services viele Aufgaben und regis- Damit kann jeder Microservice die benötigten
trieren sich selbstständig bei einer Service-Registry nichtfunktionalen Eigenschaften optimal abbil-
(Eureka1 ), nutzen clientseitige Bibliotheken für eine den, anstatt dass ein Monolith die Summe aller
Lastverteilung der Aufrufe an nachgelagerte Systeme nichtfunktionalen Eigenschaften abbilden muss.
(Ribbon2 ) und kümmern sich um die Fehlerbehand- Die Schnitte anhand der nichtfunktionalen Ei-
lung, wenn eine Schnittstelle nicht oder zu langsam genschaften reichen in der Regel aber nicht aus,
antwortet (Hystrix3 ). Im Gegensatz dazu übernimmt um Services zu erhalten, die von einem einzelnen
die Plattform Kubernetes4 das Service-Discovery Team verantwortet werden können. Hier bietet sich
und ein Service-Mesh wie envoy5 oder istio6 als Teil die fachliche Dekomposition entsprechend des Do-
der Plattform die Lastverteilung, Fehlerbehandlung main Driven Designs an [5]. Dabei werden fachliche
und das Monitoring für Schnittstellen zwischen Objekte der Anwendungsdomäne und ihre Abhän-
Services. gigkeiten und Interaktionen beschrieben. Bildet
Je mehr Funktionen die Makroarchitektur die technische Architektur diese Dekomposition
anbietet, desto einfacher erscheint die Implemen- ab und nutzt sie die fachlichen Begriffe, so kann
sich eine gemeinsame Sprache zwischen Fachseite
1 Vgl. https://github.com/Netflix/eureka. und Entwicklung etablieren, die eine langfristige
2 Vgl. https://github.com/Netflix/ribbon. Weiterentwicklung der Software unterstützt. Mit
3 Vgl. https://github.com/Netflix/Hystrix.
4 Vgl. https://kubernetes.io/. dem Konzept der Bounded Contexts wird akzeptiert,
5 Vgl. https://github.com/lyft/envoy. dass nicht jede Komponente die gleiche Sicht auf die
6 Vgl. https://github.com/istio/istio. fachlichen Objekte erfordert [6].

Informatik_Spektrum_40_6_2017 591
{ MICROSERVICES

Der kleinste mögliche Schnitt eines Microser- basieren. Für jedes Datum gibt es jedoch immer nur
vice enthält alle zu einer Transaktion benötigten einen Service, der die Datenhoheit hat und Verände-
fachlichen Objekte. Der größte sinnvolle Schnitt rungen an den Daten durchführen darf. Alle anderen
beinhaltet einen kompletten Bounded Context, da Services nutzen eine Replik.
innerhalb die fachlichen Objekte eine hohe Kohä- Es gibt verschiedene Möglichkeiten, die Repli-
sion und die Bounded Contexts untereinander eine ken aktuell zu halten: Bei Polling-Ansätzen fragen
geringe Kopplung haben. die Nutzer der Daten periodisch beim anderen Ser-
vice an. Dies ist robust und erlaubt einen einfachen,
Datenhaltung zustandslosen Server ohne zusätzliche Middleware.
Eine von mehreren Services gemeinsam genutzte Bei Publish-Subscribe-Ansätzen wird ein Message-
Datenbank steht im Gegensatz zur unabhängigen Bus benötigt, der als Teil der Makroarchitektur
Weiterentwicklung der einzelnen Services, da sie implementiert wird. Der Service mit der Datenho-
eine enge Kopplung der Services bedeutet. Außerdem heit sendet Informationen zu neuen, geänderten
können die beteiligten Services nicht mehr unab- und gelöschten Daten als Nachrichten an ein Topic
hängig voneinander skaliert werden, da sie sich mit im Message-Bus, das die Clients abonnieren. Clients
ihrer Transaktionslast gegenseitig beeinflussen. Da- erhalten die Information schneller als im Polling-
her erhält jeder Microservice, der eine Datenhaltung Verfahren, dies wird jedoch mit einer komplexeren
benötigt, seine eigene Datenbank – oder zumindest Architektur erkauft.
sein eigenes Datenbankschema, um später in eine Eine Alternative für die Kommunikation zwi-
eigene Datenbank umziehen zu können. Benötigen schen Services bieten asynchrone fachliche Events.
andere Services diese Daten, so greifen sie über APIs Ein Service kann sie nutzen, um seine Datenko-
darauf zu oder lassen sich über Veränderungen über pie zu aktualisieren oder direkt eigene Aktionen
asynchrone Events benachrichtigen. auszulösen. Events unterscheiden sich von der Da-
Sollen Daten serviceübergreifend analysiert tenreplikation dadurch, dass das Event die fachliche
werden, so kann ein gemeinsamer Datenbestand aus Änderung an den Daten beschreibt (z. B. bei einem
den verschiedenen Services zusammengeführt oder Kunden ,,E-Mail-Adresse bestätigt“ oder ,,Adresse
aus den historischen Events der einzelnen Services geändert auf XY“). Events können über Polling oder
aufgebaut werden. Die Analysen können jedoch auch Publish-Subscribe weitergegeben werden.
direkt auf den historischen Events aufsetzen und
diese als Stream verarbeiten. Serviceschnitt am Beispiel
eines Online-Shops
Kommunikation zwischen Services Die Ideen aus den vorherigen Abschnitten soll fol-
Werden die Services in der beschriebenen Form ge- gendes Beispiel eines vereinfachten Online-Shops
schnitten, so entsteht ein verteiltes System, das auf erläutern: Gemäß der nichtfunktionalen Eigenschaf-
mehreren Rechnerknoten läuft. Damit ergeben sich ten erfolgt ein erster Serviceschnitt in Bereiche, z. B.
Herausforderungen rund um Bandbreite, Latenz in Startseite (hohe Aufrufzahl, hohe Volatilität),
und Zuverlässigkeit in der Kommunikation zwi- Produktsuche (Suchindex über alle Daten benö-
schen den Services [12]. Benötigt ein Service die tigt), Detailseite (starke Verzweigung zu weiteren
Daten eines anderen Services, so kann er sich diese Funktionen, mögliche Differenzierung nach Pro-
bei Bedarf in dem Moment holen, indem er sie be- dukt), Warenkorb (auf vielen Seiten eingebunden),
nötigt. Er muss Vorkehrungen treffen für den Fall, Check-Out (Erfassen von sensiblen Zahlungs-
dass der Aufruf sehr lange dauert oder zu einem informationen) und Produktpflege (Master für
Fehler führt. Darüber hinaus darf er das aufgerufene Produktdaten, nur intern erreichbar).
System nicht überlasten. Jeder Bereich wird dann nach Bedarf in kleinere
Ein Service kann sich von anderen Services ent- Microservices unterteilt: Am Beispiel der Detail-
koppeln, indem er die benötigten Daten in seiner seite könnten dies z. B. Bildervorschau, Größen- und
eigenen Datenbank als Kopie hält und sie ent- Farbauswahl und Produktvorschläge zu ähnlichen
sprechend seiner Anforderungen strukturiert und Produkten sein.
indexiert. So kann er Servicelevels für Anfragen Auch wenn die Suche keine eigenen Daten
garantieren, die auf Daten eines anderen Services speichert, wird sie die benötigten Daten aus der

592 Informatik_Spektrum_40_6_2017
Produktpflege replizieren, um sie in einem inversen Strukturierung begrüßen. Diese wurde vom Online-
Index abzulegen. Über ein Event ,,Produkt aktuali- Shop Otto.de als Vertikale [9] vorgestellt und später
siert“ der Produktpflege kann sie ihren Datenbestand als Self-Contained System beschrieben [10]. Jedes
aktualisieren. Wenn der Service Kundenregistrie- Self-Contained System besteht aus einem (manch-
rung das Event ,,Neuer Kunde registriert“ versendet, mal auch mehreren) Microservices. Es bringt sein
so kann der Service Newsletter als Reaktion darauf eigenes Web-Frontend mit, kümmert sich um die ei-
eine Willkommens-E-Mail verschicken. gene Datenhaltung und bringt die gesamte benötigte
Ob ein Artikel einem Kunden im Online-Shop fachliche Logik selbst mit. Mit umliegenden Services
als verfügbar angezeigt wird, ist abhängig von ver- ist es idealerweise nur per Weblinks lose gekoppelt,
schiedenen Faktoren. Bei einem Versandhaus z. B. alternativ kommuniziert es asynchron im Backend.
für Modeartikel können hierfür die Bestände aus Daten aus anderen Self-Contained Systems werden
dem Lager abzüglich eines Puffers für Inventurdiffe- bei Bedarf repliziert.
renzen, die erwarteten Lieferungen der Lieferanten Wer bei den Services den Fokus auf Fachlichkeit
und die Anzahl der von Kunden kürzlich in den legen möchte und der Infrastruktur mehr Aufga-
Warenkorb gelegten Artikel berücksichtigt werden. ben zukommen lassen will, der findet mit Function
Für jede dieser Informationen hat ein anderer Ser- as a Service (FaaS) neue Möglichkeiten: Mit Ama-
vice die Datenhoheit. Das Versandhaus wird diese zon Lambda, Google Cloud Functions oder Apache
Informationen mit Heuristiken bewerten: Auf der OpenWisk7 können einzelne Funktionen unabhängig
einen Seite soll der Bestand möglichst weit abver- voneinander bereitgestellt und skaliert werden.
kauft werden, auf der anderen Seite soll der Kunde
möglichst selten die Meldung bekommen, dass der Wann sind Microservices
Artikel, den er eben noch als verfügbar sah, nun der richtige Ansatz?
doch vergriffen ist. In den ersten Schritten des Ein- Dem Ansatz von kleinen Teams, die unabhängig
kaufprozesses nutzen die Services replizierte Daten, voneinander entwickeln, sind auch im Kontext
um die Skalierbarkeit zu gewährleisten. In der Suche agiler Softwareentwicklung viele große Unterneh-
wird die Verfügbarkeit als weiteres Attribut in den men gefolgt: So haben in Deutschland Otto [9]
Suchindex integriert. Auf der Detailseite führt ein ei- und Kaufhof-Galleria die Software-Entwicklung für
genständiger Verfügbarkeitsservice die replizierten ihre Online-Shops auf diese Prinzipien umgestellt.
Daten zusammen und zeigt sie an. Der Check-out Klassische Unternehmen wie der Finanzkon-
kann je nach Warengruppe, Preis oder Restbestand zern ING in den Niederlanden haben auf agile
über einen synchronen Aufruf den Artikel zeitlich Softwareentwicklung und Microservices umgestellt.
befristet reservieren oder ebenfalls replizierte Da- Eine Gemeinsamkeit ist, dass sie sich einen
ten nutzen. Der Versandhändler Amazon verschickt Wettbewerbsvorteil durch häufige Releases, Expe-
nach dem Check-out eine Bestellbestätigung mit rimente und differenzierte Technologie erhoffen. Sie
dem Hinweis, dass der Kaufvertrag erst dadurch alle haben in Automatisierung der Releases, Self-
zustande kommen soll, dass Amazon eine Versand- Service-Funktionalität für die Entwicklungsteams
bestätigung des Artikels verschickt. Ob dies nun und Monitoring investiert. Sie ermöglichen ihnen
rechtlich haltbar ist oder nicht – es deutet darauf hin, eine kontinuierliche Weiterentwicklung ihrer Sys-
dass auch im Check-out replizierte Datenbestände teme in Bezug auf Funktion und Architektur. Diesen
und Heuristiken möglich sind. Unternehmen scheint gemeinsam zu sein, dass hier
Weiterführende Beispiele, wie ein fiktiver fachliche Individualsoftware entwickelt wird und
Check-out-Prozess eventbasiert oder mit Prozess- jedes dieser Unternehmen technische Komponenten
orchestrierung aussehen könnte, finden sich im als Open Source zur Verfügung stellt.
Artikel von Tobias Flore [13] und der sich daran Es lockt die Möglichkeit, die Architektur
anschließenden Diskussion. kontinuierlich durch den Austausch einzelner
Services erneuern zu können. Gleichzeitig entwi-
Microservices weitergedacht ckelt sich das Microservice-Ökosystem mit einer
Wer die Microservices als zu unstrukturiert erachtet, hohen Geschwindigkeit weiter, was eine hohe
sich aber dem Gedanken von autonomen Systemen
anschließen kann, wird eine zusätzliche vertikale 7 Vgl. http://openwhisk.org/.

Informatik_Spektrum_40_6_2017 593
{ MICROSERVICES

Veränderungsbereitschaft für die Mikro- und Situation geprüft und bewertet werden. Dabei hel-
Makroarchitektur fordert. fen die vorhandenen Erfahrungsberichte und Best
Practices, die zeigen, dass es sich um mehr als nur
Microservices als Architektur einen Hype handelt. Diejenigen, die sich für Micro-
für das Enterprise? services entscheiden, können bei der Umsetzung
Auch wenn immer mehr Erfolgsgeschichten von auf eine große Zahl an Open-Source-Projekten
Microservicearchitekturen veröffentlicht werden, zurückgreifen.
so sind Microservices nicht für jedes Unternehmen
die richtige Wahl. Natürlich werden Erfolge groß Literatur
1. Kim G, Humble J, Debois P, Willis J (2016) DevOps Handbook. How to Create
gefeiert und es ergibt sich ein Survivorship Bias. Ein World-Class Agility, Reliability, & Security in Technology Organizations. IT Revo-
blindes Anwenden der Technologie führt jedoch zu lution Press, Portland
großen Aufwänden, denen keine Verbesserungen 2. Gray J (2006) A Conversation with Werner Vogels. ACM QUEUE (May 2006), pp
14–22
gegenüberstehen. Für Unternehmen bedeutete es 3. Conway ME (1968) How do committees invent. Datamation 14(4):28–31
große Investitionen in Talente, Kultur und Tech- 4. Wiggins A (2017) The Twelve-Factor App. Letzte Änderung 30.1.2012,
https://12factor.net/, letzter Zugriff: 15.6.2017
nologie. Ohne Exzellenz in Automatisierung und 5. Evans E (2003) Domain-Driven Design: Tackling Complexity in the Heart of Soft-
Monitoring ist das Ziel nicht zu erreichen. Ein pro- ware. Addison Wesley
6. Vernon V (2013) Implementing Domain-Driven Design. Addison Wesley
minentes Gegenbeispiel zu Cloud und Microservices 7. Poppendieck M, Poppendieck T (2003) Lean Software Development: An Agile
ist der Online-Service StackOverflow. In regelmäßi- Toolkit. Addison Wesley
8. Lewis J, Fowler M (2017) Microservices, https://martinfowler.com/articles/
gen Abständen veröffentlicht dieses Unternehmen microservices.html, letzter Zugriff: 17.5.2017
seine Architektur und die Traffic-Eckpunkte seiner 9. Kaus S, Steinacker G, Wegner O (2013) Teile und herrsche: Kleine Systeme für
Website [11]. Das Unternehmen legt dar, warum es große Architekturen. OBJEKTspektrum 5:8–13
10. Self-Contained Systems, http://scs-architecture.org/, letzter Zugriff: 17.5.2017
sich immer wieder gegen Cloud und Microservices 11. Stack Overflow: The Architecture – 2016 Edition, https://nickcraver.com/blog/
entschieden hat und für physikalische Hardware und 2016/02/17/stack-overflow-the-architecture-2016-edition/, letzter Zugriff:
4.6.2017
eine monolithische Architektur – bei gleichzeitig 12. Deutsch P: Fallacies of Distributed Computing, https://en.wikipedia.org/wiki/
hoher Weiterentwicklungsgeschwindigkeit. Fallacies_of_distributed_computing, letzter Zugriff: 8.6.2017
13. Flore T: Wer Microservices richtig macht, braucht keine Workflow Engine und
Daher sollte der Architekturansatz Microser- kein BPMN, https://blog.codecentric.de/2015/09/wer-microservices-richtig-macht-
vices – wie jeder andere auch – in der jeweiligen braucht-keine-workflow-engine-und-kein-bpmn/, letzter Zugriff: 8.6.2017

594 Informatik_Spektrum_40_6_2017