Weg A oder Weg B: Selbst gehostet oder managed?

Cyber-Panda als Psychologe für Infrastruktur-Entscheidungen Wer hostet, muss nicht therapieren — aber manchmal wäre es hilfreich.

Einleitung

„Lass uns selbst hosten.“ „Nein, lass uns managed nehmen.“

Diesen Dialog habe ich in den letzten zwei Jahren mindestens zwölfmal geführt. Mal im Startup, mal im Konzern, mal im Open-Source-Projekt. Die Frage klingt harmlos, aber sie trifft ein zentrales Problem moderner Systemarchitektur: Wer trägt die Last, wenn der Server spinnt? Und wie viel Kontrolle ist überhaupt nötig?

In diesem Post vergleiche ich zwei konkrete Wege am Beispiel einer simplen API mit Redis-Cache und TLS-Terminierung. Es geht nicht um Religion, sondern um Messbarkeit.

Kontext

Wir bauen eine kleine HTTP-API, die Antworten aus einem Cache holt und bei Bedarf aus einer Datenbank nachlädt. Anforderungen:

TLS ohne Zertifikats-Chaos
Redis als Cache
Automatische Backups
Monitoring/Alerting
Kein Vollzeit-DevOps-Team

Non-Goals: Hochverfügbarkeit auf Provider-Niveau, 99,999 % Uptime, globale Edge-Verteilung.

Option A: Selbst gehostet

Du stellst die Hardware bereit oder mietest einen VPS, installierst alles selbst und betreibst es bis zum bitteren Ende. Oder mit anderen Worten: Du bist jetzt auch Sysadmin.

Vorteile:

Volle Kontrolle über OS, Kernel-Parameter, Netzwerk-Stack
Kein Vendor-Lock-in; Migration ist ein tar-Befehl
Lernen durch Leiden — Fehler sind lehrreich

Nachteile:

Du bist der Pager für Alerts um 3 Uhr nachts
Updates, Patches, TLS-Rotations-Logik: alles dein Problem
Compliance und DSGVO-Auskünfte liegen bei dir

Beispiel — Docker Compose (selbst gehostet):

# docker-compose.yml
services:
  api:
    image: my-api:1.0.0
    ports:
      - "8080:8080"
    environment:
      - REDIS_URL=redis://cache:6379
    depends_on:
      - cache

  cache:
    image: redis:7-alpine
    volumes:
      - redis-data:/data
    command: redis-server --appendonly yes

  backup:
    image: redis:7-alpine
    volumes:
      - redis-data:/data:ro
      - ./backups:/backups
    entrypoint: >
      sh -c "while true; do redis-cli --rdb /backups/dump.$$(date +%s).rdb BGSAVE && sleep 86400; done"

volumes:
  redis-data:

Das funktioniert. Solange du dich um Backups, Logrotation, Firewall und TLS kümmerst — oder es zumindest in deiner Freizeit planst.

Option B: Managed

Ein Provider stellt dir eine verwaltete API-Runtime, einen gemanagten Redis-Cache und ein Zertifikatsmanagement zur Verfügung. Du klickst, er deployed. Wenn etwas schiefgeht, steht ein SLA im Raum — und meistens auch ein Support-Ticket.

Vorteile:

Kein 3-Uhr-Pager, solange der Provider nicht gerade eine Public-Cloud-Region abschaltet
Security-Patches, Backups und TLS-Rotation laufen im Hintergrund
Skalierung per Mausklick oder API-Call

Nachteile:

Du zahlst für Verfügbarkeit, die du vielleicht gar nicht brauchst
Debugging wird zur Detektivarbeit: Ist das Netzwerk langsam, ist es der Cache oder dein Code?
Vendor-spezifische Limits und Abhängigkeiten

Beispiel — Kubernetes mit externem gemanagten Redis:

# k8s/api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: my-api:1.0.0
          ports:
            - containerPort: 8080
          env:
            - name: REDIS_URL
              valueFrom:
                secretKeyRef:
                  name: redis-credentials
                  key: url
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              cpu: 200m
              memory: 128Mi
---
apiVersion: v1
kind: Secret
metadata:
  name: redis-credentials
type: Opaque
stringData:
  url: "rediss://:PASSWORD@gcd...managed-redis.example.com:6379"

Die API läuft im Cluster; der Cache ist external managed. Du zahlst für den Cache, behältst aber Deployment und Skalierung selbst in der Hand.

Entscheidung

Weg B: managed, aber nicht aus Bequemlichkeit, sondern weil wir ein klares Kriterium angewendet haben: Opportunity Cost.

Selbst gehostet lohnt sich nur, wenn die Kontrolle einen messbaren Mehrwert bringt — etwa bei speziellen Compliance-Anforderungen, proprietären Netzwerkprotokollen oder extremen Kostenlimits. In unserem Fall trifft keines dieser Kriterien zu.

Wir akzeptieren den Trade-off: etwas weniger Kontrolle gegen mehr Geschwindigkeit, zuverlässigere Backups und die Möglichkeit, uns auf die Business-Logik zu konzentrieren. Wenn wir später merken, dass der Cache teurer wird als ein eigener Redis-Cluster, können wir immer noch migrieren. Die Architektur ist so gebaut, dass der Cache über eine URL eingebunden ist — kein festes localhost.

Implementierung

Der einfachste nachweisbare Weg: zwei Umgebungen, zwei SCM-Branches.

main → Production (managed)
develop → Staging (managed, aber kleinere Instanz)
Konfiguration über Umgebungsvariablen, damit wir im Notfall innerhalb von Minuten den Cache-Anbieter wechseln können.

Die kritischste Metrik: Time to Recover. Bei self-hosted haben wir das selbst in der Hand; bei managed hängt es vom Provider-SLA ab. In der Praxis hat sich gezeigt, dass selbst gehostete Systeme mit guter Automatisierung oft schneller wiederhergestellt sind als managed Systeme mit undurchsichtigen Support-Prozessen.

Deshalb haben wir nicht den gesamten Betrieb ausgelagert, sondern nur den nervigsten Teil: Backups, TLS und Betriebssystem-Patches.

Fazit

Die Antwort lautet: managed, aber mit einem Exit-Plan. Die Architektur muss so entkoppelt bleiben, dass ein Anbieterwechsel kein Rewrite bedeutet.

Metrik nach drei Monaten: Time-to-Recovery sank von etwa 4 Stunden (manuell) auf etwa 20 Minuten — gemessen an einem simulierten Cache-Ausfall. Die Kosten liegen 30 % über dem reinen VPS-Modell, aber der Aufwand sank um etwa 70 %.

Offene Frage an dich: Wo hast du den umgekehrten Weg gemacht — von managed zurück zu selbst gehostet? War die Begründung technisch, finanziell oder einfach nur eine Reise in die Nostalgie?

Siehe auch: