Kubernetes ohne DevOps-Team: Wie 500-MA-Unternehmen Production-Cluster betreiben

TL;DR

• Kubernetes ohne dediziertes DevOps-Team zu betreiben ist moeglich -- wenn Sie die richtige Arbeitsteilung zwischen intern und extern aufsetzen.
• Sie brauchen intern genau eine Rolle: einen technischen Ansprechpartner, der Anforderungen formuliert und Ergebnisse abnimmt. Kein Cluster-Betrieb, kein On-Call.
• Ein Managed-Service-Partner uebernimmt den operativen Betrieb: Monitoring, Updates, Incident Response, Backup-Verifizierung und 24/7-Erreichbarkeit.
• Die Gesamtkosten liegen bei 4.000-6.000 EUR/Monat statt 25.000+ EUR/Monat fuer ein internes 3-Personen-Team.
• Entscheidend ist die klare Trennung: Applikationslogik bleibt intern, Plattformbetrieb geht nach aussen.

Warum Mittelstaendler kein DevOps-Team aufbauen sollten

Wenn ein 500-Mitarbeiter-Unternehmen beschliesst, Kubernetes einzusetzen, folgt fast immer derselbe Plan: "Wir stellen zwei DevOps-Engineers ein." Was dann passiert, ist vorhersehbar.

Die Stelle ist drei Monate offen. Der erste Kandidat will 95.000 EUR und Remote-only. Der zweite nimmt an, ist aber Junior und braucht sechs Monate Einarbeitung. Nach einem Jahr haben Sie einen halbwegs produktiven Admin, der alleine On-Call macht, und eine offene zweite Stelle.

Das ist kein schlechtes Recruiting. Das ist der Arbeitsmarkt fuer Kubernetes-Spezialisten in Deutschland. Und selbst wenn Sie beide Stellen besetzen, haben Sie immer noch kein 24/7-faehiges Team. Dafuer brauchen Sie mindestens vier Personen in Rotation.

Die ehrliche Frage lautet deshalb nicht "Wie bauen wir ein DevOps-Team auf?", sondern "Muessen wir das ueberhaupt?"

Warum der Aufbau eines internen Teams so teuer ist, zeigt unser Kostenvergleich intern vs. extern.

Das Betriebsmodell ohne DevOps-Team

Was intern bleibt

Auch ohne DevOps-Team brauchen Sie interne Kompetenz. Aber der Umfang ist wesentlich kleiner, als die meisten denken.

Interne Rolle: Technischer Ansprechpartner (kein DevOps-Engineer)

Profil:
├── IT-Leiter, Senior Developer oder Sys-Admin mit Interesse
├── Grundverstaendnis von Containern und Deployments
├── Kann Anforderungen an den Managed-Service formulieren
├── Kann Deployment-Ergebnisse validieren (Smoke Tests)
└── Muss KEINEN Cluster administrieren koennen

Zeitaufwand: 4-8 Stunden pro Woche
Gehalt: Bestehendes Personal, keine Neueinstellung

Minimale Skills:
├── kubectl get pods / kubectl logs (Basis-Befehle)
├── YAML-Grundlagen (Deployment Manifests lesen koennen)
├── Git-Workflow (Pull Request erstellen und mergen)
└── Kommunikation mit dem Managed-Service-Partner

Das ist der springende Punkt: Sie brauchen keinen Kubernetes-Experten. Sie brauchen jemanden, der die Bruecke zwischen Ihren Entwicklern und dem externen Betriebsteam bildet.

Was nach aussen geht

Der Managed-Service-Partner uebernimmt alles, wofuer Sie sonst 2-4 Vollzeit-Engineers brauchten:

Managed Service Scope (typisch):

Cluster-Betrieb:
├── Cluster-Setup und Architektur
├── Kubernetes-Version-Upgrades (3x pro Jahr)
├── Node-Management und Autoscaling
├── etcd-Wartung und -Backup
└── Security Patches und CVE-Response

Observability:
├── Monitoring-Stack (Prometheus, Grafana)
├── Alerting-Konfiguration
├── Log-Aggregation
└── Dashboards fuer Ihr Team

Incident Response:
├── 24/7-Erreichbarkeit
├── On-Call-Rotation (5-8 Engineers)
├── Eskalationsprozeduren
└── Post-Mortem-Dokumentation

Compliance und Security:
├── Network Policies
├── RBAC-Konfiguration
├── Image-Scanning
└── Audit-Logging

