Microservices und monolithische Architektur im Vergleich

Unternehmen können abhängig von einer Reihe verschiedener Faktoren von einer monolithischen Architektur oder einer Microservice-Architektur profitieren. Eine monolithische Architektur zeichnet sich vor allem durch eine schnelle Entwicklungszeit aus, weil die Anwendung mit einer Codebasis erstellt wurde und dadurch simpel ist.

Zu den Vorteilen einer monolithischen Architektur gehören:

Einfaches Deployment – Eine ausführbare Datei oder ein Verzeichnis erleichtern das Deployment.

Entwicklung – Wenn eine Anwendung mit einer Codebasis erstellt wird, ist ihre Entwicklung einfacher.

Leistung – In einer zentralisierten Codebasis und einem Repository kann eine API häufig dieselbe Funktion übernehmen, die zahlreiche APIs mit Microservices ausführen.

Vereinfachtes Testen – Da es sich bei einer monolithischen Anwendung um eine einzige, zentralisierte Einheit handelt, können End-to-End-Tests schneller durchgeführt werden als mit einer verteilten Anwendung.

Einfaches Debugging – Da sich der gesamte Code an einem Ort befindet, kannst du einfacher Anfragen verfolgen und Probleme finden.

Wie sich bei Netflix zeigte, können monolithische Anwendungen ziemlich effektiv sein, bis sie zu groß werden und die Skalierung zur Herausforderung machen. Wenn du eine kleine Änderung in einer einzigen Funktion vornehmen möchtest, muss die gesamte Plattform kompiliert und getestet werden. Und das widerspricht dem agilen Ansatz, den Entwickler heutzutage bevorzugen.

Zu den Nachteilen einer monolithischen Architektur gehören:

Langsamere Entwicklungsgeschwindigkeit – Eine große, monolithische Anwendung macht die Entwicklung komplexer und langsamer.

Skalierbarkeit – Einzelne Komponenten können nicht skaliert werden.

Zuverlässigkeit – Wenn in einem Modul ein Fehler vorliegt, kann dieser die Verfügbarkeit der gesamten Anwendung beeinträchtigen.

Hindernis für die Einführung von Technologie – Alle Änderungen im Framework oder an der Sprache wirken sich auf die gesamte Anwendung aus, was Änderungen häufig kostspielig und zeitaufwendig macht.

Mangelnde Flexibilität – Eine monolithische Architektur wird durch die bereits darin verwendeten Technologien eingeschränkt.

Deployment – Eine geringfügige Änderung an einer monolithischen Anwendung erfordert, dass sie komplett neu bereitgestellt wird.

Eine Microservice-Architektur, die auch einfach als Microservices bezeichnet wird, ist eine Struktur, die auf einer Reihe von unabhängig bereitstellbaren Services beruht. Diese Services verfügen über ihre eigene Geschäftslogik und Datenbank mit einem bestimmten Ziel. Aktualisierungen, Tests, Deployments und Skalierungen erfolgen in jedem einzelnen Service. Microservices unterteilen wichtige bereichsspezifische Anliegen in separate unabhängige Codebasen. Microservices verringern nicht die Komplexität, machen diese aber sichtbar und besser handhabbar. Hierzu werden Aufgaben in kleinere Prozesse unterteilt, die unabhängig voneinander funktionieren und zur Gesamtfunktion beitragen.

Die Einführung von Microservices geht oft mit DevOps einher, schließlich bilden sie die Grundlage für Continuous-Delivery-Praktiken, die Teams eine schnelle Anpassung an Benutzeranforderungen ermöglichen.

Wir bei Atlassian schickten uns im Jahr 2018 an, auf Microservices umzusteigen, nachdem wir Schwierigkeiten mit dem Wachstum und der Skalierung von Jira und Confluence hatten. Wir stellten fest, dass unsere monolithischen Einzelmandanten-Architekturen, die lokal ausgeführt wurden, nicht mit zukünftigen Skalierungsanforderungen mithalten können.

Wir beschlossen daher, die Architektur von Jira und Confluence neu zu gestalten und von einem zustandsbehafteten, monolithischen Einzelmandanten-System auf mehrmandantenfähige, zustandslose Cloud-Anwendungen von Amazon Web Services (AWS) umzustellen. Diese würden wir dann im Laufe der Zeit in Microservices zerlegen. Wir nannten das Projekt "Vertigo", nach einem erfahrenen Ingenieur, der sagte: "Mir gefällt die Idee ziemlich gut, auch wenn mir davon schwindlig wird." Bis dato war dies unser größtes Infrastrukturprojekt und es sollte zwei Jahre dauern, bis die Umstellung auf AWS abgeschlossen war. Dabei wurden in etwas mehr als zehn Monaten über 100.000 Kunden ohne Serviceunterbrechungen migriert. Außerdem haben wir uns vorgenommen, die Services in Microservices zu zerlegen.

