Multi-Tenant Kubernetes für eCommerce: Wie ayedo ein Softwarehaus ohne DevOps-Team von VM-Skripting zur Developer Platform geführt hat

In vielen eCommerce-Teams ist der Engpass nicht Feature-Entwicklung, sondern Betrieb. Nicht weil die Entwickler schlechte Software schreiben, sondern weil das Betriebsmodell nicht mitwächst. Was am Anfang „ein paar Server und ein paar Skripte" ist, wird im Scale zu einem Business-Risiko: Jede Kundeninstanz entwickelt sich anders, Deployments sind nicht mehr reproduzierbar, Wartungsfenster häufen sich – und die Zeit der Entwickler fließt in Firefighting statt in Produktwert.

Genau in dieser Situation war ein eCommerce-Softwarehaus, das modulare Shop- und B2B-Commerce-Lösungen für Marken, Händler und Whitelabel-Endkunden entwickelt und betreibt. Der Kunde bleibt anonymisiert. Das Muster dahinter ist es nicht – und lässt sich auf viele SaaS- und Plattformteams übertragen, die ohne dediziertes DevOps-Team wachsen müssen.

In diesem Beitrag zeigen wir, wie ayedo den Application Lifecycle dieses Kunden auf eine Kubernetes-basierte Multi-Tenant-Plattform migriert hat – inklusive Internal Developer Platform, standardisierter Container-Strategie und flexibler Standortwahl über mehrere europäische Provider. Das Ergebnis war nicht nur „modernere Infrastruktur", sondern vor allem ein neues Liefermodell: schneller, reproduzierbarer, auditierbarer – und deutlich weniger supportintensiv.

Ausgangslage: Wenn Wachstum aus Skripten und VMs operative Schuld macht

Der Kunde ist ein Team mit rund 20 Mitarbeitenden, davon etwa 10 in der Entwicklung. Ein dediziertes DevOps-Team gab es nicht. Betrieb und Deployment wurden von den Entwicklern mitgetragen – pragmatisch, aber zunehmend teuer.

Die Plattform basierte technologisch auf einem modernen Stack: JavaScript/TypeScript, PostgreSQL, Redis und S3. Das Problem war nicht die Anwendung, sondern die Art, wie sie ausgeliefert wurde. Deployments erfolgten manuell über Bash-Skripte auf virtuellen Servern. Für einzelne Projekte kann das funktionieren. Sobald man viele Kundeninstanzen parallel betreibt, kippt das Modell.

Denn VMs plus Skripte sind selten wirklich reproduzierbar. Selbst wenn alle den gleichen Ablauf nutzen, entstehen über Zeit Abweichungen: kleine Konfigurationsänderungen, unterschiedliche Paketstände, „nur kurz" gefixte Settings, abweichende Cronjobs, spezielle Sonderfälle für bestimmte Kunden. Dieser Config Drift ist der stille Kostentreiber in wachsenden Hosting-Setups. Er macht Deployments unzuverlässig, erschwert Updates und vergrößert das Risiko von Incidents, weil niemand mehr sicher sagen kann, ob „Kunde A" wirklich das gleiche System wie „Kunde B" hat.

Genau das passierte hier. Mit steigender Nachfrage nach individuellen eCommerce-Lösungen wuchsen nicht nur die Projekte, sondern auch die Anforderungen der Kunden: Standortvorgaben, Compliance-Zertifikate, Infrastruktur-Policies. Jede neue Anforderung bedeutete im VM-Modell neue Varianten. Neue Varianten bedeuteten mehr Drift. Mehr Drift bedeutete mehr Aufwand – und damit längere Lieferzeiten und sinkende Margen.

Was zunächst wie ein operatives Problem aussieht, ist in Wahrheit ein strategischer Engpass: Wenn Betrieb pro Kunde individuell ist, skaliert die Organisation nicht. Sie skaliert nur ihre Komplexität.

Der Kern des Problems: fehlende Standardisierung auf Application-Lifecycle-Ebene

