Hybrid Cloud: on-prem + cloud

1) Warum ein Hybrid und wann es gerechtfertigt ist

Treiber: regulatorische Anforderungen (Data Residency/PII), bestehende On-Prem-Investitionen, Latenz an „eigene“ Systeme, Kostenkontrolle, Zugang zu Managed Cloud Services.
Kompromisse: Komplexität von Netzwerken und Sicherheit, Doppelkompetenzen, Synchronisation von Daten und Config, operative Risiken.

Motto: portabel, wo es kritisch ist; cloud-native, wo es profitabel ist.

2) Hybrid-Modelle

On-prem extension: Die Cloud als Erweiterung des Rechenzentrums (neue Microservices/Analysen, Fronten).
Cloud-first mit lokalen Ankern: Kern in der Cloud, On-Prem - Buchhaltungssysteme/Payment Gateways/PII-Speicher.
Cloud-Bursting: elastische Lastspitzen in die Cloud (Batch, Promo-Spitzen), Basisvolumen lokal.
DR to Cloud: Hot/Warm Reserve in der Cloud für On-Prem (RTO/RPO sind überschaubar).
Edge + Core: PoP/Edge-Knoten näher am Benutzer, Root-Daten/ML in der Cloud.

3) Netzwerk und Konnektivität

3. 1 Kanäle

Site-to-Site VPN (IPsec/SSL) - schnell starten, höhere Latenz, jitter.
Gerade Linien (DC/ER/IC, MPLS) sind vorhersehbare SLAs, niedriger als die Latenz, teurer.
Dual-Link + BGP - Fehlertoleranz und Routing-Steuerung.

3. 2 Adressierung und Routen

Ein einziges RFC1918 Schema ohne Kreuzungen; CIDR-Plan für die kommenden Jahre.
NAT-Häuser nur an den Grenzen; Ost-West ohne NAT.
Segment/VRF zur Isolation von Medien (dev/stage/prod), Tenanten, Anbietern.

3. 3 Zeit- und DNS-Richtlinien

Ein einziges NTP (Uhr = Schicksal für Kryptographie/Signaturen).
Split-horizon DNS: interne Zonen (svc. cluster. local, corp.local), extern - öffentlich.
Health-based GSLB für eingehenden Datenverkehr.

4) Identität und Zugang

SSO Federation: OIDC/SAML, On-Prem-IdP ↔ Cloud-IdP; SCIM-Providing.
Rollen nach dem Prinzip des least privilege; break-glass Konten mit MFA.
Maschinenidentität: SPIFFE/SPIRE oder Mesh-PKI für mTLS.
RBAC „End-to-End“: Git/CI/CD → Cluster/Mesh → Broker/DB → Logs.

5) Plattform: Kubernetes + GitOps

5. 1 Einzelne Ausführungsschicht

On-Prem- und Cloud-Cluster mit den gleichen Versionen/CRD.
GitOps (Argo CD/Flux): Einzelcharts/Overlays, Driftkontrolle, Promo-Streams.

5. 2 Service-mesh

Istio/Linkerd: mTLS default, locality-aware balancing, failover inter-cluster.
L7-Richtlinien (JWT, headers, rate limits, retry/circuit/timeout) - im Manifest-Code.

5. 3 Beispiel (K8s topology & mesh)

yaml anti-affinity and distribution by zones on-prem cluster spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }
Istio DestinationRule: local cluster priority, then trafficPolicy cloud:
outlierDetection: { consecutive5xx: 5, interval: 5s, baseEjectionTime: 30s }

6) Daten und Speicher

6. 1 Basen

On-prem master, cloud read-replica (Analysen/Verzeichnisse).
Cloud Master + On-prem Cache (geringe Latenz für lokale Integrationen).
Distributed SQL/NoSQL (Cockroach/Cassandra) mit lokalen Quorums.
CDC/Log-Replikation (Debezium) zwischen Schleifen; Idempotenz der Verarbeiter.

