In diesem Blog werde ich den Entscheidungsprozess untersuchen, der der Wahl zwischen den drei wichtigsten Architekturmustern zugrunde liegt, die von modernen Softwareanwendungen verwendet werden:
- Monolith
- Microservices
- Serverless
Wir werden uns die Stärken und Schwächen jedes Ansatzes zur Softwareentwicklung ansehen und die strategischen Prioritäten, die jeder Ansatz am besten oder am schlechtesten erfüllt.
Vereinfacht gesagt, lautet die gängige Praxis:
- Eine monolithische Architektur ist oft die beste Option für eine relativ kleine oder einfache Anwendung mit einer vorhersehbaren Last, wie ein MVP (Minimum Viable Product) oder eine B2B-Website, die statische Inhalte bereitstellt.
- Die Microservices-Architektur eignet sich gut für größere, komplexere Cloud-gehostete Anwendungen.
- Die Serverless-Architektur ist ideal für kleine bis mittelgroße, in der Cloud gehostete Anwendungen mit unvorhersehbaren Auslastungen und/oder schnellen (ausfallsicheren) Experimenten.
Es gibt jedoch noch weitere Punkte, auf die wir eingehen werden, um Ihnen ein umfassenderes Bild der Abwägungen zu vermitteln, die Ihre Entscheidung zwischen einem monolithischen, einem Microservices- oder einem Serverless-Architekturmuster beeinflussen sollten.
Die Wahl der Architekturmuster richtet sich sowohl nach den technischen Anforderungen als auch nach den strategischen Prioritäten
Zu Beginn eines jeden Softwareentwicklungsprozesses müssen zwei grundlegende technische Entscheidungen getroffen werden:
- Der Tech-Stack, z.B. Programmiersprachen, Frameworks usw.
- Architektonischer Ansatz.
Obwohl sich diese beiden Entscheidungsgrundlagen gegenseitig beeinflussen, schließen sie sich nicht gegenseitig aus. Die Kernkomponenten eines gewählten Tech-Stacks, z. B. der MEAN/MERN/MEVN-Stack (Datenbank – MongoDB, serverseitiges Framework – Express.js, clientseitiges Framework – Angular/React/Vue, Javascript-Laufzeitumgebung – Node.js), können mit unterschiedlichen Architekturansätzen verwendet werden.
Die Wahl des architektonischen Musters, auf das der Tech-Stack angewendet wird, wird jedoch die Ergebnisse beeinflussen:
- Anforderungen an DevOps-Ingenieure und andere Infrastruktur- und Backend-Spezialisten.
- Skalierbarkeit.
- Verfügbarkeit.
- Leistung.
- Vorausgehende Entwicklungskosten.
- Laufende Entwicklungs- und Wartungskosten.
- Kosten für Hosting und Cloud Computing.
Wir werden einen genaueren Blick darauf werfen, wie sich die drei zentralen Architekturmuster Monolith, Microservices und Serverless darauf auswirken, um Ihnen bei der Entscheidung zu helfen, welches den strategischen Prioritäten eines bestimmten Anwendungsprojekts am besten entspricht.
Aber lassen Sie uns zunächst einen kurzen Schritt zurückgehen und definieren, was Softwarearchitektur ist und warum sie wichtig ist.
Was ist Softwarearchitektur?
Eine klare prägnante Definition von Softwarearchitektur ist:
„Die Softwarearchitektur legt fest, wie die Komponenten eines Softwaresystems organisiert/zusammengesetzt werden sollten, wie sie miteinander kommunizieren und welchen Einschränkungen das gesamte System unterliegt.”
Ausgehend von dieser Definition lässt sich die Softwarearchitektur in drei Hauptkomponenten unterteilen:
- Architekturmuster – wie die Komponenten eines Softwaresystems organisiert/zusammengesetzt werden sollten.
- Systeminteraktion – wie diese Komponenten miteineander kommunizieren.
- Qualitätsattibute – die Einschränkugen, denen das gesamte System unterworfen ist.
Architekturmuster
Die Granularität der Komponenten, aus denen ein Softwaresystem besteht, wird durch das Architekturmuster bestimmt. Ein monolithisches Architekturmuster bedeutet zum Beispiel, dass alle Funktionalitäten als eine einzige Einheit ausgeführt werden, während eine Microservices-Architektur aus mehreren kleinen Komponenten besteht.
Was die Größe der Komponenten angeht, sind sich Serverless- und Microservices-Architekturen sehr ähnlich. Der Unterschied liegt eher darin, wie und wann die Komponenten aktiviert werden. Es ist möglich, die Architekturen zu kombinieren und bestimmte Funktionen, die normalerweise nur gelegentlich angefordert werden (z. B. einen Authentifizierungsdienst), als Serverless zu erstellen.
System-Interaktion
Systeminteraktion bezieht sich auf die Schnittstellen, über die die Komponenten oder Dienste, aus denen eine Anwendung besteht, miteinander kommunizieren, z. B. REST-APIs. Non-Serverless-Microservices und Serverless unterscheiden sich hier aufgrund der Unterschiede in der Art und Weise, wie die Komponenten ausgeführt und mit der zugrunde liegenden Infrastruktur verbunden werden. In einer Microservices-Architektur stellt das Softwareentwicklungsteam die (in der Regel cloudbasierte) Infrastruktur bereit, auf der die Komponenten ausgeführt werden. Im Falle von Serverless wird dies von der Serverless-Plattform, z. B. AWS Lambda, übernommen. Kurz gesagt, es gibt Unterschiede zwischen der Bereitstellung und Verwaltung von Microservices und Serverless-Funktionen.
Qualitätsattribute
Die dritte Komponente eines architektonischen Ansatzes sind seine Qualitätsmerkmale, wie z. B. Skalierbarkeit, Problemlösungsfähigkeit, Entwicklungsgeschwindigkeit, erforderliche technische Fähigkeiten des Softwareentwicklungsteams, Anpassungsfähigkeit und Widerstandsfähigkeit etc.
Eine monolithische Architektur bietet beispielsweise Eigenschaften wie schnellere und kostengünstigere Entwicklung. Skalierbarkeit und Ausfallsicherheit gehören zu den bedeutendsten Qualitäten eines Microservices-Ansatzes. Potenziell niedrigere Cloud-Computing-Kosten und ein geringerer Bedarf an Infrastrukturspezialisten sind Eigenschaften, die mit Serverless in Verbindung gebracht werden, während hohe Verfügbarkeit und Bequemlichkeit bei der iterativen Entwicklung oft als Stärken von Microservices angeführt werden.
Monolithische vs Microservices vs Serverless-Architektur – Stärken, Schwächen und Use-Cases erklärt
Werfen wir einen genaueren Blick auf die jeweiligen Stärken, Schwächen und Anwendungsfälle der monolithischen vs Microservices vs Serverless-Ansätze für die Anwendungsarchitektur.
Monolithische Architektur – traditionell, aber noch lange nicht veraltet
Monolithische Architekturen mögen zwar nicht im Trend liegen, aber der traditionelle Ansatz zur Erstellung von Anwendungen, bei dem alle Funktionen in eine einzige Einheit verpackt werden, die Front- und Backend kombiniert, ist noch lange nicht überholt. Es gibt immer noch viele Anwendungsfälle für monolithische Anwendungen.
Diese WordPress-Website ist beispielsweise ein Beispiel für eine monolithische Architektur. Wir sind ein Software- und Webentwicklungsunternehmen, das sich auf Cloud-Architekturen spezialisiert hat, wobei wir mehrere Unternehmensanwendungen sowohl mit Microservices als auch mit Serverless entwickelt haben. Wir haben die internen Ressourcen, um unsere eigene B2B-Webanwendung nach einem anspruchsvolleren Architekturmuster zu entwickeln, haben uns aber dagegen entschieden.
Und warum? Es würde keinen Sinn machen, die Komplexität und die Ressourcen zu erhöhen, um diese Website nach einem Microservices- oder Serverless-Architekturmuster zu erstellen. Diese Anwendung dient der Bereitstellung von Inhalten, wie z. B. dem Blog, den Sie gerade lesen, und stellt unsere Dienstleistungen, Fallstudien und Stellenangebote vor und informiert Sie über uns als Arbeitgeber oder Dienstleistungsanbieter. Sie muss schnell sein, eine gute Verfügbarkeit aufweisen und statische Inhalte bereitstellen, die für jeden, der sie konsumieren möchte, frei verfügbar sind.
Das war’s. Daher ist eine monolithische Architektur die naheliegende Wahl. Alles andere wäre eine Überkomplizierung der Angelegenheit. Anwendungen, die auf einer monolithischen Architektur basieren, sind in der Regel schneller, einfacher und kostengünstiger zu erstellen, da sie nicht die Synchronisierung und Verbindung mehrerer beweglicher Komponenten erfordern.
Vorteile der monolithischen Architektur
Schneller, einfacher und billiger zu realisieren – in den meisten technischen Kontexten ist die beste Lösung auch die, die am einfachsten ist, um das gewünschte Ergebnis zuverlässig zu erreichen. Bei der Softwaretechnik ist das nicht anders, wobei monolithische Anwendungen schneller, einfacher und kostengünstiger zu erstellen sind als solche, die auf komplexeren Architekturen basieren. Wenn also eine monolithische Anwendung die gestellten Anforderungen auf eine Weise erfüllt, die ihre Erfolgschancen nicht beeinträchtigt, empfiehlt es sich, eine monolithische Architektur zu verwenden.
Bequeme Test- und Produktionsprozesse – Komfortable Test- und Produktionsprozesse – es ist viel einfacher, eine monolithische App zu testen als eine Microservices- oder Serverless-App. Sie können eine Anwendung auf dem Computer des Entwicklers oder in der Staging-Umgebung starten und prüfen sowie Änderungen mit einem Standard-Bereitstellungsprozess überprüfen, bevor Sie die Anwendung in Produktion geben.
Einfache Infrastruktur – monolithische Anwendungen verwenden einen einzigen Server für ihr Frontend, Backend und ihre Datenbank, was die Infrastrukturanforderungen vereinfacht. Ein Content Delivery Network wie Cloudflare kann hinzugefügt werden, um die Geschwindigkeit, Skalierbarkeit, Verfügbarkeit und Sicherheit von monolithischen Webanwendungen zu verbessern.
Sie müssen nur ein Repository pflegen und alle Funktionen in einem Ordner suchen und finden. Außerdem müssen Sie nur eine einzige Test- und Bereitstellungspipeline entwickeln und pflegen, was die Kosten erheblich senken kann, da es teuer sein kann mehrere Pipelines zu erstellen, anzupassen und so zu pflegen, dass die Konsistenz über alle Pipelines hinweg gewährleistet ist. Alle von der Anwendung verwendeten Daten können auch in einer einzigen Datenbank gespeichert und abgerufen werden.
Monitoring – eine einfache Infrastruktur bietet den zusätzlichen Vorteil einer leichteren Überprüfbarkeit.
Einfache Transaktionskontrolle und Datenintegrität – da monolithische Anwendungen in der Regel eine einzige Datenbank zur Speicherung verwenden, profitieren diese von einer einfachen Transaktionskontrolle und verschiedenen Mechanismen sowie der Datenintegrität, die eine relationale Datenbank (RDBMS) bietet.
Nachteile der monolithischen Architektur
Umfangreiche Code-Basis – monolithische Architektur bedeutet nur eine einzelnee Code-Basis. Wenn die Codebasis groß wird, kann sie für die Entwickler schwer zu lesen und zu verstehen sein, was die Integration neuer Entwickler in ein Projekt erschwert.
Updates können eine Herausforderung sein – eine monolithische Anwendung zu aktualisieren bedeutet, die gesamte Codebasis neu zu erstell und zu verteilen.
Hohe Abhängigkeiten – eine einzige Codebasis bedeutet, dass die Komponenten eng miteinander gekoppelt sind und Änderungen an der Logik eines Moduls oder Dienstes ein viel höheres Risiko bergen, den Code und die Funktionsweise anderer Module zu beeinträchtigen. Es ist schwer vorherzusagen, welche Auswirkungen selbst eine kleine Änderung an einer Stelle auf die gesamte Anwendung hat. Aktualisierungen erfordern ein erneutes Testen der gesamten Codebasis
Mangelnde Flexibilität – eine monolithische Architektur schränkt sowohl die Bandbreite der Technologien ein, die Sie nutzen können, als auch die Notwendigkeit, dass der Tech-Stack in der gesamten Anwendung konsistent sein muss. Sie haben nicht den Luxus, eine andere, vielleicht besser geeignete Technologie nur für einen oder einige wenige Dienste zu verwenden.
Skalierbarkeit – wenn Sie eine monolithische Anwendung entwickeln, die sich unerwartet großer Beliebtheit erfreut und daher in der Lage sein muss, viel größere und unvorhersehbare Lasten zu bewältigen sowie iteriert und erweitert zu werden, müssen Sie diese wahrscheinlich nachträglich entweder auf eine Microservices- oder Serverless-Architektur migrieren. Monolithische Anwendungen lassen sich nicht so gut skalieren.
Anwendungsfälle der monolithischen Architektur
Eine monolithische Architektur eignet sich in der Regel am besten für kleinere, einfachere Anwendugen, z.B. solche, die statische Inhalte bereitstellen. Eine B2B-Website wie diese ist das perfekte Beispiel. Ein anderes Beispiel wäre die schnelle, kosteneffiziente Entwicklung eines MVP oder einer Software, die für einfache Aufgaben konzipiert ist.
Microservice-Architektur – skalierbare Flexibilität
Mit dem Wachstum und der Weiterentwicklung der digitalen Wirtschaft und Technologie haben auch die Anwendungsgröße und -komplexität zugenommen. Wie bereits erwähnt, kann eine monolithische Architektur bei der Skalierung von Anwendungen ein Problem darstellen, da die Codebasis unhandlich und für neue oder sogar bestehende Teammitglieder schwer zu lesen und zu verstehen ist.
Außerdem werden Updates und Iterationen, bei denen neue Funktionen und Features freigegeben werden, aufgrund der Abhängigkeiten zwischen den Diensten und der Notwendigkeit, die gesamte Codebasis neu zu erstellen, zu testen und bereitzustellen, immer komplexer.
Bei einer Microservices-Architektur werden Anwendungen in Gruppen von Diensten aufgeteilt. Eine E-Commerce-Anwendung könnte zum Beispiel in die folgenden Microservices unterteilt werden
- Frontend-Benutzerschnittstelle.
- Suchfunktion, die es den Nutzern ermöglicht, mit Hilfe von Suchanfragen Produkte aus einer Datenbank aufzusuchen.
- Eine Funktion für relevante Artikel, die alternative oder ergänzende Produkte zu den vom Benutzer ausgewählten empfiehlt.
- Ein Merkzettel-Dienst.
- Ein Einkaufswagen-Dienst.
- Ein Checkout-Dienst, der den Zahlungsvorgang abwickelt.
Das Konzept der Microservices-Architektur ist alles andere als neu. Der Mikrokernel-Ansatz der 80er und 90er Jahre sowie die serviceorientierte Architektur (SOA), die sich in den 2000er Jahren durchsetze, zerlegten Anwendungen ebenfalls in Komponenten. Doch erst mit dem Aufkommen von Cloud-basierten Umgebungen und der Notwendigkeit, Anwendungen dezentral auf mehreren Servern auszuführen, hat sich der moderne Microservices-Ansatz etabliert.
Mit der zunehmenden Komplexität der Softwaresysteme wurde es auch immer wichtiger, das Risiko zu streuen, indem die Dienste so entkoppelt werden, dass der Ausfall eines Microservices nicht die gesamte Anwendung in Mitleidenschaft zieht.
Vorteile einer Microservices-Architektur
Iterative Entwicklung – eine auf Microservices basierende Softwarearchitektur passt gut zu modernen agilen Softwareentwicklungsprozessen, die auf iterativer Entwicklung basieren. Die Aufteilung einer bereits funktionierenden Anwendung in lose gekoppelte Dienste bedeutet, dass neue Merkmale und Funktionen bequemer bearbeitet und hinzugefügt werden können, ohne dass das Risiko einer Unterbrechung der Verfügbarkeit besteht. Außerdem können verschiedene Teams gleichzeitig an verschiedenen Diensten arbeiten, wodurch es einfacher wird, neue Teammitglieder einzuführen.
Flexibilität – Microservices führen auf mehreren Ebenen zu mehr Flexibilität im Softwareentwicklungsprozess. Wie bereits erwähnt, bedeutet der architektonische Ansatz zum einen, dass verschiedene Teams relativ unabhängig voneinander verschiedene Dienste entwickeln können. Zum anderen sind die kleineren Codebasen leichter zu lesen und zu verstehen, was die Einführung neuer Teammitglieder erleichtert.
Freie Tech-Stack Wahl – ein weiterer großer Vorteil von Microservices ist, dass der architektonische Ansatz eine große Freiheit bei der Wahl des Tech-Stacks bietet. In einer monolithischen Architektur, in der die Dienste eng miteinander gekoppelt sind, ist es wichtig, die Konsistenz der in einer Anwendung verwendeten Technologien zu wahren. Sie sollten auch in hohem Maße miteinander kompatibel sein, was nicht bei allen Programmiersprachen und Softwareentwicklungstools der Fall ist. Theoretisch kann das Entwicklungsteam einzelne Dienste mit sehr unterschiedlichen Technologie-Stacks erstellen.
In der Praxis ist es in der Regel immer noch sinnvoll, den Stack relativ konsistent zu halten, da es für ein Unternehmen nicht kosteneffizient ist, mehrere verschiedene Tech-Stacks in einer Anwendung zu verwenden.
Das bedeutet jedoch, dass, wenn ein bestimmter Dienst von einer Technologie, die nicht in der gesamten Anwendung verwendet wird, erheblich profitieren würde, diese verwendet werden kann, ohne mit dem Haupt-Tech-Stack zu kollidieren, wie es bei einer monolithischen Architektur der Fall wäre.
Verfügbarkeit – einer der größten Vorteile einer Microservices-Architektur ist, dass lose gekoppelte Dienste zu einer robusteren Anwendung und höherer Verfügbarkeit führen. Wenn ein Dienst ausfällt, sollte die lose Kopplung bedeuten, dass der Rest der Anwendungen davon nicht betroffen ist und für die Benutzer weiterhin funktioniert.
Skalierbarkeit – eine weitere Eigenschaft der lose gekoppelten Dienste einer Microservices-Architektur ist, dass sich der Ansatz gut für die Skalierung von Anwendungen eignet. Dank des modularen Charakters ist es einfach, an einer laufenden Anwendung zu arbeiten und sie um neue Funktionen zu erweitern. Obwohl die Anfangsinvestitionen in eine Microservices-Architektur höher sind, kann die Skalierung aufgrund einer Kombination der bereits erwähnten Stärken günstiger sein als bei einer monolithischen Anwendung.
Verbesserte Leistung – die Möglichkeit, Dienste und Belastungen auf mehrere Server zu verteilen, kann die Leistung verbessern.
Nachteile der Microservice-Architektur
Komplexität – ein dezentrales System wie Microservices führt unweigerlich zu zusätzlicher Komplexität, da mehrere bewegliche Teile so synchronisiert werden müssen, dass sie als einheitliches Softwaresystem funktionieren. Wenn die Dienste auf mehrere Server verteilt sind, müssen Sie diese vielschichtige Infrastruktur bereitstellen.
Komplexe Tests – kleinere Codebasen machen es zwar viel einfacher, einzelne Microservices zu testen, aber die Notwendigkeit, jeden Service einzeln zu testen, kann bei der Skalierung einer Anwendung zu erheblicher Komplexität führen. Die Notwendigkeit die Kommunikation zwischen den Diensten zu testen und aufrechtzuerhalten, erhöht die Komplexität zusätzlich
Höhere Vorlaufkosten – während der Versuch, eine monolithische Anwendung signifikant zu skalieren, ein Albtraum sein kann, bei dem sich sowohl die direkten Entwicklungs- als auch die Opportunitätskosten schnell summieren ist eine Microservices-Architektur mit höheren Vorlaufkosten verbunden.
Jeder Microservice erfordert eine eigene Gruppe von Entwicklern (auch wenn wahrscheinlich ein einziges Team für mehrere Microservices zuständig sein wird) sowie ein maßgeschneidertes Quellcode-Verwaltungssystem, einen Testprozess und Skripte, die die automatische Bereitstellung erleichtern. Das alles führt zu höheren Vorlaufkosten.
DevOps-Anforderungen – ein verteiltes System wie Microservices erfordert eine qualifizierte Orchestrierung, die in der Regel Kubernetes und andere DevOps-Tools und -Prozesse umfasst. Das bedeutet, dass Sie höchstwahrscheinlich mindestens einen DevOps Engineer einstellen oder unter Vertrag nehmen müssen. Das treibt die Kosten in die Höhe und angesichts der steigenden Nachfrage ist es schwierig, geeignete DevOps-Spezialisten zu finden.
Eine Microservices-Architektur kompensiert höhere Kosten und Komplexität durch größere Flexibilität und bessere Leistung.
Die Entscheidung für eine Microservices-Architektur anstelle einer traditionellen monolithischen Architektur ist, kurz gesagt, ein Kompromiss. Der Aufbau einer auf Microservices basierenden Anwendung erhöht zwar die Anfangskosten, bietet aber im Gegenzug eine größere betriebliche Unabhängigkeit und Flexibilität, was die Release-Zyklen beschleunigt.
Und für viele moderne Anwendungen und Unternehmen sind die Vorteile eines Microservices-Ansatzes eher eine Notwendigkeit als ein Luxus geworden.
Microservices-Architektur – Use-Cases
Eine Microservices-Architektur eignet sich in der Regel am besten für größere, komplexere Anwendungen, die auf Skalierbarkeit und agile Iteration ausgelegt sind, insbesondere wenn sie in der Cloud gehostet werden oder Cloud-nativ sind. Mehr über den Entscheidungsprozess zwischen Monolith und Microservices erfahren Sie in dieser Fallstudie darüber, wie und warum wir das unternehmensweite, mehrfach gemietete CMS des weltweit größten Veranstaltungsunternehmens migriert haben.
Serverless Architektur – die Weiterentwicklung von Cloud-Native
Die Serverless-Architektur ist eng mit Microservices verwandt, und die Wahl zwischen beiden ist keineswegs binär. In der Tat kombinieren viele moderne Anwendungen Serverless und Microservices. Wie Microservices sind auch die Konzepte, die Serverless zugrunde liegen, schon lange bekannt, haben sich aber seit dem Aufkommen des Cloud-Computing zu einem festen Bestandteil der Mainstream-Softwareentwicklung entwickelt.
Genauer gesagt hat sich Serverless seit der Einführung des Lambda Serverless-Frameworks von AWS im Jahr 2014 durchgesetzt. Alle großen Cloud-Anbieter bieten nun Serverless-Plattformen an, und Frameworks von Drittanbietern wie OpenFaaS und Kubeless bedeuten, dass Serverless auf Iaas- und On-Premise-Infrastrukturen erweitert werden kann.
Serverless vs Microservices: was ist der Unterschied?
In einem Satz: Der Unterschied zwischen Microservices und Serverless besteht darin, dass Microservices ein Weg ist, eine Anwendung zu entwerfen, während Serverless ein Weg ist, eine Anwendung ganz oder teilweise auszuführen. Das ist der Schlüssel für ihre Kompatibilität. Es ist möglich, einen Microservice zu programmieren und ihn als Serverless-Funktion auszuführen.
Aber lassen Sie uns einen Schritt zurückgehen. Die Serverless-Architektur besteht aus einer Reihe von Funktionen und nicht aus Services. Der Unterschied besteht darin, dass ein Service ständig verfügbar ist, während eine Funktion einen Lebenszyklus hat – sie wird ausgelöst, aufgerufen, ausgeführt, läuft und wird dann „beendet“, sobald sie ihre Aufgabe erfüllt hat. Serverless-Funktionen werden nur dann ausgeführt, wenn sie benötigt werden, wodurch erhebliche Ressourcen eingespart werden können.
Ein weiterer wesentlicher Unterschied zwischen Microservices und Serverless besteht darin, dass bei Serverless die Bereitstellung der Infrastruktur durch den Anbieter der Serverless-Plattform übernommen wird. Das Entwicklungsteam muss nicht das gesamte Softwaresystem konfigurieren. Die Funktionen werden auf die Serverless-Plattform hochgeladen, die Auslöser, die sie starten sollen, werden konfiguriert, und der Anbieter kümmert sich um den Rest.
Das bedeutet, dass sich das Entwicklungsteam nur auf die Codierung konzentrieren muss und sich nicht um die Infrastruktur kümmern muss. Alle übrigen DevOps-Aufgaben können in der Regel auf das Entwicklungsteam verteilt werden, ohne dass spezielle DevOps-Ingenieure benötigt werden.
Der Hauptunterschied zwischen Serverless und Microservices besteht darin, dass Microservices normalerweise für Teile einer Anwendung verwendet werden, die ständig laufen müssen, wie das Frontend einer Benutzeranwendung. Serverless eignet sich am besten für Funktionen, die nur gelegentlich und für eine begrenzte Zeit genutzt werden. Ein ideales Szenario für eine Serverless-Funktion wäre zum Beispiel das Hochladen eines Bildes in eine Anwendung durch einen Benutzer. Sie wird nur gelegentlich ausgeführt, ist aber ressourcenintensiv.
Serverless-Funktionen, die auf einer Serverless-Plattform gehostet werden, können auch anwendungsübergreifend genutzt werden. Wenn ein Unternehmen beispielsweise mehrere Anwendungen hat, die alle über Benutzerprofile verfügen, für die Profilbilder hochgeladen werden, könnte dieselbe Serverless-Funktion für alle diese Anwendungen verwendet werden.
Die Serverless-Architektur ist jedoch weniger flexibel als Microservices. Serverless-Anbieter unterstützen von Haus aus nur bestimmte Programmiersprachen, Frameworks und Tools, und obwohl es Workarounds gibt, können diese kompliziert und problematisch sein. Außerdem unterstützt jede verschiedene Serverless-Plattform unterschiedliche Technologien, was bedeutet, dass es nicht möglich ist, dieselbe Funktion mit verschiedenen Anbietern auszuführen, ohne sie in gewissem Maße neu zu konfigurieren.
Das Serverless-Tooling gilt im Allgemeinen auch als weniger ausgereift als bei Microservices. Beispielsweise sind die Tools zur Überwachung und Protokollkonfiguration bei Serverless begrenzt.
Während in einer reinen Serverless-Architektur ganze Anwendungen aus Serverless-Funktionen aufgebaut werden, ist es in den meisten Fällen am sinnvollsten, bestimmte Dienste als Serverless laufen zu lassen – solche, die nicht permanent genutzt werden und eine relativ kurze Laufzeit haben, insbesondere wenn diese Laufzeit ressourcenintensiv ist.
Die Zukunft der Serverless-Architektur ist höchstwahrscheinlich eine Technologie, die Microservices ergänzt und nicht ersetzt.
Vorteile von Serverless
Flexibilität – Die Aufteilung von Anwendungen in Serverless-Funktionen bietet ähnliche Vorteile für die Flexibilität wie Microservices.
Kosten für Cloud Computing – das Aufrufen und Beenden von Funktionen, so dass sie nur so lange wie nötig laufen, kann zu erheblichen Einsparungen bei den Gemeinkosten für Cloud Computing im Vergleich zur ständigen Verfügbarkeit führen.
Die Bereitstellung der Infrastruktur entfällt – der Serverless-Anbieter kümmert sich um die Bereitstellung der Cloud-Infrastruktur, auf der die Serverless-Funktionen ausgeführt werden. Das bedeutet, dass sich das Softwareentwicklungsteam um eine Sache weniger kümmern muss und sich auf die Programmierung der Anwendung selbst konzentrieren kann.
Skalierbarkeit – wie bei Microservices erleichtert die Modulbauweise von Serverless den Softwareentwicklungsteam die Skalierung von Anwendungen, da neue Funktionen unabhängig voneinander bearbeitet und dann schrittweise zur Live-App hinzugefügt werden können.
Zuverlässigkeit und Verfügbarkeit – wie bei Microservices bedeutet die Aufteilung einer Anwendung in lose gekoppelte Funktionen, dass die Abhängigkeit zwischen den Funktionen viel geringer ist als bei einer monolithischen Architektur. Wenn also eine Funktion ausfällt, sollte die App ansonsten weiter funktionieren. Der Anbieter kümmert sich um die zugrundeliegende Infrastruktur, was die Zahl der potenziellen Fehlerquellen weiter verringert.
Nachteile von Serverless
Komplexität – Einerseits reduziert der Serverless-Anbieter, der sich um die Cloud-Infrastruktur kümmert, die Komplexität der Serverless-Architektur. Die Aufteilung in unabhängige Funktionen bedeutet jedoch, dass sie immer noch aus mehreren kleineren, beweglichen Teilen besteht, was sie komplexer macht als ein monolithischer Ansatz.
Limitierungen beim Tech-Stack – Serverless-Plattformen unterstützen nur bestimmte Programmiersprachen, Frameworks und Tools, was bedeutet, dass Sie auf die Programmierung von Funktionen beschränkt sind, die von Ihrem Anbieter unterstützt werden.
Anbieterabhängigkeit – Anwendungen, die vollständig Serverless sind oder Serverless-Funktionen enthalten, sind relativ stark an die Plattform des Anbieters gebunden, für die sie entwickelt wurden, da keine zwei Plattformen exakt gleich und austauschbar sind. Es ist keineswegs unmöglich, Serverless-Funktionen für die Plattform eines anderen Anbieters neu zu konfigurieren, aber bei einer großen, komplexen Anwendung mit zahlreichen Funktionen wäre dies ein umfangreiches Vorhaben.
Unausgereiftes Tooling – im Vergleich zu traditionellen monolithischen und Microservices wird oft argumentiert, dass das verfügbare Tooling zur Unterstützung der Serverless-Entwicklung und Wartung unausgereift ist. Regelmäßig wird ein Mangel an guter Überwachung und Unterstützung für die Protokollkonfiguration hervorgehoben. Da die Serverless Architektur jedoch schnell an Zugkraft gewinnt, wird das Tooling mit der Zeit unweigerlich ausreifen.
Serverless Use-Cases
Es ist am sinnvollsten, Serverless Use Cases auf der Funktionsebene darzustellen, anstatt bestimmte Anwendungskategorien zu erwähnen. Zu den Services, die sich besonders für die Ausführung als Serverless-Funktionen eignen, gehören:
- Schnelle Dokumentenkonvertierung
- Frühzeitiges Seiten-Rendering
- Arbeiten mit externen Services
- Log-Analyse im laufenden Betrieb
- Automatisierte Backups und tägliche Aufgaben
- Verarbeitung hochgeladener S3-Objekte
- Backend-Reinigung
- Massenverarbeitung von Echtzeitdaten
Zusammenfassend lässt sich sagen, dass monolithische, Microservices und serverlose Dienste alle ihre idealen Anwendungsszenarien haben
Wie fast immer, wenn es um den Vergleich von mehreren alternativen Technologien und Ansätzen für die Softwareentwicklung geht, vor allem wenn es sich um etablierte und beliebte Ansätze handelt, gibt es keine einheitliche richtige Antwort: monolithisch vs Microservices vs Serverless.
Alle drei Ansätze haben ihre Stärken und Schwächen, und die Entscheidung für die eine oder andere Variante ist immer eine Abwägung. Außerdem sind, wie wir gesehen haben, Microservices und Serverless miteinander kompatibel. Es wäre sogar möglich, eine gesamte monolithische Anwendung als eine große Serverless-Funktion auf einer Serverless-Plattform auszuführen, wobei es schwer ist, sich einen konkreten Anwendungsfall für diesen Ansatz vorzustellen.
Die traditionelle monolithische Architektur wird weiterhin die effizienteste Lösung für relativ einfache Anwendungen wie Websites sein, die statische Inhalte bereitstellen. Für größere, komplexere, in der Cloud gehostete Anwendungen, bei denen Skalierbarkeit, Flexibilität und Verfügbarkeit im Vordergrund stehen, werden Microservices oder eine Kombination aus Microservices und Serverless eingesetzt.
