E-Commerce mit Microservices-Architektur

Microservices als Basis moderner Ansätze

‍

Ein grosser Teil unserer Evaluation drehte sich um das Potenzial dieser E-Commerce-Anwendungen, eine Microservices-Architektur zu übernehmen oder danach entwickelt zu werden. «Headless-E-Commerce» bezeichnet den neuen Standard für die Entwicklung von E-Commerce-Anwendungen und -Umgebungen. Früher wurden E-Commerce-Anwendungen mit monolithischen Frameworks gebaut, die sich nicht aufteilen liessen. Die Ursache komplexer Probleme war deshalb schwer zu finden. Seit dem Wechsel zu Headless-E-Commerce können wir Komponenten herauslösen und ihre Performance sowohl isoliert als auch im Zusammenspiel des gesamten Frameworks beobachten. Headless-E-Commerce bezeichnet eine E-Commerce-Architektur, bei der Frontend und Backend vollständig getrennt sind.

Wir setzen Ihre Headless-E-Commerce-Plattform mit Microservices um. Eine Microservices-Architektur besteht aus einzelnen, getrennten und doch miteinander verbundenen Anwendungen und Services, die in einer ereignisgesteuerten Architektur zusammenarbeiten. Jeder Service erfüllt eine eigene Aufgabe und kommuniziert mit den anderen über Protokolle wie HTTP/REST-APIs oder Message Queues. Jeder Service ist eine eigenständige Anwendung und lässt sich unabhängig testen, bereitstellen und veröffentlichen, ohne dass das System ausfällt.

Natürlich sind Microservices nicht der Heilige Gral, sondern ein weiterer Weg, zuverlässige Software zu liefern. Dank der modularen Architektur lassen sich Tests relativ schnell durchführen, und die Wartung bleibt beherrschbar, vor allem bei Upgrades. Unten sehen Sie ein Beispieldiagramm einer einfachen Microservices-Architektur. Zu den wichtigsten Merkmalen gehören: 1) separate Microservices, die jeweils eine Funktion abbilden, und 2) Datenbanken, die an einzelne Microservices angebunden sind. Die Datenbanken sind unabhängig mit den Microservices verbunden und speichern die Daten der jeweiligen Funktion. Das verringert Abhängigkeiten zu anderen Datenbanken. Zudem ist klarer, was wo gespeichert ist: Fällt etwas aus, wissen wir, welche Datenbank betroffen sein könnte. Ein weiterer grosser Vorteil der gekapselten Datenhaltung ist die Skalierbarkeit von Microservices-Architekturen, denn die Daten verteilen sich auf mehrere Speicher und lassen sich so leichter handhaben als eine grosse Datenbank.

Geschäftliche Anforderungen erfüllen

Geschäftliche Agilität trifft auf Software-Agilität: Klar abgegrenzte Funktionsbausteine machen das System flexibler und beweglicher. Microservices fördern technische Einfachheit und ermöglichen eine gezielte Softwareentwicklung. Je einfacher das System, desto besser lässt es sich skalieren und desto besser unterstützt es die Agilität des Unternehmens. Wie fein ein Microservice geschnitten wird, sollte man bewusst entscheiden. Massgeblich ist vor allem die geschäftliche Anforderung, die er erfüllt. Feiner als nötig sollte man ihn nicht schneiden.

‍

‍

Eine Microservices-Architektur passt sehr gut zu einer DevOps-Kultur. Entwicklungsteams können den Funktionsumfang selbst bemessen und in Containern bereitstellen. Mit möglichst viel Autonomie erfüllen die Teams die geschäftlichen Anforderungen, die zu ihrem jeweiligen Funktionsbereich gehören. So arbeiten sie schneller und effizienter.

‍

CI/CD als Voraussetzung für Microservices

Für den Erfolg mit Microservices sind Continuous Integration und Continuous Delivery (CI/CD) unverzichtbar. Ohne funktionierenden CI/CD-Prozess ist agile Entwicklung kaum möglich. Schwierig wird die Umsetzung von CI/CD für Microservices, wenn diese über mehrere Codebasen verflochten oder zu stark voneinander abhängig sind. Die Herausforderung besteht darin, Services so unabhängig zu gestalten, dass sie sich bereitstellen lassen, ohne andere Services zu beeinträchtigen.

Eine monolithische Anwendung hängt an einer einzigen Build-Pipeline. Müssen dringende Fehlerbehebungen sofort ausgerollt werden, verzögert das meist die Veröffentlichung von Verbesserungen und neuen Funktionen. Mit der Zeit wird die Anwendung immer komplexer, und ihre Abhängigkeiten verflechten sich immer enger. Auch Tests und Deployments werden zunehmend aufwendig und zeitraubend. Microservices lassen sich dagegen unabhängig voneinander bereitstellen. In einer Microservices-Umgebung hat Team A eine direkte Pipeline in die Qualitätsumgebung und in die Produktion, ohne dass ein Fehler bei Team B sie stört. Hat Team B Schwierigkeiten, kann es den Fehler isolieren, ohne die Produktionsreife der Funktionen von Team A, C und D zu gefährden. Eine automatisierte Release-Pipeline verringert zudem das Risiko von Fehlern beim Deployment.

‍