Unterschiede zwischen monolithischen, PBC- und Microservice-Ansätzen im E-Commerce

Die gängigsten technischen Konzepte/Ansätze sind monolithische Architekturen, Microservices und Packaged Business Capabilities (PBC). Sie haben vielleicht bemerkt, dass viele E-Commerce-Plattformanbieter mit diesen Begriffen für ihre Produkte werben. 

Natürlich hat jeder Ansatz für eine E-Commerce-Softwarearchitektur seine eigenen Vor- und Nachteile, abhängig von Ihrer Situation und Ihren Prioritäten.

Oft ist es für diejenigen, die sich für einen Ansatz entscheiden müssen, schwierig, die technischen Begriffe und Definitionen zu verstehen. 

Das führt zu Verwirrung und kann dazu führen, dass Sie sich für die falsche Lösung für Ihre Geschäftsanforderungen entscheiden.

Damit Sie eine fundierte Entscheidung treffen können, lassen Sie uns einen Blick auf diese drei Ansätze werfen.

Monolithische Architektur

Wenn Sie eine Unternehmenswebsite betreiben und seit mehreren Jahren dieselbe Plattform verwenden, ist die Wahrscheinlichkeit groß, dass es sich um einen Monolithen handelt. Das liegt daran, dass die beiden anderen Ansätze relativ neu sind: „Microservices“ wurde 2012 definiert, und PBCs haben sich daraus entwickelt.

Bei Software denkt man bei dem Wort „Monolith“ zuerst an etwas Großes, das alle Funktionen abdeckt, die Sie für die Geschäftsanforderungen benötigen. Das wäre die beste Art, eine monolithische Architektur zu beschreiben.

Anwendungen, die auf diese Weise erstellt werden, sind darauf ausgelegt, mehrere Aufgaben zu bewältigen und eine ganze Reihe von Diensten zu verwalten. Das Wichtigste dabei: auf diese Weise erstellte Software stellt ihre Funktionen dem Benutzer zur Verfügung, ohne dass dieser die Absicht hat, den zugrunde liegenden Code anzupassen oder zu verbessern.

Wenn überhaupt eine Anpassung möglich ist, dann nur innerhalb der vom Softwarehersteller vorgegebenen Grenzen und in den meisten Fällen unter Verwendung der eigenen Vorlagen, um die Lösung in einem sehr begrenzten Rahmen anzupassen.

Das bedeutet, dass aufgrund des proprietären Charakters der Softwarearchitektur selbst so etwas Kleines wie eine Fehlerbehebung den Support des Softwareanbieters erfordert.

Architektur als Puppenhaus

Um die Funktionsweise der monolithischen Architektur besser verstehen zu können, stellen Sie sich ein klassisches Puppenhaus vor. Es ist ein großes, ausgeklügeltes Spielzeug. Sie können es mit verschiedenen Möbeln, Dekorationselementen und Figuren ausstatten. Das Puppenhaus kann im Vintage- und Antik-Stil dekoriert werden, oder Sie können ihm das Aussehen einer modernen Villa geben.

Die Größe der einzelnen Zimmer im Puppenhaus bleibt jedoch gleich, und Sie können keine neuen Zimmer hinzufügen, egal was Sie tun. Ähnlich wie das Puppenhaus können Sie auch die Architektur einer monolithischen E-Commerce-Software nicht ändern, sondern nur den Inhalt.

Das kann problematisch sein, wenn man es vom Standpunkt der Softwarearchitektur aus betrachtet. Vor allem, wenn Sie es mit Hunderten von Produkten zu tun haben. Dieser Ansatz hat jedoch auch einige positive Aspekte.

Vor- und Nachteile einer monolithischen Architektur

Vorteile

• Leichtere Erstellung von Arbeitsabläufen. Der Code befindet sich an einem einzigen Ort

• Einfaches Debugging

• Einfache Bereitstellung, da es keine Abhängigkeiten gibt. Die gesamte Anwendung ist in einem einzigen Paket enthalten, das auf den Server installiert werden muss