6. 2 Objekt/Datei/Block

S3-kompatible Store (on-prem MinIO + cloud S3/GCS) mit Replikation/Versionierung; WORM für Audit.
Backups: 3-2-1 (3 Kopien, 2 Medien, 1 - offsite), regelmäßige Überprüfung der Wiederherstellung.

6. 3 Cache und Warteschlangen

Redis/KeyDB des Per-Site-Clusters; globaler Cache - nur über Ereignisse/TTL.
Kafka/Pulsar: MirrorMaker 2/replicator; der Schlüssel ist die Dedup/Idempotenz der Konsumenten.

7) Sicherheit und Compliance (Zero Trust)

mTLS überall (mesh), TLS 1. 2 + auf dem Perimeter; Verbot von unverschlüsselten Kanälen.
Geheimnisse: HashiCorp Vault/ESO; kurzlebige Token; Auto-Rotation.
KMS/HSM: Schlüssel segmentiert per Jurisdiktion/Tenant; Krypto-Rotation nach Zeitplan.
Segmentierung: NetworkPolicies, micro-segmentation (NSX/Calico), ZTNA für Admin-Zugriff.
Protokolle: unveränderlich (Objektsperre), Ende-zu-Ende' trace _ id', PII/PAN-Maskierung.

8) Überwachung, SLO und Incident Management

OpenTelemetry SDK überall; Collector on-prem und in der Cloud.
Tail-sampling: 100% ошибок и p99, labels `site=onprem|cloud`, `region`, `tenant`.
SLO und Error Budgets nach Abschnitten (Route/Tenant/Anbieter/Website); Alerts auf Burn-Rate.
Durchgehende Dashboards: RED/USE, Abhängigkeitskarten, Kanarienvergleiche (vor/nach Migrationen).

9) CI/CD und Configs

Einzelregistrierung von Artefakten (Pull-Through-Cache auf dem Prem).
Promo-Stream: dev → stage (on-prem) → canary (cloud) → prod; oder umgekehrt - je nach Ziel.
Prüfungen: Vertragstests (OpenAPI/gRPC/CDC), statische Analyse, IaC-Linting, Image-Scan, SLO-Gates.

10) DR/BCP (Kontinuitätsplan)

• Kataloge/Landings: RTO 5-15 min, RPO ≤ 5 min;
• Zahlungen/Wallets: RTO ≤ 5 min, RPO ≈ 0-1 min (Quorum/Synchron innerhalb des Standorts).
• Runbook: GSLB/Weights umschalten, Standby im Cluster anheben, Feature-Flags im „Lightweight Mode“.
• GameDays: vierteljährlich - Standort-/Kanalabschaltung, Überprüfung echter RTOs/RPOs.

11) Kosten und FinOps

Egress zwischen On-Prem und Cloud - der wichtigste „versteckte“ Verbrauch; Cashing und reduzieren Wanderungen auf ein Minimum (SWR, Rand).
Tagging: 'service', 'env', 'site', 'tenant', 'cost _ center'.
80/20-Regel: Wir übertragen/halten 20% des "kritischen Kerns' tragbar, der Rest ist dort, wo es billiger ist.
Downsampling Metriken, Hot/Cold Log Retentionen, Budget-Aware-Sampling-Tracing.

12) Workload Platzierungsmuster

13) Beispiele für Config

13. 1 IPsec S2S (Idee)

onprem ↔ cloud: IKEv2, AES-GCM, PFS group 14, rekey ≤ 1h, DPD 15s, SLA monitoring jitter/packet-loss

13. 2 Terraform (Fragment von Tags/Labels)

hcl resource "kubernetes_namespace" "payments" {
metadata {
name = "payments"
labels = {
"site"    = var. site    # onprem    cloud
"tenant"   = var. tenant
"cost_center" = var. cc
}
}
}

13. 3 Vault + ESO (Geheimnis von on-prem zu Cloud-Cluster)