Dieser Ansatz funktioniert, weil der Managed-Service-Partner seine Kosten auf 10-20 Kunden verteilt. Ihr Cluster braucht vielleicht drei Stunden aktive Arbeit pro Woche -- aber 168 Stunden Erreichbarkeit. Genau das kann ein einzelnes Unternehmen nicht wirtschaftlich abbilden.

Welche 18 Komponenten dabei tatsaechlich betrieben werden muessen, beschreibt unser Kubernetes Komplexitaet Guide.

Die Arbeitsteilung im Detail

Die haeufigste Frage: "Was genau machen wir intern, was macht der Partner?" Diese Tabelle klaert das:

Die Faustregel: Alles, was applikationsnah ist, bleibt intern. Alles, was plattformnah ist, geht nach aussen.

Kosten: Managed Service vs. internes Team

Die Zahlen sprechen eine deutliche Sprache:

Szenario A: Internes DevOps-Team (Minimum fuer 24/7)

3 Senior DevOps Engineers:
├── 3x Gehalt + AG-Anteil (je 105.000 EUR):  315.000 EUR/Jahr
├── Recruiting (anteilig bei 3J Verweildauer):  25.000 EUR/Jahr
├── Schulungen und Zertifizierungen:            15.000 EUR/Jahr
├── Tools und Lizenzen:                         18.000 EUR/Jahr
├── On-Call-Zulagen:                            18.000 EUR/Jahr
└── Management-Overhead:                        20.000 EUR/Jahr
─────────────────────────────────────────────────────────────────
Jahreskosten:                                  411.000 EUR/Jahr
Monatskosten:                                  ~34.250 EUR/Monat


Szenario B: Managed Service + interner Ansprechpartner

├── Managed Service Fee (inkl. 24/7):           4.500 EUR/Monat
├── Interner Ansprechpartner (8h/Woche):        1.200 EUR/Monat
└── Onboarding (einmalig, auf 12M umgelegt):      500 EUR/Monat
─────────────────────────────────────────────────────────────────
Monatskosten:                                   6.200 EUR/Monat
Jahreskosten:                                  74.400 EUR/Jahr

Differenz: 336.600 EUR/Jahr

Bei diesen Zahlen geht es nicht darum, ob der Managed Service "gut genug" ist. Die Frage ist, ob ein 500-MA-Unternehmen 411.000 EUR pro Jahr fuer eine Funktion ausgeben kann, die nicht das Kerngeschaeft ist.

Mehr Details zu den versteckten Personalkosten finden Sie im Team-Aufbau-Kostenguide.

Minimale interne Kubernetes-Skills aufbauen

Auch ohne DevOps-Team sollten Ihre Entwickler grundlegende Kubernetes-Konzepte verstehen. Nicht um Cluster zu betreiben, sondern um effektiv mit dem Managed Service zusammenzuarbeiten.

Was jeder Entwickler wissen sollte

# deployment-basic.yaml
# Jeder Entwickler sollte dieses Manifest lesen und verstehen koennen
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: registry.example.com/web-app:v1.2.3
          ports:
            - containerPort: 8080
          resources:
            requests:
              memory: "128Mi"
              cpu: "100m"
            limits:
              memory: "256Mi"
              cpu: "200m"
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 15
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

Ihre Entwickler muessen dieses Manifest nicht von Grund auf schreiben koennen. Aber sie sollten verstehen, was replicas, resources und probes bedeuten -- weil das direkte Auswirkungen auf ihre Applikation hat.

Schulungsplan: 2 Tage statt 6 Monate

Nach zwei Tagen kann Ihr Entwicklerteam:

• Den Status einer Applikation im Cluster pruefen
• Logs lesen und grundlegende Fehler identifizieren
• Deployment-Manifests anpassen (Replicas, Image-Version, Resources)
• Ein Deployment ueber die CI/CD-Pipeline ausloesen

Alles darueber hinaus -- Networking, Security, Cluster-Administration -- bleibt beim Managed Service.

Die 5 haeufigsten Fehler beim Betrieb ohne DevOps-Team

Fehler 1: Den Managed Service als Black Box behandeln

Wenn Sie nicht verstehen, was der Partner macht, koennen Sie die Qualitaet nicht beurteilen. Fordern Sie monatliche Reports und vierteljahresweise Reviews ein.

Fehler 2: Keinen internen Ansprechpartner benennen

