Monolith vs. Microservices: Welches ist die beste Option für Sie?

Definieren wir zunächst, was wir unter „Monolith“ und „Microservice“ verstehen. Eine monolithische Architektur wird als ein großes System aufgebaut und besteht normalerweise aus einer Codebasis. Ein Monolith wird oft auf einmal bereitgestellt, sowohl Front- als auch Endcode zusammen, unabhängig davon, was geändert wurde. Bei einer Microservices-Architektur wird eine App jedoch als Suite kleiner Dienste erstellt, von denen jeder über eine eigene Codebasis verfügt. Diese Dienste basieren auf spezifischen Funktionen und sind in der Regel unabhängig voneinander einsetzbar.

Konventionelle Weisheit predigt, mit einem Monolithen zu beginnen. Diese Versuchung ist besonders groß, wenn man mit einem schlanken Team und engen Fristen beginnt. Aber ist die konventionelle Weisheit immer richtig? Mein guter Freund Darby Frey hat kürzlich ein Greenfield-Projekt gestartet, nachdem er seine neue Rolle als Sr. Platform Engineering Lead von übernommen hatte Farbskala. Obwohl er bei seinem vorherigen Unternehmen mit Monolith angefangen hat Bauchentdeckte er, dass es (unter den richtigen Umständen) nicht immer der beste Weg ist, mit einem Monolithen zu beginnen.

Bei Belly haben Darby und sein Team ihren Monolithen in eine ziemlich große Microservices-Architektur zerlegt. Sie haben es geschafft, es an einen guten Ort zu bringen, aber erst nach Monaten voller Irrungen und Wirrungen bei der Migration zu Microservices. Mit dieser Erfahrung im Kopf ging er sein neues Projekt bei Gamut etwas vorsichtiger gegenüber Microservices an:

„Ich war ein festes Mitglied des Team Monolith. [I thought] Lasst uns eine einzige Anwendung erstellen und die Dinge später einfach wieder auseinandernehmen, wenn wir anfangen, Schmerzen zu verspüren“, sagte er. Obwohl es sich um ein Greenfield-Projekt handelte, war Darbys Team klein und er hatte strenge Zeitvorgaben, sodass oberflächlich betrachtet ein Monolith die offensichtliche Wahl zu sein schien. „[But with this new project]„Ich wollte die Fehler der Vergangenheit nicht wiederholen.“

Und damit stand er vor einer Entscheidung, mit der wir alle zu kämpfen haben: Sollen wir mit einem Monolithen oder Microservices beginnen und wie entscheiden wir uns?

Die Entscheidungen verstehen

Um zwischen den beiden zu entscheiden, sollten wir zunächst genau festlegen, was wir unter „Monolith“ und „Microservice“ verstehen.

Zachary Crockett, CTO bei Partikel sagte mir, dass „Systemarchitekturen in einem Spektrum liegen … Wenn man über Microservices spricht, konzentrieren sich die Leute meist auf ein Ende dieses Spektrums: viele kleine Anwendungen, die sich gegenseitig zu viele Nachrichten übermitteln.“ Am anderen Ende des Spektrums steht ein riesiger Monolith, der zu viele Dinge tut. Für jedes reale System gibt es viele mögliche serviceorientierte Architekturen zwischen diesen beiden Extremen.“

Den Monolithen definieren

Eine monolithische Anwendung wird als einzelne, einheitliche Einheit erstellt. Häufig besteht ein Monolith aus drei Teilen: einer Datenbank, einer clientseitigen Benutzeroberfläche (bestehend aus HTML-Seiten und/oder JavaScript, die in einem Browser ausgeführt werden) und einer serverseitigen Anwendung. Die serverseitige Anwendung verarbeitet HTTP-Anfragen, führt domänenspezifische Logik aus, ruft Daten aus der Datenbank ab und aktualisiert sie und füllt die HTML-Ansichten auf, die an den Browser gesendet werden sollen.

Lesen:  Die 25 spannendsten Ideen für Betriebsausflüge

In einem Monolithen sind serverseitige Anwendungslogik, Front-End-Client-seitige Logik, Hintergrundjobs usw. alle in derselben umfangreichen Codebasis definiert. Das Fazit: Wenn Entwickler Änderungen oder Aktualisierungen vornehmen möchten, müssen sie den gesamten Stack auf einmal erstellen und bereitstellen.

