Von VM-Betrieb zu Plattform: Wie ayedo Planwerk zu skalierbarem, auditierbarem SaaS-Betrieb geführt hat

Viele SaaS-Plattformen wachsen so, wie sie gebaut werden: Schritt für Schritt, pragmatisch, „funktioniert erstmal". Das ist in der frühen Phase richtig. Doch irgendwann kippt es. Dann wird aus pragmatischer Infrastruktur ein Risiko – nicht, weil sie schlecht ist, sondern weil das Produkt ihr entwachsen ist.

Planwerk entwickelt eine Plattform für digitale Bauplanung und Projektsteuerung. Architekturbüros, Bauträger und öffentliche Auftraggeber planen damit kollaborativ, dokumentieren Entscheidungen, steuern Bauvorhaben. Rund 8.000 aktive Nutzer auf etwa 200 Kunden – von kleinen Büros bis zu kommunalen Bauämtern mit hunderten Nutzern. Zusätzlich gab es drei Enterprise-Kunden, die die Plattform aus regulatorischen Gründen in einer dedizierten On-Premise-Instanz betreiben.

Planwerk hatte ein erfolgreiches Produkt. Was fehlte, war ein Betriebssystem, das dem Produktwachstum standhält.

Ausgangslage: Ein VM-Setup, das für den Prototyp gut war – für das Produkt aber zu klein

Die Plattform lief bei einem europäischen Cloud-Anbieter auf sechs VMs: zwei Applikationsserver hinter einem Load Balancer, zwei Datenbankserver im Primary-Replica-Setup, ein Worker-Server für Hintergrundprozesse und ein Server für Dateispeicherung. Deployments, Konfiguration und Wartung wurden über Ansible und SSH erledigt.

Was für ein Team und ein paar Dutzend Kunden gut funktioniert, wird bei 200 Kunden plötzlich zur täglichen Betriebslast. Nicht wegen einer einzelnen Schwachstelle, sondern weil sich mehrere Probleme gegenseitig verstärken.

Montagmorgen – wenn hunderte Bauteams gleichzeitig die Wochenplanung aktualisieren – wurde die Plattform spürbar langsam. Es gab keine elastische Skalierung. Die einzige Reaktion war: größere VMs buchen. Das ist vertikale Skalierung als Reflex – teuer und träge. Und vor allem: Sie löst nicht den operativen Stress, weil Lastspitzen weiterhin zu dem führen, was man in SaaS vermeiden will: „wir müssen reagieren".

Deployments waren ein eigenes Ereignis. Rollout über beide App-Server, manuell, mit Zwischenprüfungen. Währenddessen gab es spürbare Einschränkungen von ein bis zwei Minuten. Bei Fehlern war Rollback Handarbeit – inklusive weiterer Downtime. Dadurch wurden Deployments künstlich auf wenige Abende pro Woche begrenzt. Ein Produkt, das eigentlich iterativ weiterentwickelt werden soll, wird so zwangsläufig langsamer.

Staging existierte zwar – aber als einzelne VM, die der Produktion nur grob ähnelte. Andere Maschinengröße, andere Netzwerkpfade, keine Replica-Datenbank. Fehler, die unter Last oder im Multi-Server-Betrieb auftreten, wurden auf Staging nicht sichtbar. Das verstärkte wiederum die Angst vor Deployments und verlängerte Releasezyklen.

Am kritischsten war das Thema Backups. Datenbank-Backups liefen als nächtlicher pg_dump auf denselben Storage wie die Datenbank. Ein Restore wurde in drei Jahren genau einmal getestet – und scheiterte, weil das Backup korrupt war. Für die Dateispeicherung gab es gar kein automatisiertes Backup. Das ist kein „technisches Detail", sondern ein existenzielles Risiko: In Audits zählt nicht, dass Backups laufen – sondern dass Restore nachweislich funktioniert.

Und schließlich die On-Premise-Kunden: drei separate Installationen, manuell gepflegt, mit eigenen Playbooks und eigenen Updatezyklen. Updates hinkten regelmäßig Wochen hinterher. Jeder On-Premise-Kunde band dauerhaft DevOps-Kapazität – und machte das Team defensiv: On-Premise war nicht Umsatzchance, sondern Belastung.

Der Wachstumshebel, der alles zuspitzte, war eine mögliche große kommunale Einkaufsgemeinschaft: potenziell 2.000 zusätzliche Nutzer in sechs Monaten. Das Engineering-Team wusste: Mit dem bestehenden Setup würde das nicht gehen – nicht ohne drastische Risiken.

ayedos Ansatz: Ein Betriebssystem bauen – nicht nur Infrastruktur austauschen

