Cloud & DevOps als Subscription

Warum DevOps kein Nice-to-Have ist

Jede Minute die Ihr Deployment dauert, ist eine Minute in der Ihre Entwickler warten statt Features zu bauen. Jede manuelle Konfiguration ist eine potenzielle Fehlerquelle. Jedes System ohne Monitoring ist eine tickende Zeitbombe.

DevOps ist kein separates Team und keine Rolle. Es ist eine Kultur und ein Set von Praktiken die Entwicklung und Betrieb zusammenbringen. In der Praxis bedeutet das:

• Automatisierung: Alles was manuell passiert, wird automatisiert. Builds, Tests, Deployments, Infrastruktur
• Reproduzierbarkeit: Jede Umgebung kann in Minuten neu aufgebaut werden. Infrastructure as Code statt Snowflake-Server
• Observability: Sie wissen jederzeit was in Ihrem System passiert. Nicht erst wenn Kunden sich beschweren
• Schnelle Feedback-Loops: Code-Änderungen erreichen die Produktion in Minuten, nicht Wochen

Wie DevOps unseren Entwicklungsprozess beschleunigt: Development as a Subscription

CI/CD: Continuous Integration und Deployment

Unsere CI/CD Pipeline

Jedes Projekt das wir betreuen hat eine vollautomatisierte Pipeline. Kein Code erreicht die Produktion ohne diese Schritte:

Continuous Integration (bei jedem Push):

1. Linting: ESLint prüft Code-Qualität und Konsistenz
2. Type-Check: TypeScript Compiler findet Typfehler
3. Unit Tests: Jest/Vitest mit Coverage-Report
4. Integration Tests: API-Tests mit Supertest
5. E2E Tests: Playwright für kritische User Flows
6. Security Audit: npm audit und Snyk für Dependency-Checks
7. Build: Produktions-Build muss erfolgreich sein

Continuous Deployment (bei Merge in Main):

1. Docker Image: Multi-Stage Build für minimales Image
2. Image Scan: Trivy für Container-Vulnerabilities
3. Staging Deploy: Automatisches Deployment auf Staging
4. Smoke Tests: Automatische Checks auf Staging
5. Production Deploy: Blue-Green oder Rolling Update
6. Health Check: Automatische Verifizierung nach Deploy
7. Rollback: Automatisch bei fehlgeschlagenen Health Checks

GitHub Actions als CI/CD Platform

Wir nutzen GitHub Actions für alle CI/CD Pipelines. Die Vorteile:

Feature	GitHub Actions	Jenkins	GitLab CI
Setup	Keine Infrastruktur nötig	Server managen	GitLab-Instanz nötig
Integration	Nativ in GitHub	Plugin-basiert	Nur GitLab
Marketplace	15.000+ Actions	Plugins veralten oft	Weniger Auswahl
Kosten	2.000 Min/Monat gratis	Server-Kosten	Server-Kosten
Self-Hosted Runners	Ja	Standard	Ja
YAML Config	Ja	Groovy/YAML	YAML
Caching	Built-in	Plugin	Built-in
Matrix Builds	Ja	Plugin	Ja

Pipeline-Performance

Langsame Pipelines töten die Produktivität. Unsere Optimierungen:

• Caching: Node Modules, Docker Layer, Turborepo Remote Cache
• Parallelisierung: Lint, Test, Build laufen gleichzeitig
• Inkrementelle Builds: Nur geänderte Packages werden neu gebaut
• Self-Hosted Runners: Für große Projekte mit langen Build-Zeiten
• Ziel: Unter 5 Minuten von Push bis Deploy-Ready

Container-Strategie mit Docker

Warum Docker?

Docker löst das "works on my machine" Problem ein für alle Mal:

• Konsistente Umgebung: Development, Staging und Production laufen identisch
• Isolierung: Jeder Service hat seine eigenen Dependencies
• Portabilität: Läuft auf jedem Cloud-Provider, on-premise, oder lokal
• Schnelles Scaling: Container starten in Sekunden, nicht Minuten

Unsere Docker Best Practices

Multi-Stage Builds für minimale Image-Größen:

• Build-Stage: Node.js mit allen Dev-Dependencies, Compile-Step
• Production-Stage: Nur Runtime, keine Dev-Tools, non-root User
• Ergebnis: Images unter 200MB statt 1.5GB

Security Hardening:

• Non-root User in jedem Container
• Read-only Filesystem wo möglich
• Keine Secrets in Images (Environment Variables oder Secret Manager)
• Regelmäßige Base-Image Updates
• Trivy-Scan in der CI/CD Pipeline

Docker Compose für lokale Entwicklung:

• Ein docker-compose up startet das gesamte System
• PostgreSQL, Redis, Kafka, alles lokal ohne Installation
• Hot-Reload für schnelle Entwicklung
• Seed-Daten für konsistente Testumgebung

Kubernetes: Wann und warum

Nicht jedes Projekt braucht Kubernetes. Aber wenn Sie skalieren müssen, ist es der Industriestandard.

Wann Kubernetes sinnvoll ist

Kriterium	Einfaches Hosting	Kubernetes
1-3 Services	Ideal	Overkill
5+ Services	Komplex	Ideal
Auto-Scaling nötig	Manuell	Automatisch
Zero-Downtime Deployments	Möglich, aber manuell	Built-in
Multi-Region	Kompliziert	Standard
Team-Größe	1-5 Devs	5+ Devs
Traffic-Spitzen	Problematisch	Horizontal Pod Autoscaler
Budget	< €1.000/Monat	> €1.000/Monat

Unser Kubernetes Stack

Komponente	Tool	Funktion
Cluster	EKS (AWS) / GKE (GCP)	Managed Kubernetes
Ingress	nginx Ingress Controller	Traffic-Routing, SSL-Terminierung
Service Mesh	Istio (optional)	mTLS, Observability, Traffic Management
Secrets	External Secrets Operator	Secrets aus AWS SSM/GCP Secret Manager
Monitoring	Prometheus + Grafana	Metriken und Dashboards
Logging	Loki + Grafana	Zentralisiertes Log-Management
Alerting	Alertmanager	PagerDuty/Slack Integration
GitOps	ArgoCD	Deklaratives Deployment aus Git

Kubernetes ohne Kubernetes

Für Teams die Kubernetes-Power wollen ohne die Komplexität:

• AWS App Runner: Container deployen ohne Cluster-Management
• Google Cloud Run: Serverless Container, pay-per-request
• Railway / Render: PaaS mit Docker-Support
• Coolify: Self-hosted PaaS (unsere Empfehlung für Startups)

Infrastructure as Code mit Terraform

Manuelle Infrastruktur-Konfiguration über Web-Konsolen ist der schnellste Weg zu Problemen. Wir definieren jede Ressource als Code.

Warum Infrastructure as Code?

• Versioniert: Jede Änderung ist im Git-Verlauf nachvollziehbar
• Review-fähig: Infrastruktur-Änderungen durchlaufen Code-Review wie jeder andere Code
• Reproduzierbar: Eine neue Umgebung in 15 Minuten statt 2 Tagen
• Testbar: terraform plan zeigt Änderungen bevor sie angewendet werden
• Dokumentation: Der Code ist die Dokumentation. Immer aktuell

Unser Terraform Workflow

1. Entwickler erstellt Terraform-Änderung in Feature-Branch
2. CI Pipeline führt terraform fmt, terraform validate, tflint aus
3. PR Review: terraform plan Output wird als PR-Kommentar gepostet
4. Merge: terraform apply wird automatisch nach Approval ausgeführt
5. State: Remote State in S3/GCS mit State Locking

Was wir mit Terraform verwalten

• Compute: EC2, ECS, EKS, Cloud Run, App Runner
• Database: RDS, Cloud SQL, ElastiCache
• Networking: VPC, Subnets, Security Groups, Load Balancer
• DNS: Route53, Cloud DNS
• Storage: S3, Cloud Storage
• IAM: Roles, Policies, Service Accounts
• Monitoring: CloudWatch, Cloud Monitoring Alerts

Deployment-Strategien

Die richtige Deployment-Strategie entscheidet ob Ihre Nutzer den Release bemerken oder nicht.

