- Authors

- Name
- Phillip Pham
- @ddppham
TL;DR
- ISVs brauchen kein eigenes DevOps-Team um SaaS anzubieten -- ein Managed Kubernetes Partner uebernimmt Betrieb, Security und Compliance
- Kosten pro Kunde sinken auf ca. 200 EUR/Monat (Managed) statt 925 EUR/Monat (Inhouse-Betrieb) bei 20 Kunden
- Von Idee bis erster Kunde live in 6-10 Wochen statt 12-18 Monaten bei Eigenentwicklung
- Multi-Tenancy-Optionen reichen von Namespace-per-Kunde bis Virtual Clusters (vCluster) fuer Enterprise-Kunden
- Parallelbetrieb moeglich: On-Premise-Kunden bleiben wie sie sind, SaaS wird als zusaetzliche Option angeboten
Kubernetes für ISVs: Der Weg zum SaaS ohne DevOps-Overhead
Sie sind Independent Software Vendor (ISV) und Ihre Kunden fragen nach einer SaaS-Version Ihrer Software? Dieser Guide zeigt, wie Sie Kubernetes nutzen, ohne selbst Infrastruktur-Experten zu werden.
Das ISV-Dilemma: Produkt vs. Plattform
Die Ausgangssituation
Sie haben:
├── Ein erfolgreiches Software-Produkt
├── Kunden, die On-Premise installieren
├── Entwickler, die Features bauen
└── Anfragen: "Gibt's das auch als SaaS?"
Sie brauchen (scheinbar):
├── DevOps-Team (2-3 Personen)
├── Kubernetes-Expertise
├── 24/7-Betrieb
├── Security & Compliance
└── Multi-Tenant-Architektur
Das Problem: Ihre Entwickler sollen Features bauen, nicht Infrastruktur betreiben.
Die typische Falle
"Wir bauen das selbst!"
↓
6 Monate später:
├── 2 DevOps eingestellt (140k€/Jahr)
├── Kubernetes-Cluster läuft (irgendwie)
├── Monitoring? "Machen wir noch"
├── Security? "Steht auf der Liste"
├── 0 neue Features released
└── CTO: "Warum dauert das SaaS so lange?"
Der smarte Weg: Managed Kubernetes für ISVs
Was Sie wirklich brauchen
| Komponente | Selbst machen | Partner |
|---|---|---|
| Ihre Software | Sie entwickeln | - |
| Container-Packaging | Sie definieren | Support |
| Kubernetes-Cluster | - | Managed |
| Monitoring & Alerting | - | Managed |
| Security & Compliance | - | Managed |
| Backup & DR | - | Managed |
| 24/7 Operations | - | Managed |
Das Ergebnis
Ihr Team fokussiert auf:
├── Neue Features entwickeln
├── Kunden-Feedback umsetzen
├── Produkt-Roadmap vorantreiben
└── Wettbewerbsvorteile schaffen
Der Partner kümmert sich um:
├── Infrastruktur-Betrieb
├── Verfügbarkeit (99.9%+)
├── Security-Updates
├── Compliance-Nachweise
└── Nachts-um-3-Uhr-Probleme
Typische ISV-Szenarien
Szenario 1: B2B Software wird SaaS
Ausgangslage:
- ERP-Addon oder Branchen-Software
- 50+ On-Premise-Kunden
- Kunden fordern Cloud-Option
Lösung:
┌─────────────────────────────────────────────────┐
│ Managed Kubernetes Platform │
├─────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │Kunde A │ │Kunde B │ │Kunde C │ │
│ │Namespace│ │Namespace│ │Namespace│ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Shared Services │ │
│ │ Ingress │ Monitoring │ Logging │ Auth │ │
│ └─────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────┘
Vorteile:
- Jeder Kunde in eigenem Namespace (Isolation)
- Shared Infrastructure (Kosteneffizienz)
- Zentrale Updates für alle Kunden
- Compliance durch Plattform-Standard
Szenario 2: Startup mit Product-Market-Fit
Ausgangslage:
- SaaS-Produkt mit ersten zahlenden Kunden
- 5-10 Entwickler, kein DevOps
- Wachstum erfordert Skalierung
Lösung:
Monat 1-3: Pilot-Phase
├── Managed Cluster Setup
├── CI/CD Pipeline (Sie commiten, wir deployen)
├── Monitoring Dashboard
└── Kosten: ~2.500€/Monat
Monat 4-12: Wachstums-Phase
├── Auto-Scaling für Traffic-Spitzen
├── Multi-Region (optional)
├── Disaster Recovery
└── Kosten: 4.000-6.000€/Monat (je nach Last)
Szenario 3: Enterprise ISV mit Compliance-Anforderungen
Ausgangslage:
- Software für regulierte Branchen (Finanz, Pharma, Gesundheit)
- Kunden fordern: ISO 27001, SOC2, DSGVO
- Audits mehrmals jährlich
Lösung:
Compliance-as-a-Service:
├── DSGVO-konforme Infrastruktur (DE-Rechenzentren)
├── Audit-Logs für alle Zugriffe
├── Verschlüsselung at-rest und in-transit
├── Penetration Tests (jährlich)
├── ISO 27001 / BSI-Grundschutz aligned
└── Audit-Support (wir beantworten Ihre Kundenfragen)
Die technische Umsetzung
Was Sie liefern
# Ihr Dockerfile (Beispiel)
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
# Ihre Deployment-Definition (vereinfacht)
apiVersion: apps/v1
kind: Deployment
metadata:
name: meine-software
spec:
replicas: 3
template:
spec:
containers:
- name: app
image: registry.example.com/meine-software:v2.3.1
resources:
requests:
memory: "256Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
Was der Partner bereitstellt
# Managed Platform liefert automatisch:
# Ingress mit TLS
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
tls:
- hosts: ["app.example.com"]
secretName: app-tls
# Monitoring (vorkonfiguriert)
# → Prometheus scrapet automatisch
# → Grafana-Dashboards ready
# → Alerting nach Best Practices
# Backup (täglich automatisch)
# → Velero Snapshots
# → Offsite-Kopie
# → Getestete Recovery-Prozeduren
# Security (continuous)
# → Image Scanning bei jedem Push
# → Runtime Security mit Falco
# → Network Policies (Isolation)
Multi-Tenancy für ISVs
Option 1: Namespace per Kunde
Cluster
├── namespace: customer-acme
│ └── Deployment: meine-software (Acme Config)
├── namespace: customer-globex
│ └── Deployment: meine-software (Globex Config)
└── namespace: customer-initech
└── Deployment: meine-software (Initech Config)
Vorteile: Einfach, gute Isolation Nachteile: Overhead bei 100+ Kunden
Option 2: Shared Deployment, Tenant per Config
# Ein Deployment, viele Tenants
env:
- name: TENANT_ID
valueFrom:
fieldRef:
fieldPath: metadata.annotations['tenant']
Vorteile: Kosteneffizient, einfache Updates Nachteile: Weniger Isolation, Noisy Neighbor möglich
Option 3: Virtual Clusters (vCluster)
Physical Cluster
├── vcluster: customer-enterprise-a (volle K8s API)
├── vcluster: customer-enterprise-b (volle K8s API)
└── shared: customer-smb-* (Namespace-basiert)
Vorteile: Enterprise-Kunden bekommen "eigenen" Cluster Nachteile: Komplexer, höhere Kosten
Kosten-Kalkulation für ISVs
Beispiel: B2B SaaS mit 20 Kunden
Managed Kubernetes Platform:
├── Base Platform: 2.500€/Monat
├── 20 Kunden-Namespaces: 500€/Monat
├── Monitoring & Logging: 300€/Monat
├── Backup & DR: 200€/Monat
└── Support (Business Hours): 500€/Monat
────────────────────────────────────────────────
GESAMT: 4.000€/Monat
Pro Kunde: 200€/Monat
Vergleich: Selbst betreiben
Inhouse-Betrieb für 20 Kunden:
├── 1.5 DevOps FTE: 9.000€/Monat
├── Cloud-Infrastruktur: 3.000€/Monat
├── Tools & Lizenzen: 500€/Monat
├── Ausfallrisiko (kalkuliert): 1.000€/Monat
└── Opportunitätskosten (Features): 5.000€/Monat
────────────────────────────────────────────────
GESAMT: 18.500€/Monat
Pro Kunde: 925€/Monat
Ersparnis mit Managed: 78%
Der Onboarding-Prozess für ISVs
Phase 1: Assessment (1 Woche)
├── Ihre Software verstehen
│ └── Architektur, Dependencies, State
├── Anforderungen definieren
│ └── Verfügbarkeit, Compliance, Scale
├── Multi-Tenancy-Strategie wählen
└── Kosten-Projektion erstellen
Phase 2: Containerisierung (1-2 Wochen)
├── Dockerfile optimieren
├── Helm Chart erstellen
├── CI/CD Pipeline aufsetzen
│ └── Sie commiten → Auto-Build → Auto-Deploy (Staging)
└── Lokale Entwicklung mit K8s einrichten
Phase 3: Plattform-Setup (1-2 Wochen)
├── Production-Cluster provisionieren
├── Monitoring & Alerting konfigurieren
├── Backup-Strategie implementieren
├── Security-Baseline etablieren
└── Dokumentation erstellen
Phase 4: Pilot (2-4 Wochen)
├── Ersten Kunden onboarden
├── Monitoring validieren
├── Performance-Tuning
├── Runbooks vervollständigen
└── Go-Live für weitere Kunden
Gesamtdauer: 6-10 Wochen von "Wir wollen SaaS" bis "Erster Kunde live"
Häufige Fragen von ISVs
"Unsere Software ist komplex - geht das überhaupt?"
Ja. Wir haben komplexe Architekturen containerisiert:
- Monolithen mit 50+ Microservices
- Legacy-Java-Anwendungen
- Software mit speziellen Hardware-Anforderungen (GPU)
- Multi-Datenbank-Setups
"Was ist mit unseren On-Premise-Kunden?"
Parallelbetrieb ist möglich:
- On-Premise bleibt wie es ist
- SaaS als zusätzliche Option
- Hybrid-Kunden (teilweise Cloud, teilweise On-Prem)
"Können unsere Entwickler weiter lokal entwickeln?"
Ja, und besser:
# Entwickler-Workflow
git commit -m "Feature XYZ"
git push origin feature/xyz
# Automatisch:
# 1. CI baut Container
# 2. Tests laufen
# 3. Preview-Environment wird erstellt
# 4. Link zum Testen im PR
"Was wenn ein Kunde eigene Infrastruktur will?"
Möglich:
- Helm Chart für Self-Hosting anbieten
- Oder: Dedicated Cluster für Enterprise-Kunden
- Managed Service auch für Kunden-eigene Cloud-Accounts
Warum mit einem Kubernetes-Partner arbeiten?
Sie gewinnen Zeit
Ohne Partner:
└── 12-18 Monate bis Production-ready SaaS
Mit Partner:
└── 6-10 Wochen bis erster Kunde live
Sie sparen Geld
Ohne Partner (Jahr 1):
├── 2 DevOps einstellen: 140.000€
├── Lernen & Fehler: 50.000€
├── Tools & Lizenzen: 15.000€
└── GESAMT: 205.000€
Mit Partner (Jahr 1):
├── Managed Service: 48.000€
├── Onboarding: 15.000€
└── GESAMT: 63.000€
Sie reduzieren Risiko
- Kein Single-Point-of-Failure (DevOps kündigt)
- Erprobte Prozesse statt Trial-and-Error
- 24/7 Support statt Nachts-Panik
- Compliance von Tag 1
Next Steps für ISVs
1. Kostenlose Architektur-Bewertung
Wir schauen uns Ihre Software an und zeigen:
- Wie die Container-Architektur aussehen würde
- Welche Multi-Tenancy-Strategie passt
- Was die monatlichen Kosten wären
2. Proof of Concept (4 Wochen)
- Ihre Software auf unserer Plattform
- Erster Test-Kunde onboarden
- Reale Erfahrung vor Commitment
3. Production Onboarding
- Schrittweise Migration
- Ihre Entwickler werden geschult
- Langfristige Partnerschaft statt Vendor-Lock-in
Fazit für ISVs
SaaS anbieten bedeutet nicht, DevOps aufbauen.
Ihre Kernkompetenz ist Ihre Software - nicht Kubernetes-Betrieb. Ein Managed-Service-Partner:
- Beschleunigt Ihren SaaS-Launch um 12+ Monate
- Spart 50-70% gegenüber Inhouse-DevOps
- Gibt Ihren Entwicklern Zeit für Features
- Liefert Enterprise-Grade Plattform vom ersten Tag
Ihr Code. Unsere Plattform. Ihr Erfolg.
Weiterführende Artikel:
- Kubernetes Managed Service vs. Inhouse: Der ehrliche Kostenvergleich
- Kubernetes Kosten: Intern vs. Extern im Vergleich
- Multi-Tenancy in Kubernetes für deutsche Unternehmen
- Kubernetes Vendor Lock-in vermeiden: Cloud-Exit-Strategie
- Kubernetes Compliance ohne Security-Team umsetzen
Dieser Guide basiert auf unserer Erfahrung mit 20+ ISV-Kunden, die von On-Premise zu SaaS migriert sind.
Kubernetes-Beratung gesucht?
Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.
📖 Verwandte Artikel
Weitere interessante Beiträge zu ähnlichen Themen
SaaS-Anbieter werden mit Kubernetes ohne Ops-Team
Wie Software-Hersteller mit Managed Kubernetes zum SaaS-Anbieter werden, ohne ein eigenes DevOps-Team aufbauen zu müssen.
SaaS skalieren mit Managed Kubernetes ohne Ops
SaaS-Anbieter skalieren mit Managed Kubernetes von 10 auf 1.000 Kunden und senken die Cost-per-Customer auf unter 25 EUR pro Monat.
Software-Haus zu SaaS: Kubernetes ohne DevOps-Team
Wie Software-Häuser ihr On-Premise-Produkt mit Managed Kubernetes zu SaaS transformieren, inklusive Multi-Tenancy und CI/CD-Pipeline.
Kubernetes Omnichannel-Backend für den Einzelhandel
Omnichannel-Backend mit Kubernetes: POS, E-Commerce und Filiale auf einer Plattform synchronisieren, inklusive Managed-Service-Empfehlung für den Mittelstand.
Kubernetes Freelancer vs Managed Service: Kostenvergleich
Kubernetes Freelancer vs Managed Service ehrlich verglichen: Versteckte Kosten, Wissenssilo-Risiko, fehlende SLAs und Break-Even-Analyse für den Mittelstand.