Der Begriff Microservices ist in aller Munde. Die kleinen Unternehmen möchten das adaptieren, was die Internetgiganten wie Twitter, Amazon oder Netflix in den letzten Jahren erfolgreich vorgemacht haben. Was sind eigentlich Microservices und welche Gründe sprechen für sie?
Autor: Roman Isheim, 29.06.2018, Thema: Microservices
Kurznavigation in diesem Beitrag:
Seite 1 Beitrag / Diskussionsgrundlage
Seite 2 Am nächsten persönlichen Erfahrungsaustausch teilnehmen
Seite 3 Kostenloses PDF-Angebot zum Artikel
Seite 4 Personalbedarf oder Jobsuche melden
Seite 5 Artikel mitgestalten, Fragen stellen, Erfahrungen teilen
Was sind überhaupt Microservices?
Bei Microservices handelt es sich um ein Architekturmuster der Informationstechnik, bei dem komplexe Anwendungssoftware aus unabhängigen Prozessen komponiert wird, die untereinander mit sprachunabhängigen Programmierschnittstellen kommunizieren. Microservices dienen eigentlich nur zur Modularisierung von Software. Die Dienste sind weitgehend entkoppelt und erledigen eine kleine Aufgabe. So ermöglichen sie einen modularen Aufbau von Anwendungssoftware. Getrieben wird die Entwicklung im Bereich von Microservices einerseits durch die Verfügbarkeit neuer Technologien wie Container und andererseits von der fortschreitenden digitalen Transformation, mit der sich Unternehmen zusehends konfrontiert sehen.
Die drei Varianten von Microservices
Ein Beispiel für Microservices ist die Developer Anarchy. Hierbei sind alle Mitglieder der Teams an der Entwicklung involviert und es gibt keine Requirements Engineers oder Manager. Die Geschäftsziele stellen das Hauptziel der Entwickler dar, also beispielsweise ein höherer Umsatz. Erfahrungen mit diesem Ansatz gibt es in klassischen Organisationen wie dem Onlinemagazin des Guardian oder in modernen Umgebungen wie Internetanzeigen. In diesem Szenario sind typische Microservices sehr klein und in verschiedenen Programmiersprachen geschrieben. Es ist auch möglich einen Microservice in einer anderen Programmiersprache neu zu schreiben. Da Microservices asynchron kommunizieren, können sie auch Log- und Monitoringdaten bereitstellen.
Für eine andere Variante steht Netflix. Hier Implementieren die Microservices REST-Schnittstellen, die von Clients genutzt werden können. Die Skalierung und eine unabhängige Entwicklung der Microservices stehen bei dieser Variante an erster Stelle. Für die Implementierung wird Java benutzt, da die meisten Werkzeuge und Bibliotheken aus dem Netflix-Universum auf diese Programmiersprache abgestimmt sind. Diese Tools stehen als Open Source zur Verfügung. Andere Technologien sind nur über einen Sidecar möglich. Dieser ist in Java geschrieben und stellt die Funktionalitäten über eine REST-Schnittstelle zur Verfügung. Bei diesem Ansatz ist die Implementierung komplexer Geschäftsfunktionalitäten möglich und die Microservices sind wesentlich größer.
Hinweis: Unsere Berichte sind oft sehr ausführlich. Daher bieten wir an dieser Stelle eine Zusendung des Artikels im PDF-Format zur späteren Sichtung an. Nutzen Sie das Angebot um sich die Praxis-Impulse in Ruhe durchzulesen, Sie können hierfür auch einfach auf das PDF-Symbol klicken.
Eine weitere Variante sind Self-contained Systems, kurz SCSs. Jedes SCS stellt eine eigene Webanwendung dar. Diese Webanwendungen können die Logik in einem anderen SCS aufrufen oder Daten replizieren. Das Hauptaugenmerk liegt jedoch auf der Intergration von Webinhalten. Im einfachsten Fall sind das Links auf ein anderes SCS. Jedoch können auch HTML-Schnipsel anderer SCSs integriert werden. Ein SCS ist normalerweise in der Verantwortung eines Teams und kann intern in mehrere Microservices aufgeteilt werden. Aber auch außerhalb von Microservices sind sie ein guter Ansatz für die Koordination der Arbeit mehrerer Teams bei der Entwicklung von Portalen. Weil der Fokus auf einer Integration der Web-Frontends liegt, muss bei der Nutzung von SCS auch auf diesen Bereich besonders geachtet werden.
Änderungen durch Microservices
Microservices gehen mit Architektur anders um als klassische Entwürfe. So ist es beispielsweise ein Ziel von Microservices, dass jeder einzelne Service ersetzt werden kann. Dieser Aspekt wird normalerweise nicht bei einer Architektur berücksichtigt. Das Hauptaugenmerk liegt eher bei der Änderbarkeit der einzelnen Teile als ihre Ablösung. Viele Entwickler beschäftigen sich damit, alte Systeme durch neue Implementierungen abzulösen. Deshalb ist die Idee, die Ablösung einer Software gleich schon beim Entwurf zu beachten, sicher ein wichtiger neuer Aspekt, den Microservices in den Mittelpunkt rücken.
Bei Microservices wird eine fachliche Aufteilung durch eine passende Aufteilung in die Teams und damit in der Organisation unterstützt. Microservices unterstützen also die unabhängige Arbeit von Teams. Letztendlich wird durch die Architektur sichergestellt, dass auch ein großes komplexes Gesamtsystem entwickelt werden kann. Hierfür erfolgt eine Unterteilung des großen Systems in technisch unabhängige Systeme. So wird schließlich ein großes Projekt in viele kleine Projekte zerlegt. Dadurch können Probleme bezüglich der Skalierung der Organisation eines Projektes durch eine geschickte Architektur gelöst werden.
Vorteile von Microservices
- Microservices sind klein. Dadurch bleibt die Übersichtlichkeit bestehen. Je nach Bedarf können sie, mit kleinem bis überschaubaren Aufwand, durch eine Neuimplementierung ersetzt werden.
- Unabhängiges arbeiten der Teams, da Microservices unabhängig voneinander verteilt und entwickelt werden können.
- Sie können unabhängig voneinander skaliert werden.
- Das Gesamtsystem ist robust, da Microservices-Systeme gegen den Ausfall anderer Services abgesichert werden.
- Erlauben langfristig eine produktive Entwicklung des Systems, da sie wartbar bleiben und auch die Architektur des Gesamtsystems erhalten bleibt.
Nachteile von Microservices
- Die Softwareverteilung und das Testen sind komplexer, weil es eine Vielzahl an Services gibt.
- Der Aufwand für die Migration bestehender Systeme ist hoch und bedeutet in den meisten Fällen eine Anpassung der Kommunikationskultur in den beteiligten Organisationen.
- Die Wahrscheinlichkeit steigt, dass mindestens eine Komponente ausfällt, da es mehr Systeme gibt.
- Die verteilte Architektur erzeugt zusätzliche Komplexität, vor allem Lastverteilung, Netzwerk-Latenzen oder Fehlertoleranz.
- Das Logging und Monitoring wird komplexer, da mehrere Systeme involviert sind, welche ggf. unterschiedliche Logging- und Monitoringtechnologien einsetzen.
