Was sind Microservices?

Microservices [1],[2] sind kleine, unabhängig deploybare Software-Module. Große Systeme in kleine Module aufzuteilen ist nichts Neues. Die unabhängige Deploybarkeit ist der entscheidende Unterschied: Jeder Microservice kann unabhängig von anderen Microservices in Produktion gebracht werden. Andere Ansätzen für die Modularisierung reichen nicht so weit: die Entwicklung ist zwar in einzelne Module aufgeteilt, aber für den Betrieb ist die Anwendung ein Monolith. Da solche Anwendungen nur als Ganzes in Produktion genommen werden können, spricht man auch von einem Deployment-Monolithen. Microservices hingegen sind auch für den Betrieb klar als Module erkennbar.

Es besteht keine Einigkeit, ob Microservices auch eine UI enthalten sollen. In einem engen Zusammenhang damit steht der Schnitt der Microservices. Ein Microservice sollte eine fachliche Einheit sein, so dass eine fachliche Anforderung am besten nur Änderungen an einem Microservice bedingt. Da fachliche Anforderungen oft eine Änderung an der UI benötigen, kann es sinnvoll sein, auch die UI als Teil desselben Microservice zu implementieren.

Ein Beispiel kann ein E-Commerce-Shop sein: Die Produktsuche, die Anmeldung und Verwaltung von Benutzern und der Bestellprozess können jeweils eigene Microservices sein - oder auch mehrere Microservices. Jeder der Microservices wird von einem eigenen Team entwickelt und betrieben.

Abb. 1: Beispiel für Microservices und Teams

Um Microservices unabhängig voneinander in Produktion bringen zu können, muss jeder Microservice ein eigener Prozess sein - oder sogar eine eigene virtuelle Maschine mit einer vollständigen Software-Installation einschließlich Betriebssystem. Seit einiger Zeit wird dafür Docker [3] verstärkt eingesetzt: Docker bietet viele Vorteile von virtuellen Maschinen, nutzt aber Linux-Container und ein spezielles Dateisystem. Dadurch verursachen Docker-Container im Vergleich zu einfachen Prozessen praktisch keine zusätzliche Last.

Wegen dieses Vorgehen können Microservices in verschiedenen Technologien implementiert sein: Die Programmiersprache und -plattform kann frei gewählt werden. Die Microservices müssen aber miteinander kommunizieren. Dazu muss eine gemeinsame Kommunikationstechnologie wie REST oder eine Messaging-Plattform festgelegt werden. Ebenso sollte ein gemeinsames Monitoring, eine einheitliche Überwachung von Log-Dateien und Standards für das Deployment definiert werden. Nur so ist der Aufwand für den Betrieb klein genug, um 50 oder 100 Microservices in Produktion zu bringen. Ein so hoher Grad an Automatisierung können im Moment nur wenige Organisationen vorweisen. Die Implementierung solcher Automatisierungen ist eine wichtige Voraussetzung für die Nutzung von Microservices.

Microservices müssen einen getrennten Datenhaushalt haben: Die Nutzung einer gemeinsamen Datenbasis würde die Microservices zu eng aneinander binden. Eine Änderung der Daten-Schemata wäre nur noch durch die Koordination der beteiligten Services möglich - und das kann sehr aufwendig sein. Eine so starke Abhängigkeit widerspricht auch der weitgehenden Unabhängigkeit beim Deployment, das auch eine unabhängige Entwicklung ermöglicht.

Letztendlich erzeugen Microservices nämlich eine große Unabhängigkeit zwischen den einzelnen Modulen: Technologie-Entscheidungen können in jedem Microservice einzeln getroffen werden und ebenso können die Microservices getrennt voneinander in Produktion gebracht werden. Ebenso kann der interne Aufbau und die Architektur der Microservices unabhängig voneinander entschieden und definiert werden.

Die Größe eines Microservice