• Niedrige Kosten, wenn Standardlösungen für Ihr Unternehmen ausreichend sind

• Es ist einfach, neue UI-Funktionen zu testen. Sie können einfach die Anwendung starten und ein Testtool wie Selenium ausführen

• Viele monolithische Softwareanbieter bieten einen App-Marktplatz an, auf dem Sie spezialisierte Erweiterungen von Drittanbietern finden können, um die Software zu ergänzen

• Sie können leicht eine gute Benutzerdokumentation erstellen

• Sofort einsatzbereite Funktionen ermöglichen eine schnellere Integration in den Betrieb

Nachteile

• Komplexe Codebasis

• Implementiert mit einer einzigen Programmiersprache: Einige Änderungen können die Verwendung eines anderen Frameworks oder einen kompletten Wechsel zu einer anderen Programmiersprache erfordern

• Sehr teure Lösung, wenn Sie Ihre Architektur erweitern müssen, um komplexen Geschäftsszenarien gerecht zu werden

• Begrenzte Änderungsmöglichkeiten für Funktionen

• Leistungsprobleme bei der Website, da nur eine Datenbank verwendet wird. Zwar kann sie optimiert werden, aber mit begrenzten Möglichkeiten

• Ein kleiner Fehler kann den gesamten Betrieb zum Erliegen bringen, denn um ihn zu beheben, müssen Sie eventuell das System neu einrichten

• Die Erweiterungen von Drittanbietern funktionieren nach einer Aktualisierung des Kernprodukts möglicherweise nicht mehr, bis der Drittanbieter seine Erweiterung an den neuen (oft proprietären) Code angepasst hat

• Der Softwarehersteller entwickelt die Funktionen und Merkmale des Kernprodukts oft auf der Grundlage des Feedbacks seiner größten Kunden. Solange diese Kunden eine Funktion nutzen, wird sie nicht aus der Software entfernt. Das kann die Software für alle anderen Kunden aufblähen

• Monolithische Softwareanbieter, die proprietären Code anstelle von offenen Standards verwenden, sind schwerer auszutauschen, was zu einer starken Anbieterbindung führt.

• Wenn Ihre Anwendung wächst, werden hohe Wartungskosten und Entwicklungsprobleme auftreten.

Microservices-Architektur

Während eine monolithische Architektur Ihre Anwendung als eine einzige Einheit ausführt, tun Microservices das genaue Gegenteil.

Am besten lassen sich Microservices mit der Definition von Gartner beschreiben:

„Ein Microservice ist eine serviceorientierte Anwendungskomponente, die eng skaliert, stark in sich abgeschlossen, lose gekoppelt, unabhängig implementierbar und unabhängig skalierbar ist.“

Mit anderen Worten: Bei einer monolithischen Architektur wird jeder einzelne Teil Ihrer E-Commerce-Anwendung aus einem einzigen Stück Code ausgeführt, der von demselben Team, in der Regel dem Softwareanbieter, gepflegt wird. Bei Microservices hingegen wird jede Komponente der Anwendung unabhängig von den anderen ausgeführt, und für jede Komponente gibt es ein eigenes Team, das sie pflegt.

So sind zum Beispiel Ihr Zahlungsgateway, Ihre Marketinginhalte und Ihr Artikelbestand separate Codebasen. Das heißt, dass jede Anwendung ihren eigenen Code hat und unabhängig von anderen Diensten ausgeführt wird, anstatt ein einziges großes Stück Code zu haben, das von einer einzigen Stelle aus ausgeführt wird.

Die gesamte Kommunikation zwischen den Diensten erfolgt über APIs.

Architektur als Lego-Set

Eine Microservice-Architektur ist wie eine aus Legosteinen gebaute Struktur. Sie können alle Anweisungen eines Bauplans befolgen oder sie so bauen, wie Sie es für richtig halten. Aber egal, für welchen Weg Sie sich entscheiden, Sie müssen bei null anfangen.