yaml apiVersion: external-secrets. io/v1beta1 kind: ExternalSecret spec:
refreshInterval: 1h secretStoreRef: { kind: ClusterSecretStore, name: vault-store }
target: { name: psp-hmac, creationPolicy: Owner }
data:
- secretKey: hmac remoteRef: { key: kv/data/payments, property: HMAC_SECRET }

14) Antipatterns

Überschneidungen von CIDR- → NAT-Chaos Erst der Adressplan, dann die Kanäle.
Ein „gemeinsamer“ globaler Cache mit starker Konsistenz → Latenz und Split-Brain.
Retrays ohne Idempotenz → doppelte Abschreibungen/Aufträge.
Ein „nacktes“ VPN ohne mTLS/Zero Trust im Inneren ist eine seitliche Bewegung, wenn sie kompromittiert wird.
Fehlende DR-Übungen: Pläne funktionieren in der Realität nicht.
Verschiedene Versionen von K8s/CRD/Operatoren → die Unmöglichkeit von Einzelcharts.
Protokolle im freien Format ohne' trace _ id 'und Maskierung - forensica ist nicht möglich.

15) Spezifität von iGaming/Finanzen

Datenresidenz: PII/Zahlungsereignisse - im On-prem/Regionalkreis; in die Cloud - Aggregate/anonym.
PSP/KYC: Multi-Provider; Smart-Routing von der Cloud zu lokalen Gateways, Fallback zu Backup; Webhooks über einen Broker mit einem Deduplex.
„Wege des Geldes“: einzelne SLOs über dem allgemeinen; sind obligatorisch HMAC/mTLS, „Retry-After“, „Idempotency-Key“.
Audit: WORM-Speicher (Object Lock), unveränderliche Transaktionsprotokolle, bidirektionale Aufzeichnung (on-prem + cloud) für kritische Ereignisse.
Jurisdiktionen: KMS/Vault Schlüsselsegmentierung per Land/Marke; Geoblöcke am Perimeter.

16) Checkliste Prod-Ready

• Adressplan, DNS, NTP - eins; Kanäle S2S + gerade Linien mit Reserve (BGP).
• Unified Identity (SSO/OIDC/SAML), MFA, least privilege; SPIFFE/SPIRE für Dienste.
• K8s an allen Standorten, GitOps, gleiche Betreiber/CRD; service mesh с mTLS и locality-aware LB.
• Daten: CDC, Consistency Tests, RPO/RTO-Richtlinien, 3-2-1-Backup und regelmäßige Restore-Drids.
• Sicherheit: Vault/ESO, Rotation, NetworkPolicies, ZTNA; Die Protokolle sind unveränderlich.
• Beobachtbarkeit: OTel, Tail-Sampling, SLO/Budgets nach Standort/Region/Tenant; kanarische Dashboards.
• CI/CD: Vertragstests, IaC-Linting, Image-Scan; Release-Gates nach SLO.
• DR-runbooks, GameDays, gemessene tatsächliche RTO/RPO; Cutover/Roll-Back-Tasten.
• FinOps: egress-Limits, Tags und Berichte, Retenche-Richtlinie für Metriken/Logs/Traces.
• iGaming-Spezifität: Datenresidenz, Multi-PSP, WORM-Audit, separate SLOs für Zahlungen.

17) TL; DR

Hybrid = gemeinsame Ausführungsplattform (K8s + GitOps + Mesh + OTel + Vault) auf zwei Welten: On-Prem und Cloud. Planen Sie Ihr Netzwerk und Ihre Identität, machen Sie Daten über CDC/Idempotenz übertragbar, grenzen Sie die Sicherheit durch Zero Trust ab, messen Sie die Zuverlässigkeit von SLO/Error Budgets und trainieren Sie regelmäßig DR. Für iGaming halten Sie Daten und Zahlungen in der Gerichtsbarkeit, verwenden Sie Multi-PSP Smart-Routing und unveränderliches Audit.