Im Gegensatz zu dem, was Sie vielleicht denken, ist ein Monolith keine veraltete Architektur, die wir in der Vergangenheit zurücklassen müssen. Unter bestimmten Umständen ist ein Monolith ideal. Steven Czerwinski, Leiter Technik bei Scaylr und ein ehemaliger Google-Mitarbeiter erklärte, dass eine einheitliche Anwendung einfacher zu verwalten sei, weil sein Team bei Scaylr klein sei, als alles in Microservices aufzuteilen: „[In the early days of Scaylr] Obwohl wir diese positiven Erfahrungen mit dem Einsatz von Microservices bei Google gemacht hatten, sind wir gegangen [for a monolith] Route, weil ein einziger monolithischer Server für uns als zwei Ingenieure weniger Arbeit bedeutet.“

Wenn Sie eine Monolith-Architektur in Betracht ziehen, sollte Ihr Team Folgendes berücksichtigen:

Monolith-Profis

  • Weniger Querschnittsthemen: Der Hauptvorteil der monolithischen Architektur besteht darin, dass die meisten Apps typischerweise eine große Anzahl übergreifender Anliegen haben, wie z. B. Protokollierung, Ratenbegrenzung und Sicherheitsfunktionen wie Audit-Trails und DOS-Schutz. Wenn alles über dieselbe App läuft, ist es einfach, Komponenten für diese übergreifenden Anliegen zu verknüpfen.
  • Weniger Betriebsaufwand: Einen haben [large] Anwendung bedeutet, dass es nur eine Anwendung gibt, für die Sie Protokollierung, Überwachung und Tests einrichten müssen. Die Bereitstellung ist im Allgemeinen auch weniger komplex.
  • Leistung: Es können auch Leistungsvorteile entstehen, da der Shared-Memory-Zugriff schneller ist als die Inter-Process-Communication (IPC).

Monolith-Nachteile

  • Eng verbunden: Monolithische App-Dienste neigen dazu, mit der Weiterentwicklung der Anwendung eng gekoppelt und verflochten zu sein, was es schwierig macht, Dienste für Zwecke wie unabhängige Skalierung oder Code-Wartbarkeit zu isolieren.
  • Schwerer zu verstehen: Monolithische Architekturen sind auch viel schwieriger zu verstehen, da es Abhängigkeiten, Nebenwirkungen und Magie geben kann, die beim Betrachten eines bestimmten Dienstes oder Controllers nicht offensichtlich sind.

Microservices definieren

Microservices an sich haben nichts von Natur aus „Mikro“. Obwohl sie tendenziell kleiner sind als der durchschnittliche Monolith, müssen sie nicht winzig sein. Bei einigen ist das der Fall, aber die Größe ist relativ und es gibt keinen unternehmensweiten Standard für Maßeinheiten.

Der Microservice-Architekturstil ist ein Ansatz zur Entwicklung einer einzelnen Anwendung als Suite kleiner Dienste, die jeweils in einem eigenen Prozess ausgeführt werden und mit einfachen Mechanismen, häufig einer HTTP-Ressourcen-API, kommunizieren. Diese Dienste basieren auf Geschäftsfunktionen und können unabhängig voneinander durch vollautomatische Bereitstellungsmaschinen bereitgestellt werden. Es besteht ein absolutes Minimum an zentraler Verwaltung dieser Dienste.

Wenn Sie Microservices in Betracht ziehen, sollte Ihr Team Folgendes berücksichtigen:

Microservices-Profis

  • Bessere Organisation: Microservice-Architekturen sind in der Regel besser organisiert, da jeder Microservice eine ganz bestimmte Aufgabe hat und sich nicht um die Aufgaben anderer Komponenten kümmert.
  • Entkoppelt: Entkoppelte Dienste lassen sich auch einfacher neu zusammenstellen und neu konfigurieren, um die Zwecke verschiedener Apps zu erfüllen (z. B. sowohl die Web-Clients als auch die öffentliche API bedienen). Sie ermöglichen außerdem eine schnelle, unabhängige Lieferung einzelner Teile innerhalb eines größeren, integrierten Systems.
  • Leistung: Unter den richtigen Umständen können Microservices je nach Organisation auch Leistungsvorteile haben, da es möglich ist, Hot Services zu isolieren und unabhängig vom Rest der App zu skalieren.
  • Weniger Fehler: Microservices ermöglichen eine parallele Entwicklung, indem sie eine schwer zu überschreitende Grenze zwischen verschiedenen Teilen Ihres Systems schaffen. Dadurch wird es schwieriger – oder zumindest schwieriger –, das Falsche zu tun: Nämlich Teile zu verbinden, die nicht verbunden werden sollten, und diejenigen, die verbunden werden müssen, zu fest zu koppeln.