Der Name “Microservice” verrät schon, dass die Größe eines Microservices wichtig ist. Es gibt jedoch keine feste Größe für einen Microservices, sondern nur bestimmte Grenzen:

Abb. 2: Grenzen für die Größe von Microservice

Aber Microservices können nicht beliebig klein werden - es gibt auch untere Grenzen für die Größe eines Microservice:

Letztendlich hängt also die minimale Größe eines Microservice entscheidend von der Infrastruktur ab. Amazon Lambda [5] ermöglicht beispielsweise sehr einfach das Deployment einer einzelnen JavaScript-Funktion oder Java-Klasse. Dabei wird jeder Aufruf des Codes einzeln abgerechnet. Mit einer solchen Infrastruktur sind viel kleinere Microservice-Größen möglich als mit Docker-Containern und Application Servern, weil der Aufwand für das Deployment viel geringer ist.

Warum Microservices?

Offensichtlich haben Microservices einige Herausforderungen - verteilte Systeme zu entwickeln und zu betreiben ist nicht einfach. Ebenso ist das Management der Architektur über die Microservices hinweg komplex.

Gründe für Microservices gibt es viele:

Abb. 3: Fachliche Aufteilung von Microservices und Microservice-Teams

Viele Unternehmen migrieren von einem Deployment-Monolithen zu einer Microservices-Architektur, weil sie damit eine größere Unabhängigkeit der Teams erreichen und Microservices mit Continuous Delivery schneller in Produktion bringen können. Dabei kommt ihnen zu Gute, dass Legacy-Systeme sehr einfach mit Microservices ergänzt werden können.

Neben diesen drei Vorteilen gibt es weitere Gründe für Microservices:

Diese Vorteile von Microservice können alleine schon Grund genüg sein, um Microservices einzuführen. So gibt es beispielsweise Projekte, in denen das System durch Microservices robuster gemacht werden soll. Das hat natürlich Auswirkungen darauf, wie Microservices eingeführt werden. In diesem Fall würde zunächst das System mit den entsprechenden Technologien versorgt werden, um bei Ausfällen von Teilen die Verfügbarkeit der anderen Teilen des Systems zu garantieren. Danach können diese Teile in einzelne Microservices überführt werden. Dieser Ansatz ist ganz anders also die Ergänzung eines Monolithen mit dem Ziel von Continuous Delivery und abhängiger Entwicklung.

Es gibt also nicht nur einen Grund für die Einführung von Microservices, sondern eine Vielzahl. Die Gründe lösen konkrete Problemen, denen immer mehr Unternehmen gegenüber stehen. Und die Idee ist auch nicht besonders neu: Die Idee, dass Teams jeweils einen Service entwickeln und betreiben, hat Amazon schon 2006 umgesetzt [7]. Microservices sind also deutlich mehr als ein neuer Hype.

Einsteigen oder weiter wie bisher?

Wie bei jeder Architektur-Entscheidung sollte man auch bei Microservices überlegen, ob sich der Einstieg lohnt. Microservices habe viele Vorteile, so dass mehr als ein Faktor betrachtet werden muss. Außerdem ist der Einstieg einfach: Einen Microservice zu schreiben ist nicht besonders aufwendig. Und ebenso ist es nicht besonders schwierig, ein Legacy-System mit Microservices zu ergänzen.

Bei dem Einstieg in Microservice ist die Migration weg von einem Monolithen gang und gäbe. Interessanterweise gibt es bei Microservices-Architektur auf der grünen Wiese keine Einigkeit, ob es besser ist mit einem Monolithen zu starten [8] oder nicht [9]. Die Struktur eines Monolithen ist leichter änderbar, was gerade am Anfang eines Projekts ein Vorteil sein kann. Auf der anderen Seite muss der Monolith später in Microservices aufgebrochen werden.

Abb. 4: Projekte können die Anzahl Microservices schrittweise erhöhen.