Deployment-Strategien im Vergleich

Strategie	Downtime	Risiko	Rollback	Ressourcen
Rolling Update	Keine	Niedrig	Automatisch	1x
Blue-Green	Keine	Sehr niedrig	Sofort (Switch)	2x
Canary	Keine	Minimal	Sofort (Route)	1.1x
Recreate	Kurze Downtime	Mittel	Manuell	1x
Feature Flags	Keine	Minimal	Feature Toggle	1x

Unsere Standard-Empfehlung: Rolling Update für die meisten Projekte. Blue-Green für kritische Systeme. Canary für High-Traffic Anwendungen.

Zero-Downtime Deployments

Jedes Deployment das wir konfigurieren ist Zero-Downtime:

• Health Checks: Neuer Container muss gesund sein bevor Traffic geroutet wird
• Graceful Shutdown: Laufende Requests werden abgeschlossen bevor der alte Container stoppt
• Database Migrations: Backward-compatible Migrations die mit alter und neuer Code-Version funktionieren
• Connection Draining: Load Balancer wartet bis bestehende Verbindungen geschlossen sind

Monitoring und Observability

Die drei Säulen der Observability

1. Metriken (Prometheus + Grafana)

• CPU, Memory, Disk, Network pro Service
• Request Rate, Error Rate, Duration (RED)
• Custom Business Metrics (Registrierungen, Bestellungen, etc.)
• Alerting bei Schwellenwert-Überschreitungen

2. Logs (Loki + Grafana)

• Strukturierte JSON-Logs mit Correlation IDs
• Log Levels: Error, Warn, Info, Debug
• Log Retention: 30 Tage in Loki, 90 Tage in S3
• Full-Text-Suche und Log-Aggregation

3. Traces (Jaeger / OpenTelemetry)

• Request-Tracing über Service-Grenzen hinweg
• Latenz-Analyse pro Service und Dependency
• Error-Tracking mit vollständigem Stack-Trace
• Performance Bottleneck Identifikation

Alerting-Strategie

Nicht jeder Alert ist wichtig. Wir konfigurieren Alerts nach Severity:

Severity	Beispiel	Kanal	Reaktionszeit
Critical	Service down, Error Rate > 10%	PagerDuty + Slack	Sofort
Warning	Hohe Latenz, Disk > 80%	Slack	4 Stunden
Info	Deployment abgeschlossen, Cert Renewal	Slack	Nächster Arbeitstag

Dashboard-Setup

Jedes Projekt bekommt ein Grafana-Dashboard mit:

• Service Health: Alle Services auf einen Blick
• Request Metrics: Rate, Duration, Error Rate pro Endpoint
• Infrastructure: CPU, Memory, Disk, Network
• Business KPIs: Registrierungen, Bestellungen, Revenue (falls relevant)
• Dependencies: Status und Latenz externer Services

Cloud-Provider: AWS vs GCP

Entscheidungshilfe

Kriterium	AWS	GCP
Marktanteil	31% (Marktführer)	11%
Service-Breite	200+ Services	100+ Services
Kubernetes	EKS (gut)	GKE (am besten)
Serverless	Lambda (etabliert)	Cloud Functions + Cloud Run
Datenbank	RDS, Aurora, DynamoDB	Cloud SQL, Spanner, Firestore
ML/AI	SageMaker, Bedrock	Vertex AI (am besten)
Preismodell	Komplex	Einfacher, Sustained Discounts
Deutschland Region	Frankfurt (eu-central-1)	Frankfurt (europe-west3)
Enterprise Support	Ausgereift	Gut, aber weniger Partner
Startup Credits	AWS Activate (bis $100k)	Google for Startups (bis $200k)

Unsere Empfehlung: AWS als Default für Enterprise und etablierte Startups. GCP wenn Kubernetes oder ML/AI im Fokus stehen. Beide haben Rechenzentren in Frankfurt für DSGVO-Konformität.

Kostenoptimierung in der Cloud

Cloud-Kosten explodieren schnell wenn niemand hinschaut. Wir optimieren von Anfang an:

Sofort-Maßnahmen