Microservices sind keineswegs eine Wunderwaffe, sie beheben jedoch diverse Probleme von wachsenden Softwarelösungen und Unternehmen. Da eine Microservice-Architektur aus Einheiten besteht, die unabhängig voneinander ausgeführt werden, kann jeder Service entwickelt, aktualisiert, bereitgestellt und skaliert werden, ohne andere Services zu beeinträchtigen. Softwareupdates können häufiger durchgeführt werden, um eine verbesserte Zuverlässigkeit, Verfügbarkeit und Leistung zu erzielen. Früher haben wir einmal pro Woche Updates durchgeführt, mittlerweile sind wir bei zwei bis drei Updates pro Tag.

Während Atlassian weiter wächst, können wir mit Microservices Teams und geografische Standorte zuverlässiger skalieren, indem wir Zuständigkeiten nach Serviceinhabern aufteilen. Vor dem Vertigo-Projekt hatte Atlassian fünf verschiedene Entwicklungszentren auf der ganzen Welt. Diese verteilten Teams waren aufgrund einer zentralisierten monolithischen Struktur eingeschränkt, deshalb mussten wir einen Weg finden, sie autonom zu unterstützen. Mit Microservices war das möglich.

Zu den Vorteilen von Vertigo gehören eine höhere Deployment-Geschwindigkeit, Disaster Recovery, geringere Kosten und eine höhere Leistung. Dank ihnen erreichen wir unser Ziel schneller und können Kunden gleichzeitig einen besseren Mehrwert bieten.

Insgesamt machen Microservices es Teams auch einfacher, Code zu aktualisieren und Release-Zyklen durch Continuous Integration und Continuous Delivery (CI/CD) zu beschleunigen. Teams können mit Code experimentieren und Änderungen rückgängig machen, falls etwas schiefgeht.

Die Vorteile von Microservices sind kurz zusammengefasst folgende:

Agilität – Du kannst agile Arbeitsweisen mit kleinen Teams fördern, die häufige Deployments vornehmen.

Flexible Skalierung – Wenn ein Microservice seine Ladekapazität erreicht, können neue Instanzen dieses Service schnell im zugehörigen Cluster bereitgestellt werden, um Abhilfe zu schaffen. Wir haben jetzt eine mehrmandatenfähige und zustandslose Architektur, bei der Kunden auf mehrere Instanzen verteilt sind. Dadurch können wir viel größere Instanzen unterstützen.

Continuous Deployment – Wir haben jetzt häufige und schnellere Release-Zyklen. Früher wurden Updates einmal pro Woche durchgeführt, mittlerweile sind wir bei zwei bis drei Updates pro Tag.

Sehr gute Wartbarkeit und Testfähigkeit – Teams können mit neuen Funktionen experimentieren und Änderungen rückgängig machen, wenn etwas nicht funktioniert. Auf diese Weise kann Code einfacher aktualisiert und die Einführung von neuen Funktionen beschleunigt werden. Außerdem lassen sich Fehler und Bugs in einzelnen Services einfach isolieren und beheben.

Unabhängig voneinander einsetzbar – Da Microservices einzelne Einheiten sind, ermöglichen sie ein schnelles und einfaches unabhängiges Deployment einzelner Funktionen.

Flexible Technologie – Microservice-Architekturen geben Teams die Möglichkeit, ihre bevorzugten Tools auszuwählen.

Hohe Zuverlässigkeit – Du kannst Änderungen für einen bestimmten Service bereitstellen, ohne zu riskieren, dass die gesamte Anwendung zum Erliegen kommt.

Zufriedenere Teams – Atlassian-Teams, die mit Microservices arbeiten, sind viel zufriedener, weil sie selbstständiger arbeiten und Funktionen selbst entwickeln und bereitstellen können, ohne wochenlang auf die Genehmigung einer Pull-Anfrage warten zu müssen.

