Kleiner Leitfaden für die Wahl der Architektur Microservices, Monolith oder Serverless?

Anbieter zum Thema

OutSystems

Jedes Unternehmen steht irgendwann vor der Entscheidung, wie es seine serverseitige Architektur aufbaut. Aber für welche Anwendungsfälle qualifizieren sich die verschiedenen Ansätze und welche wesentlichen Vor- und Nachteile sind dabei zu beachten?

Die Softwarebranche erlebt grundlegende Veränderungen. Dank innovativer Entwicklungen sind das Schreiben von Code und die Bereitstellung der Lösungen einfacher geworden und eröffnen dadurch neue Möglichkeiten. Inwieweit stehen diese technischen Fortschritte auch im Dienst des unternehmerischen Erfolgs? Worauf sollten Unternehmen unbedingt achten, wenn sie sich für Microservices, Monolith oder eine serverlose Architektur entscheiden?

Microservices – Services als Baukasten

Der Ansatz baut auf einer Reihe von autonomen Komponenten auf, die durch APIs miteinander verbunden sind. Im Grunde wird ein komplexes System in mehrere, kleinere und unabhängige Teile zerlegt.

Dies trägt dazu bei, dass Doppelarbeit reduziert, die Kopplung zwischen Komponenten verringert und das System skalierbar und leichter verständlich wird. Eine solche Architektur wird im Prinzip für stabile und verifizierte Geschäftskonzepte mit viel Traffic empfohlen.

Vorteile

Einer der größten Vorteile von Microservices gegenüber Monolith und anderen Architekturen ist der sehr vereinfachte Entwicklungs-, Test- und Bereitstellungsprozess. Da jeder einzelne kleine Service unabhängig entwickelt, getestet und bereitgestellt werden kann, ist es möglich, entwickelte Produkte schneller freizugeben.

Hinzu kommt, dass sich auch Komponenten freigeben lassen, während andere noch in Bearbeitung sind. Des Weiteren verringern sich die üblichen Bereitstellungsrisiken, da die Entwickler sukzessive einzelne Teile und nicht gleich die gesamte Softwarelösung bereitstellen. Auf diese Weise können auch verschiedene Teams für eine kurze Bearbeitungszeit an verschiedenen Aufgaben arbeiten.

Nachteile

Obwohl Microservices jede Komponente vereinfachen, kann das Aufteilen der Software in kleinere Teile ein komplexer Prozess sein. Es sind mehr Artefakte zu verwalten und gleichzeitig muss die Automatisierung für Tests und Überwachung erhöht werden. Microservices benötigen viel Speicherplatz, um Container bereitzustellen und zu verwalten. Da jeder Dienst getrennt ist, können unterschiedliche Programmiersprachen zu Problemen führen.

Monolith – aus einem Guss

Bei einem monolithischen Software-Engineering ist alles auf einer einzigen Plattform miteinander verbunden und voneinander abhängig. Das heißt, die Anwendung wird über eine einzige Bereitstellung geliefert und es werden alle Funktionen in einer einzigen Umgebung verwaltet. Das große Plus: Ein Monolith benötigt nur minimale Ressourcen. Dieser Ansatz eignet sich am besten für Projekte mit geringem Potenzial an Traffic wie zum Beispiel ein firmeninternes System mit einer geringen Anzahl von Mitarbeitern.

Vorteile

Der größte Vorteil einer monolithischen Architektur liegt in der Entwicklungsgeschwindigkeit, denn ein solcher Ansatz kann vergleichsweise schneller realisiert werden als eine Microservices-Architektur. Durch die Verwendung von Softwareentwicklungs- und Engineering-Tools ist die Arbeit an allen Aufgaben als auch die Update-Bereitstellung in einem Verzeichnis wesentlich einfacher.

Auf diese Weise lassen sich Zeit und Ressourcen für die Bereitstellung und Aktualisierung der Software reduzieren. Eine Monolith-Software ermöglicht aufgrund ihres gemeinsamen Codes und Speichers eine schnellere Kommunikation zwischen den Komponenten.

Nachteile

