Was sind Microservices?
Als Microservice wird eine Anwendung (Software) bezeichnet, die einzelne Funktionalitäten als modulare und separat voneinander ausführbare Software-Bausteine einer beliebig großen Applikation oder eines umfangreicheren Services abbildet.
Im Wesentlichen zerlegen Microservices große Anwendungen in kleinere, voneinander unabhängige Anwendungen – sozusagen in „Mikro-Anwendungen“. Microservices unterteilen große Anwendungen auf Basis ihrer praktischen Anwendung bzw. Nutzung und nicht auf Basis technischer Funktionalitäten im Backend, die für den Anwender irrelevant sind.
Jeder Dienst ist somit nur für eine Aufgabe verantwortlich und funktioniert für sich als unabhängiges, geschlossenes System.
Wie funktioniert eine Microservice-Architektur?
Im Gegensatz zu einer monolithisch aufgebauten Applikation, deren Komponenten nicht voneinander trennbar sind, werden in Microservice-Architekturen die einzelnen Funktionalitäten in auch separat abrufbare, kleinste Service-Bausteine unterteilt. Als sog. Backend for Frontend Services können diese dann bedarfsabhängig über Schnittstellen (APIs) miteinander kommunizieren.
Der primäre Unterschied zwischen einer Microservice-Architektur und einer monolithischen Architektur einer Applikation besteht darin, dass die einzelnen Komponenten oder Microservice-Bausteine auch in verschiedenen Clustern gehalten, betrieben und gewartet werden können.
Warum werden Microservices benötigt – welches Problem wird gelöst?
Microservices sind die Antwort auf zahlreiche Probleme, die monolithische Architekturen mit sich bringen.
Wenn eine Anwendung auf einer monolithischen Architektur beruht, sind alle darin beinhalteten Funktionen und Dienste Teil einer einzigen großen Einheit. Entweder funktioniert die Anwendung oder sie funktioniert nicht. Es ist somit nicht möglich, einzelne Funktionen oder Dienste unabhängig voneinander zu nutzen. Bei Microservice-Architekturen sind alle Dienste und Funktionen modular und unabhängig voneinander nutzbar.
Um die Vorteile von Microservice-Architekturen zu verstehen, hilft ein kleiner Exkurs über die Funktionsweise einer monolithischen Architektur.
Exkurs: Eigenschaften einer monolithischen Architektur
- Alle Komponenten einer Anwendung sind Teil einer einzigen Einheit.
- Alles findet in dieser Einheit statt: Development, Deployment und Skalierung.
- Alles muss mit demselben Tech-Stack geschrieben werden.
- Teams müssen aufpassen, sich nicht gegenseitig in die Quere zu kommen.
- Für jede kleine Änderung muss die gesamte Anwendung inkl. aller Funktionen neu ausgerollt werden.
Sie sehen, eine monolithische Architektur bringt schon durch ihre Natur gewisse Einschränkungen und Herausforderungen mit sich.
Die Herausforderungen von monolithischen Architekturen im Detail
- Anwendungen sind groß und komplex.
- Einzelne Funktionen einer Anwendung sind stark voneinander abhängig.
- Anstatt einzelne Funktionen zu skalieren, muss eine gesamte Anwendung skaliert werden.
- Basieren einzelne Dienste auf unterschiedlichen Versionen einer Anwendung, kommt es zu Kompatibilitätsschwierigkeiten.
- Release-Prozesse benötigen mehr Zeit.
- Für jede Veränderung muss die gesamte Anwendung getestet werden.
All diese Nachteile lassen sich umgehen, indem Anwendungen in viele kleine Teile zerlegt werden: in die namensgebenden Microservices.
Vorteile von Microservices
- Einzelne Funktionen einer Anwendung können unabhängig voneinander entwickelt, bereitgestellt und skaliert werden.
- Anwendungen laufen stabiler, da ihre Funktionen nicht voneinander abhängig sind.
- Die Plan- und Wartbarkeit wird verbessert, da die Entwicklung und Bereitstellung einer Software-Lösung in kleine überschaubare Bestandteile zerlegt wird.
- Die logische und physikalische Unabhängigkeit einzelner Komponenten ermöglicht eine optimale Lastenverteilung, was für mehr Effizienz und eine bessere Skalierbarkeit sorgt.
- Da einzelne Funktionen unabhängig voneinander laufen, verstärkt sich automatisch die Ausfallsicherheit einer Anwendung.
- Eine Anwendung funktioniert auch, wenn einzelne Komponenten versagen, was sie automatisch beständiger gegen Angriffe macht.
Kommunikation zwischen Microservices
Jeder Dienst hat bei Microservices eine eigene API (Schnittstelle), was ein solides API-Management obligatorisch macht. Dienste können dabei auf drei verschiedene Arten miteinander kommunizieren.
1. API Calls
API Calls sind die einfachste Kommunikationsvariante. Dabei kommunizieren Dienste synchron miteinander, indem einzelne Anfragen direkt an den jeweils zuständigen API-Endpunkt gesendet werden.
2. Messagebroker
Bei dieser Methode kommunizieren Dienste asynchron über Nachrichtenbroker (engl. „Message Broker“) miteinander, d.h. über eine zwischengeschaltete Stelle, die alle Nachrichten an die zuständige API weitergibt. Dabei sendet beispielsweise ein Nutzer-Account (Publisher) eine Nachricht an den Messagebroker, der sie wiederum an den entsprechenden Dienst weitergibt und dann auf dessen Antwort wartet, um sie wieder an den Nutzer-Account weiterzuleiten.
3. Service Mesh
Diese Kommunikationsvariante findet insbesondere im Kubernetes-Bereich verstärkt Anwendung. Hierbei übernimmt ein sog. „Service Mesh“ die komplette Kommunikationslogik und fungiert als eine Art Hilfsdienst, der die Anfragen automatisch an die entsprechenden Dienste delegiert. Das hat den Vorteil, dass die Kommunikationslogik nicht in die jeweiligen Microservices programmiert werden muss, wie es bei der Kommunikation über Messagebroker.
Microservice-Architekturen bringen auch neue Herausforderungen
- Die Konfiguration der Kommunikation zwischen Microservices kann anspruchsvoll sein.
- Das Monitoring und Troubleshooting einzelner Dienste kann erschwert werden, da diese über mehrere Instanzen und Server verteilt sind.
- Die Einheitlichkeit der Daten ist schwerer zu gewährleisten, da Microservices oft auf unterschiedliche Server und Datenbanken zugreifen.
- Eine erhöhte Anzahl verschiedener Dienste erhöht auch die Anzahl potenzieller Angriffspunkte.
- Das Deployment und die Orchestrierung kann bei einer hohen Anzahl verschiedener Dienste komplex und anspruchsvoll werden.
Glücklicherweise werden kontinuierlich neue Tools entwickelt, um diesen Herausforderungen zu begegnen und sie zu meistern. Das bekannteste Tool hierbei ist Kubernetes, ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von Container-basierten Anwendungen. Auch können bestimmte Prozesse dabei helfen, die kontinuierliche Entwicklung von Microservices zu vereinfachen, wie z.B. eine CI/CD-Pipeline, die z.B. von Amazon und Google verwendet wird.
Wie werden Microservices entwickelt und bereitgestellt?
Da die einzelnen Komponenten einer Anwendung bei Microservices unabhängig voneinander entwickelt werden, ist die Code-Verwaltung im Repository im Gegensatz zu herkömmlichen Einzelanwendungen etwas anspruchsvoller. Microservices werden daher entweder mithilfe von Monorepo oder Polyrepo entwickelt, wobei beide Herangehensweisen ihre eigenen Vor- und Nachteile mit sich bringen.
Was sollten Sie beim Einsatz von Microservices noch beachten?
Bei Software-Lösungen in der IT ist es Entwicklern stets ein Anliegen, Applikationen kleinstmöglich und damit wartbar zu gestalten. Wächst eine Applikation durch Anfügen weiterer Funktionalitäten oder ist der Task, für den sie entwickelt wurde, etwas komplexer, kann es passieren, dass die Dokumentation oder sogar die Struktur der monolithischen Applikation unübersichtlich werden. Dies führt zu erhöhtem Aufwand bei der Implementierung oder späteren Anpassung dieser Art von Software-Lösungen bis hin zur Unwartbarkeit.
Ein weiteres Ziel von Entwicklern sowohl bei Microservice-Architekturen als auch bei klassischen Applikationen ist, die angeforderte Architektur so robust und ausfallsicher wie möglich zu konzipieren. Der Fokus liegt zwar auf der Ausfallsicherheit, aber auch die Vermeidung unnötiger Redundanzen ist aus Kosten- und Performance-Gründen oft ein Thema.
Hier kann in einem monolithischen System nur sehr begrenzt Abhilfe geschaffen werden, da eine solche Applikation immer als „Gesamtwerk“ funktioniert und somit Teilfunktionalitäten nicht nach ihren jeweiligen Eigenschaften (wie Priorität innerhalb des Systems) trenn- oder staffelbar sind. Fällt also z.B. das Cluster, der Server oder die Datenbank aus, auf dem ein Service angeboten wird, so muss eine monolithisch aufgebaute Applikation auf einem separaten System noch einmal abgebildet werden, um weiterhin angeboten werden zu können.
Mit Lobster verwalten Sie Ihre Microservices so einfach wie nie
Für die Abwicklung der Backend-for-frontend-Datenkommunikation ist die Datenintegrations-Software Lobster_data die Lösung der Wahl. Alle gängigen Schnittstellentypen (APIs) können aufgrund von No-Code-Technologie mit Lobster_data ohne Programmierkenntnisse auch von Nicht-Profi-Entwicklern (Citizen Developers) erstellt und ausgeliefert werden.
Das zweite No-Code-basierte Lobster Produkt zur Erstellung von Teillösungen für umfangreiche Funktionalitäten beispielsweise von Portalen zur Datenerfassung ist die Software für Prozessautomatisierung Lobster_pro.
Auch in Lobster_pro sind die angebotenen Möglichkeiten zur Datenbereitstellung, -eingabe und -aufwertung (ETL/ELT) oder -verarbeitung mittels Logiken durch Ereignisbehandlungen ohne Programmierkenntnisse erstellbar. Insbesondere durch den großen Spielraum bei der Wahl der Datenstruktur für Lobster_pro Portale, die im Gegensatz zu gewöhnlichen Formular-Oberflächen von der zugrundeliegenden Datenstruktur entkoppelt werden können, ergeben sich so für Unternehmen vielfältige Perspektiven für die Entwicklung performanter Microservices-Architekturen.
Sie möchten die Vorteile der Verwaltung Ihrer Microservices durch Lobster_data mit eigenen Augen sehen? Kontaktieren Sie unverbindlich unsere Spezialisten – wir beantworten gerne Ihre Fragen oder zeigen Ihnen in einer auf Ihren speziellen Anwendungsbereich zugestellten Demo die Vorzüge des API- und Microservice-Managements mit Lobster.
