Microservices: Vorteile und Nachteile

[vc_row fullwidth=”true” fullwidth_content=”false” el_class=”easy-post-layout”][vc_column][vc_column_text disable_pattern=”false” css=”.vc_custom_1576772323112{margin-bottom: 0px !important;}”]Microservices sind eine gute Möglichkeit, große Software-Projekte in lose miteinander verbundene Module aufzubrechen, die mittels Schnittstellen (APIs) miteinander kommunizieren. In den vergangenen Jahren sind Microservices zunehmend populär geworden, denn die modulare Architektur, die es erlaubt große Software Projekte in kleinere, unabhängige und lose miteinander verbundene Module aufzubrechen, sorgt für größere Dynamik und Agilität. Doch der Einsatz von Microservices birgt viele Vor- und Nachteile, über die es aufzuklären gilt.[/vc_column_text][/vc_column][/vc_row][mk_page_section bg_image=”https://easy-software.com/wp-content/uploads/2019/09/banner-microservices-vorteile-nachteile.jpg” bg_repeat=”no-repeat” bg_stretch=”true” speed_factor=”0″ video_opacity=”0″ min_height=”450″ full_width=”true” padding_top=”0″ padding_bottom=”0″ el_class=”easy-post-layout” sidebar=”yawp_wim”][vc_column][/vc_column][/mk_page_section][vc_row fullwidth=”true” fullwidth_content=”false” el_class=”easy-post-layout”][vc_column][vc_custom_heading text=”Blick zurück: der Monolith” use_theme_fonts=”yes” el_id=”WasistdieeIDAS-Verordnung”][vc_column_text disable_pattern=”false” css=”.vc_custom_1576772547026{margin-bottom: 0px !important;}”]Zunächst einmal ein Blick auf die klassische, monolithische Architektur, wie sie bis vor wenigen Jahren noch Standard war: Wenn zum Beispiel jemand eine klassische Applikation in Java baut, dann wird er zunächst eine erste Ebene – das Nutzer Interface – erstellen, gefolgt von einer Anwendungsebene, die alle Business-Logiken handhabt. Darauf folgt dann die Integrationsebene, die die einzelnen Komponenten der Anwendungseben lose miteinander verbindet. Danach ist eine Datenebene notwendig, die ein darunterliegendes Persistenz-System zugänglich macht. Danach wird normalerweise ein Anwendungspaket erstellt und an einen Anwendungsserver geliefert. Dadurch wird die Architektur selbst ganz automatisch monolithisch, da es zwar einzelne Komponenten gibt, diese aber alle zusammen verpackt sind.[/vc_column_text][/vc_column][/vc_row][vc_row fullwidth=”true” fullwidth_content=”false” el_class=”easy-post-layout”][vc_column][vc_custom_heading text=”Vorteile von Microservices” use_theme_fonts=”yes” el_id=”WasleistetdieeIDAS-Verordnung”][vc_column_text disable_pattern=”false” css=”.vc_custom_1576772598665{margin-bottom: 0px !important;}”]Für Entwickler schafft diese Art Architektur einige Herausforderungen, denn monolithische Architekturen haben im Gegensatz zu Microservices einige Nachteile:

1. Wächst eine Anwendung, so wächst auch die damit verbundene Code-Basis, die die Entwicklungsumgebung jedes Mal überlastet, wenn die Applikation lädt. Das reduziert die Produktivität der Entwickler.
2. Da die Applikation auf EAR/JAR/WAR läuft, wird es schwierig, die Technologie nachträglich zu ändern. Die Code-Basis zu ändern ist kompliziert, da sich immer nur schwer absehen lässt, wie sich das auf die Funktionalität der gesamten Anwendung auswirkt.
3. Versagt eine einzelne Funktion der Applikation oder eine einzelne Komponente, dann versagt die gesamte Anwendung. Wenn zum Beispiel eine Anwendung Funktionen wie Bezahlung, Login und History beinhaltet und nur eine der Funktionen beginnt, mehr Rechenleistung zu beanspruchen, dann behindert das die Leistung der gesamten Anwendung.
4. Wer monolithische Applikationen skalieren will, der kann dies nur tun, indem er die gleichen EAR/JAR/WAR Pakete auf zusätzlichen Servern verteilt. Das bezeichnet man als horizontale Skalierung. Jede Kopie der Applikation auf zusätzlichen Servern nutzt die gleiche Zahl der darunterliegenden Ressourcen, was es zu einem ineffizienten Design macht.
5. Monolithische Architekturen beeinflussen die Entwicklung ebenso wie die Bereitstellung von Applikationen. Wenn sich Applikationen vergrößern, dann ist es umso wichtiger, Applikationen in kleinere Komponenten aufzubrechen. Da alles so eng zusammenhängt, können Entwickler bei monolithischen Architekturen nicht unabhängig voneinander arbeiten oder nur ihre eigenen Module bereitstellen. Vielmehr sind sie abhängig von anderen und das verlangsamt die Entwicklungszeit.

Mit diesen Nachteilen von Monolithen im Hinterkopf soll nun ein Blick auf die Microservices geworfen werden und wie diese für die Flexibilität sorgen, die monolithische Architekturen vermissen lassen.

Skalierbarkeit ist eine treibende Kraft hinter allen Architekturlösungen. Und hier liegt einer der größten Vorteile von Microservices: Statt eine Anwendung erst bereitstellen zu können, wenn alle Komponenten fertig sind, können Entwickler ihre Services unabhängig voneinander bereitstellen – und daher auch unabhängig voneinander arbeiten. Es bietet zudem größere Flexibilität für Änderungen und Neuauflagen von Modulen, da man sich dabei keine Sorgen um den Rest der Anwendung machen muss.

Die Vorteile von Microservices haben große Unternehmen wie Amazon, Netflix oder eBay überzeugt. Zu diesen gehören:

• Bessere Fehlerisolation: Größere Anwendungen bleiben weitestgehend unberührt von dem Versagen eines einzelnen Moduls.
• Es vermeidet einen Lock-in-Effekt: Microservices eröffnen die Möglichkeit, eine neue Technologie nur an einem ganz bestimmten Service oder einem Stapel an Services zu testen. Dabei muss man sich weniger Sorgen um Abhängigkeiten machen. Weniger Code bedeutet größere Flexibilität.
• Einfache Verständlichkeit: Durch eine zusätzliche Vereinfachung können Entwickler die Funktionalität von Services besser verstehen.
• Microservices werden am besten in Containern bereitgestellt in virtuelle Betriebsumgebungen, was die Skalierung erleichtert.

[/vc_column_text][/vc_column][/vc_row][vc_row fullwidth=”true” fullwidth_content=”false” el_class=”easy-post-layout”][vc_column][vc_custom_heading text=”Nachteile von Microservices” use_theme_fonts=”yes”][vc_column_text disable_pattern=”false” css=”.vc_custom_1576772646568{margin-bottom: 0px !important;}”]Neben allen Vorteilen gibt es auch Herausforderungen bzw. Nachteile von Microservices, die ebenfalls zu thematisieren sind. Traditionellen Monolith-Architekturen beruhen auf einer Drei-Schichten-Architektur aus Client, Anwendung und Datenbank. Microservices stellt dies komplett auf den Kopf, da die einzelnen Services aufgebrochen und separat bereitgestellt werden können. Die Vorteile davon sind groß, sie haben aber einen Preis und der liegt häufig in den Betriebskosten – Zeit und Geld. Folgende Probleme bestehen bei Microservices:[/vc_column_text][/vc_column][/vc_row][mk_page_section bg_image=”/wp-content/uploads/2020/02/cta-teaser_v4.jpg” bg_repeat=”no-repeat” bg_stretch=”true” speed_factor=”0″ video_opacity=”0.4″ min_height=”300″ padding_top=”30″ padding_bottom=”30″ margin_bottom=”40″ el_class=”content-overlay-image” sidebar=”yawp_wim”][vc_column][vc_custom_heading text=”Mit Microservices die Anforderungen in dynamischen Umgebungen bewältigen” font_container=”tag:h3|font_size:34|text_align:center|line_height:46px” google_fonts=”font_family:Open%20Sans%3A300%2C300italic%2Cregular%2Citalic%2C600%2C600italic%2C700%2C700italic%2C800%2C800italic|font_style:700%20bold%20regular%3A700%3Anormal” link=”url:%23form||target:%20_blank|”][vc_column_text disable_pattern=”false” align=”center” css=”.vc_custom_1550689259682{margin-bottom: 0px !important;}”][/vc_column_text][vc_btn title=”Jetzt Whitepaper herunterladen” color=”sky” align=”center” link=”url:%23form|title:Mehr%20jetzt%20mehr%20erfahren|target:%20_blank|”][/vc_column][/mk_page_section][vc_row fullwidth=”true” fullwidth_content=”false” el_class=”easy-post-layout”][vc_column][vc_custom_heading text=”1. Monitoring von Microservices” font_container=”tag:h3|text_align:left” use_theme_fonts=”yes”][vc_column_text disable_pattern=”false” css=”.vc_custom_1576772691846{margin-bottom: 0px !important;}”]Während es bei monolithischen Applikationen auch Probleme gibt, ist es dort recht einfach, eine schlechte Veröffentlichung wieder zurückzunehmen. In einer Container-basierten Applikation sind Dinge sehr viel komplizierter. Wer eine monolithische App in Microservices aufbricht oder ein ganz neues Microservice-System baut, hat sehr viel mehr Services zu überwachen. Zum Beispiel:

• Microservices nutzen verschiedene Technologien und/oder Sprachen.
• Sie sind auf verschiedenen Maschinen und/oder in unterschiedlichen Containern aktiv.
• Sie haben alle ihre eigene Versionskontrolle.

Dadurch wird das System sehr fragmentiert und es entsteht ein Bedürfnis nach zentralisierter Überwachung und Protokollierung.

Komponenten einer Container-Applikation können unabhängig voneinander erstellt und bereitgestellt werden. Geht also etwas nach der Bereitstellung kaputt, muss erst einmal identifiziert werden, welcher Service das Problem ist. Danach muss entschieden werden, wie die Version zurückgestellt werden kann.[/vc_column_text][/vc_column][/vc_row][vc_row fullwidth=”true” fullwidth_content=”false” el_class=”easy-post-layout”][vc_column][vc_custom_heading text=”2. Aufteilung der Protokollierung auf mehrere Services” font_container=”tag:h3|text_align:left” use_theme_fonts=”yes”][vc_column_text disable_pattern=”false” css=”.vc_custom_1576772723969{margin-bottom: 0px !important;}”]Wenn es um die Überwachung von Applikationen geht, steht eine Sache stets im Mittelpunkt: Logs oder Protokolle! Diese Gigabytes von unstrukturiertem Text werden tagtäglich von Servern generiert und sorgen oft für eine Datenbelastung auf Servern und Festplatten. Selbst bei kleinen monolithischen Architekturen, bereiten sie der IT oft Kopfschmerzen, denn oft enthalten sie keine wirklich brauchbaren Informationen. Selbst bei Monolithen durchdringt der Code verschiedene Ebene, so dass ein Protokoll über das gleiche Problem gleich an verschiedenen Plätzen wieder auftaucht.

Bei Microservices werden diese Protokolle noch stärker zersplittert. Eine einzige Nutzer-Transaktion kann gleich durch mehrere Services laufen, die alle über einen eigenen Protokollrahmen verfügen. Um einem Problem auf den Grund zu gehen, müssen die Protokolle von allen Services herangezogen werden, die eine Transaktion durchlaufen hat, um herausfinden zu können, was schief gelaufen ist.

Das zweite Problem ist also: In Microservices geht es darum, Dinge in einzelne Komponenten aufzubrechen. Als Nebeneffekt werden auch operative Prozeduren und deren Überwachung in einzelne Services aufgebrochen und so geht die Fähigkeit verloren, das gesamte System als Einheit zu überwachen. Die Herausforderung ist hier, das richtige Werkzeug für eine Re-Zentralisierung zu finden und zu nutzen.[/vc_column_text][/vc_column][/vc_row][vc_row fullwidth=”true” fullwidth_content=”false” el_class=”easy-post-layout”][vc_column][vc_custom_heading text=”3. Abhängigkeiten unter Services kann Probleme verlagern” font_container=”tag:h3|text_align:left” use_theme_fonts=”yes”][vc_column_text disable_pattern=”false” css=”.vc_custom_1576772764008{margin-bottom: 0px !important;}”]Ist eine Transaktion in einem spezifischen Service fehlgeschlagen, kann nicht davon ausgegangen werden, dass tatsächlich dieser Service der Ursprung des Problems ist. In Wirklichkeit gibt es drei Szenarien, die erklären können, was passiert ist:

 

1. Der Input ist schlecht, das heißt man muss verstehen, was dafür gesorgt hat, dass der vorangegangene Service fehlgeschlagen ist.
2. Der Output hat eine unerwartete Antwort vom darauf folgenden Service verursacht, das heißt man muss verstehen, wie der nächste Service sich verhält.
3. Das wahrscheinlichste Szenario aber ist, dass die Abhängigkeiten sehr viel komplexer sind als „A verursacht B“. Es ist wahrscheinlich, dass mehr als nur ein Service das Problem verursacht.

 

Bei Microservices ist es also zunächst notwendig herauszufinden, wo man überhaupt nach Antworten suchen kann und muss. Die Daten sind überall verteilt und sind nicht immer vom Dashboard oder den Protokollen aus zugänglich. Das dritte Problem bei Microservices ist also: Bei Monolithen weiß man fast immer, wo man mit der Suche nach Fehlern beginnen kann. Microservices machen es schwieriger herauszufinden, was die Ursache eines Problems ist und wie man an die entsprechenden Daten gelangt.[/vc_column_text][/vc_column][/vc_row][vc_row fullwidth=”true” fullwidth_content=”false” el_class=”easy-post-layout”][vc_column][vc_custom_heading text=”4. Die Ursache eines Problems finden” font_container=”tag:h3|text_align:left” use_theme_fonts=”yes”][vc_column_text disable_pattern=”false” css=”.vc_custom_1576772820753{margin-bottom: 0px !important;}”]Wer an dem Punkt ist, dass er weiß, welches die problematischen Services sind, alle Daten gezogen hat und Einblicke aus den Protokollen gesammelt hat und womöglich bereits über eine Lösung verfügt, die Auffälligkeiten im Verhalten von Anwendungen und deren Komponenten aufdeckt, wird weitere Daten sammeln – zum Beispiel über besonders lange Prozesszeiten. Aber dann bleibt noch immer die alles entscheidende Frage: Was ist die eigentliche, tieferliegende Ursache?

Es gilt dabei der Datenspur zu folgen und Hinweise zur Ursache zu erkennen. So kann es hilfreich sein, in einem bestimmten Service eine verstärkte Protokollierung durchzuführen und diesen neu aufzulegen, in der Hoffnung, dass durch einen besseren Kontext die eigentliche Ursache findet. Das beste Mittel ist allerdings, von Anfang an entsprechende Monitoringlösungen einzusetzen, um diesen Szenarien pro-aktiv zu begegnen und Probleme zu identifizieren, die Programmierer selbst vielleicht nicht berücksichtigt haben.

Das vierte Problem ist also: Die Ursache eines Fehlers verteilt sich über gleich mehrere Services. Das macht es notwendig ein zentralisiertes Werkzeug zu haben, das diese Probleme von der Wurzel her erkennt.

Zusammengefasst lässt sich festhalten: Wer neue Technologie wie Microservices annimmt, braucht starke Skills, um erfolgreich zu sein.[/vc_column_text][/vc_column][/vc_row][vc_row fullwidth=”true” fullwidth_content=”false” el_class=”easy-post-layout”][vc_column][vc_raw_html]JTVCZXJlY2h0c2hhcmUlMjBzZXJ2aWNlcyUzRCUyN2ZhY2Vib29rJTdDdHdpdHRlciU3Q3hpbmclN0NsaW5rZWRpbiU3Q3doYXRzYXBwJTI3JTIwaGVhZGxpbmUlM0QlMjdBcnRpa2VsJTIwamV0enQlMjB0ZWlsZW4lMjclNUQ=[/vc_raw_html][/vc_column][/vc_row][mk_page_section bg_image=”/wp-content/uploads/2020/02/cta-teaser_v5.jpg” bg_color=”#0aa1e2″ bg_position=”center top” bg_repeat=”no-repeat” padding_top=”50″ el_class=”cta-banner” sidebar=”yawp_wim”][vc_column][vc_empty_space height=”100px”][vc_custom_heading text=”Download Whitepaper: Mit Microservices die Anforderungen in dynamischen Umgebungen bewältigen” font_container=”tag:h2|text_align:center|color:%23ffffff” use_theme_fonts=”yes” css=”.vc_custom_1583743700416{margin-bottom: 30px !important;}” el_id=”form”][vc_row_inner is_fullwidth_content=”false” css=”.vc_custom_1580975361282{padding-right: 20% !important;padding-left: 20% !important;}”][vc_column_inner][vc_column_text css=”.vc_custom_1583743737250{margin-bottom: 30px !important;}”]Lernen Sie im Whitepaper mehr über die Vorteile, wie Sie mit EASY ApiOmat unternehmensweite Standards etablieren und die Entwicklung von Microservices und Anwendungen beschleunigen.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner is_fullwidth_content=”false” el_class=”standard-form white-form”][vc_column_inner][vc_raw_html]JTNDJTIxLS0lNUJpZiUyMGx0ZSUyMElFJTIwOCU1RCUzRSUyMCUzQ3NjcmlwdCUyMGNoYXJzZXQlM0QlMjJ1dGYtOCUyMiUyMHR5cGUlM0QlMjJ0ZXh0JTJGamF2YXNjcmlwdCUyMiUyMHNyYyUzRCUyMiUyRiUyRmpzLmhzZm9ybXMubmV0JTJGZm9ybXMlMkZ2Mi1sZWdhY3kuanMlMjIlM0UlM0MlMkZzY3JpcHQlM0UlMjAlM0MlMjElNUJlbmRpZiU1RC0tJTNFJTIwJTNDc2NyaXB0JTIwY2hhcnNldCUzRCUyMnV0Zi04JTIyJTIwdHlwZSUzRCUyMnRleHQlMkZqYXZhc2NyaXB0JTIyJTIwc3JjJTNEJTIyJTJGJTJGanMuaHNmb3Jtcy5uZXQlMkZmb3JtcyUyRnYyLmpzJTIyJTNFJTNDJTJGc2NyaXB0JTNFJTIwJTNDc2NyaXB0JTNFJTIwaGJzcHQuZm9ybXMuY3JlYXRlJTI4JTdCJTIwcG9ydGFsSWQlM0ElMjAlMjIzOTczNjM1JTIyJTJDJTIwZm9ybUlkJTNBJTIwJTIyYzNiMGQyOWItNjhmNC00Nzk2LTlkMGItYTEyNGFjYTQ3YzY3JTIyJTIwJTdEJTI5JTNCJTIwJTNDJTJGc2NyaXB0JTNF[/vc_raw_html][/vc_column_inner][/vc_row_inner][vc_row_inner is_fullwidth_content=”false” el_class=”standard-form white-form”][vc_column_inner][vc_raw_html]JTNDc3R5bGUlM0UlMEElMEEud2hpdGUtZm9ybSUyMGlucHV0JTVCdHlwZSUzRCUyMmVtYWlsJTIyJTVEJTJDJTIwLndoaXRlLWZvcm0lMjBpbnB1dCU1QnR5cGUlM0QlMjJwYXNzd29yZCUyMiU1RCUyQyUyMC53aGl0ZS1mb3JtJTIwaW5wdXQlNUJ0eXBlJTNEJTIyc2VhcmNoJTIyJTVEJTJDJTIwLndoaXRlLWZvcm0lMjBpbnB1dCU1QnR5cGUlM0QlMjJ0ZWwlMjIlNUQlMkMlMjAud2hpdGUtZm9ybSUyMGlucHV0JTVCdHlwZSUzRCUyMnRleHQlMjIlNUQlMkMlMjAud2hpdGUtZm9ybSUyMHRleHRhcmVhJTJDJTIwLm1hc3Rlci1ob2xkZXIlMjAud2hpdGUtZm9ybSUyMHNlbGVjdCUzQW5vdCUyOC5nZmllbGRfc2VsZWN0JTI5JTIwJTdCJTBBJTIwJTIwJTIwJTIwYmFja2dyb3VuZC1jb2xvciUzQSUyMCUyM2ZmZiUyMCUyMWltcG9ydGFudCUzQiUwQSUyMCUyMCUyMCUyMGJvcmRlciUzQSUyMG5vbmUlMjAlMjFpbXBvcnRhbnQlM0IlMEElN0QlMEElMEEud2hpdGUtZm9ybSUyMGxhYmVsJTIwc3BhbiUyMCU3QiUwQSUyMCUyMCUyMCUyMGNvbG9yJTNBJTIwJTIzZmZmJTNCJTBBJTdEJTBBJTBBLndoaXRlLWZvcm0lMjBpbnB1dC5ocy1idXR0b24ucHJpbWFyeSUyMCU3QiUwQSUyMCUyMCUyMCUyMGJhY2tncm91bmQtY29sb3IlM0ElMjAlMjNmZmYlMjAlMjFpbXBvcnRhbnQlM0IlMEElMjAlMjAlMjAlMjBib3JkZXIlM0ElMjBub25lJTIwJTIxaW1wb3J0YW50JTNCJTBBJTIwJTIwJTIwJTIwY29sb3IlM0ElMjAlMjMwYWExZTIlM0IlMEElN0QlMEElMEEud2hpdGUtZm9ybSUyMGlucHV0LmhzLWJ1dHRvbi5wcmltYXJ5JTNBaG92ZXIlMjAlN0IlMEElMjAlMjAlMjAlMjBiYWNrZ3JvdW5kLWNvbG9yJTNBJTIwcmdiYSUyODI1NSUyQyUyMDI1NSUyQyUyMDI1NSUyQyUyMDAuNiUyOSUzQiUwQSUyMCUyMCUyMCUyMGJvcmRlciUzQSUyMG5vbmUlMjAlMjFpbXBvcnRhbnQlM0IlMEElMjAlMjAlMjAlMjBjb2xvciUzQSUyMCUyMzBhYTFlMiUzQiUwQSU3RCUwQSUwQS53aGl0ZS1mb3JtJTIwLnN0YW5kYXJkLWZvcm0lMjBsZWdlbmQuaHMtZmllbGQtZGVzYyUyMCU3QiUwQSUyMCUyMCUyMCUyMGNvbG9yJTNBJTIwcmdiYSUyODI1NSUyQzI1NSUyQzI1NSUyQzAuNjUlMjklMjAlMjFpbXBvcnRhbnQlM0IlMEElN0QlMEElMEElNDBtZWRpYSUyMG9ubHklMjBzY3JlZW4lMjBhbmQlMjAlMjhtYXgtd2lkdGglM0ElMjAxNTUwcHglMjklMEElN0IlMEElMjAlMjAlMjAuY3RhLWJhbm5lciUyMC5iYWNrZ3JvdW5kLWxheWVyJTIwJTdCJTBBJTIwJTIwJTIwJTIwJTIwJTIwJTIwYmFja2dyb3VuZC1zaXplJTNBJTIwaW5oZXJpdCUzQiUwQSUyMCUyMCUyMCUyMCUyMCUyMCUyMGJhY2tncm91bmQtcG9zaXRpb24lM0ElMjB0b3AlMjBjZW50ZXIlMjAlMjFpbXBvcnRhbnQlM0IlMEElMjAlMjAlMjAlN0QlMEElN0QlMEElMEElMkYlMkElMjBoaWRlJTIwb3RoZXIlMjBlbGVtZW50cyUyMCUyQSUyRiUwQS5hdXRvci13cmFwcGVyJTJDJTIwLmluZm8tYWZ0ZXItYXVodG9yJTIwJTdCJTBBJTIwJTIwJTIwZGlzcGxheSUzQSUyMG5vbmUlMjAlMjFpbXBvcnRhbnQlM0IlMEElN0QlMEElMEElM0MlMkZzdHlsZSUzRQ==[/vc_raw_html][/vc_column_inner][/vc_row_inner][vc_empty_space height=”50px”][/vc_column][/mk_page_section]