• Right-Sizing: Viele Instanzen sind überdimensioniert. Monitoring zeigt die tatsächliche Auslastung
• Reserved Instances / Committed Use: 30-60% Ersparnis bei 1-3 Jahres-Commitment
• Spot Instances: 60-90% günstiger für Batch-Jobs und CI/CD Runner
• Auto-Scaling: Nachts und am Wochenende runterskalieren
• Unused Resources: Alte Snapshots, ungenutzte EBS-Volumes, idle Load Balancer

Architektur-Optimierungen

• Serverless für sporadische Workloads: Lambda/Cloud Functions statt dauerhaft laufender Container
• Caching: Redis/CloudFront reduziert Datenbank- und Compute-Kosten
• CDN: Statische Assets global cached, Backend entlastet
• Compression: gzip/brotli für API-Responses reduziert Transfer-Kosten
• Object Storage statt Block Storage: S3 ist 10x günstiger als EBS

Kosten-Monitoring

• AWS Cost Explorer / GCP Billing: Monatliche Review
• Budget Alerts: Warnung bei 80% und 100% des Budgets
• Cost Allocation Tags: Kosten pro Service, Team, Umgebung
• FinOps Dashboard: Grafana-Dashboard mit Kostentrends

So arbeiten wir an Ihrer Infrastruktur

1. Infrastructure Audit

Bestehende Infrastruktur wird analysiert: Kosten, Sicherheit, Skalierbarkeit, Disaster Recovery. Das Ergebnis ist ein priorisierter Maßnahmenkatalog.

2. Terraform-Setup

Bestehende Infrastruktur wird in Terraform importiert. Neue Ressourcen werden als Code definiert. State-Management und CI/CD für Infrastructure wird eingerichtet.

3. CI/CD Pipeline

GitHub Actions Pipeline mit allen Quality Gates. Automatisches Deployment auf Staging bei Merge, manuelles Approval für Production.

4. Monitoring & Alerting

Prometheus, Grafana, Loki und Alertmanager werden aufgesetzt. Dashboards und Alerts werden konfiguriert. Runbook für häufige Incidents.

5. Continuous Improvement

Monatliche Review: Kosten, Performance, Sicherheit. Terraform-Updates, Dependency-Updates, Base-Image-Updates.

Häufige Fragen zu Cloud & DevOps

Brauche ich Kubernetes?

Für die meisten Startups und KMUs: nein. Docker Compose für Entwicklung, AWS App Runner oder Google Cloud Run für Produktion. Kubernetes wenn Sie 5+ Services haben, Auto-Scaling brauchen, oder Multi-Region deployen wollen.

AWS oder GCP?

Beide sind exzellent. AWS hat mehr Services und ist Marktführer. GCP hat besseres Kubernetes (GKE) und einfacheres Pricing. Beide haben Frankfurt-Regionen für DSGVO. Wir unterstützen beide.

Wie viel kostet Cloud-Infrastruktur?

Stark abhängig von Traffic und Architektur. Typische Ranges: MVP (€50-200/Monat), Startup (€200-1.000/Monat), Wachstumsphase (€1.000-5.000/Monat). Wir optimieren aktiv. Mehr zu Gesamtkosten: Die wahren Kosten eines Entwicklers.

Können Sie unsere bestehende Infrastruktur übernehmen?

Ja. Wir übernehmen bestehende AWS/GCP Setups, dokumentieren den Ist-Zustand, importieren in Terraform und optimieren schrittweise. Kein Big-Bang-Migration nötig.

Wie schnell können Sie eine neue Umgebung aufsetzen?

Mit Terraform: eine neue Staging- oder Production-Umgebung in unter einer Stunde. Ein komplettes Setup inkl. CI/CD, Monitoring und erstem Service: 1-2 Tage. Danach läuft alles automatisiert.

Verwandte Leistungen

• Node.js Backend: Die Services die in Ihrer Cloud laufen
• API Entwicklung: APIs die wir deployen und monitoren
• TypeScript: Typsichere Build-Pipelines mit Turborepo
• React Entwicklung: Frontend-Deployment und CDN-Setup
• Next.js Entwicklung: Vercel oder Self-Hosted Deployment