Vom Software-Haus zum SaaS-Anbieter: Kubernetes als Plattform ohne eigenes DevOps

TL;DR

• Software-Haeuser koennen SaaS anbieten, ohne DevOps aufzubauen -- ein Managed Kubernetes Partner betreibt die Plattform, Sie liefern die Software
• Multi-Tenancy mit Namespace-Isolation trennt Kunden sicher voneinander, bei geteilter Infrastruktur und reduzierten Kosten pro Kunde
• CI/CD-Pipeline von Git bis Production in 6-8 Wochen statt 12-18 Monaten Eigenentwicklung
• Parallelbetrieb moeglich: Bestehende On-Premise-Kunden bleiben wie sie sind, SaaS wird als zusaetzlicher Vertriebskanal angeboten
• Break-even ab 8-12 SaaS-Kunden -- danach steigt die Marge mit jedem weiteren Kunden

Die Ausgangssituation: Warum Software-Haeuser unter Druck stehen

Sie haben ein erfolgreiches Software-Produkt. Ihre Kunden installieren es On-Premise, Ihr Support-Team betreut 50 bis 200 Installationen. Das Geschaeft laeuft. Aber drei Dinge aendern sich gerade gleichzeitig:

1. Kunden fordern SaaS. Neue Interessenten wollen keine eigene Server-Infrastruktur mehr betreiben. Im Evaluierungsprozess faellt Ihre Software raus, weil es keine Cloud-Option gibt.
2. Support-Kosten steigen. Jede On-Premise-Installation laeuft auf einer anderen Umgebung. Version 4.2 auf Windows Server 2016, Version 4.5 auf CentOS 8, Version 4.7 auf Ubuntu 22.04. Ihr Support kaempft mit Umgebungsproblemen statt mit echten Bugs.
3. Release-Zyklen sind zu lang. Ein Update auf 50 Kundeninstallationen zu verteilen dauert Wochen. Manche Kunden aktualisieren erst nach Monaten. Feature-Feedback kommt spaet, Bugfixes kommen spaeter.

Die Loesung: SaaS auf Basis von Managed Kubernetes. Sie kuemmern sich um Ihre Software, ein Partner kuemmert sich um die Plattform.

Architektur: Vom Monolithen zur SaaS-Plattform

Die drei Optionen fuer Multi-Tenancy

Nicht jedes Software-Produkt braucht die gleiche Isolationsstufe. Die Wahl haengt von Ihren Kunden und regulatorischen Anforderungen ab.

Fuer die meisten Software-Haeuser im Mittelstand ist Namespace per Kunde der beste Kompromiss: Echte Isolation auf Infrastruktur-Ebene bei vertretbaren Kosten.

Multi-Tenancy umsetzen: Namespace per Kunde

Kunden-Namespace mit Resource Quotas und Network Policies

# kunde-namespace-template.yaml
# Wird fuer jeden neuen SaaS-Kunden automatisch angelegt
apiVersion: v1
kind: Namespace
metadata:
  name: kunde-acme-gmbh
  labels:
    tenant: acme-gmbh
    tier: standard
    managed-by: platform
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: kunde-acme-gmbh
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    limits.cpu: "4"
    limits.memory: 8Gi
    persistentvolumeclaims: "5"
    services.loadbalancers: "0"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tenant-isolation
  namespace: kunde-acme-gmbh
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kunde-acme-gmbh
    - namespaceSelector:
        matchLabels:
          role: shared-services
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kunde-acme-gmbh
    - namespaceSelector:
        matchLabels:
          role: shared-services
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    ports:
    - protocol: TCP
      port: 443

Jeder Kunde bekommt seinen eigenen Namespace mit definierten Ressourcenlimits und strenger Netzwerktrennung. Kunden koennen nur mit ihren eigenen Pods und den Shared Services kommunizieren. Ausgehender Traffic ist auf HTTPS beschraenkt.

CI/CD: Vom Git-Commit zum Kunden-Deployment

Die Pipeline fuer Software-Haeuser

Der groesste Vorteil von SaaS gegenueber On-Premise: Sie deployen einmal, alle Kunden profitieren sofort. Kein Update-Marathon ueber Wochen.

