Cloud & DevOps Consulting für US- und EU-Teams

Die Preise sind festumfänglich und all-in, in USD angegeben. Ein Infrastruktur-Audit beginnt ab 700 $; eine schlüsselfertige CI/CD- und Cloud-Umsetzung ab 1.800 $; Managed DevOps ab 1.100 $ pro Monat; und ein dedizierter DevOps-Entwickler über Staff Augmentation ab 100 $ pro Stunde. Die genaue Zahl hängt von der Größe der Landschaft, dem Migrations- und Refactoring-Mix, dem Compliance-Umfang und der Dauer des Managed-Retainers ab. Sie sehen das Budget mit Einzelposten am Ende der Discovery-Phase und geben Ihre Freigabe, bevor Arbeiten beginnen. Es gibt keinen Recruiting-Aufschlag, keine Tool-Zuschläge, und Cloud-Gebühren laufen über Ihre eigenen Konten, sodass Sie den Kostenhebel behalten.

Wir entscheiden nach Workload, regionaler Verfügbarkeit (EU und US), vorhandenen Kenntnissen und dem Total Cost of Ownership über drei Jahre. EU-SaaS landet typischerweise auf AWS Frankfurt oder Azure West Europe; US-Workloads auf AWS us-east-1/us-west-2 oder Azure East US; datenintensives ML geht häufig zu GCP. Wir drängen kein bevorzugtes Logo auf.

Ein Lift-and-Shift einer mittelgroßen SaaS-Anwendung dauert drei bis vier Monate. Ein Replatforming auf Kubernetes mit neu aufgebautem CI/CD, Observability und IaC dauert in der Regel sechs bis neun Monate inklusive Parallelbetriebsphase.

Ja. Ein FinOps-Audit dauert zwei bis drei Wochen und deckt typischerweise 20 bis 40 Prozent Verschwendung durch Rightsizing, Savings Plans, Storage-Tiering und das Abschalten ungenutzter Workloads auf. Wir teilen das Playbook, damit die Einsparungen nachhaltig sind.

Nein. Kubernetes ist großartig, wenn Sie Multi-Team-Isolation, komplexes Netzwerking oder polyglotte Workloads benötigen. Für kleinere Estates bleiben ECS, App Service, Cloud Run oder sogar verwaltetes PaaS günstiger und einfacher. Wir empfehlen das kleinste Werkzeug, das passt.

Für EU-Kunden setzen wir standardmäßig auf EU-Regionen (DSGVO + Datenresidenz, EU-exklusive KMS-Schlüssel, EU-Support-Verträge, EU-CDN-Edges); für US-Kunden deployen wir in US-Regionen mit US-exklusiven KMS-Schlüsseln (SOC 2 + CCPA + HIPAA wo erforderlich) mit US-Resident-Support und US-CDN-Edges. Wo transatlantische Dienste unvermeidbar sind, wenden wir DPF, SCCs und Datenminimierprinzipien an und dokumentieren die Entscheidung. Eine vollständige Checkliste zur Partnerwahl und aktuelle EU-Sätze finden Sie in unserem Leitfaden zur Wahl europäischer DevOps-Berater.

Beides. Neben Migrationen zu AWS, Azure und GCP arbeiten wir als DevOps-Beratung, die CI/CD-Pipelines, Kubernetes-Plattformen, Observability und SRE-Praktiken dauerhaft betreibt — nicht nur für die Migrationsphase. Als DevOps-Unternehmen mit Delivery-Center in Jerewan liefern wir im MEZ-Arbeitstag mit Überlappung zur US-Ostküste, 9–13 Uhr ET, und ein SRE-Team, das On-Call, Incident-Response und vierteljährliche Kapazitätsplanung übernimmt.

