Microservices

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Microservices sind ein Architekturmuster der Informationstechnik, bei dem komplexe Anwendungssoftware aus kleinen, unabhängigen Prozessen komponiert wird, die untereinander mit sprachunabhängigen Programmierschnittstellen kommunizieren. Die Dienste sind klein, weitgehend entkoppelt und erledigen eine kleine Aufgabe. So ermöglichen sie einen modularen Aufbau von Anwendungssoftware.[1][2]

Philosophie und Details[Bearbeiten | Quelltext bearbeiten]

Der Gedanke hinter Microservices entspricht weitgehend dem der Unix-Philosophie („Do One Thing and Do It Well“). Die Dienste sollten üblicherweise die folgenden Eigenschaften haben:

  • Die Services können einfach ersetzt werden.
    • Der Umfang eines Microservices sollte für jedes Teammitglied überschaubar sein.
    • Ein Microservice sollte vom zuständigen Team (üblicherweise 5 bis 7 Entwickler) mit vertretbarem Zeitaufwand (z. B. innerhalb eines Monats) neu erstellt und ersetzt werden können.
  • Ein Microservice sollte einen Bounded Context im Sinne von Domain-driven Design implementieren.
    • Die Dienste haben eine einzige Geschäftsfunktion. Sie können beispielsweise einen Bestellvorgang, die Registrierung oder die Rechnungserstellung umfassen, jedoch nicht mehrere dieser Dinge.
  • Der Nutzen für den Benutzer steht im Mittelpunkt.
    • Die Kernfunktionalität sollte frühzeitig ausgeliefert werden um einen möglichst frühen Nutzen bereitzustellen.
    • Schnittstellen sollten, z. B. über Humane Registries, selbstdokumentierend sein. Beispielsweise Swagger für JSON-basierte REST-Services.
    • Nach der Bereitstellung einer neuen Version des Services muss die alte Version des Endpunktes für eine bestimmte Zeit weiter bereitgestellt werden.
      Hauptartikel: REST-Versionierung
  • Ein Microservice wird nur von einem Team entwickelt. So sorgt das Gesetz von Conway dafür, dass die Architektur auch durch organisatorische Maßnahmen abgesichert wird. Ebenso kann ein Team für mehrere fachlich zusammenhängende Microservices (Self-contained System)[3] verantwortlich sein.
    • Kommunikationsoverhead und Interessenskonflikte zwischen Teams wird vermieden.
  • Die Schnittstellen verstecken Implementierungsdetails.
    • Es sollte nicht ersichtlich sein, mit welcher Architektur ein Service implementiert wurde. Es werden dabei bevorzugt Standardverfahren mit geringem Overhead, wie REST, eingesetzt.
    • Datenbanken werden nicht von mehreren Services verwendet, sondern immer nur von einem einzigen Service. Dies betrifft auch Zugriffe über Views und Stored Procedures. Andernfalls wird die Architektur über die Datenbank veröffentlicht und die Transaktionssicherheit, Datenintegrität und Versionierung können nicht sichergestellt werden.
  • Microservices werden gegenüber anderen Services isoliert.
    • Jeder Microservice kann eine andere Programmiersprache, Datenbank oder einen ganz anderen Technologie-Stack nutzen.
    • Jeder Microservice kann unabhängig von anderen Microservices in Produktion gebracht werden. Dies erleichtert einen hohen Automatisierungsgrad und ermöglicht Continuous Delivery.
    • Objekte, welche in mehreren Bounded Contexts vorkommen, werden in jedem Service getrennt implementiert. Beispielsweise wird derselbe Kunde in einem Authentifizierungssystem, einem Bestellsystem, einem Logistiksystem und einem Rechnungssystem jeweils durch unterschiedliche Objekte repräsentiert, da an die Objekte unterschiedliche Anforderungen gestellt werden.
    • Microservices werden in getrennten OS-Containern, Virtuellen Maschinen oder Servern ausgeliefert. Dies sichert den Service gegenüber einer Überlastung des Host-Systems durch einen anderen Service.
  • Wie alle Services müssen auch Microservices sicher sein:

Die Größe eines Microservices wird hierbei dadurch nach unten begrenzt, dass die Netzwerkkommunikation zwischen Microservices ressourcenintensiv ausfallen kann und für jeden Microservice ein eigenes Deployment vorgesehen werden muss.