Ohne klare Ansprechperson auf Ihrer Seite verlaeuft die Kommunikation im Sand. Tickets bleiben liegen, Anforderungen kommen zu spaet, Abstimmung fehlt.

Fehler 3: Zugangskontrollen nicht regeln

Ihr Managed-Service-Partner braucht Zugang zu Ihrem Cluster. Aber geregelt: RBAC, Audit-Logging, kein permanenter Admin-Zugang. Definieren Sie das vor Vertragsschluss.

Fehler 4: Kein Exit-Plan

Was passiert, wenn der Managed Service nicht mehr funktioniert? Sie brauchen dokumentierte Prozesse, exportierbare Konfigurationen und die Sicherheit, wechseln zu koennen. Mehr dazu im Freelancer vs. Managed Service Vergleich.

Fehler 5: Vendor Lock-in durch proprietaere Tools

Achten Sie darauf, dass der Partner Standard-Tools einsetzt: Helm Charts statt proprietaerer Installer, Prometheus statt eigener Monitoring-Loesung, Vanilla Kubernetes statt stark angepasster Distributionen.

Checkliste: Managed-Service-Partner bewerten

Bevor Sie unterschreiben, pruefen Sie diese Punkte:

Managed Service Bewertungskriterien:

SLA und Verfuegbarkeit:
├── [ ] 24/7-Erreichbarkeit mit definierten Reaktionszeiten
├── [ ] SLA mit messbaren Kennzahlen (MTTR, Uptime)
├── [ ] Eskalationsprozeduren dokumentiert
└── [ ] Vertragsstrafen bei SLA-Verletzung

Team und Kompetenz:
├── [ ] Mindestens 3 Engineers mit CKA/CKS-Zertifizierung
├── [ ] Erfahrung mit Ihrem Cloud-Provider (AWS/Azure/GCP)
├── [ ] Referenzkunden in vergleichbarer Groesse
└── [ ] Deutschsprachiger Support

Prozesse:
├── [ ] Onboarding-Prozess dokumentiert
├── [ ] Change-Management-Prozess definiert
├── [ ] Monatliches Reporting Standard
├── [ ] Vierteljahresweise Reviews vereinbart

Sicherheit und Compliance:
├── [ ] DSGVO-Konformitaet nachgewiesen
├── [ ] Zugriffskontrolle und Audit-Logging
├── [ ] Verschluesselungsstandards definiert
└── [ ] Exit-Klausel mit Daten-Uebergabe

Wann dieses Modell NICHT funktioniert

Ehrlichkeit ist wichtig: Ein Managed Service ohne internes DevOps-Team ist nicht fuer jedes Unternehmen die richtige Loesung.

Fuer die meisten 300-1.000-MA-Unternehmen, die Kubernetes als Infrastruktur-Plattform nutzen (nicht als Produkt), ist das Modell ohne internes DevOps-Team die wirtschaftlichere und stabilere Loesung.

Was passiert, wenn Ihr einzelner Admin doch kuendigt, beschreibt der Notfallplan bei Team-Kuendigung.

Der Uebergangsplan: Von Null auf Managed Service

Wenn Sie heute noch kein Kubernetes nutzen oder den Betrieb umstellen wollen:

In drei Monaten von der Entscheidung zum produktiven Kubernetes-Betrieb -- ohne eine einzige DevOps-Stelle auszuschreiben.

Wie sich der 24/7-Betrieb im Mittelstand rechnet, zeigt unser 24/7-Betriebsguide.

Fazit

Ein 500-Mitarbeiter-Unternehmen braucht kein DevOps-Team, um Kubernetes produktiv zu betreiben. Es braucht einen klaren Plan, welche Kompetenzen intern bleiben und welche ein spezialisierter Partner uebernimmt.

Intern bleiben: Applikationsentwicklung, fachliche Anforderungen, ein technischer Ansprechpartner mit Basiswissen. Extern geht: Cluster-Betrieb, Monitoring, Incident Response, Updates und Compliance.

Die Kostenersparnis gegenueber einem internen Team ist erheblich. Aber der eigentliche Vorteil ist ein anderer: Sie konzentrieren Ihre begrenzten IT-Ressourcen auf das, was Umsatz bringt -- Ihre Applikationen. Nicht auf Infrastruktur-Betrieb.

Sie wollen wissen, wie der Betrieb ohne internes DevOps-Team konkret fuer Ihre Infrastruktur aussehen wuerde? In einem 30-minuetigen Gespraech zeigen wir Ihnen, was realistisch ist -- Termin vereinbaren.