Apps, Software as a Service, Onlineshops und andere Software-Produkte sind heutzutage niemals fertig. Sie befinden sich, überspitzt formuliert, in einem dauerhaften Beta-Zustand, denn Programmierer und Programmiererinnen optimieren und erweitern sie fortlaufend. Dabei spielen agile Prozesse und flexible Microservices-Architekturen eine elementare Rolle.
Was sind Microservices?
Wird eine Anwendung mit einer Microservice-Architektur entwickelt, besteht sie aus zahlreichen Elementen – unter anderem aus den namensgebenden Microservices. Microservices sind Prozesse, die unabhängig voneinander laufen und über Schnittstellen (= API, Application Programming Interface) miteinander kommunizieren. Das ermöglicht eine modulare Softwareentwicklung.
Microservices: Beispiele aus der Praxis
Viele moderne Onlineshops basieren auf einer Microservice-Architektur. Dort werden beispielsweise Backend und Frontend voneinander getrennt. So können Entwickler und Entwicklerinnen die Verwaltung der Kundendaten und die Routinen für die Kaufabwicklung unabhängig von der Darstellung der Produktseiten betreuen und verbessern.
Auch Streaming-Anbieter wie Spotify und Netflix basieren auf einer Microservice-Architektur. Derart ist es den Unternehmen möglich, ihre Plattformen agil an die Wünsche der Kundschaft anzupassen, indem die Developer und Developerinnen an einzelnen Modulen und Services losgelöst vom „Kern“ programmieren.
Microservices vs. Monolith: Was unterscheidet die Architektur-Ansätze?
Entwickeln Sie eine Software, indem Sie alle relevanten Funktionen und Prozesse in einer Datei ablegen, erschaffen Sie Komponenten, die unflexibel miteinander verbunden sind. Die Weiterentwicklung und Verbesserung wird über die Zeit kompliziert und bei vielen Beteiligten auch komplex.
Eine Microservices-Architektur ist das Gegenteil von einem monolithischen System: Einzelne Elemente, die Services, können Sie jederzeit und frei verändern. Auch der Austausch von Services ist in der Regel recht schnell und einfach möglich.
Microservices vs. SOA: Wo liegen die Gemeinsamkeiten und Unterschiede?
Das Akronym SOA heißt ausgeschrieben Serviceorientierte Architektur (engl. service-oriented architecture). Eine Definition, was SOA exakt bedeutet, gibt es allerdings nicht. In der IT-Fachwelt steht es jedoch für ein Paradigma, für die Strukturierung von verteilten Systemen und Services. Diese Systeme sind unternehmensweit verteilt und über einen ESB (Enterprise Service Bus) verbunden.
Im Grunde ähneln sich die Serviceorientierte Architektur und eine Microservice-Architektur, da beide große Anwendungen in kleinere Komponenten zerlegen. Trotzdem gibt es ein paar Unterschiede: So kommunizieren die Elemente bei einer SOA über den ESB und Microservices über APIs. Und während bei einer Microservice-Architektur die Dienste unabhängig voneinander laufen können, sind sie bei SOA darauf ausgelegt, dass sie gemeinsam genutzt werden.
Was sind die Vorteile von Microservices?
Es liegt heutzutage im Trend, Anwendungen und andere Software-Lösungen auf einer Microservice-Architektur aufzubauen. Die Entwicklerinnen und Entwickler profitieren von diesen Vorteilen:
Flexibilität
Einzelne Komponenten lassen sich ganz flexibel und unabhängig von anderen entwickeln und optimieren. Somit muss es auch nicht immer einen großen Release geben, wenn etwas in einem Dienst verändert wurde.
Aufteilung
Die Entwicklung einzelner Bestandteile lassen sich auf verschiedene Personen oder Teams aufteilen. Jeder Programmierer und jede Programmiererin bzw. jedes Team kann die eigenen Ziele verfolgen und im persönlichen Rhythmus arbeiten. Derart entstehen agile Einheiten, die teilweise in sehr kurzen Zyklen neue Versionen ihrer Komponenten veröffentlichen.
Skalierung
Monolithische Software-Architekturen erreichen irgendwann eine Obergrenze, ab der die integrierten Anwendungen nicht mehr weiter wachsen können. Microservices sind dagegen flexibel skalierbar, beispielsweise über die Einbeziehung von Cloud-Diensten.
Freiheit
In einem System, das auf Microservices basiert, können die Komponenten sehr gut in verschiedenen Programmiersprachen und Technologien entwickelt werden. Damit ist es Ihnen möglich, Ihre Software stets „up to date“ zu halten.
Resilienz
Kommt es zu Fehlern oder Ausfällen, zum Beispiel durch Hacker-Angriffe, sind Microservice-Architekturen robuster als monolithische Strukturen. Einzelne Komponenten lassen sich zeitweise abschalten oder ersetzen. Auch das Bugfixing der Anwendungen fällt in der Regel einfacher aus, da Sie nur die betroffenen Dienste überprüfen und dort die Fehler beheben müssen.
Das sind die Nachteile von Microservices
Selbstverständlich ist der Aufbau einer Microservices-Architektur nicht perfekt. Diese Herausforderungen und Nachteile sollten Sie daher bedenken:
Betrieb
Verfolgen Sie den Microservice-Ansatz, haben Sie unter Umständen zahlreiche Dienste zu betreiben. Der Aufwand fällt somit höher als bei einem monolithischen System aus.
Technologien
Sie und Ihr Team müssen sich in verschiedene Technologien einarbeiten, um die unterschiedlichen Services realisieren, betreuen und updaten zu können.
Inkonsistenz
Werden Daten über verschiedene Dienste verteilt, können diese einen unterschiedlichen Stand haben. Dementsprechend müssen Sie Inkonsistenzen entgegenwirken.
Testing
Je mehr eine Microservice-Architektur wächst, desto schwieriger wird das Testen der einzelnen Komponenten und des gesamten Systems.
Monitoring
Das Überwachen einer Microservice-Struktur kann sehr aufwändig sein, da unterschiedliche Dienste und Technologien zum Einsatz kommen.
Wann machen Microservices Sinn?
Eine Microservice-Architektur ermöglicht es, neue Konzepte agil und schnell – beispielsweise über Methoden wie Scrum – auszuprobieren. Der sogenannte Time-to-Market (die Zeit bis zum Release) für eine erste Fassung verkürzt sich. Zudem spricht die modulare Webentwicklung und Betreuung für Microservices.
Was ist die perfekte Lösung?
Das lässt sich nicht pauschal sagen. Im E-Commerce und bei der SaaS-Entwicklung haben sich Microservice-Strukturen etabliert, besonders wenn eine Lösung über die Cloud skaliert werden soll.
Trotzdem kann es unter Umständen besser sein, wenn Ihr Team auf einen „klassischen“ Software-Monolithen setzt. Bei diesem müssen Sie zahlreiche Komponenten nicht ständig bedenken und überwachen. Vielmehr ist alles aus einem Guss und unter einer Haube. Das reduziert die Komplexität und auch die Fehleranfälligkeit, was besonders bei kleinen Applikationen ein starker Vorteil ist.
Titelbild: growtika / Unsplash