In Gesprächen zeigt sich in solchen Situationen fast immer ein Muster: Die Entwickler wissen, wie die Anwendung laufen soll. Sie können das aber nicht als Standard ausrollen, weil das Betriebsmodell nicht deklarativ ist.

VM-Skripting führt zwangsläufig dazu, dass „Deployment" eine Abfolge imperativer Schritte ist. Das macht Rollbacks schwierig, es macht Updates riskant, und es macht Provisionierung langsam. Besonders kritisch wird das bei Whitelabel-Endkunden, weil der Supportaufwand dort selten linear wächst. Ein kleiner Bug oder ein Performanceproblem kann durch die Vielzahl an Instanzen plötzlich zu einem Support-Sturm werden – und das Team wird immer reaktiver.

Das Team hatte außerdem keine Containerisierung. Ohne Containerisierung gibt es kein einheitliches Artefakt, das man sauber bauen, prüfen und ausrollen kann. Man deployt dann nicht eine Version, sondern man verändert einen Serverzustand. Genau diese Zustandsänderungen sind es, die im Wachstum zum Problem werden.

Die Zielsetzung war deshalb nicht „Kubernetes einführen". Die Zielsetzung war: den Application Lifecycle so zu standardisieren, dass Deployments reproduzierbar sind, Betrieb automatisiert abläuft, und neue Kundeninstanzen schnell und konsistent bereitgestellt werden können – unabhängig davon, welcher Entwickler gerade Zeit hat.

ayedos Ansatz: Multi-Tenant Plattform + Internal Developer Platform statt „mehr Skripte"

Wir haben das Projekt als Plattformaufbau verstanden: nicht als einzelne Migration, sondern als Einführung eines Betriebsmodells, das den Entwicklern Arbeit abnimmt und zugleich die betriebliche Qualität erhöht. Dafür braucht es zwei Ebenen.

Die erste Ebene ist die Laufzeitplattform: Kubernetes als Multi-Tenant-Betriebsumgebung mit klarer Isolation, standardisierten Deployments und skalierbarer Observability. Die zweite Ebene ist eine Internal Developer Platform (IDP), die den Lifecycle in einen Standardprozess übersetzt: Build, Scan, Deploy, Observability, Secrets – ohne dass jedes Team diese Bausteine selbst zusammensetzen muss.

Der Kunde sollte am Ende nicht „Kubernetes bedienen", sondern Features liefern – und die Plattform sollte die langweiligen, wiederkehrenden Dinge zuverlässig erledigen.

Betriebsplattform: Betrieb in ayedo Fleet Clustern – skalierbar, isoliert, hochverfügbar

Als Basis wurden die Kundenumgebungen in einem oder mehreren ayedo Fleet Clustern betrieben. Der Grundgedanke dabei ist einfach: Multi-Tenancy funktioniert nur dann gut, wenn Isolation und Betriebsstandard Teil der Plattform sind – nicht nachträgliche Disziplin.

Jeder Kunde wird in einer logisch isolierten Umgebung betrieben. Damit sind Policies, Ressourcenlimits und Zugriffskontrollen sauber definierbar. Wenn ein Endkunde Lastspitzen hat, soll das nicht zum Noisy-Neighbor-Effekt führen. Wenn ein Kunde besondere Policies benötigt, sollen diese als deklarative Konfiguration abbildbar sein, nicht als Sonderfall auf einem Server.

Aus Unternehmenssicht ist das der entscheidende Schritt weg vom „wir betreiben Server" hin zu „wir betreiben eine Plattform". Denn sobald die Plattform die Isolation standardisiert, wird es möglich, sehr viele Kundeninstanzen zu betreiben, ohne dass das Team pro Instanz „hinterherläuft".

Internal Developer Platform: Standardisierte Bausteine statt Tool-Zoo

Parallel wurde eine Internal Developer Platform aufgebaut, die die operativen Grundlagen bereitstellt, die sonst in kleinen Teams oft fehlen – und die in VM-Welten typischerweise verteilt und uneinheitlich sind.

Entscheidend ist hier nicht die bloße Existenz von Tools, sondern die Tatsache, dass sie als zusammenhängende Plattform gedacht und betrieben werden. CI/CD, Registry, Secrets, Observability und IAM sind keine getrennten Projekte mehr, sondern Teil eines einheitlichen Lifecycle-Standards.