Typische Bestandteile einer Microservice-Architektur[Bearbeiten | Quelltext bearbeiten]

Microservices benötigen sehr viel Infrastruktur, welche durch jeweils eigenständige Services implementiert wird.

Für die Lastverteilung externer HTTP-Anfragen von Clienten kommen Load-Balancer zum Einsatz. Statische Inhalte werden mittels eines Content Delivery Network ausgeliefert.

Die für die Geschäftsanforderungen zuständigen Services werden durch eine Reihe von Plattform- oder Infrastruktur-Services unterstützt. Diese übernehmen zentrale Aufgaben wie das Anwendungs- und Service-Monitoring, Logging-Webservices, Operations-Datenbanken, Konfigurationsmanagement, Verschlüsselung, Autorisierung und Authentifizierung, sowie Autoscaling, Deployment, A/B-Testing und Fault-Injection-Testing (FIT). Zudem gibt es zentrale Routingdienste, welche sich um die Zuordnung von URLs zu Instanzen mit den jeweiligen Diensten kümmern.

Hiezu kommen noch Dienste für die Datenpersistierung, insbesondere Caching, Relationale Datenbanken und NoSQL-Datenbanken, sowie BLOB-Speicher für beliebige Dateien.

Abgrenzung zu SOA[Bearbeiten | Quelltext bearbeiten]

SOA (Serviceorientierte Architektur) und Microservices nutzen beide Dienste als Architektur-Elemente. SOA nutzt Dienste, um verschiedene Anwendungen zu integrieren. Die Kombination der Dienste erfolgt durch Orchestrierung oder Choreografie und Portale können eine gemeinsame UI für alle Dienste bieten. Microservices strukturieren eine Anwendung durch Dienste. Jeder Microservice kann eine UI enthalten und Geschäftsprozesse implementieren, wie sie bei SOA in der Orchestrierung zu finden sind.

Vorteile[Bearbeiten | Quelltext bearbeiten]

  • Weil Microservices unabhängig voneinander verteilt und entwickelt werden können, können Teams unabhängig voneinander arbeiten. Das ermöglicht die Skalierung agiler Entwicklungs-Prozesse, ohne viel Kommunikations- und Koordinationsaufwand zu erzeugen.
  • Microservices sind klein. Dadurch bleiben sie übersichtlich und leicht weiterentwickelbar. Bei Bedarf können sie, mit kleinem bis überschaubaren Aufwand, durch eine Neuimplementierung ersetzt werden.
  • Oft schleichen sich bei Systemen ungewollte Abhängigkeiten ein und irgendwann geht die ursprüngliche Architektur vollständig verloren. Die Architektur des Microservices-Systems bleibt stabil, weil Abhängigkeiten zwischen Microservices über die API eingeführt werden müssen. Das ist aufwändig und passiert nicht aus Versehen.
  • Weil die Microservices wartbar bleiben und auch die Architektur des Gesamtsystems erhalten bleibt, erlauben Microservices auch langfristig eine produktive Entwicklung des Systems.
  • Microservices können unabhängig voneinander skaliert werden.
  • Microservice-Systeme können gegen den Ausfall anderer Services abgesichert werden, so dass das Gesamtsystem robust ist.
  • Continuous Delivery ist aufgrund der Größe der Microservices einfacher.
  • Jeder Microservice kann mit einer anderen Technologie implementiert werden. Das vereinfacht Experimente mit neuen Technologien und verhindert das Veralten des Technologie-Stacks.
  • Microservices können auch dazu genutzt werden, um Legacy-Systeme zu erweitern, ohne dabei zu viele Änderungen an der alten Code-Basis vornehmen zu müssen.
  • Wenn Schlüsseldienste identifiziert wurden, können im Falle einer Überlastung unkritische Services reduziert oder abgeschaltet werden, um Ressourcen für kritische Services frei zu machen.

Nachteile[Bearbeiten | Quelltext bearbeiten]