# .github/workflows/saas-deploy.yaml (Beispiel mit GitHub Actions)
name: SaaS Deployment Pipeline
on:
  push:
    branches: [main]
    tags: ['v*']

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - name: Unit Tests ausfuehren
      run: ./gradlew test

    - name: Container-Image bauen
      run: |
        docker build -t registry.internal/ihre-software:${{ github.sha }} .
        docker push registry.internal/ihre-software:${{ github.sha }}

    - name: Security-Scan
      run: trivy image registry.internal/ihre-software:${{ github.sha }}

  deploy-staging:
    needs: build-and-test
    runs-on: ubuntu-latest
    steps:
    - name: Deploy auf Staging-Tenant
      run: |
        kubectl set image deployment/app \
          app=registry.internal/ihre-software:${{ github.sha }} \
          -n staging-tenant

    - name: Integration Tests
      run: ./scripts/integration-tests.sh

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
    - name: Rolling Update fuer alle Tenants
      run: |
        for ns in $(kubectl get ns -l managed-by=platform -o name); do
          kubectl set image deployment/app \
            app=registry.internal/ihre-software:${{ github.sha }} \
            -n "${ns##*/}" --record
        done

    - name: Rollout-Status pruefen
      run: |
        for ns in $(kubectl get ns -l managed-by=platform -o name); do
          kubectl rollout status deployment/app \
            -n "${ns##*/}" --timeout=300s
        done

Der Ablauf: Entwickler pushen Code, die Pipeline baut, testet, scannt und deployt. Erst auf Staging, dann auf alle Kunden-Namespaces. Ein fehlgeschlagener Rollout wird automatisch zurueckgerollt.

Vergleich: SaaS-Transformation mit und ohne Managed Platform

Break-even-Rechnung

Managed Platform:
├── Monatliche Kosten:               4.000 EUR
├── SaaS-Preis pro Kunde:              500 EUR/Monat
├── Break-even:                    8 Kunden
└── Marge ab Kunde 9:                  500 EUR/Monat pro Kunde

Eigenbetrieb:
├── Monatliche Kosten:              16.000 EUR
├── SaaS-Preis pro Kunde:              500 EUR/Monat
├── Break-even:                   32 Kunden
└── Marge ab Kunde 33:                 500 EUR/Monat pro Kunde

Differenz beim Start:
├── Managed: Ab Monat 3 profitabel (bei 10 Kunden)
└── Eigenbetrieb: Ab Monat 18 profitabel (bei 35 Kunden)

Die Managed-Variante ist nicht nur guenstiger, sie ist vor allem schneller profitabel. Und die eingesparten 12-15 Monate nutzen Ihre Entwickler fuer Features, die neue Kunden bringen.

Der Parallelbetrieb: On-Premise und SaaS gleichzeitig

Die meisten Software-Haeuser koennen und wollen nicht von heute auf morgen alle Kunden auf SaaS migrieren. Der Parallelbetrieb ist der realistische Weg.

So funktioniert es

Ihre Software-Architektur:
├── Core-Codebase (identisch fuer On-Premise und SaaS)
│   ├── Business-Logik
│   ├── API-Layer
│   └── Datenbank-Schema
│
├── On-Premise-Distribution
│   ├── Installer / MSI / DEB-Paket
│   ├── Kunden betreiben selbst
│   └── Support per Ticket und Remote
│
└── SaaS-Distribution
    ├── Container-Image (aus gleicher Codebase)
    ├── Kubernetes-Deployment (Managed)
    └── Kunden nutzen per Browser

Der Schluessel: Die Codebase bleibt eine. Das Container-Image wird aus dem gleichen Repository gebaut wie das On-Premise-Paket. Konfigurationsunterschiede werden ueber Umgebungsvariablen gesteuert, nicht ueber Code-Branches.

Kunden-Onboarding automatisieren

Ab 20 SaaS-Kunden wird manuelles Onboarding zum Flaschenhals. Automatisierung ist von Anfang an sinnvoll.

Was bei jedem neuen Kunden passiert

Neuer Kunde signiert Vertrag
        │
        ▼