Als wir von einer kleinen Anzahl monolithischer Codebasen auf noch mehr verteilte Systeme und Services umstellten, die unsere Produkte unterstützen, verkomplizierte sich die Arbeit unerwartet. Wir hatten am Anfang Schwierigkeiten, neue Funktionen mit derselben Geschwindigkeit und Souveränität hinzuzufügen, wie wir das bisher getan hatten. Microservices können die Komplexität erhöhen, was zu einer unkontrollierten Entwicklung oder zu einem schnellen und nicht regulierten Wachstum führt. Da kann es schwierig werden herauszufinden, welchen Bezug verschiedene Komponenten zueinander haben, wer für eine bestimmte Softwarekomponente zuständig ist oder wie verhindert werden kann, dass abhängige Komponenten beeinträchtigt werden.

Mit Vertigo haben wir eine gängige Funktion entwickelt, die unsere bestehenden sowie zukünftige Produkte unterstützt, die wir erwerben und erstellen. Wenn dein Unternehmen ein einziges Produkt herstellt, wirst du wahrscheinlich keine Microservices brauchen.

Zu den Nachteilen von Microservices zählen unter anderem folgende:

Unkontrollierte Entwicklung – Microservices erhöhen im Vergleich zu einer monolithischen Architektur die Komplexität, da es an mehreren Orten mehr Services gibt, die von mehreren Teams erstellt wurden. Wenn die unkontrollierte Entwicklung nicht ordnungsgemäß eingedämmt wird, führt dies zu einer langsameren Entwicklungsgeschwindigkeit und einer schlechten Betriebsleistung.

Exponentielle Infrastrukturkosten – Für jeden neuen Microservice können eigene Kosten für Testsuite, Deployment-Playbooks, Hosting-Infrastruktur, Überwachungstools und mehr anfallen.

Zusätzlicher organisatorischer Aufwand – Teams müssen eine weitere Ebene für Kommunikation und Zusammenarbeit eröffnen, um Updates und Schnittstellen zu koordinieren.

Debugging-Herausforderungen – Jeder Microservice verfügt über eigene Protokolle, was das Debugging zum Problem macht. Darüber hinaus kann ein einzelner Geschäftsprozess auf mehreren Computern ausgeführt werden, wodurch das Debugging noch komplizierter wird.

Mangelnde Standardisierung – Ohne eine gemeinsame Plattform kann es zu einer unkontrollierten Zunahme von Sprachen, Protokollierungsstandards und Überwachungsvorgängen kommen.

Keine klaren Zuständigkeiten – Mit der Anzahl der eingeführten Services steigt auch die Zahl der Teams, die diese Services ausführen. Im Laufe der Zeit wird es schwierig festzustellen, welche Services ein Team nutzen und wer bei Supportanfragen kontaktiert werden kann.

Viele Projekte haben eine monolithische Architektur als Ausgangspunkt und entwickeln sich dann zu einer Microservice-Architektur. Wenn einer monolithischen Struktur neue Funktionen hinzugefügt werden, kann es umständlich werden, wenn mehrere Entwickler an einer einzigartigen Codebasis arbeiten. Codekonflikte werden immer häufiger und das Risiko steigt, dass Updates einer Funktion Bugs bei einer nicht verwandten Funktion verursachen. Wenn diese unerwünschten Muster auftreten, ist es möglicherweise an der Zeit, über eine Migration zu Microservices nachzudenken.

Nachstehend führen wir einige Best Practices auf, die sich bei unserer Migration als nützlich erwiesen haben:

Im Januar 2016 hatten wir insgesamt etwa 15 Microservices. Mittlerweile sind es über 1.300. Wir haben 100.000 Kunden in die Cloud verlagert, dabei eine neue Plattform erstellt, unsere Unternehmenskultur verändert und am Ende neue Tools erhalten. Wir haben zufriedenere, unabhängigere Teams und unsere DevOps-Kultur hat sich verbessert.

Microservices sind nicht unbedingt für jeden geeignet. Eine veraltete monolithische Architektur kann noch einwandfrei funktionieren, sodass es sich nicht lohnt, diese zu zerlegen. Aber wenn Unternehmen wachsen und die Anforderungen an ihre Anwendungen steigen, kann sich die Microservice-Architektur bezahlt machen.

Da der Trend in vielen Unternehmen zu Microservices mit verteilten Architekturen geht, hat Atlassian Compass entwickelt, um Unternehmen bei der Handhabung komplexer verteilter Architekturen während der Skalierung zu unterstützen. Die Lösung ist eine erweiterbare Developer-Experience-Plattform, die unzusammenhängende Informationen über die gesamten Entwicklungsergebnisse und die Teamzusammenarbeit an einem zentralen, durchsuchbaren Ort zusammenführt.