Microservices werden wegen einiger Merkmale kritisiert:

  • Die verteilte Architektur erzeugt zusätzliche Komplexität, vor allem Netzwerk-Latenzen, Lastverteilung oder Fehlertoleranz (siehe dazu auch: Fallacies of Distributed Computing).
  • Da es mehr Systeme gibt die ausfallen können als bei monolithischen Services, steigt auch die Wahrscheinlichkeit, dass mindestens eine Komponente ausfällt. Gibt es beispielsweise 10 Services mit jeweils 99,9 % Ausfallsicherheit, so besteht für das Gesamtsystem nur noch eine Ausfallsicherheit von (99,9 %)10 = 99,0 %.
  • Die Vielzahl an Services macht die Softwareverteilung und das Testen komplexer.
  • Der Aufwand für die Migration bestehender Systeme ist beträchtlich und bedeutet in der Regel auch eine Anpassung der Kommunikationskultur in den beteiligten Organisationen.[4]
  • Das Logging und Monitoring wird komplexer, da mehrere Systeme involviert sind, welche ggf. unterschiedliche Logging- und Monitoringtechnologien einsetzen. Es sollten daher, zusätzlich zu dezentralen Logging- und Monitoringlösungen, zentrale Logging-, Monitoring- und OpsDB-Dienste eingesetzt werden.
  • Da es sich um ein, potentiell weltweit, verteiltes System handelt, müssen nicht nur unterschiedliche Zeitzonen der Client-Anwendungen, sondern auch unterschiedliche Zeitzonen der Hosts berücksichtigt werden. Eine Zeitsynchronisierung zwischen den Hosts (z. B. mittels NTP oder noch besser PTP) und die Verwendung passender Zeit-Bibliotheken (z. B. Joda Time oder Noda Time) wird damit zwingend notwendig.[5][6]
  • Da es sich bei Microservices um eine verteilte Architektur handelt, muss aufgrund des CAP-Theorems zwischen Verfügbarkeit der Anwendung und der Datenkonsistenz gewählt werden. Dem steht allerdings gegenüber, dass ein monolithischer Service im Fehlerfall, etwa bei einer Überlastung, ebenfalls nicht immer verfügbar ist. Zudem kann für Daten, sobald sie dem Nutzer angezeigt wurden, ebenfalls keine Konsistenz garantiert werden.
  • Da die Services in unterschiedlichen Programmiersprachen und Software-Stacks implementiert werden können, erhöhen sich die Anforderungen an die Entwicklungswerkzeuge und das Plattform-Management. Zudem muss die Funktionalität von Bibliotheken teilweise dupliziert werden.

Beispiele[Bearbeiten | Quelltext bearbeiten]

Folgende Internetdienste sind bekannt dafür, Microservices zu benutzen:

Implementierungen[Bearbeiten | Quelltext bearbeiten]

Siehe auch[Bearbeiten | Quelltext bearbeiten]

Weblinks[Bearbeiten | Quelltext bearbeiten]

Literatur[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. Eberhard Wolff: Microservices: Grundlagen flexibler Softwarearchitekturen., ISBN 978-3-86490-313-7.
  2. Sam Newman: Microservices: Konzeption und Design, ISBN 978-3-95845-081-3.
  3. Stefan Tilkov: Characteristics of Microservices, Applications and Systems.
  4. Microservices. In: In: Jens Fromm und Mike Weber, Hg., 2016: ÖFIT-Trendschau: Öffentliche Informationstechnologie in der digitalisierten Gesellschaft. Berlin: Kompetenzzentrum Öffentliche IT. ISBN 978-3-9816025-2-4.
  5. Noah Sussman: Falsehoods programmers believe about time. In: Infinite Undo! Abgerufen am 12. April 2017 (englisch).
  6. Noah Sussman: More falsehoods programmers believe about time; “wisdom of the crowd” edition. In: Infinite Undo! Abgerufen am 12. April 2017 (englisch).
  7. a b c d Todd Hoff: Deep Lessons From Google And EBay On Building Ecosystems Of Microservices. In: High Scalability. 1. Dezember 2015, abgerufen am 11. März 2017.
  8. Microservices bei Amazon.
  9. Microservices bei Netflix.
  10. Microservices bei Guardian.
  11. Microservices bei SoundCloud.
  12. Schedule Thursday (3rd Dec.) - conference.
  13. From Monolith to Microservices, Zalando’s Journey.
  14. Guido Steinacker: Von Monolithen und Microservices. In: Informatik Aktuell. 2. Juni 2015, abgerufen am 28. April 2016 (deutsch).
  15. Vertx.