GitLab übernimmt Build und Pipeline-Standardisierung. Harbor sorgt für eine private Container Registry und ermöglicht Security- und Qualitätskontrollen, bevor etwas produktiv geht. Vault wird zur zentralen Quelle für Secrets und Konfiguration, statt dass Parameter in Skripten oder Umgebungsvariablen verstreut sind. Keycloak bringt ein konsistentes Identity- und Rollenmodell für interne Zugriffe. VictoriaMetrics, VictoriaLogs und Grafana liefern die Observability-Schicht, die im Betrieb den Unterschied zwischen „Kunden melden Probleme" und „wir sehen Probleme früh" ausmacht.

Damit entsteht ein Kernprinzip, das in wachstumsstarken Produktteams fast immer den Durchbruch bringt: Entwickler bauen Artefakte. Die Plattform betreibt sie.

Base-Image-Strategie: Ein Artefakt pro Version, Parameter pro Kunde

Ein typischer Fehler bei Multi-Tenant eCommerce ist, dass man zwar containerisiert, aber weiterhin pro Kunde eigene Images baut – und damit wieder Drift erzeugt, nur eben auf Image-Ebene. Unser Ansatz war deshalb eine konsequente Base-Image-Strategie.

Pro Software-Version existiert ein standardisiertes Container-Image. Kundenspezifische Unterschiede entstehen nicht durch Forks, sondern durch Parameter. Diese Parameter werden sauber als Konfiguration geführt und über Vault sowie definierte Environments injiziert. Damit bleibt die Softwarebasis identisch, während die Variabilität kontrolliert bleibt.

Das ist ein entscheidender Hebel für Betriebskosten: Wenn alle Kunden auf der gleichen Image-Version laufen, werden Updates zu einem steuerbaren Rollout statt zu 80 einzelnen Sonderfällen. Wenn ein Security-Fix notwendig ist, muss nicht jeder Kunde separat „aufgeholt" werden. Man rollt eine neue Version aus und parametrisiert weiter wie zuvor.

Der zweite Vorteil ist Debuggability. Wenn ein Problem auftritt, kann man es viel leichter reproduzieren, weil die Laufzeitbasis gleich ist. Und man kann konkrete Regressionen auf Versionen zurückführen, statt zu rätseln, ob „bei diesem Kunden irgendwas anders ist".

Automatisierung des Lifecycles: Von manuellen Deployments zu CI/CD als Standard

Sobald Container-Artefakte, Secrets und Observability standardisiert sind, wird der nächste Schritt möglich: Deployments werden nicht mehr „gemacht", sondern passieren als Ergebnis eines Prozesses.

CI/CD wurde zum Default. Jede Änderung läuft durch Pipeline-Stufen, wird geprüft, baut ein Image, veröffentlicht es in der Registry und rollt es in die Zielumgebung aus. Dadurch verschwindet die Abhängigkeit von einzelnen Entwicklern, die „das Skript kennen". Der Betrieb wird reproduzierbar, und Rollbacks werden zu einem sauberen Zustand, nicht zu einer improvisierten Aktion.

Das ist nicht nur Effizienz. Das ist Risiko-Management. Denn in eCommerce sind Release-Fenster und Verkaufsaktionen echte Business-Kritikalität. Ein Deployment-Prozess, der manuell ist, ist in solchen Kontexten strukturell zu fragil.

Standort- und Zertifizierungsanforderungen: Loopback Cloud-Broker als Skalierungshebel

Ein Wachstumstreiber – und gleichzeitig ein Bremser im alten Setup – waren Standortanforderungen und Compliance-Policies. Manche Kunden wollen spezifische Länder, bestimmte zertifizierte Provider oder definierte Infrastrukturvorgaben. In einem VM-basierten Modell führt das schnell zu Wildwuchs, weil jede neue Vorgabe eine neue Betriebsvariante erzwingt.

