Cloud & Plattform-Engineering

Lift & Shift ist eine Falle. On-Prem-VMs ohne Redesign in die Cloud zu verschieben bedeutet dreifache Kosten bei gleichen Problemen. Wir migrieren strategisch — Assessment, Workload-Priorisierung, Hybrid Bridge, schrittweises Umschalten.

5R-Assessment-Framework: Für jeden Workload entscheiden wir: Rehost (Lift & Shift — nur für Legacy mit kurzer Lebensdauer), Replatform (Containerisierung, Managed Services), Refactor (Redesign für Cloud-Native), Replace (SaaS-Alternative), Retire (abschalten). Die meisten Workloads sind ein Mix aus Replatform + Refactor.

Hybrid Bridge: Alte und neue Welt laufen parallel. VPN/ExpressRoute zwischen On-Prem und Cloud. Schrittweises Service-Umschalten mit Traffic-Splitting und automatischem Rollback. Kein Big-Bang-Cutover.

Dependency Mapping: Bevor Sie irgendetwas migrieren, müssen Sie wissen, was wovon abhängt. Automatische Discovery (Azure Migrate, AWS Migration Hub) + manuelle Validierung. Ergebnis: Abhängigkeitsgraph mit Risikobewertung für jeden Workload.

Typischer Zeitplan: Assessment (2–4 Wochen) → Pilot (4–6 Wochen, 2–3 Services) → Wave Migration (2–4 Services/Monat) → Konsolidierung (4–6 Wochen). Insgesamt 3–12 Monate je nach Größe.

Manuelle Infrastruktur ist technische Schuld. Ein per SSH-Konsole konfigurierter Server ist ein Snowflake — niemand weiß genau, wie man ihn reproduziert, die Dokumentation ist veraltet, Disaster Recovery ist ein Ratespiel. IaC eliminiert das.

Terraform vs. Pulumi: Terraform (HCL) ist der Industriestandard — riesiges Ökosystem an Providern, ausgereiftes Tooling, große Community. Pulumi ermöglicht Infrastruktur in TypeScript/Python — besser für Teams, die keine weitere Sprache lernen wollen. Wir wählen nach Team-Kontext.

GitOps-Workflow: Alle Infrastrukturänderungen gehen über Pull Requests. Code Review, automatisierte Tests (terraform validate, tflint, checkov für Security), Plan-Preview in PR-Kommentaren. Merge = Apply. Audit-Trail in der Git-Historie.

Modularisierung: Terraform-Module für Standardmuster — VPC/VNet, Kubernetes-Cluster, Datenbank, Monitoring-Stack. Internes Modul-Registry. Neues Team bekommt produktionsreife Infrastruktur in Stunden, nicht Wochen.

State Management: Remote State in verschlüsseltem Storage (S3 + DynamoDB Lock, Azure Blob + Lock). State Locking für Teamzusammenarbeit. Drift Detection — automatische Erkennung manueller Änderungen.

Kubernetes ist nicht für jeden — aber wenn Sie es brauchen, machen wir es richtig. K8s macht Sinn bei 5+ Microservices, Multi-Cloud-Anforderungen oder spezifischen Betriebsanforderungen (Auto-Scaling, Service Mesh, Progressive Delivery).

Managed Kubernetes: AKS (Azure), EKS (AWS), GKE (Google). Wir bauen keine eigenen Control Planes — Managed Service eliminiert 80 % des operativen Overheads. Fokus auf Workloads, nicht auf etcd-Backup.

GitOps mit ArgoCD: Deklaratives Deployment. Desired State in Git, ArgoCD synchronisiert den Cluster. Drift Detection — wenn jemand manuell etwas ändert, korrigiert ArgoCD es. Self-Healing-Cluster.

Helm + Kustomize: Helm Charts für Standardkomponenten (nginx, cert-manager, Monitoring). Kustomize für umgebungsspezifische Overlays (dev/staging/prod). Templating ohne Template-Hell.

Progressive Delivery: Argo Rollouts für Canary- und Blue-Green-Releases. Automatisierte Analyse (Prometheus-Metriken) entscheidet über Rollout/Rollback. Istio/Linkerd Service Mesh für Traffic Splitting und mTLS.

CI/CD ist nicht nur Build und Deploy. Es ist die gesamte Delivery-Pipeline — vom Commit über Tests, Security-Scans, Quality Gates, Staging-Validierung bis zum progressiven Rollout in die Produktion. Jeder Schritt automatisiert, messbar, auditierbar.