Nehmen wir an, Sie haben ein Lego-Schloss-Set. Jedes Fenster, jede Tür, jeder Turm, jede Fahne und jede Zugbrücke wäre ein Microservice, und die Bausteine, die diese Teile miteinander verbinden, wären APIs.

Sobald Sie ein solides Fundament des Modells aufgebaut haben, können Sie leicht entscheiden, ob Sie höhere Türme, eine andere Zugbrücke, mehr oder weniger Fenster usw. wünschen.

Vor- und Nachteile der Microservices-Architektur 

Vorteile

• Die Codebasis ist leicht zu verstehen, da jeder Dienst seine eigene hat

• Flexibilität, wenn es um die Verwendung verschiedener Technologien bei der Entwicklung und Skalierung von Diensten geht

• Hohe Fehlertoleranz. Wenn einer der Dienste ausfällt, funktionieren die anderen weiter

• Hervorragende Lösung für einen agilen Entwicklungsansatz, da die Lösung im Laufe der Zeit schrittweise ausgebaut werden kann

• Durch getrennte Teams, die Experten für ihren Teil der Anwendung sind, wird die Kommunikation mit den Business-Analysten, Produktmanagern und Product Owner erleichtert

• Wenn Ihre Anwendung im Laufe der Zeit größer und komplexer wird, kann sie in zusätzliche Microservices aufgeteilt werden

Nachteile

• Komplexe und zeitaufwändige Bereitstellung

• Für kleinere Anwendungen oft nicht rentabel

• Das Testen neuer Funktionen kann kompliziert sein, da jeder Dienst separat gestartet und getestet werden muss

• Sie sind möglicherweise auf einen guten Implementierungsdienstleister mit einer nachgewiesenen Erfolgsbilanz angewiesen, der die Anpassungen für Sie vornimmt

• Die Kosten sind in den frühen Phasen der Produktion möglicherweise höher. In späteren Phasen können mehrere Datenbanken und verschiedene Transaktionsmanagementlösungen diese Kosten in die Höhe treiben

• Der Anbieter von Microservices wird Ihnen in der Regel nicht bei Ihrer spezifischen Integration helfen.

PBC (Packaged Business Capabilities)

PBC wird oft in Verbindung mit Composable Commerce genannt. Es handelt sich um einen Kompromiss zwischen monolithischen Architekturen und Microservices. Gartner beschreibt es als „Softwarekomponenten, die eine klar definierte Geschäftsfähigkeit darstellen“.

Der Unterschied zwischen Microservices und Packaged Business Capabilities ist sehr gering. Ein PBC besteht aus mehreren Microservices, die zusammengefügt werden, um eine bestimmte Funktionalität zu liefern, die einen Mehrwert für das Unternehmen darstellt.

Wie bereits erwähnt, ist bei monolithischen Architekturen alles in einem einzigen Stück Code geschrieben. Bei Microservices hingegen sind alle Teile Ihres E-Commerce-Shops als separate Dienste geschrieben.

Packaged Business Capabilities erstellen eine Sammlung von Microservices, die für einen Aspekt Ihres E-Commerce verantwortlich sind. Das macht PBC nicht so granular wie Microservices und operativ schneller als monolithische Architekturen.

Architektur als Playmobil Set

Wir beschreiben dies anhand eines Beispiels – Der Playmobil Mittelalterburg.

Während Sie bauen, können Sie nach Belieben Wandteile hinzufügen oder entfernen und so die Burg nach Ihren Vorstellungen gestalten. Wenn Sie jedoch eine Tür, einen Turm oder eine Bogenschützenposition hinzufügen möchten, müssen Sie einen neuen Abschnitt hinzufügen. Die neuen Abschnitte, die Sie hinzufügen, werden nicht von Grund auf neu gebaut (wie bei Lego), sondern enthalten die notwendigen Komponenten.