Wir sind nicht mit dem Ziel gestartet, „VMs durch Kubernetes zu ersetzen". Wir sind mit einem Plattformziel gestartet:

Planwerk brauchte ein einheitliches Betriebsmodell, das

• horizontal skaliert statt vertikal zu wachsen,
• Deployments ohne Downtime ermöglicht,
• Staging wirklich produktionsnah macht,
• Backup/Recovery nachweisbar macht,
• Disaster Recovery testbar und dokumentierbar macht,
• und Cloud wie On-Premise über denselben Prozess abbildet.

Die zentrale Entscheidung war deshalb: Managed Kubernetes als einheitliche Betriebsplattform – mit GitOps als Betriebsstandard.

Eine Plattform für Cloud und On-Premise: derselbe Prozess, anderer Standort

Der größte strukturelle Gewinn war die Vereinheitlichung. Bisher gab es zwei Welten: VM-basierte SaaS in der Cloud und separat gepflegte On-Premise-Installationen. Nach der Migration gibt es nur noch einen Prozess.

Die Anwendung läuft als Container-Workload – dieselben Images, dieselben Manifeste, dieselbe Konfigurationsstruktur. Ob sie in der ayedo Cloud oder im Cluster eines On-Premise-Kunden läuft, ist nur noch eine Standortfrage, keine Betriebsfrage.

Damit verschwindet der größte Kostenfresser im Alltag: „Sonderlösungen" für On-Premise. Updates werden nicht mehr individuell nachgezogen, sondern über denselben GitOps-Pfad ausgerollt – planbar und konsistent.

Skalierung und Verfügbarkeit: Lastspitzen werden Routine

Mit Horizontal Pod Autoscaling skaliert die Applikationsschicht automatisch basierend auf CPU-Auslastung und Request-Volumen. Die berüchtigten Montagmorgen-Spitzen sind damit kein Alarmzustand mehr, sondern ein normaler Zustand, den die Plattform abfedert – ohne Ticket, ohne manuelle VM-Vergrößerung, ohne „wir müssen dranbleiben".

Redis entkoppelt Sessions von einzelnen Applikationsinstanzen. Pods können neu gestartet oder skaliert werden, ohne Nutzer auszuloggen. RabbitMQ verlagert aufwendige Background-Jobs aus dem Request-Pfad heraus: PDF-Generierung, Mailversand, Exporte und Integrationen laufen asynchron. Das reduziert Latenzen und macht das System stabiler unter Last.

Deployments als Routine: GitOps statt SSH

ArgoCD wurde zur zentralen Ausroll-Engine. Deployments sind ein Git-Commit: Version im Manifest ändern, ArgoCD rollt aus – mit Rolling Updates, Health Checks und automatischen Rollbacks, wenn etwas schiefgeht.

Das ist nicht nur bequemer. Es ist ein kompletter Wechsel des Risikomodells: Ein Deployment ist kein Ereignis mit Downtime mehr, sondern eine Routine. Dadurch werden Releases entkoppelt von „Dienstag- und Donnerstagabend". Planwerk kann jederzeit deployen – im Zweifel auch mehrmals täglich – ohne Nutzerbeeinträchtigung.

GitLab CI/CD baut versionierte Images, führt Tests aus und aktualisiert die GitOps-Manifeste automatisiert. Damit ist der Weg von Commit zu Production nicht nur schnell, sondern nachvollziehbar und reproduzierbar.

Staging, das seinen Namen verdient: produktionsidentisch und belastbar

Ein häufig unterschätzter Punkt in solchen Migrationen ist Staging. Nicht „eine VM, die ungefähr passt", sondern eine Umgebung, die wirklich identisch ist.

Planwerks Staging läuft nun im selben Plattformmodell, mit identischer Konfiguration, identischer Datenbankstruktur und realistischen, anonymisierten Testdaten. Dadurch werden Fehler, die vorher erst im Multi-Server-Betrieb oder unter Last auftraten, bereits vor Production sichtbar. Preview-Environments pro Pull Request ergänzen das Setup für feature-spezifisches Testing.

Das nimmt Druck aus dem Prozess und bringt Geschwindigkeit zurück in die Entwicklung.

Backup, Restore, Disaster Recovery: aus Hoffnung wird Nachweis

Der größte Compliance-Hebel war die Professionalisierung von Backup und Recovery.

PostgreSQL läuft als Cluster mit automatischem Failover, kontinuierlicher WAL-Archivierung und täglichen Full-Backups auf georedundantem Storage. Point-in-Time Recovery ermöglicht die Wiederherstellung auf jede beliebige Sekunde innerhalb der Retention – ein entscheidender Unterschied zu „wir haben ein nächtliches Dump".