Pipeline-Architektur: Build → Unit Tests → SAST (Security) → Container Build → Integrationstests → Deploy auf Staging → E2E-Tests → Deploy auf Prod (Canary) → Automatisierte Analyse → Vollständiger Rollout. Gesamter Flow < 15 Minuten für typischen Service.

Quality Gates: Automatisierte Checks, die das Deployment bei Fehlschlag stoppen. Testabdeckung < Schwellenwert? Stopp. Sicherheitslücke (critical/high)? Stopp. Performance-Regression > 10 %? Stopp. Keine manuelle Freigabe für Standardänderungen.

Monorepo vs. Polyrepo: Wir unterstützen beides. Für Monorepo: Affected Detection (nur geänderte Services werden gebaut/deployed). Für Polyrepo: Standardisierte Pipeline-Templates, die über alle Repos geteilt werden.

Metriken: DORA-Metriken als Feedback-Loop. Deployment-Frequenz, Lead Time, Change Failure Rate, MTTR. Dashboard für Engineering-Leadership. Trends, nicht Snapshots.

Monitoring sagt Ihnen DASS. Observability sagt Ihnen WARUM. Drei Säulen: Metriken (Prometheus), Logs (Loki), Traces (Jaeger/Tempo). OpenTelemetry als Standard-Instrumentierung — herstellerunabhängig, einmal instrumentieren, überallhin exportieren.

SLO/SLI-Framework: Wir definieren Service Level Objectives für jeden kritischen Service. SLI (Metriken) misst die Realität, SLO (Ziel) definiert akzeptable Qualität. Error Budget = wie viel „Fehlerhaftigkeit” Sie sich leisten können. Wenn das Error Budget aufgebraucht ist, Feature-Arbeit stoppen, Zuverlässigkeit verbessern.

Alerting-Philosophie: Wir alerten auf Symptome, nicht auf Ursachen. „API Error Rate > 1 %” ist ein guter Alert. „CPU > 80 %” ist ein schlechter Alert (CPU kann bei 95 % sein und alles funktioniert). Page nur für handlungsrelevante Alerts — wenn der Bereitschaftsdienst nichts tun kann, ist es kein Page.

SRE-Prozesse: Bereitschaftsrotation, Incident Management (Severity-Klassifizierung, Kommunikationsprotokoll, Eskalation), Post-Mortems ohne Schuldzuweisungen. Runbooks für die Top-10-Incidents. Toil-Tracking und -Eliminierung.

Dashboards: Executive Dashboard (SLO-Compliance, Verfügbarkeit, Kosten), Engineering Dashboard (Latenz, Fehlerrate, Durchsatz pro Service), On-Call Dashboard (aktive Incidents, kürzliche Deployments, Anomalieerkennung).

Die Cloud-Rechnung ist kein Wetterbericht — sie ist ein steuerbarer Prozess. Die meisten Unternehmen zahlen 30–50 % mehr für die Cloud als nötig. Ungenutzte Reserved Instances, überdimensionierte VMs, vergessene Ressourcen, nicht-optimiertes Storage Tiering.

Kostentransparenz: Tagging-Strategie (Team, Umgebung, Projekt, Kostenstelle). Kostenzuordnung pro Team/Projekt/Service. Showback/Chargeback-Modell — Teams sehen, was ihre Services kosten. Wenn Sie den Preis sehen, verhalten Sie sich anders.

Optimierungstechniken: Reserved Instances/Savings Plans (Commitment = 30–60 % Rabatt), Right-Sizing (die meisten VMs sind 2–4× überdimensioniert), Spot/Preemptible Instances für nicht-kritische Workloads, Autoscaling (Scale to Zero in Dev/Staging), Storage Tiering (Hot → Cool → Archive).

Kontinuierliche Optimierung: Monatliche Kostenüberprüfung mit Empfehlungen. Automatische Alerts bei Kostenanomalien (unerwarteter Spike). Waste Detection (ungenutzte Disks, nicht zugewiesene IPs, idle Load Balancer). FinOps-Dashboard mit Trends und Forecasting.

Stückkosten: Kosten pro Transaktion, Kosten pro Nutzer, Kosten pro API-Call. Wenn Sie die Stückkosten kennen, können Sie sinnvoll optimieren. „Wir kosten 0,003 CZK pro API-Call” ist handlungsrelevant. „Azure hat letzten Monat 500K gekostet” nicht.