Lesezeit ca. 7 Minuten
Einleitung
Microservices können Unternehmen eine Reihe von Vorteilen bieten. Schließlich sind große Applikationen beliebt und erfordern eine Softwarearchitektur, die die Bedürfnisse der Geschäftstätigkeiten, der Entwickler und der Endnutzer erfüllt.
Die zehn wichtigsten Vorteile von Microservices-Architekturen
- Zugang:
Da Microservices separat deployed werden und über APIs kommunizieren, werden Codes und Applikationen zugänglicher für Mitarbeiter, die nicht Teil der Entwickler-Teams sind. Dank des modularen Ansatzes können Unternehmen ihre verschiedenen Services, einschließlich ihrer spezifischen Funktionen, verstehen, ohne sich Gedanken um andere Softwareteile machen zu müssen. - Fehlermanagement:
Wenn eine Microservices-Architektur richtig implementiert wird, vereinfacht das den Entwickler-Teams, Bugs oder andere Fehler zu erkennen. Immer, wenn ein Fehler auftritt, wissen die Entwickler ganz genau, wo sie schauen müssen, wodurch wertvolle Zeit eingespart und Aufwand im Allgemeinen reduziert wird. Zudem bedeutet die Fehlerbehebung an einem einzelnen, unabhängigen Service gleichzeitig, dass keine anderen Codes repariert oder die gesamte Applikation als solche deployed werden muss. - Wartung:
Dieser Vorteil geht Hand in Hand mit den ersten beiden Punkten. Microservices-Architekturen gestalten die Wartung und die Verwaltung der Services einfacher. Tatsächlich kann jeder einzelne Service von einem anderen Team verwaltet werden, da diese Services für einen einzigartigen Prozess mit eigener Datenbank stehen. Zudem können einzelne Updates durchgeführt werden, ohne dass dafür das gesamte Softwaresystem zum Stillstand gebracht wird. - Anpassungsfähigkeit:
Microservices sind nur lose miteinander gekoppelt und kommunizieren über standardisierte Schnittstellen (APIs). Da sie einzeln entwickelt werden, brauchen sie nicht auf derselben Programmiersprache oder Technologie zu basieren. So kann jeder Service individuell, den auszuführenden Funktionen entsprechend, gestaltet werden. - Evolutionär:
Geschäftsanforderungen sind konstanten Änderungen unterworfen, weswegen Services angepasst und neue Features hinzugefügt werden müssen. In traditionellen Architekturen, in denen Software als ein großes Ganzes gesehen wird, bedeutet dies einen ernsthaften Eingriff in die gesamte Unternehmenssoftware und die mögliche Beschädigung bereits vorhandener Features. Durch den modularen Ansatz der Microservice-Architektur wird solchen Problemen vorgebeugt. - Skalierbarkeit:
Einer der wichtigsten Vorteile von Microservices ist ihre Fähigkeit, horizontal zu skalieren: Jeder eingesetzte Service kann dupliziert werden, um Engpässe aufgrund einer langsamen Ausführung zu vermeiden. Eine weitere Möglichkeit der Leistungssteigerung wäre das Deployment von Services auf einer leistungsfähigeren Hardware oder auf mehreren Maschinen, die Daten parallel verarbeiten. - Tests und Überwachung:
Einzelne Software-Komponenten lassen sich viel einfacher als komplexe Applikationen testen. Wenn jeder Microservice angemessen getestet wird, dann ist meist die Software als solche robuster und zuverlässiger. Und da man eben auch nur bestimmte Teile einer Applikation isoliert betrachten kann, führt dies zu einem besseren Sicherheitsmanagement. - Bereitstellung:
In den letzten Jahren haben sich Automatisierungstechniken drastisch verbessert, wodurch auch die Entwicklung der Cloud und AWS vorangetrieben wurde. Dank Automatisierungstechniken für Infrastrukturen und des Prinzips der kontinuierlichen Bereitstellung konnte die operative Komplexität der Erstellung, Implementierung und des Testens von Microservices signifikant reduziert werden. - Integration:
Eine Software sollte so viele Features und Services wie nötig integrieren. Auch wenn dies auf den ersten Blick logisch erscheinen mag, kann die Integration einer neuen Softwarekomponente in eine bereits bestehende Applikation in der traditionellen Software-Entwicklung eine Herausforderung darstellen. Durch den Einsatz kontinuierlicher Integrationstools haben Microservices diesen Prozess grundlegend revolutioniert. - Wiederverwendbarkeit:
Ein allzu häufig vernachlässigter Vorteil von Microservices ist die Tatsache, dass die unabhängigen Komponenten, die die Software ausmachen, für weitere Projekte in der Zukunft genutzt werden können. Indem erfolgreiche Prozesse wiederverwendet und nur leicht an die neuen Anforderungen angepasst werden, brauchen Entwickler nicht für jedes Projekt das Rad neu zu erfinden und sparen wertvolle Ressourcen ein.
Das sind die wesentlichsten Vorteile von Microservices im Vergleich zu monolithischer Architektur. Dabei wird oft versucht, alle Ressourcen jedem Microservice individuell zur Verfügung zu stellen und Datenaustausch entsprechend durch Kommunikation zwischen Microservices zu gewährleisten. Dies funktioniert in einigen Projekten perfekt, in anderen schlecht und in anderen gar nicht. Deswegen kann schon aus diesem Grund keine pauschale Entscheidung für oder gegen Microservices getroffen werden, und gerade solche Dinge haben zum „Niedergang“ von EJBs und sogar der gesamten Programmiersprache „C++“ in Webapplikationen geführt. EJB waren nicht grundsätzlich schlecht durchgedacht. Was dabei allerdings kaum einkalkuliert wurde, war der Faktor „Mensch“. In fast jedem Projekt wurden unzählige kaum benutzte Pools aus stateless beans gemacht, was Ressourcen-Verbrauch und Applikationsstartzeit immer weiter steigerte.
Der einzige Ausweg aus dem Dilemma ist, entsprechende Systemeigenschaften rechtzeitig zu erkennen und die wichtigste Ressource – Datenbank – nur logisch zwischen Microservices zu teilen, ohne das systemweite Entity-Relationship-Modell zu zerstören.
System muss gut durchdacht sein
Dasselbe Problem entsteht auch, wenn man versucht, das System 100 Prozent ersetzbar und skalierbar zu machen. Mit großer Wahrscheinlichkeit wird dabei eine Ressource nicht dupliziert. Man kann aber mit immer komplizierterer Architektur diesem Ziel näherkommen. Beispiel: Jeder Datenbankcluster übernimmt eine Rolle als Datenbank und DB-Cluster-Koordinator. Die Frage wäre: Ist so ein vielfach komplizierteres System sicherer als ein deutlich einfacheres? Bei Datenbank-Clustern – Kafka-Clustern – trifft dies zu, da diese genauso wie Java VM unzählige Male getestet und in vielen Unternehmen verwendet wurden. Fazit: Microservices sind im Vergleich zu monolithischer Architektur sind vielfältiger, skalierbarer und performanter als ein einziger Microservice. Allerdings muss das System gut durchdacht werden, und es existiert keine pauschale Systemarchitektur. In einigen Fällen ist eines besser, in anderen nicht. Im schlimmsten Fall ist alles 100 Prozent gegensätzlich und implementierte Microservices sind langsamer und schlechter zu warten als ein einziger Microservice (monolithische Architektur). Wobei ein einziger Microservice als Web-Applikation oder EJB-Applikation unterschiedliche Dinge sind – sie gehören aber beide in diesem Fall zur selben Kategorie. Es gibt sogar Beschreibungen mit Microservice-Architektur innerhalb der EJB-Applikation. Oder: Weit vor der Spring-Verbreitung wurde „Lego“-Architektur von vielen Firmen in der eigenen Softwareentwicklung präsentiert. Spring-Vorteile wurden im Jakarta-EJB-Projekt nach Möglichkeit benutzt, und so existieren Nachteile, die nie beseitigt werden, nur in vergessenen Projekten
Fehler zu spät erkannt
Es existieren unzählige spring/spring boot Bibliotheken, mit denen man JPA, NoSQL, Model-View-Contoller, Security etc. bei Microservice realisieren kann. Man kann auch asynchrone Kommunikation mit Message Broker oder synchrone mit REST oder SOAP gewährleisten. Über jedes einzelne Thema ließe sich ein gesamtes Buch schreiben, und es existieren unzählige Bücher diesbezüglich. Das alles ist Java-spezifisch und für Java-Entwickler gedacht. Worauf ich stattdessen lieber eingehen würde ist die weitere mögliche Microservice-Entwicklung und Java- Entwicklung im Allgemeinen. Dabei kann man auch die vergangenen Jahrzehnte bei der Vorhersage berücksichtigen. Es existierte zuerst die gut verbreitete Programmiersprache C++ mit entsprechender Tuxedo-Implementierung für Webapplikationen. Die war aus heutiger Sicht nicht überlebensfähig, da alles gleich nativ kompiliert wurde und ein Garbage Collector mit entsprechenden Nachteilen nicht vorhanden war. Einige Zeit später wurde managed code in C++ eingeführt und ein Garbage Collector implementiert. Aber zu spät: Rein objektorientierte Sprachen wie Java breiteten sich bereits aus, und dort war es im Vergleich zu C++ gar nicht möglich, unmanaged source code zu schreiben.
Später wurde in Java zuerst EJB 2 und danach das stark vereinfachte EJB 3 implementiert. In EJB 3 benutzte man stateless und statefull session beans. Später hat man den Fehler erkannt, die vernachlässigte EJB-Entwicklung von Oracle an Jakarta abgegeben, aber genauso wie bei C++ war es zu spät. Spring breitete sich bereits aus, und den schwergewichtigen Applikationsserver mit unzähligen dafür implementierten Applikationen konnte man nicht von heute auf morgen schlank machen.
Im Laufe der Jahre kamen neue Konzepte hinzu: Parallele Verarbeitung (Anzahl der PC-Prozessoren steigt von Jahr zu Jahr), weitere Modularisierung etc. Die entsprechende Reaktion in Java waren Streams, OSGi, Lombok, Microservices etc. Da Java-Syntax ursprünglich auf solche Dinge nicht ausgelegt wurde, ist die Schreibweise nicht so kompakt wie in der einen oder anderen ganz neuen Programmiersprache. Die Deklarationen sind nicht so perfekt wie in der Programmiersprache Swift. Das spielt aber bis heute keine relevante Rolle. Microservices sind eben nur eine optionale Vorgehensweise. Man kann einen einzigen Microservies implementieren, danach aus irgendeinem Grund einen zweiten. Dann kann man es als Microservices-Architektur bezeichnen. Ohne eine Erfindung vergleichbar mit Garbage Collector vor Jahrzehnten wird sich da kaum etwas grundsätzlich ändern.
Ihr Ansprechpartner:
Viatcheslav Mikhalev | Java Entwickler | viatcheslav.mikhalev@lucke-edv.de
Lucke EDV GmbH | Zurück