Eine wesentliche Herausforderung ist der Betrieb. Um mit einer großen Anzahl von Microservices zurecht zu kommen, ist ein hohes Maß an Automatisierung notwendig. Das stellt viele Betriebseinheiten vor unlösbare Herausforderungen. Technisch sind solche Herausforderungen lösbar - aber oft steht die Barriere zwischen Entwicklung und Betrieb einem reibungslosen Projekt im Weg.

Fazit

Microservices sind ein weiterer Ansatz für die Modularisierung von Systemen. Microservices können unabhängig voneinander in Produktion gebracht werden. Das hat viele Vorteile - vor allem im Bereich von Änderbarkeit und Continuous Delivery. Damit passen Microservices gut zu Herausforderungen, denen immer mehr Unternehmen gegenüber stehen - nämlich schneller mehr Änderungen in Produktion zu bringen. Aber darüber hinaus gibt es noch viele weitere Gründe für Microservices. Daher sind Microservices mehr als ein Hype, sondern ein Architektur-Trend, der eine Folge aktueller Anforderungen ist. Firmen wie Netflix oder Amazon zeigen, wie Microservices erfolgreich umgesetzt werden können.

Der Einsteig in Microservices ist ohne größere Schwierigkeiten möglich, denn ein kleinen Service zu entwickeln und in Produktion zu bringen ist nicht allzu komplex. Später ergeben sich Herausforderung bei Deployment und Betrieb. Sie hängen damit zusammen, dass die Anzahl Microservices irgendwann sehr groß sein wird.

Meta-Fazit

Auf einer anderen Ebene sind Microservices ebenfalls interessant: Schon 1967 hat Mel Conway das nach ihm benannte Gesetz aufgestellt [10]. Es besagt, dass eine Organisation nur Architekturen hervorbringen kann, die ihren Kommunikationsbeziehungen entspricht. Das ist logisch, denn eine Schnittstelle in der Architektur bedingt, dass Teams sie abstimmen müssen. Microservices nutzen das aus. Die Architektur wird dadurch unterstützt, dass die Aufteilung in fachliche Microservices in der Organisation durch fachliche Teams gespiegelt wird. Jeder Microservices wird durch ein Team umgesetzt. Auch außerhalb von Microservices wäre eine solche Integration von Organisation und Architektur sicher hilfreich.

Außerdem berücksichtige Microservices, dass Software irgendwann abgelöst wird. Da einzelne Microservices ersetzt werden können, ist eine Migration einzelner Teile des System einfacher. Sicher wäre es hilfreich, wenn die Entsorgung von Software bei Architekturen generell stärker betrachtet wird. Schließlich gibt es sehr viele Projekte, die alte System ablösen sollen - und diese Projekte sind oft sehr aufwändig und komplex. Wenn die Architektur ähnlich wie Microservices eine Ablösung vereinfacht, würden solche Projekt weniger risikoreich sein.

Referenzen

  1. Sam Newman: Building Microservices,O'Reilly, 2015,ISBN 978–1–4919–5035–7  ↩

  2. Eberhard Wolff: Microservices: Grundlagen flexibler Softwarearchitekturen, dpunkt Verlag, 2015, ISBN 978–3–8649–0313–7  ↩

  3. http://docker.com/  ↩

  4. http://martinfowler.com/articles/distributed-objects-microservices.html  ↩

  5. https://aws.amazon.com/de/lambda/  ↩

  6. Eberhard Wolff: Continuous Delivery: Der pragmatische Einstieg, dpunkt Verlag, 2014, ISBN 978–3–8649–0208–6  ↩

  7. http://jandiandme.blogspot.com/2006/10/jaoo-2006-werner-vogels-cto-amazon.html  ↩

  8. http://martinfowler.com/bliki/MonolithFirst.html  ↩

  9. http://martinfowler.com/articles/dont-start-monolith.html  ↩

  10. http://www.melconway.com/Home/Conways_Law.html  ↩