Verteilte Entwicklung

Microservices vs. Serverless Computing

In der Softwareentwicklung verschafft der Einsatz von Microservices und Serverless Computing verschiedene Vorteile. Die beiden Architekturen haben aber auch ihre Nachteile. In welcher Situation welche Architektur geeignet ist, erklärt bbv-Experte Shpend Kelmendi.

10.06.2021Text: tnt-graphics0 Kommentare
Microservices Serverless

Softwareentwickler-Teams stehen vor der Herausforderung, die jeweils richtige Entscheidung für die Lösung eines Problems zu treffen. Bei der Architekturwahl zeigen sich sowohl Microservices als auch Serverless-Architekturen für viele Probleme als sehr vielversprechend. Beide Methoden sorgen für mehr Agilität und Produktivität. Doch wann eignet sich welche dieser beiden Architekturstile? Wo liegen die Unterschiede und ihre Vor- und Nachteile? Shpend Kelmendi, Cloud Community Leader und Senior Software Entwickler bei bbv, gibt einen Überblick und erklärt, warum im bbv Technica Radar zurzeit Serverless Computing im Trend liegt, während der Hype zu Microservices bereits wieder etwas nachlässt.

Microservices: Kampf gegen Monolithen

Mit Microservices hoffen viele Firmen, den Problemen einer monolithisch aufgebauten Software zu entkommen. «Der Monolith ist wegen seiner Grösse schwieriger zu deployen und zu skalieren. Das Risiko, beim Bereitstellen etwas zu brechen und das ganze System lahmzulegen, wird von vielen Entwicklern gefürchtet», sagt Shpend Kelmendi. Ein weiterer Grund für den Entscheid zu Microservices kann die Reduzierung von Komplexität sein: Während bei einem monolithischen Aufbau alle Funktionalitäten in einem grossen System vereint werden und somit das Risiko für unverständlichen, nicht wartbaren und erweiterbaren Code hoch sei, könne dieses Risiko mit Microservices verringert werden.

Diese und weitere Vorteile führen bei manchen Firmen dazu, Microservices einzusetzen. Doch ist das in jedem Fall der richtige Weg?

Möglichkeiten und Grenzen von Microservices

Microservices können bei der Lösung von Problemen betreffend Deployment und Skalierbarkeit helfen, doch sind damit neue Herausforderung verbunden. Beispielsweise sollte die Aufteilung in kleinere Dienste so vorgenommen werden, dass diese eine komplette Business-Komponente abbilden und somit unabhängig voneinander entwickelt werden können. In der Folge haben Änderungen, die in einem Service vorgenommen werden, keinen Einfluss auf andere Services.

Weiter muss bei der Aufteilung einzelner Dienste die Datenaufteilung mitberücksichtigt werden – und in diesem Zusammenhang auch die Konsistenz der Daten. Durch diese Trennung können sensitive Daten in einem Service gehalten und mit besonderen Sicherheitsmassnahmen geschützt werden, während für die restlichen Services eventuell weniger restriktive Sicherheitsmassnahmen ausreichen.

Grundsätzlich kann die Komplexität mittels Microservices reduziert werden. Doch es stellt sich die Frage, ob das Problem nur verschoben wird (zum Beispiel in die Service-Orchestrierung) oder ob die Komplexität mittels anderer Massnahmen einfacher reduziert werden könnte. Unter Umständen reicht die konsequente Anwendung von Architekturparadigmen wie Modularisierung oder Clean Architecture, um die Hauptvorteile von Microservices auch bei einem Deployment-Monolithen zu erreichen. Denn auch mit der Verwendung von Microservices müssen Themen wie asynchrone Verarbeitung, Latenz, Fehlertoleranz, Sicherheit oder Schnittstellenmanagement thematisiert werden.

Weitere Aspekte sind Koordination und Kommunikation: Die Entscheidung zur Microservice-Architektur kann die richtige sein, sobald mehrere Teams an einem Gesamtsystem arbeiten. Doch ist auch hier entscheidend, wie die Teams zusammengesetzt werden. Denn die Verwendung von Microservices setzt cross-funktionale Teams voraus, das heisst, alle notwendigen Kompetenzen sind im Team vereint, um möglichst autonom das Produkt entwickeln und betreiben zu können. Cross-funktionale Teams sorgen dafür, dass die Koordination und die Kommunikation zwischen den Teams minimiert werden kann. Ein weiterer Vorteil von Microservices ist die Tatsache, dass die autonomen Teams für die Entwicklung jeweils ihre bevorzugte Programmiersprache, Technologie und Persistenzstrategie einsetzen können.

Vielversprechend: Serverless Computing

Ist Serverless die bessere Alternative zu Microservices? Nicht unbedingt. Denn Serverless löst ein anderes Problem: Mit Microservices wird das Design des Services definiert, wohingegen Serverless ein Ausführungsmodell ist und den Betrieb des Services beschreibt. Serverless-Funktionen werden als Function-as-a-Service (kurz FaaS) beschrieben. In Kombination mit den anderen Diensten der Cloud-Anbieter (Platform-as-a-Service, kurz PaaS) können die Teams schnell Lösungen realisieren. Auf diese Weise können sich die Teams besser auf die Lösung des Business-Problems konzentrieren: Sie implementieren die Business-Logik, anstatt sich mit der Infrastruktur zu beschäftigen, welche vom Cloud-Anbieter verwaltet wird.