Wichtiger als das Backup selbst sind die automatisierten Restore-Tests. Planwerk testet Restores wöchentlich automatisiert, und die Ergebnisse werden protokolliert. Damit ist Backup-Funktionalität nicht mehr eine Annahme, sondern ein belegbarer Prozess – genau das, was öffentliche Auftraggeber in Ausschreibungen sehen wollen.

Velero ergänzt das Ganze auf Plattformebene: nicht nur Datenbanken, sondern Kubernetes-Ressourcen, Konfigurationen, Secrets und Volumes sind gesichert und wiederherstellbar. Damit ist Disaster Recovery nicht „wir bauen alles neu und spielen irgendwie Daten ein", sondern ein definierter, wiederholbarer Ablauf.

Auf dieser Basis haben wir ein DR-Konzept mit definierten RTO/RPO-Werten aufgebaut, dokumentiert und regelmäßig getestet. Die Recovery-Zeit sinkt damit von „mehrere Tage, wenn alles gut läuft" auf Stunden – und vor allem: sie ist nachweisbar.

Compliance als Nebenprodukt des Betriebs

Harbor bringt Vulnerability Scanning und SBOM-Generierung in den Standardprozess. Jedes Container-Image wird vor dem Deployment geprüft. Das ist nicht nur Security-Hygiene, sondern ein starker Compliance-Nachweis für öffentliche Auftraggeber.

Authentik sorgt für konsistente Zugriffskontrolle mit SSO und OIDC-Anbindung. VictoriaMetrics, VictoriaLogs und Grafana liefern Observability: Request-Latenzen, Fehlerraten, Plattform-Health, Datenbankmetriken – inklusive Alerting bei Anomalien.

Damit werden viele Fragen, die früher mühsam beantwortet wurden, zu Standardreports: Zugriff, Backup, Versionsstand, Schwachstellenlage, Betriebszustand.

Ergebnis: Skalierbar, auditierbar, und endlich einheitlich

Planwerk deployt heute ohne Downtime und nicht mehr nach Kalender, sondern nach Bedarf. Releases sind nicht mehr „ein Abendprojekt", sondern Routine.

Die Plattform skaliert horizontal und kann Wachstum aufnehmen, ohne dass das Team vor jedem neuen Kunden „Infrastruktur umbauen" muss. Der Rahmenvertrag mit der kommunalen Einkaufsgemeinschaft konnte unterzeichnet werden, weil die Plattform den Nutzerzuwachs technisch abfedern kann.

Backup und Recovery sind nicht nur implementiert, sondern getestet und dokumentiert. Disaster Recovery wurde von einem unklaren Risiko zu einem planbaren Prozess mit definiertem RTO.

Die On-Premise-Kunden sind kein Sonderfall mehr. Sie laufen auf demselben Deployment-Prozess wie die Cloud. Updates erreichen sie am selben Tag statt Wochen später. Der DevOps-Aufwand pro On-Premise-Kunde sinkt drastisch – und On-Premise wird wieder verkaufbar, statt intern abgewehrt zu werden.

Und nicht zuletzt: Compliance-Nachweise sind heute auf Knopfdruck möglich. Genau diese Nachweisfähigkeit war entscheidend, um öffentliche Ausschreibungen zu gewinnen, bei denen die Dokumentation den Unterschied macht.

Warum dieser Ansatz funktioniert

SaaS-Plattformen scheitern selten an Features. Sie scheitern an Betrieb, wenn Betrieb nicht mitwächst.

Der Wechsel von VM-Handbetrieb zu einer deklarativen Plattform mit GitOps, Auto-Scaling, tested Recovery und einheitlichem Cloud-/On-Premise-Betrieb macht aus „wir betreiben Software" ein echtes Betriebsmodell – reproduzierbar, auditierbar und skalierbar.

Call to Action

Wenn eure SaaS-Plattform noch über SSH und Playbooks betrieben wird, Deployments Downtime verursachen und Backups eher „gefühlt" als nachweislich funktionieren, ist das kein Einzelfall. Es ist der typische Übergangspunkt: vom Produkt, das läuft, zur Plattform, die wachsen muss.

ayedo migriert SaaS-Anwendungen auf Managed Kubernetes – inklusive GitOps, Auto-Scaling, produktionsidentischem Staging, Backup/PITR, Disaster Recovery und einem einheitlichen Modell für Cloud und On-Premise.

Wenn ihr vor ähnlichen Herausforderungen steht oder Wachstum aktuell aus Infrastrukturgründen bremst, lasst uns sprechen. Wir schauen uns gemeinsam an, wo euer größtes Betriebsrisiko liegt – und wie daraus ein skalierbarer, auditierbarer Plattformbetrieb wird.