Automatisches Provisioning:
├── 1. Namespace anlegen (mit Quotas und NetworkPolicies)
├── 2. Datenbank-Instanz erstellen
├── 3. Initiales Daten-Schema migrieren
├── 4. Application Deployment starten
├── 5. DNS-Eintrag setzen (kunde.ihre-software.de)
├── 6. TLS-Zertifikat ausstellen (Let's Encrypt)
├── 7. Monitoring und Alerting konfigurieren
└── 8. Willkommens-E-Mail mit Zugangsdaten senden

Dauer: 5-10 Minuten (vollautomatisch)

Vergleichen Sie das mit dem On-Premise-Onboarding: Installationshandbuch senden, Termin fuer Remote-Session vereinbaren, 2-4 Stunden gemeinsam installieren, 1-2 Wochen Nachfragen beantworten. Kosten pro Onboarding: 800 bis 2.000 EUR. Mit SaaS: nahe Null.

Sicherheit und Datentrennung

Software-Haeuser verkaufen an Unternehmen, die Datentrennung ernst nehmen. Ihre SaaS-Plattform muss das widerspiegeln.

Diese Massnahmen sind bei einer Managed Kubernetes Platform Standard. Sie muessen sie nicht selbst implementieren, aber Sie koennen Ihren Kunden gegenueber damit argumentieren.

Haeufige Einwaende und ehrliche Antworten

Unsere Software ist nicht containerisierbar

In 95% der Faelle stimmt das nicht. Wenn Ihre Software auf Linux laeuft und eine Datenbank verwendet, ist sie containerisierbar. Java-Applikationen, .NET-Anwendungen, Python-Services -- alles laeuft in Containern. Die Containerisierung dauert typischerweise 1-3 Wochen, nicht Monate.

Unsere Kunden akzeptieren keine Shared Infrastructure

Dann nutzen Sie die vCluster-Option: Jeder Kunde bekommt einen virtuellen Cluster, der sich wie ein dedizierter Cluster anfuehlt. Technisch laeuft alles auf der gleichen Infrastruktur, aber der Kunde hat seine eigene Kubernetes-API. Details dazu finden Sie im Artikel zu Multi-Tenancy in Kubernetes fuer deutsche Unternehmen.

Was passiert, wenn wir den Managed-Service-Anbieter wechseln wollen?

Kubernetes ist ein offener Standard. Ihre Deployments, Services und ConfigMaps laufen auf jedem Kubernetes-Cluster. Exit-Klauseln und portable Konfigurationen schuetzen Sie vor Abhaengigkeit. Mehr dazu unter Kubernetes Vendor Lock-in vermeiden: Cloud-Exit-Strategie.

Der Fahrplan: In 10 Wochen zum SaaS-Angebot

Woche 1-2:  Assessment
├── Software-Architektur analysieren
├── Multi-Tenancy-Modell waehlen
├── Kosten-Projektion erstellen
└── Go/No-Go-Entscheidung

Woche 3-4:  Containerisierung
├── Dockerfile erstellen und optimieren
├── CI-Pipeline fuer Image-Build aufsetzen
├── Lokale Tests mit Docker Compose
└── Security-Scan integrieren

Woche 5-6:  Plattform-Setup
├── Managed Kubernetes Cluster aufsetzen
├── Kunden-Namespace-Template definieren
├── CD-Pipeline nach Kubernetes aufsetzen
└── Monitoring und Alerting konfigurieren

Woche 7-8:  Pilot-Kunde
├── Ersten Kunden auf SaaS onboarden
├── Funktions- und Lasttests durchfuehren
├── Feedback einarbeiten
└── Dokumentation fuer Vertrieb erstellen

Woche 9-10: Go-Live
├── Weitere Kunden onboarden
├── On-Premise-Parallelbetrieb sicherstellen
├── SLA-Monitoring aktivieren
└── Vertrieb und Marketing starten

Weiterfuehrende Artikel

• Kubernetes Multi-Tenancy in Deutschland: DSGVO-konforme Loesung
• Kubernetes Kosten: Intern vs. Extern im Vergleich
• Kubernetes Managed Service vs. Inhouse: Der ehrliche Vergleich
• Kubernetes-Betrieb auslagern: Die komplette Checkliste
• Kubernetes Vendor Lock-in vermeiden: Cloud-Exit-Strategie