GitOps behandelt Ihr Git-Repository als einzige Quelle der Wahrheit für Infrastruktur- und Anwendungszustand: Ein Push in main löst eine Reconciliation-Schleife (Argo CD oder Flux) aus, die den Cluster mit dem deklarierten Zustand im Repository in Übereinstimmung bringt. Die Vorteile sind vollständige Nachvollziehbarkeit jeder Änderung, sofortiges Rollback per Git-Revert und Drift-Erkennung, die warnt, wenn jemand manuell ein kubectl-Patch anwendet. Wir empfehlen GitOps für Teams, die Kubernetes betreiben und eine starke Änderungssteuerung ohne schwerfälligen ITSM-Prozess wünschen. Für kleinere Estates auf ECS oder App Service ist ein konventionelles CI/CD-Push-Modell meist einfacher und ausreichend.

Die Technik hängt von der Architektur ab. Für zustandslose Dienste verwenden wir Rolling Updates mit konfigurierbarem Surge und Max-Unavailable oder Blue-Green-Deployments, bei denen der Load Balancer Ziele nach einem Smoke-Test-Gate wechselt. Canary-Releases, gesteuert durch Argo Rollouts oder eine Feature-Flag-Schicht, leiten einen kleinen Prozentsatz des Traffics zur neuen Version und führen bei Fehlerratenverletzungen automatisch ein Rollback durch. Datenbankschema-Änderungen sind der schwierigste Teil: Wir wenden Expand-Contract-Migrationsmuster an, damit alter und neuer Code während des Übergangsfensters gegen das Schema funktionieren — ohne Wartungsseite.

Unser Managed-Retainer umfasst ein 99,9-Prozent-Plattform-Uptime-SLO (gemessen am Load-Balancer-Health-Check, nicht an der Statusseite des Cloud-Anbieters), ein 15-Minuten-SLA für P1-Vorfallbestätigung und ein Vier-Stunden-SLA für P1-Behebung. P2-Vorfälle (Dienst eingeschränkt, nicht ausgefallen) werden innerhalb einer Stunde bestätigt und innerhalb von 24 Stunden behoben. SLOs werden vierteljährlich überprüft und an die tatsächlichen Zuverlässigkeitsanforderungen Ihres Produkts angepasst; wir verkaufen keine pauschale "Five-Nines"-Aussage ohne vorheriges Verständnis Ihres Traffics und Ihrer Fehlermodi.

Ja, und das ist eine der häufigsten Engagement-Formen. Wir ergänzen ein internes Team typischerweise auf drei Arten: Platform Build (wir konzipieren und implementieren die Plattformschicht, während Ihr Team die Anwendungs-Pipelines verantwortet), Spezialisierungskompetenz (wir bringen Kubernetes-, FinOps- oder Security-Tiefe ein, die Ihr Team intern nicht hat) oder Kapazitätserweiterung (wir übernehmen On-Call-Rotation zur 24/7-Abdeckung, ohne Ihre Ingenieure zu belasten). In allen Fällen arbeiten wir in Ihrem Jira, Ihrem Slack und Ihren Runbooks und dokumentieren alles, damit das Wissen bei Ihrem Team bleibt.

Wir beginnen mit einer Business-Impact-Analyse: Was kostet eine Stunde Ausfallzeit im Vergleich zu den Kosten, eine Ein-Stunden-RTO zu erreichen? Diese Berechnung zeigt in der Regel, dass die meisten kleinen SaaS-Produkte eine Warm-Standby-Strategie (RTO 30–60 Min., RPO 5–15 Min.) benötigen und keine aktive-aktive Multi-Region-Einrichtung, die drei- bis fünfmal mehr Betriebskosten verursacht. Wir dokumentieren Wiederherstellungsverfahren, testen sie vierteljährlich mit Game-Day-Übungen und messen tatsächliche RTO gegen Zielwerte statt anzunehmen, dass das Runbook funktioniert. Für regulierte Workloads (Finanz, Gesundheit) richten wir DR-Testkadenz und -nachweise am Rahmenanforderung aus — SOC 2 A1.3, HIPAA Contingency Plan — damit Tests gleichzeitig als Prüfnachweise dienen.