Lesen:  Was ist verwaltetes WordPress-Hosting?

Nachteile von Microservices

  • Übergreifende Anliegen für jeden Dienst: Wenn Sie eine neue Microservice-Architektur erstellen, werden Sie wahrscheinlich auf viele übergreifende Probleme stoßen, mit denen Sie zum Zeitpunkt des Entwurfs nicht gerechnet haben. Sie müssen entweder den Overhead separater Module für jedes bereichsübergreifende Anliegen (z. B. Tests) in Kauf nehmen oder bereichsübergreifende Anliegen in einer anderen Serviceschicht kapseln, über die der gesamte Datenverkehr geleitet wird. Letztendlich tendieren sogar monolithische Architekturen dazu, den Datenverkehr aus übergreifenden Gründen über eine äußere Serviceschicht zu leiten. Bei einer monolithischen Architektur ist es jedoch möglich, die Kosten für diese Arbeit hinauszuzögern, bis das Projekt viel ausgereifter ist.
  • Höherer Betriebsaufwand: Microservices werden häufig auf ihren eigenen virtuellen Maschinen oder Containern bereitgestellt, was zu einer Zunahme der VM-Wrangling-Arbeit führt. Diese Aufgaben werden häufig mit Containerflottenmanagement-Tools automatisiert.

Treffen Sie die richtige Entscheidung für Ihr Unternehmen

Vor- und Nachteile können einen allgemeinen Rahmen für die Diskussion potenzieller Vor- und Nachteile einer Architektur gegenüber einer anderen bieten, wenn Sie sich mit Ihrem Team zusammensetzen. Um diese allgemeinen Grundsätze effektiv anzuwenden, habe ich Dutzende von CTOs interviewt, um eine Rubrik mit Überlegungen zu erstellen, die Sie bei der Entscheidung, was für Ihr Unternehmen am besten ist, berücksichtigen sollten.

Befinden Sie sich in einem vertrauten Gebiet?

Darby und sein Team bei Gamut konnten sich direkt mit Microservices befassen, da er Erfahrung mit E-Commerce-Plattformen hatte und sein Unternehmen über umfassende Kenntnisse über die Bedürfnisse und Anforderungen seiner Kunden verfügte. Wenn er hingegen einen unbekannten Weg eingeschlagen hätte, wäre ein Monolith möglicherweise tatsächlich die sicherere Option gewesen.

Ist Ihr Team vorbereitet?

Hat Ihr Team Erfahrung mit Microservices? Sind Microservices ideal für diese Situation, wenn Sie die Größe Ihres Teams innerhalb des nächsten Jahres vervierfachen? Die Bewertung dieser Dimensionen Ihres Teams ist entscheidend für den Erfolg Ihres Projekts.

Wenn Ihr Team darauf vorbereitet ist, ist es sinnvoll, mit Microservices zu beginnen, da Sie sich so von Anfang an an den Rhythmus der Entwicklung in einer Microservice-Umgebung gewöhnen können.

Wie ist Ihre Infrastruktur?

In Wirklichkeit benötigen Sie eine cloudbasierte Infrastruktur, damit Microservices für Ihr Projekt funktionieren.

„[Previously]möchten Sie mit einem Monolithen beginnen, da Sie einen Datenbankserver bereitstellen möchten. Die Idee, für jeden einzelnen Microservice einen Datenbankserver einrichten und dann skalieren zu müssen, war eine Mammutaufgabe. Das könnte nur eine große, technisch versierte Organisation leisten“, so David Strauss, CTO von Pantheon mir erklärt. „Heutzutage haben Sie bei Diensten wie Google Cloud und Amazon AWS viele Möglichkeiten, kleine Dinge bereitzustellen, ohne dass Sie für jede einzelne die Persistenzebene besitzen müssen.“

Bewerten Sie das Geschäftsrisiko

Sie denken vielleicht, dass Microservices der „richtige“ Weg für ein technisch versiertes Startup mit hohen Ambitionen ist. Doch Microservices stellen ein Geschäftsrisiko dar. David Strauss erklärte:

