Plattform
Multi-Tenant-PaaS
Eine Codebasis, viele Mandanten — jeder mit eigener Datenbank, eigenem Netzwerk und eigenen Backups.
| Art | Plattform |
|---|---|
| Beginn | |
| Beendet | |
| Technik | .NET, NestJS, PostgreSQL, Kubernetes, Terraform, ArgoCD, Traefik, Prometheus |
| Laufzeit | 16Monatebeendet |
Im Einzelnen
Die meisten Mandantenmodelle sparen genau dort, wo es später teuer wird: ein gemeinsames Schema, eine Mandanten-Spalte, und die Trennung hängt daran, dass jede einzelne Abfrage korrekt nach Mandant filtert. Ein vergessener Filter reicht, damit ein Kunde die Daten eines anderen sieht.
Hier bekam jeder Mandant eine eigene Datenbank, einen eigenen Connection Pool, eigene Backups an zwei getrennten Orten und eine Netzwerkregel, die den Zugriff zwischen Mandanten unterbindet. Die Trennung lag damit in der Infrastruktur, wo ein Programmierfehler sie nicht aufheben konnte.
Ein Dienst richtete neue Mandanten ein: Er erzeugte die komplette Umgebung, rollte sie aus und fuhr ungenutzte wieder herunter. Alles darunter — Cluster, Datenbank, Registry, DNS — kam vollständig aus Terraform.
Das Projekt wurde beendet, und mit ihm die Plattform. Bis dahin lief sie mit echten Mandanten in Produktion.
Das Logbuch zu diesem System.
- Betrieb
Mandantentrennung in die Infrastruktur verlegt: eigener Namespace, eigene Datenbank und eigene Netzwerkregel für jeden Mandanten.
- Betrieb
Ruhezustand für ungenutzte Mandanten automatisiert: herunterfahren und bei Bedarf wieder starten.
- Bau
Alle Mandanten auf dieselbe Kustomize-Basis mit Overlays je Mandant umgestellt, sodass ein Release überall gleich ablief.
- Betrieb
Cluster, Managed Database, Container-Registry und DNS vollständig über Terraform bereitgestellt.
- Bau
Beginn der Mandantenplattform: API-Gateway und erste Backend-Dienste.
Nächster Schritt
Wir sagen Ihnen vorab, was daran Zeit kostet.
Schildern Sie uns Ihr Vorhaben in ein paar Sätzen. Wir nennen Ihnen die zwei oder drei Stellen, an denen ein System dieser Art aufwendig wird.