Hier hat der Loopback Cloud-Broker einen strategischen Vorteil gebracht: Cluster können dynamisch bei verschiedenen europäischen Cloud-Providern bereitgestellt werden, um Standort- oder Zertifizierungsanforderungen zu erfüllen, ohne dass das Produktteam für jede Region eine neue Betriebswelt bauen muss. Entscheidend ist dabei, dass der Lifecycle-Standard identisch bleibt. Der Ort ändert sich – nicht der Prozess.

Damit lässt sich aus einem eCommerce-Produkt ein echtes skalierbares Plattformangebot machen: gleiche Software, gleiche Delivery, unterschiedliche Betriebsorte nach Kundenanforderung – ohne dass jedes Mal neu erfunden werden muss, wie man deployt, überwacht und betreibt.

Ergebnis: schnelleres Provisioning, weniger Drift, mehr Fokus auf Produkt

Nach der Migration war die Veränderung vor allem im Tagesgeschäft spürbar.

Neue Kundeninstanzen können heute innerhalb weniger Stunden provisioniert werden – inklusive Monitoring, Logging und Alerting. Das ist ein massiver Unterschied zu einem VM-Modell, in dem Provisioning und Monitoring-Konfiguration häufig Tage dauern oder erst „nachgezogen" werden.

Config Drift ist nicht mehr der Normalzustand, weil Deployments aus standardisierten Artefakten und deklarativen Konfigurationen entstehen. Updates sind planbar, weil ein Release nicht mehr bedeutet, 80 Instanzen mit individuellen Skriptständen zu treffen, sondern eine Version mit Parametern sauber auszurollen.

Die Tenant-Isolation sorgt dafür, dass Kundenumgebungen sauber getrennt sind und Policies durchgesetzt werden können, ohne dass das Team in Sonderfällen erstickt. Und die Observability-Schicht verschiebt den Betrieb weg vom reaktiven Support hin zu proaktiver Wartung: Performance- und Stabilitätsprobleme werden erkennbar, bevor sie beim Endkunden eskalieren.

Das Wichtigste für ein Team ohne dediziertes DevOps: Entwicklerzeit fließt wieder in Features. Betrieb ist nicht verschwunden – aber er ist standardisiert und damit beherrschbar.

Damit kehrt auch die Business-Logik zurück: Lieferzeiten sinken, Margen stabilisieren sich, und die Organisation kann wachsen, ohne dass der operative Aufwand linear mitwächst.

Warum dieser Ansatz funktioniert: Multi-Tenancy ist ein Produkt, keine Hosting-Taktik

Der entscheidende Unterschied ist, dass Multi-Tenancy nicht als „wir packen mehrere Kunden auf ein Cluster" umgesetzt wurde, sondern als Plattformprinzip: Isolation, Standardisierung, Observability und Lifecycle-Automation sind nicht nachgelagert, sondern eingebaut.

Eine Internal Developer Platform ist dabei kein Luxus. Für kleine Teams ist sie die einzige realistische Möglichkeit, Plattformstandards zu etablieren, ohne ein DevOps-Team aufzubauen. Sie verlagert Komplexität weg von individuellen Skripten hin zu wiederverwendbaren Bausteinen – und macht Betrieb zu einer Eigenschaft, nicht zu einer Belastung.

Call to Action

Wenn ihr als eCommerce- oder SaaS-Anbieter merkt, dass VM-basierte Deployments eure Lieferfähigkeit bremsen, Support eskaliert und jeder Kunde „ein bisschen anders" ist, dann ist das kein Wachstumspech. Es ist ein Betriebsmodell, das nicht skaliert.

ayedo unterstützt Teams dabei, Kundenumgebungen auf Multi-Tenant Kubernetes-Plattformen zu konsolidieren, eine Internal Developer Platform aufzubauen und Standort- sowie Compliance-Anforderungen über mehrere europäische Provider hinweg beherrschbar zu machen – ohne dass ihr dafür ein eigenes DevOps-Team aufbauen müsst.

Wenn ihr eure Delivery wieder beschleunigen und gleichzeitig Betriebssicherheit erhöhen wollt, sprechen wir gern darüber, wie euer Zielbild aussehen kann.