Contact
Evolutionary Architecture • 16 Minuten Lesedauer

Monolith vs Microservices: Wählen Sie die richtige Architektur für Ihr Unternehmen aus

Mark Blockhuys | 19-01-2022

Wenn Sie nur die monolithische Architektur kennen, haben Sie gewissermaßen hinter dem Mond gelebt. Die heutige Technologie hat sich weiterentwickelt, um neue Geschäftsprobleme zu lösen und die Microservices-Architektur verspricht eine schnellere Markteinführung, geschäftliche Agilität und Flexibilität. Man sagt sogar, dass Microservices eine treibende Kraft hinter der digitalen Transformation sind. Dennoch hat auch das monolithische System seine Vorteile und Szenarien. Wie lassen sich also Monolith- und Microservices-Architekturen vergleichen und in welchen Situationen sollten Sie sich für eine entscheiden?

Dies ist der dritte Artikel in unserer Artikelserie über evolutionary Architecture. Auf dieser Seite können Sie die zugrundeliegenden Prinzipien wie Microservices, API, Cloud Commerce, Headless Commerce und ereignisgesteuerte Architektur ausführlich kennenlernen.

Trotz seines Namens ist ein Monolith keine veraltete Architektur, die der Vergangenheit angehört. Es handelt sich lediglich um die traditionelle Art und Weise, Anwendungen als eine einzige und unteilbare Einheit zu erstellen. Wenn Sie der gleichen Codebasis neue Funktionen und Änderungen hinzufügen, wird sie mit der Zeit wachsen. Diese Struktur eignet sich gut für kleine Teams und bietet Vorteile wie weniger operativen Aufwand und Konzentration. Ein Monolith hat in der Regel eine serverseitige Anwendung, eine Front-End-Benutzeroberfläche und eine einzige Datenbank. Alle Funktionen werden an einem Ort verwaltet und bedient, was große Vorteile mit sich bringt.

VORTEILE EINER MONOLITHISCHEN ARCHITEKTUR

Eine monolithische Anwendung ist einfach zu entwickeln, zu testen und bereitzustellen. Nach der Bereitstellung müssen Sie sie lediglich an laufende Veränderungen anpassen. Dies bedeutet zwar, dass es während der Bereitstellung einen einzigen Fehlerpunkt gibt, was aber für die meisten Unternehmen kein Problem darstellt. Da alles über dieselbe Anwendung läuft, lassen sich übergreifende Probleme wie Protokollierung, Handhabung, Caching und Sicherheit leicht lösen, da Speicher, Platz und Ressourcen gemeinsam genutzt werden. Der monolithische Ansatz bringt auch Leistungsvorteile mit sich, da der gemeinsame Speicherzugriff schneller ist als beispielsweise die Interprozesskommunikation (ICP).

Typische Szenarien für den Start mit einem Monolithen sind:

  1. Ihr Team ist klein und befindet sich in der Gründungsphase. Für ein Startteam mit zwei bis fünf Mitgliedern ist eine monolithische Architektur ideal, um sich darauf zu konzentrieren.
  2. Sie bauen einen "Proof of Concept" auf. Neue Produkte werden sich verändern und weiterentwickeln, während Sie herausfinden, was für Ihre Benutzer nützlich ist. Hierfür ist ein Monolith perfekt geeignet, da er eine schnelle Iteration des Produkts ermöglicht.
  3. Vorhersehbare Größe und Komplexität. Wenn Ihre Anwendung keine erweiterte Skalierbarkeit erfordert und die Komplexität überschaubar ist, dann ist eine monolithische Architektur der beste Weg, den Sie einschlagen können.

DER BEDARF AN GESCHÄFTLICHER FLEXIBILITÄT

Der globale Handel ist bislang exponentiell gewachsen, da jeder neue Kanal einen völlig neuen Markt schafft. Kunden auf der ganzen Welt werden immer anspruchsvoller und wünschen sich inspirierende Einkaufserlebnisse über alle Kanäle und auf allen Geräten. Personalisierung, hohes Serviceniveau und schnelle Lieferung sind nur einige der Herausforderungen, denen sich Händler derzeit stellen müssen. Unternehmen, die eine Vorreiterrolle einnehmen, müssen in der Lage sein, sich schnell anzupassen.

DIE NACHTEILE EINER MONOLITHISCHEN ARCHITEKTUR

