Microservices Part 1

P&M Individualsoftware Hamburg - Entwicklung von Individualsoftware

Microservices Part 1

In dieser zweiteiligen Blogserie werden wir uns mit dem Architekturmuster „Microservices“ beschäftigen. Im ersten Teil geht es um das grundsätzliche Verständnis. Was sind Microservcies? Was sind die Vor- und Nachteile? Und wofür braucht man Microservices überhaupt? Los geht’s!

Was sind Microservices?

Was sind Microservices?Wenn man eine Definition haben möchte, die in vielen Fällen unverständlich daherkommt, fragt man gerne Wikipedia: „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.“

Aha. So weit, so unverständlich – zumindest für Nicht-Informatiker. Unabhängig davon, was nun genau Microservices sind, fällt einem in der Beschreibung von Wikipedia auf, dass das Microservices Muster wohl nur bei großen Anwendungen zum Einsatz kommt. Und das ist auch richtig. Bei kleineren Anwendungen macht dieser Ansatz wenig Sinn: Die Microservice Architektur erzeugt einen gewissen Overhead und fügt der Anwendung Komplexität hinzu. Dies macht bei mittelgroßen Anwendungen wenig Sinn, da der Aufwand für die Implementierung von Microservices nicht im Verhältnis zu der Projektgröße steht.

Das Microservices Muster ist also ein Konzept, eine Strukturvorgabe, eine Blaupause um große komplexe Anwendungen zu entwerfen. Dabei wird die Anwendung aus kleineren, im Idealfall voneinander unabhängigen Prozessen, die eigenständige Anwendungen sind, zusammengesetzt. Das Zusammensetzen nennt man in diesem Fall Komposition. Letztlich wird die Anwendung in kleinere, voneinander unabhängige Anwendungen (Microservices) aufgeteilt.

Das Pendant zu Microservices ist die monolithische Architektur: Bei letzterer besteht die Anwendung aus nur einem Prozess – und so sind auch die meisten Anwendungen bis dato konzipiert. Die monolithische Architektur ist also der Normalfall.
Microservices vs. monolithische Architektur

Kurz zusammengefasst:

  • Microservices sind keine Technologie oder Sprache, sondern ein Muster (Pattern).
  • Microservices sind nur im Kontext von komplexen Anwendungen sinnvoll. Bekannte Beispiele, die die Microservices Architektur intensiv nutzen, sind Netflix, Amazon und eBay.
  • Eine große Anwendung wird durch das Microservices Muster in kleinere Anwendungen zerlegt. Die einzelnen Anwendungen erledigen eine für sich abgeschlossene Aufgabe, z.B. Produktkatalog, Suche, Accounting.
  • Micorservices sind insofern ein Ansatz, ein Versuch der Frage beizukommen, wie man mit der zunehmenden Größe und Komplexität von modernen Anwendungen umgeht, um weiterhin effektiv und effizient zu arbeiten.

 

Vor und Nachteile von Microservices

Die meisten offensichtlichen Vorteile wurden bereits erwähnt. Abschließend noch ein paar Punkte, die vielleicht nicht sofort jedem klar sind:

  • Wenn ein einzelner Microservice abschmiert, betrifft das nicht gleich die gesamte Anwendung. Beim monolitischen Ansatz ist die Verfügbarkeit der gesamten Anwendung nicht mehr gewährleistet.
  • Der Technologie-Stack ist nicht gesetzt. Einzelne Microservices können in jeder beliebigen Sprache implementiert werden, da sie letztlich eigene kleine Anwendungen sind und über z.B. REST Schnittstellen mit anderen Microservices kommunizieren können.
  • Neue Entwickler können sich schneller einarbeiten.

Wie so oft gibt es auch hier eine Kehrseite der Medaille:

  • Die Entwicklung von verteilten Systemen (und genau das ist der Ansatz von Microservices) kann sehr komplex sein. Die Tatsache, dass alle Komponenten, die normalerweise in einem Prozess laufen (z.B. Authentifizierung, Payment Service, …), nun unabhängige Anwendungen sind, erhöht die Anforderungen an die Kommunikation. Was ist, wenn eine Anwendung über das Netzwerk nicht erreichbar ist? Latenzzeiten können ebenfalls zum Problem werden.
  • Grundsätzlich können verteilte Datenbanken und das entsprechende Transaktionsmanagement sehr unangenehm sein. 🙂
  • Das Testen einer Micorservice basierten Anwendung ist komplexer. Jeder abhängige Service muss hochgefahren und verifiziert werden. Das kann schnell anstrengend werden, wenn über 100 Services ihr Unwesen treiben.
  • Das Deployen ist natürlich im ersten Schritt auch komplexer im Vergleich zum monolitschen Ansatz, wo nur eine Anwendung deployed wird.  Nun müssen die einzelnen Microservices untereinander koordiniert werden.

 

Allen genannten Nachteilen ist jedoch mit den entsprechenden Tools und einer cleveren Automatisierung beizukommen. Aber das ist nicht trivial und muss gut geplant werden.

Ausblick

Wir haben nun also eine grobe Vorstellung davon, was Microservices sind und für welche Projekte das Konzept in Frage kommt. Wir haben uns mit Vor- und Nachteilen der Architektur beschäftigt und wollen im zweiten Teil die Serie mit einem praktischen Beispiel schließen: Dabei erstellen wir eine CRUD Applikation mit jhipster auf Basis der Microservice Architektur. Schritt für Schritt.

Hattet Ihr schon mit Microservices zu tun? Gibt es Erfahrungen die Ihr mit uns teilen möchtet?

 

No Comments

Post A Comment