„Viele Teams überbauen ihr Projekt zunächst; Jeder möchte glauben, dass sein Startup das nächste Einhorn sein wird und dass er daher alles mit Microservices oder einer anderen hyperskalierbaren Infrastruktur aufbauen sollte. Aber das ist normalerweise fast immer falsch.“

Lesen:  So fügen Sie Stellenangebote in WordPress mit WP-Stellenangeboten hinzu

Er fuhr fort, dass in diesen Fällen die Bereiche, von denen Sie dachten, dass sie skaliert werden müssten, wahrscheinlich nicht die Teile seien, die zuerst skaliert werden müssten, und dass dies selbst bei den Systemen, die skaliert werden müssten, zu fehlgeleitetem Aufwand führe.

Der Kontext ist wichtig

Die CTOs, mit denen ich gesprochen habe, verfügten über umfangreiche Erfahrungen sowohl mit Monolithen als auch mit Microservices. Einige begannen selbstbewusst mit Microservices, während andere zunächst bei einem Monolithen blieben und schließlich mit dem Wachstum ihrer Startups auf Microservices umstiegen. Berücksichtigen Sie Ihren eigenen Kontext und die folgenden Szenarien, um festzustellen, welche Architektur zu Ihrer Situation passt.

Wann man mit einem Monolithen beginnen sollte

Hier sind einige Szenarien, die darauf hindeuten, dass Sie Ihr nächstes Projekt mit einer monolithischen Architektur beginnen sollten:

  • Ihr Team befindet sich in der Gründungsphase: Ihr Team ist klein, zwischen 2 und 5 Mitgliedern, und daher nicht in der Lage, eine umfassendere Microservices-Architektur mit hohem Overhead in Angriff zu nehmen.
  • Sie bauen ein unbewiesenes Produkt oder einen Proof of Concept: Bauen Sie ein noch unerprobtes Produkt auf den Markt? Wenn es sich um eine neue Idee handelt, wird sie sich im Laufe der Zeit wahrscheinlich ändern und weiterentwickeln. Daher ist ein Monolith ideal, um eine schnelle Produktiteration zu ermöglichen. Das Gleiche gilt für einen Proof of Concept, bei dem Ihr Ziel darin besteht, so schnell wie möglich so viel wie möglich zu lernen, auch wenn Sie es am Ende wegwerfen.
  • Sie haben keine Erfahrung mit Microservices: Wenn Ihr Team noch keine Erfahrung mit Microservices hat, ist dies wahrscheinlich ein weiteres Zeichen dafür, dass Sie zunächst bei einem Monolithen bleiben sollten, es sei denn, Sie können es rechtfertigen, das Risiko einzugehen, zu einem so frühen Zeitpunkt „on the fly“ zu lernen.

Wann Sie mit Microservices beginnen sollten

Hier sind einige Szenarien, die darauf hinweisen, dass Sie Ihr nächstes Projekt mit Microservices starten sollten:

  • Sie benötigen eine schnelle und unabhängige Servicebereitstellung: Microservices ermöglichen eine schnelle, unabhängige Lieferung einzelner Teile innerhalb eines größeren, integrierten Systems. Beachten Sie, dass es abhängig von der Größe Ihres Teams einige Zeit dauern kann, bis sich Verbesserungen bei der Servicebereitstellung im Vergleich zum Beginn mit einem Monolithen bemerkbar machen.
  • Ein Teil Ihrer Plattform muss äußerst effizient sein: Wenn Ihr Unternehmen eine intensive Verarbeitung von Petabytes an Protokollvolumen durchführt, möchten Sie diesen Dienst wahrscheinlich in einer sehr effizienten Sprache (z. B. C++) erstellen, während Ihr Benutzer-Dashboard möglicherweise in Ruby on Rails erstellt wird.
  • Sie planen, Ihr Team zu vergrößern: Wenn Sie mit Microservices beginnen, gewöhnt sich Ihr Team von Anfang an daran, in separaten kleinen Services zu entwickeln, und wenn Teams durch Servicegrenzen getrennt sind, können Sie Ihr Team bei Bedarf viel einfacher skalieren, ohne eine exponentielle Komplexität einzuführen.

Der Monolith ist nicht tot und Microservices sind nicht für jeden Kontext optimal geeignet. Vermeiden Sie die Versuchung, in Microservices einzutauchen, nur weil sie explosionsartig wachsen. Nutzen Sie stattdessen die Weisheit früherer CTOs, um sorgfältig zu überlegen, welche Architektur für Sie am sinnvollsten ist.

Aktuelle Artikel:

Empfohlen