Einer für Alle oder Alle für Einen? - Gegenüberstellung

In unserem Alltag als Consultants, Softwarearchitekten oder Entwickler stellt sich immer häufiger die Frage, ob ein Projekt als Monolith oder in einem Microservice-Ansatz umgesetzt werden soll. Dies ist insbesondere im eCommerce Bereich in einem Umfeld mit großen Legacy-Monolithen wie SAP Hybris relevant. In dieser Artikelserie wollen wir einmal beleuchten, wie ein Entscheidungsweg und eine Transformation zu einer Architekturumstellung auf Microservices aussehen könnte - oder wie dies auch scheitern könnte. Dabei bedienen wir uns langjähriger Erfahrungen aus einer Vielzahl von eCommerce Projekten.

Zunächst ist es wichtig zu betonen, dass ein Monolith nicht per se schlecht ist. Ganz im Gegenteil - es gibt eine Reihe von guten Gründen sich für eine monolithische Architektur zu entscheiden. Beispielsweise ist es mithilfe des SAP Commerce Accelerators schnell und einfach möglich, einen Onlineshop mit vielen Standardfeatures zu realisieren. Der initiale Entwicklungsaufwand ist bei einer solchen Standardsoftware geringer, da schon eine Menge an Logiken und Strukturen vorhanden sind, welche bereits nahtlos ineinander greifen. Die Erweiterung dieser Systeme besteht dann vor allem im Customizing.

Out-of-the-box bietet der Accelerator eine große Anzahl von Features, so stehen beispielsweise ein Checkout, Listen- und Detailseiten, Payment und sogar ein integriertes CMS zur Verfügung. Neben diesen Standardfeatures gibt es noch viele spezialisierte Features die kontinuierlich erweitert und verbessert werden.

Läuft ein solches System über mehrere Jahre hinweg und wird stetig weiterentwickelt, kommen wir allerdings schnell in eine Situation, in der “historisch gewachsene” Lösungen eine große Bedeutung einnehmen. Eine Ursache hierfür kann sein, dass Lösungen in den Monolithen implementiert werden, die dort eigentlich keine Daseinsberechtigung haben. Die Flexibilität einer solchen Softwarelösung vereinfacht dieses Vorgehen. Es wird häufig missachtet, dass es auch hier relevant ist, einen Scope abzustecken - im Beispiel einer eCommerce Plattform sind dies eben nur die tatsächlich Webshop-relevanten Features.

Daraus ergibt sich nun erst einmal kein grundsätzliches Problem, allerdings erleben wir in unserem Alltag immer wieder, dass Kunden ihren technischen Schulden zu geringe Aufmerksamkeit schenken. Langfristig führt dies zu stetig steigender Komplexität und immer schwererer Wartbarkeit der Systeme. Das System wächst häufig im fachlichen Umfang kontinuierlich weiter. Unbenötigte Funktionalitäten bleiben oftmals lange oder sogar für immer in der Plattform. Neue Entwickler werden somit beim Onboarding vor eine große Herausforderung gestellt. Für sie ist es nur schwer möglich, sich in verhältnismäßig kurzer Zeit einzuarbeiten. Ohne die notwendige Aufmerksamkeit und Disziplin besteht ein hohes Risiko nicht gewollte Äbhängigkeiten in Module einzuführen. Dies führt langfristig auch dazu, dass die Erweiterung um neue Features oder das Refactoring immer teurer wird.

Irgendwann gelangt man an einen Punkt, an dem man sich fragt wie der Entwicklungsprozess beschleunigt werden kann. Dazu gibt es in jedem Projekt mit Sicherheit eine Vielzahl von Antworten. Die Umstellung auf eine Microservicearchitektur ist hierbei ein sehr häufig diskutierter Punkt. Mit Sicherheit sind Microservices kein Allheilmittel, denn die Konzeption einer solchen Architektur birgt wiederum andere Hürden. Jedoch bietet sich durch deren Einsatz die Möglichkeit, die eigentlichen Features am Rande unserer eCommerce Plattform zu entkoppeln und unkompliziert zu bedienen.

Sind einzelne Microservices fachlich korrekt abgegrenzt und zustandslos implementiert, ergeben sich daraus eine Reihe von Vorteilen. Horizontale Skalierbarkeit ist gewährleistet und sehr einfach möglich. Sind die Schnittstellen korrekt versioniert und ist ein Balancing vorgeschaltet, könnte ein Deployment sogar jederzeit und ohne Ausfallzeiten stattfinden. Dazu können unbenötigte Services einfach stillgelegt werden. Zudem fällt es durch die fachliche Abgrenzung neuen Entwicklern wesentlich leichter, sich im Themengebiet eines einzelnen Services zurechtzufinden und einzuarbeiten.

Ein Beispiel für ein Feature, das aus einem bestehenden Monolithen herausgetrennt werden kann, stellen die Kochrezepte eines Shops für Küchengeräte dar. Dort können sich potentielle Kunden online Rezepte heraussuchen und werden so durch mehr Content auf die eigenen Seiten gebracht. Man könnte eine solche Rezeptseite nun als einfache Content-Page betrachten, möchte den Kunden vielleicht aber auch mehr bieten, um mit anderen Anbietern in diesem Bereich mithalten zu können. Die Berechnung der Zutaten und die dafür notwendigen Logiken und Datenbankerweiterungen sind in einem Webshop-Monolithen zumindest fragwürdig. Es bietet sich viel mehr an, dafür einen eigenen Service bereitzustellen. Bei der Umsetzung dieser Rezeptschnittstelle besteht nun eine freie Technologiewahl. Unabhängigkeit vom bestehenden System. Sollte diese Schnittstelle aus irgendeinem Grund ausfallen, hätte dies nur wenig Einfluss auf den restlichen Webshop.

Natürlich wäre es auch möglich, solch ein Feature in das bestehende System zu verbauen. Dafür wäre jedoch ein SAP Commerce-Spezialist notwendig, im Gegensatz zu einem eigenständigen Service mit freier Technologiewahl.