In diesem schnelllebigen, wachstumsstarken Marktumfeld werden die Nachteile einer monolithischen Anwendungsarchitektur deutlich:

    1. Hoher Grad an Softwarekomplexität. Eine erfolgreiche Anwendung wird ständig weiterentwickelt, um mit den sich ändernden Anforderungen Schritt zu halten. Das hat zur Folge, dass diese monolithischen Anwendungen immer schwieriger zu warten sind, geschweige denn von den Entwicklern, die daran arbeiten, vollständig verstanden werden.
    2. Keine Verantwortung. Eine große Anwendung läuft Gefahr, als Blackbox wahrgenommen zu werden, für die niemand die Verantwortung übernehmen will. Dies kann dazu führen, dass sich einzelne Entwickler nicht trauen, etwas anzurühren, und wird als "großer Schlammball" bezeichnet.
    3. Mangelnde Agilität. Bei monolithischen Anwendungen sind die Teams in der Regel nach ihren einzelnen Funktionen strukturiert, z. B. Frontend, Backend oder Datenbank. Wenn eine Anforderung gestellt wird, die alle diese Teams betrifft, können die daraus resultierenden Projekte sehr viel Zeit in Anspruch nehmen, da die Aufgaben von und unter mehreren verschiedenen Teammitgliedern aufgeteilt werden müssen.
    4. In einer zentralisierten Architektur sind die einzelnen Teile stark gekoppelt und voneinander abhängig. Dies führt dazu, dass ein einziger Fehler das gesamte System zum Einsturz bringen kann.
    5. Ineffiziente Tests. Aufgrund der einzelnen Fehlerquellen in diesen Anwendungen sind umfassende und wiederholte Tests von entscheidender Bedeutung. Wenn nur ein kleiner Teil der Anwendung geändert wird, muss sie in ihrer Gesamtheit getestet werden - auch in Bezug auf Funktionen, die nichts mit den ursprünglichen Änderungen zu tun haben.
    6. Keine Spezialisierung. In einer stark gekoppelten Anwendung werden die einzelnen Komponenten in der Regel hinsichtlich der Art und Anzahl der Ressourcen, auf die sie Zugriff haben, gleich behandelt - unabhängig davon, ob ein bestimmter Teil mehr oder weniger CPU, RAM oder Disk I/O benötigt.
    7. Skalierungsprobleme. Bei den meisten monolithischen Anwendungen ist eine horizontale Skalierung die einzige Option, was wiederum viele andere Probleme mit sich bringt. Es ist verständlich, dass Unternehmen, die schneller arbeiten und Innovationen vorantreiben müssen, versuchen, diese Einschränkungen zu umgehen.

ZUR RETTUNG: VORTEILE UND NUTZEN VON MICROSERVICES

Bei einem Microservices-Ansatz wird jede Geschäftsfunktion in einzelne Dienste gekapselt. Jeder Anwendungsprozess funktioniert als separater, lose gekoppelter Dienst mit eigener Logik und Datenbank. Die Aktualisierung, Bereitstellung, Prüfung und Skalierung erfolgt im Rahmen der einzelnen Dienste. Microservices reduzieren zwar nicht die Komplexität eines Systems, aber sie machen die Komplexität sichtbarer und überschaubarer. Je nach Bedarf kann ein und derselbe Dienst in mehreren Geschäftsprozessen und über eine Vielzahl von Kanälen und Berührungspunkten wiederverwendet werden. Durch die Standardisierung von Verträgen über geschäftsorientierte APIs bemerken die Benutzer keine Änderungen im Backend.

In unserem Blog Wie Microservices geschäftliche Agilität und E-Commerce-Erfolg ermöglichen können Sie mehr über die Hintergründe, Herausforderungen und Vorteile von Microservices lesen.

Mit Befürwortern wie Netflix, Airbnb, Google, Disney und Amazon haben Microservices an Dynamik und Bekanntheit gewonnen. Typische Best Practices für die Microservices-Architektur sind:

  • Klare Domänen. Während der Entwurfsphase der Microservices sollten ihre Grenzen klar sein, damit sie mit den Geschäftsfähigkeiten in Einklang gebracht werden können. Beim domänengesteuerten Design wird dies auch als gebundener Kontext bezeichnet. Auf diese Weise können Sie die Sprache verwenden, die für jede Domäne am effizientesten ist.
  • Extreme Anforderungen. Microservices können ein Maximum an Flexibilität, Geschwindigkeit und Skalierbarkeit bieten. Anwendungen mit extremen Anforderungen sind am besten mit einer Microservices-Architektur bedient, die sich speziell auf jeden Dienst einstellen kann.
  • Fachwissen über Microservices. Um mit Microservices zu beginnen, brauchen Sie ein Team mit Erfahrung in Microservices oder verteiltem Design. DevOps- und Containerexperten sind empfehlenswert, da diese Konzepte eng mit Microservices verbunden sind.
  • Komplexität. Wenn Sie eine große Anwendung mit mehreren Modulen und User Journeys planen, die zu einer hohen Komplexität führen, ist eine Microservices-Architektur die beste Lösung. Sie macht die Skalierung und das Hinzufügen neuer Funktionen viel einfacher.

Der Preis für Geschwindigkeit und Agilität: herausforderungen der Microservices 