Die Ressourcen zur Ausführung der Business-Funktionalität werden in einer Serverless-Architektur nur bei Bedarf aufgesetzt, ausgeführt und nach Abschluss der Arbeit wieder aufgeräumt. Das heisst: Der Kunde bezahlt die Services nur, wenn sie gebraucht werden. Serverless-Funktionen eignen sich für schwankende, kurzzeitige Programme. Sie werden oft in Event-basierten Systemen eingesetzt und sind stets kurzlebig: Sie laufen maximal 5 bis 15 Minuten, oft nur im Sekundenbereich.

Die Grenzen von Serverless Computing

Wer einzelne Teile einer Software an den Cloud Provider übergibt, gibt auch bis zu einem gewissen Grad die Kontrolle über diese ab. So ist man beispielsweise von den Sicherheitsmassnahmen der Serverless-Anbieter abhängig. Zudem droht ein Vendor Lock-in und kann bei einem Wechsel zu einem anderen Cloud-Anbieter ein Neuschreiben oder Anpassen des Codes bedeuten. Um den Wechsel des Cloud-Anbieters nicht zusätzlich zu erschweren, kann der Einsatz von Containern Abhilfe schaffen. So könnte bei Bedarf die ganze Umgebung von einem Anbieter zum anderen transferiert werden. Doch stellt sich dabei die Frage, ob man auf die Cloud-Dienste mit ihren vielen Vorteilen verzichten will.

Wie schon bei Microservices stellt sich bei Serverless auch die Herausforderung von verteilten Systemen. Insbesondere das End-to-End-Monitoring von FaaS-Umgebungen ist sehr komplex.

Die Kostenfrage

Im Gegensatz zur Microservices-Architekturen, welches permanent zur Verfügung steht, wird bei Serverless für die eingesetzten Ressourcen nur gezahlt. Somit können Kosten gespart werden. Zudem bleibt die Anwendung nahezu beliebig skalierbar. Dies ist vor allem bei kurzfristig auftretenden Bedarfsspitzen ein grosser Vorteil. Mit Serverless entstehen Vorteile der Skalierbarkeit, doch müssen die umgebenden Systeme ebenfalls skalierbar sein, ansonsten kann ein Flaschenhals entstehen.

Welche Architektur ist nun die richtige?

Welche Methode eignet sich nun in welchen Situationen? Grundsätzlich kann man für die meisten Fälle beide Architekturen einsetzen. Die Frage, die es zu beantworten gilt, ist: Wird damit das Problem gelöst oder folgt man bloss einem Trend? Empfohlen wird daher, beispielsweise zuerst mit einem gut modulierten Monolithen zu beginnen, um die Software dann dort, wo es sich lohnt, in Microservices auszulagern.

Microservices eignen sich für:

  • Langfristig aktive, komplexe Anwendungen, die eine Business-Komponente abbilden (z. B. eine Bestellprozess im Onlineshop)
  • Anwendungen mit hohem, eher gleichmässigem Ressourcenbedarf
  • Entwicklungen ab einer bestimmen Teamgrösse bzw. Anzahl Teams, wobei die Teams nach Produkten und cross-funktional aufgestellt werden. Mit kleinen, fachlichen Teams können der Koordinationsaufwand und die Kommunikation minimiert werden.
  • eine einfachere Einhaltung von Datenschutzanforderungen durch Auslagerung in einen Microservice (etwa, indem nur sensible Personendaten auf Servern in der Schweiz gespeichert werden, während der Rest der Daten in EU-Rechenzentren liegt).
  • Komplexe Workflows
  • Batch-Processing

Serverless-Architekturen eignen sich für:

  • kurzzeitige Anwendungen mit unregelmässigen Bedarfsspitzen (z. B. eine Produktsuche im Onlineshop)
  • ereignisgesteuerte Anwendungen
  • Anwendungen mit Bedarf nach automatischer und hoher Skalierung (Scaling to zero), um die Dienste bei Bedarf schnell von Null aufs Maximum und umgekehrt nutzbar zu machen.
  • Prototyping und Proof of Concepts, da der Fokus auf Fachlichkeiten gelegt werden kann, anstatt sich mit grossen Infrastrukturhürden herumzuschlagen. Kurzfristige Bereitstellung von Services.
  • Stateless (keine eigene Datenhaltung)

Der Experte

Shpend Kelmendi

Shpend Kelmendi ist Software Engineer bei bbv mit Schwerpunkt im Cloud- und Web-Bereich und Cloud-Community-Lead. In dieser Funktion setzt er vor allem auf offene Kommunikation, Teamarbeit sowie auf die Entwicklung einfacher, qualitativ nachhaltiger und kundenorientierter Lösungen.

Unser Wissen im Abo

Microfrontends: Microservices weitergedacht

Wie Webentwickler Komplexität reduzieren

Microservices
KEDA – Kubernetes Event-driven Autoscaling

Ein Level-Up für die Skalierung in Kubernetes

App-Entwicklung
Microservices und verteilte Systeme

An API-Gateways führt kein Weg vorbei

Cloud Computing

Artikel kommentieren

Beachtung!

Entschuldigung, bisher haben wir nur Inhalte in English für diesen Abschnitt.

Achtung!

Entschuldigung, bisher haben wir für diesen Abschnitt nur deutschsprachige Inhalte.

Beachtung!

Entschuldigung, bisher haben wir nur Inhalte in English für diesen Abschnitt.

Achtung!

Entschuldigung, bisher haben wir für diesen Abschnitt nur deutschsprachige Inhalte.