Da es nur eine einzige Komponente gibt, ist es im Laufe der Zeit extrem problematisch, mehr Entwicklungen zu erstellen und zu ändern. Jedes Software-Update, auch kleinere, erfordert eine vollständige Neuimplementierung. Selbst wenn mehrere Teams daran arbeiten, kann dies zu einer geringeren Agilität und damit zu Verzögerungen für den gesamten Projektabschluss führen.

Serverlos – mit der Cloud

Eines mal vorweg: Nur weil es serverlos heißt, heißt das nicht, dass es de facto keinen Server im System gibt. Vielmehr handelt es sich hierbei um einen Ansatz, der Cloud-Dienste nutzt, um Dienste zu erstellen und auszuführen, ohne dass eine Infrastruktur-Verwaltung beim Anwender erforderlich ist.

Ein Cloud-Server übernimmt die Codeausführung der Software. Während der Bereitstellung müssen sich Entwickler also nicht um die Serverwartung und -bereitstellung kümmern. Eine solche Architektur reduziert den Bedarf an Softwareskalierung, Datenbank- und Speichersystemen und anderen zusätzlichen Ressourcen.

Es gibt zwei Hauptkonzepte für serverloses Software-Engineering. Der erste ist Function as a Service (FaaS), der es Entwicklern ermöglicht, Funktionsfragmente in die Cloud hochzuladen. Nach dem Hochladen können sie die Komponenten unabhängig voneinander ausführen. Das zweite Konzept lautet Backend as a Service (BaaS). Es ist ein Cloud-Computing-Modell, das Zugriff auf ausgelagerte Backend-Aspekte gewährt, während nur der Frontend-Dienst geschrieben und verwaltet wird.

Eine serverlos-Architektur empfiehlt sich eher für kleinere Unternehmen oder Startups, da sie meist schneller und kostengünstiger als eine alternative Architektur wachsen wollen, ohne sich mit zu viel Konfiguration herumschlagen zu müssen.

Vorteile

Da quasi keine Infrastruktur benötigt wird, ist die Bereitstellung sehr einfach und die Entwickler können sich auf den Code konzentrieren. Dies führt dazu, dass Software in kurzer Zeit hochgefahren werden kann.

Ohne Datenbanken und Server verwalten zu müssen, ist es dem Anwender möglich, qualitativ hochwertigen Code zu geringeren Kosten zu erstellen. Er muss sich im Grunde lediglich über CPU-Zyklen und den Arbeitsspeicher Gedanken machen. Gleichzeitig profitiert der User von einem hohen Maß an Skalierbarkeit. Zudem entfallen lästige Wartungsarbeiten.

Nachteile

Eine serverlose Architektur funktioniert am besten bei kurzen Echtzeitprozessen. Bei einem langfristigen Betrieb muss der Anwender möglicherweise zusätzliche FaaS-Funktionen einplanen. Die Migration von einem Dienstanbieter zu einem anderen ist ein weiteres Thema, das er berücksichtigen muss.

Noch wichtiger ist die Tatsache, dass die Möglichkeiten des Anwenders zur Anpassung der Back-End-Infrastruktur an das Angebot des Dienstanbieters begrenzt sind. Da der Anwender letztlich selbst über keinen Server verfügt, kann er auch seine „global conditions“ nicht speichern. Dieses Problem lässt sich umgehen, indem er eine In-Memory-Datenbank wie Redis oder Memcached zu seiner Infrastruktur hinzufügt, um die „global conditions“ zu speichern.

Fazit

Welche Architektur eignet sich nun am besten für welches Szenario? Die Antwort liegt immer in den speziellen Projektanforderungen und den verfügbaren Ressourcen des Anwenders. Die groben Faustregeln:

• Microservices eignen sich am besten für Anwendungen mit konstanter Last, die horizontal skaliert werden. Daher eignen sich Microservices auch hervorragend für größere Teams.

• Die monolithische Architektur qualifiziert sich ideal für Prototypen, Minimum Viable Products (MVP) und Start-ups in der Anfangsphase. Hier steht die Geschwindigkeit der Entwicklung im Vordergrund.

• Serverlose Architekturen kommen dagegen für Projekte mit sehr inkonsistenter Auslastung oder beim Hinzufügen einiger Back-End-Funktionen zu statischen Sites infrage.

(ID:47949348)