- Authors
- Name
- Phillip Pham
- @ddppham
Freelancer-Falle: Warum 1.200 EUR Tagessatz teurer ist als 4.000 EUR Managed Service
Sie suchen einen Kubernetes-Experten und finden auf Freelancer-Portalen Profile mit 1.200 EUR Tagessatz. Klingt nach einem guten Deal im Vergleich zu 4.000 EUR monatlich fuer einen Managed Service. Aber die Rechnung geht nicht auf.
Dieser Artikel zeigt, warum die Entscheidung Kubernetes Freelancer vs Managed Service mehr Variablen hat als nur den Tagessatz - und warum der vermeintlich guenstigere Weg oft der teurere ist.
TL;DR
- Ein Freelancer mit 1.200 EUR/Tag kostet bei 10 Tagen/Monat bereits 12.000 EUR - dreimal so viel wie ein Managed Service
- Freelancer erzeugen Wissenssilos: Wenn der Freelancer geht, geht das Know-how mit
- Ohne SLA gibt es keine garantierte Reaktionszeit bei Production-Ausfaellen
- Ein Managed Service liefert Team-Redundanz, 24/7 Erreichbarkeit und dokumentierte Prozesse
- Die Break-Even-Analyse zeigt: Ab 5 Tagen/Monat Bedarf ist der Managed Service guenstiger
Die ehrliche Kostenrechnung
Was der Freelancer wirklich kostet
Kubernetes Freelancer - Monatliche Kosten:
Szenario A: Minimalbetrieb (8 Tage/Monat)
├── 8 Tage x 1.200 EUR: 9.600 EUR
├── Reisekosten (4x vor Ort): 800 EUR
├── Projektmanagement intern (8h): 1.200 EUR
└── Wissensdokumentation: 0 EUR (macht keiner)
──────────────────────────────────────────────────
GESAMT: 11.600 EUR/Monat
Szenario B: Realistischer Betrieb (12 Tage/Monat)
├── 12 Tage x 1.200 EUR: 14.400 EUR
├── Reisekosten (4x vor Ort): 800 EUR
├── Projektmanagement intern (12h): 1.800 EUR
└── Wissensdokumentation: 0 EUR
──────────────────────────────────────────────────
GESAMT: 17.000 EUR/Monat
Was der Managed Service kostet
Managed Service - Monatliche Kosten:
├── Service Fee (inkl. 24/7): 4.000 EUR
├── Interner Ansprechpartner (10%): 800 EUR
└── Onboarding (einmalig, auf 12M): 500 EUR
──────────────────────────────────────────────────
GESAMT: 5.300 EUR/Monat
Direktvergleich auf 12 Monate
| Kostenfaktor | Freelancer (8 Tage/M) | Managed Service |
|---|---|---|
| Monatliche Kosten | 11.600 EUR | 5.300 EUR |
| Jahreskosten | 139.200 EUR | 63.600 EUR |
| 24/7 Verfuegbarkeit | Nein | Ja |
| SLA mit Vertragsstrafe | Nein | Ja |
| Team-Redundanz | Nein | Ja (3-5 Engineers) |
| Dokumentation | Vielleicht | Standard-Prozess |
| Jahresersparnis | Referenz | 75.600 EUR |
Die 5 versteckten Risiken beim Freelancer-Modell
1. Das Wissenssilo-Problem
Der Freelancer kennt Ihren Cluster. Er weiss, warum der Ingress so konfiguriert ist. Er weiss, welcher CronJob jeden Dienstag um 4 Uhr laufen muss. Aber dieses Wissen ist in seinem Kopf - nicht in Ihren Systemen.
# Was passiert, wenn der Freelancer kuendigt:
# Tag 1: Freelancer informiert ueber Kuendigung
kubectl get deployments -A
# Sie sehen 47 Deployments. Wer weiss, was jedes einzelne tut?
# Tag 14: Freelancer ist weg. Alert kommt rein:
# CRITICAL: Pod crash-loop in namespace payment-processing
kubectl logs payment-processor-7d8f9b6c4-x2k9m -n payment-processing
# Error: connection refused to custom-auth-sidecar:8443
# Wer weiss, was der custom-auth-sidecar macht?
# Wer weiss, warum Port 8443 statt 443?
# Wer hat die Doku? Niemand.
In der Praxis sehen wir dieses Muster bei etwa 7 von 10 Freelancer-Engagements: Kein Runbook, keine Architektur-Dokumentation, keine Uebergabe-Checkliste.
2. Keine SLA - kein Netz
Ein Freelancer hat keinen Vertrag mit garantierten Reaktionszeiten. Wenn Ihr Production-Cluster Freitag um 22 Uhr ausfaellt, rufen Sie an - und hoffen.
| Situation | Freelancer | Managed Service |
|---|---|---|
| Freitag 22:00, Cluster down | Mailbox. Vielleicht Rueckruf Montag | Reaktion in 15 Min (SLA) |
| Samstag, Security Incident | Nicht erreichbar | Incident Response Team |
| Urlaub des Freelancers | 4-6 Wochen kein Support | Team-Rotation, kein Ausfall |
| Freelancer krank | Unplanbar, kein Backup | Automatische Vertretung |
3. Der Bus-Faktor
Der Bus-Faktor beschreibt, wie viele Personen ausfallen koennen, bevor ein Projekt zum Stillstand kommt. Bei einem Freelancer ist der Bus-Faktor exakt 1.
Bus-Faktor Vergleich:
Freelancer: [X] ← 1 Person = 1 Single Point of Failure
└── Krankheit, Kuendigung, Urlaub = Totalausfall
Managed Service: [E1] [E2] [E3] [E4] [E5]
└── 5 Engineers in Rotation
└── Jeder kennt Ihre Infrastruktur
└── Ausfall eines Engineers = 0 Impact
4. Fehlende Breite im Stack
Ein Freelancer ist oft Spezialist fuer einen Bereich. Kubernetes-Betrieb erfordert aber Expertise in mindestens 8 Disziplinen gleichzeitig.
| Kompetenzbereich | Typischer Freelancer | Managed Service Team |
|---|---|---|
| Kubernetes Core | Ja | Ja |
| Networking (CNI, Ingress, DNS) | Teilweise | Netzwerk-Spezialist |
| Security (Scanning, Policies) | Grundlagen | Security Engineer |
| Monitoring (Prometheus, Grafana) | Ja | Observability-Spezialist |
| Backup & Disaster Recovery | Selten | Standard-Prozess |
| CI/CD Integration | Ja | Ja |
| Compliance (DSGVO, BSI) | Nein | Compliance-Beratung |
| Cost Optimization | Selten | FinOps-Expertise |
5. Skalierung unmoeglich
Ihr Unternehmen waechst. Sie brauchen einen zweiten Cluster, eine Staging-Umgebung, Multi-Region. Der Freelancer arbeitet bereits 12 Tage im Monat fuer Sie. Was nun? Einen zweiten Freelancer suchen? Dann haben Sie zwei Wissenssilos statt einem.
Der Entscheidungsrahmen
Wann ein Freelancer Sinn macht
Es gibt Szenarien, in denen ein Freelancer die bessere Wahl ist:
- Einmaliges Projekt: Migration zu Kubernetes, Cluster-Aufbau, Architektur-Review
- Weniger als 3 Tage/Monat Bedarf: Gelegentliche Beratung oder Code-Review
- Ueberbrueckung: Bis ein Managed Service oder internes Team aufgebaut ist
- Spezialwissen: GPU-Cluster, ML-Pipelines, sehr nischige Anforderungen
Wann ein Managed Service die bessere Wahl ist
- Laufender Betrieb von Production-Clustern
- 24/7 Verfuegbarkeit erforderlich
- Mehr als 5 Tage/Monat an Kubernetes-Arbeit
- Kein internes Kubernetes-Team vorhanden
- Compliance-Anforderungen (DSGVO, BSI, ISO 27001)
- Risikominimierung durch SLAs und Team-Redundanz
Die Break-Even-Analyse
Kosten pro Monat nach Bedarf:
Tage/Monat | Freelancer | Managed Service | Guenstiger
──────────────────────────────────────────────────────────
2 Tage | 2.400 EUR | 5.300 EUR | Freelancer
4 Tage | 4.800 EUR | 5.300 EUR | Freelancer
5 Tage | 6.000 EUR | 5.300 EUR | Managed Service
8 Tage | 9.600 EUR | 5.300 EUR | Managed Service
12 Tage | 14.400 EUR | 5.300 EUR | Managed Service
15 Tage | 18.000 EUR | 5.300 EUR | Managed Service
Break-Even: ~4,5 Tage pro Monat
Hinweis: Managed Service inkl. 24/7, SLA, Team.
Freelancer: Nur Tagessatz, ohne SLA, ohne 24/7.
Ab 5 Tagen monatlichem Bedarf ist der Managed Service nicht nur guenstiger, sondern liefert auch erheblich mehr Leistung durch Team-Redundanz und SLA-Garantien.
Checkliste: Freelancer richtig einsetzen
Falls Sie sich trotzdem fuer einen Freelancer entscheiden, minimieren Sie die Risiken:
# freelancer-onboarding-checklist.yaml
# Dokumentationsanforderungen an jeden Freelancer
documentation_requirements:
architecture:
- cluster_topology_diagram
- network_architecture
- component_dependencies
runbooks:
- deployment_procedures
- rollback_procedures
- incident_response_steps
- backup_restore_procedures
handover:
- access_credentials_in_vault
- monitoring_dashboard_links
- alerting_rules_explanation
- known_issues_and_workarounds
review_cadence:
weekly: "Code Review aller Aenderungen"
monthly: "Architektur-Review mit internem Team"
quarterly: "Wissenstransfer-Session (aufgezeichnet)"
exit_strategy:
notice_period: "mindestens 4 Wochen"
handover_document: "vollstaendiges Runbook"
knowledge_transfer: "2 Tage mit Nachfolger"
access_revocation: "sofort nach letztem Tag"
Vertragsklauseln die Sie brauchen
| Klausel | Warum wichtig |
|---|---|
| Dokumentationspflicht | Runbooks muessen bei Projektende vollstaendig sein |
| IP-Rechte | Alle Skripte und Configs gehoeren Ihrem Unternehmen |
| Uebergabepflicht | 2+ Tage Wissenstransfer bei Vertragsende |
| Haftung | Mindestens fuer grobe Fahrlaessigkeit |
| Kuendigungsfrist | Mindestens 4 Wochen, besser 8 |
Hybridmodell: Das Beste aus beiden Welten
Fuer manche Unternehmen funktioniert ein Hybridansatz:
Hybridmodell:
Managed Service (Basis): 4.000 EUR/Monat
├── 24/7 Monitoring & Alerting
├── Incident Response
├── Security Patches & Updates
├── Backup & Disaster Recovery
└── Monatliches Reporting
Freelancer (Projekte): nach Bedarf
├── Neue Feature-Entwicklung
├── Grosse Migrationen
├── Spezial-Integrationen
└── Architektur-Workshops
Vorteil: Betrieb ist gesichert,
Freelancer bringt Projekt-Expertise ein.
Dieses Modell funktioniert gut, wenn Sie einen stabilen Betrieb durch den Managed Service sicherstellen und gezielt Freelancer fuer abgegrenzte Projekte einsetzen.
Praxis-Szenario: Was passiert bei einem Ausfall
Stellen Sie sich vor: Donnerstag, 23:15 Uhr. Ihr Online-Shop ist down. Kubernetes meldet: Node NotReady, 12 Pods in CrashLoopBackOff.
# Das Alert kommt rein:
kubectl get nodes
# NAME STATUS ROLES AGE VERSION
# worker-01 NotReady <none> 180d v1.29.2
# worker-02 Ready <none> 180d v1.29.2
# worker-03 NotReady <none> 180d v1.29.2
kubectl get pods -A | grep -v Running
# NAMESPACE NAME STATUS
# shop checkout-6f8d9c7b5-abc12 CrashLoopBackOff
# shop product-api-8b4e5d2f1-def34 CrashLoopBackOff
# payment stripe-gw-3a7c9e8d6-ghi56 CrashLoopBackOff
# ...12 weitere Pods
Ablauf mit Freelancer
23:15 Alert kommt
23:16 Sie rufen den Freelancer an → Mailbox
23:20 SMS geschickt → keine Antwort
23:45 Freelancer ruft zurueck: "Bin auf einer Feier, kann gerade nicht"
00:30 Freelancer schaut remote drauf: "Hmm, das ist komisch"
01:15 Freelancer findet das Problem: etcd disk full
01:45 Problem geloest
──────────────────────────────────────────────────
Downtime: 2,5 Stunden
Umsatzverlust (bei 50.000 EUR/Tag Online-Umsatz): ~5.200 EUR
Ablauf mit Managed Service
23:15 Alert kommt → automatisch an On-Call-Engineer
23:16 Engineer bestaetigt Incident, beginnt Diagnose
23:22 Root Cause identifiziert: etcd disk full
23:28 Fix deployed, Pods starten
23:35 Alle Services wieder healthy, Incident Report gestartet
──────────────────────────────────────────────────
Downtime: 20 Minuten
Umsatzverlust: ~700 EUR
SLA-Reaktionszeit eingehalten: Ja (15 Min garantiert)
Differenz eines einzigen Vorfalls: 4.500 EUR - mehr als die monatliche Managed-Service-Gebuehr.
Fazit
Die Entscheidung Kubernetes Freelancer vs Managed Service ist keine Frage des Tagessatzes. Es ist eine Frage der Gesamtkosten, der Risiken und der Zuverlaessigkeit.
Fuer den laufenden Betrieb von Production-Clustern im Mittelstand ist der Managed Service in den allermeisten Faellen die wirtschaftlichere und sicherere Wahl. Freelancer haben ihre Berechtigung - aber fuer abgegrenzte Projekte, nicht fuer den 24/7-Betrieb.
Die Frage ist nicht, was der Tagessatz kostet. Die Frage ist, was eine Stunde Downtime kostet.
Verwandte Artikel
- Kubernetes Managed Service vs. Inhouse: Der ehrliche Kostenvergleich
- Kubernetes Kosten senken: 10 Praxis-Tipps
- Kubernetes ohne DevOps-Team im Mittelstand
- Kubernetes Partner Deutschland: Auswahl-Guide
Sie stehen vor der Entscheidung und moechten eine ehrliche Einschaetzung fuer Ihre Situation? Wir beraten Sie unverbindlich - ohne Verkaufsdruck. Sprechen Sie mit uns.
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
Kubernetes intern vs. extern: TCO-Vergleich Mittelstand
Ehrlicher TCO-Vergleich: Kubernetes intern betreiben vs. Managed Service mit versteckten Kosten bei Gehalt, Tooling, Fluktuation und Einarbeitung.
Tagessatz vs. Managed Service: Kostenvergleich Kubernetes
Freelancer-Tagessatz gegen Managed Service für Kubernetes: TCO-Analyse über 12 Monate zeigt versteckte Kosten und warum Festpreis günstiger ist.
Kubernetes Managed Service vs. Inhouse: TCO-Vergleich
Kubernetes selbst betreiben oder auslagern? Dieser Guide zeigt den echten TCO-Vergleich und warum 4.000 EUR pro Monat oft günstiger ist als ein DevOps-Team.
Kubernetes Budget kalkulieren: Vorlage für den CFO
Kubernetes-Kosten für den CFO aufbereiten: Intern vs. Managed Service mit allen Kostenpositionen, Risikobewertung und Make-or-Buy-Empfehlung.
Kubernetes-Migration gescheitert: Projekt in 6 Wochen retten
Kubernetes-Migration gescheitert? Assessment-Framework, Rettungsplan und Entscheidungshilfe: Reparieren oder neu starten für IT-Leiter im Mittelstand.