Mit anderen Worten: Sie können die Burg bauen, wie Sie wollen, aber die Zusammensetzung der einzelnen Mauerteile kann nicht geändert werden. Sie müssten den gesamten Mauerabschnitt austauschen, um die von Ihnen gewünschten Funktionen in diesem Abschnitt zu platzieren.

PBCs können die Microservices enthalten, die Sie benötigen, so wie ein Mauerabschnitt die Türen und Fenster enthalten kann, die Sie benötigen. Sie können sie verwenden, um Dienste hinzuzufügen oder zu entfernen, solange sie zu den anderen Diensten in der Anwendung passen.

Vor- und Nachteile von Packaged Business Capabilities 

Vorteile

• Alle Pakete sind wiederverwendbar. Etwas, das zuvor geschrieben und in einem Modell eingekapselt wurde, kann bei Bedarf in späteren Entwicklungsphasen verwendet werden

• Sofort einsatzbereite Ökosysteme ermöglichen den Ingenieuren schnelle Integrationen

• Perfekte Abstimmung zwischen Entwicklern und Stakeholdern. Die Stakeholder wissen, was sie wollen, und die Entwickler wissen, wie sie es dank gut dokumentierter APIs liefern können

• Die Möglichkeit, neue Ansätze auszuprobieren und innovativ zu sein, da sich Geschäftsinitiativen leichter mit PBCs abstimmen lassen

• Die Fähigkeit, PBCs ohne große Komplexität an die Bedürfnisse Ihrer Kunden anzupassen

• Die hohe Flexibilität ermöglicht es Ihnen, einen Stack zu erstellen, der einem bestimmten Geschäftsbedarf entspricht. Sie müssen keine Software entwickeln, die „alles kann.“

Nachteile

• Erfordert möglicherweise viel Arbeit für die Frontend-Entwickler, um die Benutzeroberfläche für alle Dienste einheitlich zu gestalten.

• Nicht so anpassungsfähig wie ein Microservice-Ansatz.

Was ist der beste Ansatz für Ihr Unternehmen?

Jeder dieser Ansätze ist legitim. Welcher Ansatz für Sie am besten geeignet ist, hängt von verschiedenen Parametern Ihres Unternehmens ab – z. B. von der Größe, der Komplexität und der Verfügbarkeit von technischen Ressourcen.

Eine monolithische Architektur eignet sich gut, wenn Ihr Unternehmen am Anfang steht (und nicht beabsichtigt, schnell zu wachsen), über begrenzte technische Ressourcen verfügt oder Ihr Geschäft relativ vorhersehbar ist. In diesen Fällen sollte Ihre Anwendung über einige Standarddienste verfügen, die für den Betrieb des Unternehmens ausreichend sind.

Der Einsatz von Microservices eignet sich am besten für große Unternehmen, die über genügend Ressourcen und qualifizierte Experten verfügen. Mit vielen Arbeitskräften und IT-Ressourcen hinter der Microservices-Architektur erhalten Sie die beste Leistung und Flexibilität der Branche. Für Unternehmen mit individuellen Anforderungen, die mit einer monolithischen Architektur oder einem PBC-Ansatz nicht vollständig umgesetzt werden können, ist ein reiner Microservices-Ansatz am besten geeignet.

Packaged Business Capabilities sind ein Ansatz, der am besten geeignet ist, wenn Sie eine ausgewogene Mischung aus den besten Eigenschaften der oben genannten Ansätze suchen. Ein PBC-Ansatz ist sinnvoll, wenn Sie keine individuellen Anforderungen für bestimmte Geschäftsfunktionen haben oder Ihnen die Erfahrung/Fähigkeiten fehlen, diese (vorerst) anzupassen.

Letztendlich liegt die Entscheidung bei Ihnen. Jeder Ansatz hat seine Vor- und Nachteile, und alles hängt von Ihrer individuellen geschäftlichen Situation ab.

Wenn Sie sich immer noch nicht sicher sind, welcher Ansatz für Sie der beste ist, kontaktieren Sie uns und besprechen Sie Ihre geschäftlichen Anforderungen und Herausforderungen mit unserem Expertenteam.