Anhand der großen Namen, die für Microservices plädieren, und der typischen Ausgangspunkte können Sie sehen, dass die Microservices-Architektur kein Allheilmittel ist. Entscheiden Sie sich nicht für Microservices, nur weil Sie sehen, dass andere Unternehmen damit Erfolg haben. Der Microservice-Ansatz ist weder für jeden Geschäftskontext geeignet noch führt er dazu, dass die Komplexität von Entwicklung und Wartung auf magische Weise verschwindet.

Nehmen Sie Abstand von der Vorstellung, dass Microservices Ihren E-Commerce zum Kinderspiel machen, und bedenken Sie die folgenden Nachteile von Microservices im Vergleich zum monolithischen Ansatz:

  • Querschnittsthemen. Jeder Microservice muss sich mit einer Reihe von Querschnittsthemen befassen, z. B. Protokollierung, Metriken, Zustandsprüfungen, externalisierte Konfiguration usw. Es ist wahrscheinlich, dass Sie diese Probleme zur Entwurfszeit nicht vollständig vorausgesehen haben. Sie könnten den Overhead von separaten Modulen für jedes Problem in Kauf nehmen. Oder aber Sie kapseln diese Belange in einer anderen Dienstschicht, durch die der gesamte Datenverkehr geleitet wird.
  • Höhere Kosten. Microservices sind mit einem höheren Arbeitsaufwand für Betrieb, Bereitstellung und Überwachung verbunden. Dies ist mit einem höheren betrieblichen Aufwand verbunden. Da die Dienste miteinander kommunizieren, kann die daraus resultierende hohe Anzahl von Remote-Aufrufen zu höheren Kosten in Verbindung mit Netzwerklatenz und -verarbeitung führen. Und da jeder Microservice unabhängig eingesetzt wird und seine eigene Laufzeitumgebung und CPU benötigt, ist auch der Ressourcenbedarf höher.
  • Unternehmerischer Wandel. Jedes Team muss den gesamten Lebenszyklus eines Microservices abdecken, um völlig unabhängig zu sein. Vom Design und der Konzeption über die technischen Entscheidungen und die Implementierung bis hin zum laufenden Betrieb und der Überwachung. Das erfordert organisatorische Veränderungen, wie die Verlagerung von Kompetenzen und Macht von den Managern auf die Teams. Eine DevOps-Kultur, die auch Automatisierungspraktiken betont, ist für die erfolgreiche Anpassung eines Microservice-Ansatzes dringend zu empfehlen.

Ein Ansatz passt nicht für alle

Als Service-Architektur erfreut sich die Microservices-Architektur zunehmender Beliebtheit. Die Entscheidung, ob Sie mit einer monolithischen oder einer Microservices-Architektur beginnen sollten, hängt jedoch von Ihrem eigenen Geschäftskontext ab, der anhand der oben genannten Vor- und Nachteile bewertet werden muss. Für eine leichtgewichtige Anwendung ist ein monolithisches System oft besser geeignet. Für eine komplexe, sich entwickelnde Anwendung mit klaren Domänen ist die Microservices-Architektur die bessere Wahl. Die wichtigste Erkenntnis? Konzentrieren Sie sich nicht ausschließlich auf den architektonischen Ansatz, sondern auf die spezifischen Bedürfnisse Ihres Unternehmens. Das wird Ihnen helfen, unnötige Komplexität zu klären und zu reduzieren und als technischer Entscheidungsträger die Richtung vorzugeben.

Möchten Sie mehr über den Wechsel von Monolithen zu Microservices erfahren? Nehmen Sie Kontakt mit uns auf und wir beantworten gerne alle Ihre Fragen.

Dies ist der dritte Artikel in unserer Artikelserie über evolutionäre Architektur. Die zugrundeliegenden Prinzipien wie Microservices, API, Cloud Commerce, Headless Commerce und Even-Driven können Sie auf dieser Seite in aller Tiefe kennenlernen.

About SQLI & Commercetools: SQLI wurde in den 90er Jahren gegründet und ist eine der größten europäischen Dienstleistungsgruppen, die sich dem digitalen Geschäft widmet; wir sind spezialisiert auf die Konzeption, die Implementierung, den globalen Einsatz und den Betrieb von Omnichannel-Commerce-Lösungen. Viele unserer Kunden sind Marktführer. Unser Ziel ist es, sie bei der Weiterentwicklung ihres Geschäftsmodells zu unterstützen, damit sie sich in jedem Markt oder Kanal auszeichnen können. SQLI hilft Unternehmen, B2B- und B2C-Kunden mit einer nahtlosen Erfahrung in jedem Kanal zu erreichen, in dem sie aktiv sind. Mit unserer Expertise in Evolutionärer Architektur & Microservices können wir die richtigen Grundlagen für eine Omnichannel-Pressence schaffen. Das Ergebnis ist eine E-Commerce-Lösung, die ein umfassendes Markenerlebnis ermöglicht und den Umsatz steigert.

Microservices

whitepaper

5 Schritte um heute mit Microservices zu beginnen

Download Now
Picture of Mark Blockhuys

Mark Blockhuys

CTO