Von Heroku zu AWS ohne Ausfall, bei 14 Mio. $ Volumen pro Monat
In 14 Wochen von Heroku zu AWS, ohne Ausfall, nach dem Strangler-Fig-Muster: −35 % Infrastrukturkosten, −93 % Deployment-Dauer, +800 % Deployment-Frequenz.
Der Kunde verarbeitet rund 14 Mio. $ Transaktionsvolumen im Monat, verteilt auf mehr als 180.000 Transaktionen für etwa 900 kleine und mittlere Händler in den USA und Kanada. Die gesamte Plattform lief als monolithische Ruby-on-Rails-Anwendung auf Heroku, und die Architektur war zum größten Hemmnis für das Geschäft geworden.
Die Probleme ließen sich beziffern. Jedes Deployment war ein vollständiger Neustart von 38 Minuten und nur zweimal pro Woche in einem Wartungsfenster erlaubt. Ein fehlgeschlagenes Deployment hatte zur Hauptgeschäftszeit einen Ausfall von 47 Minuten und rund 62.000 $ an fehlgeschlagenen Transaktionen verursacht. Auf Heroku ließen sich einzelne Komponenten nicht unabhängig skalieren, sodass die Reporting-Spitzen zum Monatsende die gesamte Anwendung zum Skalieren zwangen. Die Kosten hatten 14.200 $ pro Monat erreicht und stiegen monatlich um 8–12 %. Und ein einzelner Fehler an beliebiger Stelle konnte alles lahmlegen: Ein Formatierungsfehler im Reporting ließ einmal die Zahlungs-Queue für 23 Minuten abstürzen, was zwei Enterprise-Interessenten kostete.
Die Vorgabe von CTO-Seite ließ keinen Spielraum: kein Migrationsfenster und keine Störung, die Händler bemerken. Die Migration musste unter laufendem Zahlungsverkehr stattfinden.
Am Anfang stand eine Infrastruktur-Analyse für 6.000 $: die Durchsicht der Rails-Codebasis mit rund 85.000 Zeilen, die Aufnahme des Schemas mit 47 Tabellen (12 davon mit mehr als 1 Mio. Zeilen) und ein Request-Tracing. Es zeigte, dass Reporting-Abfragen zum Monatsende 60 % der Datenbank-CPU beanspruchten, während der Zahlungspfad selbst bei einer p99-Latenz von 340 ms lag. Wir empfahlen das Strangler-Fig-Muster: Services einzeln herauslösen, Alt und Neu parallel betreiben, den Traffic schrittweise verlagern. Die Reihenfolge richtete sich nach dem Risiko: Benachrichtigungen, Reporting, Onboarding, Webhooks und zuletzt der Zahlungskern.
In den Wochen 3 und 4 entstand das Fundament, bevor irgendetwas herausgelöst wurde: jede AWS-Ressource in Terraform, CI/CD mit GitHub Actions samt Sicherheitsscans und Blue-Green-Deployments auf EKS sowie ein Observability-Stack mit Datadog, der von Beginn an lief, um Abweichungen zwischen altem und neuem System innerhalb von Sekunden zu erkennen.
Die risikoarmen Teile folgten in den Wochen 5–8. Der Benachrichtigungsservice lief 5 Tage parallel, mit einer Abweichungsrate von 0,00 %, bevor umgeschaltet wurde. Die Verlagerung des Reportings auf eine Read Replica senkte die CPU-Last der Primärdatenbank von 78 % auf 31 % und verbesserte als Nebeneffekt die p99-Latenz bei Zahlungen von 340 ms auf 180 ms. Der Zahlungskern wurde zuletzt und mit größter Vorsicht migriert: 48 Stunden Shadow-Traffic über 12.000 Transaktionen bei 0,00 % Abweichung, dann über 10 Tage eine schrittweise Verlagerung von 1 % auf 100 % des Traffics, mit einem getesteten Rollback-Plan für jeden Schritt. Woche 14 endete mit Runbooks, Wissenstransfer und einem dreistündigen Game Day, an dem gezielt Ausfälle ausgelöst wurden.
Gemessen über die ersten 90 Tage nach der Migration im Vergleich zu den 90 Tagen davor: Die Deployment-Dauer sank von 38 Minuten auf 2,5 Minuten pro Service (−93 %), die Deployment-Frequenz stieg von 2× auf 18× pro Woche (+800 %), die monatlichen Infrastrukturkosten fielen von 14.200 $ auf 9.230 $ (−35 %), die p99-Latenz bei Zahlungen verbesserte sich von 340 ms auf 145 ms (−57 %), und die Reporting-Abfragen zum Monatsende brauchten statt 12–45 Sekunden nur noch 2–8 Sekunden (−82 %). Ungeplante Ausfallzeit: vorher 70 Minuten, danach keine. Ausfallzeit während der Migration selbst: keine.
Beim Volumenwachstum des Unternehmens von 15 % pro Quartal hätten die Heroku-Kosten bis zum Jahresende 22.000 $ pro Monat erreicht. Die AWS-Architektur kommt bei gleichem Volumen voraussichtlich auf 11.500 $ pro Monat. Das ergibt eine wachsende jährliche Einsparung von mehr als 120.000 $. Die Migration für 74.000 $ amortisiert sich allein über die Infrastruktur-Einsparungen in 14,8 Monaten. Das entfallene Ausfallrisiko von 62.000 $ pro Vorfall ist dabei nicht eingerechnet.
Der Kunde hat einen DevOps-Engineer von Gigabit dauerhaft für den SRE-Betrieb behalten, für 5.500 $ pro Monat. Auf der aktuellen Roadmap stehen ein Multi-Region-Deployment, eine Pipeline zur Betrugserkennung in Echtzeit und eine Infrastruktur für SOC 2 Type II.
Drei Firmen haben uns für diese Migration ein Angebot vorgelegt. Zwei schlugen ein zwölfmonatiges „Lift and Shift“ mit einem Migrationswochenende vor. Gigabit schlug einen 14-wöchigen Strangler-Fig-Ansatz vor, mit der Zusage, dass es keinen Ausfall gibt. Sie haben genau das geliefert, was sie versprochen hatten: Kein einziger Händler hat bemerkt, dass die Migration stattgefunden hat. Wir deployen nicht mehr zweimal pro Woche, sondern mehrmals täglich. Das allein hat verändert, wie schnell wir am Produkt liefern können.
Unsere veröffentlichten Fallstudien stammen überwiegend aus Nordamerika. Alle Beträge in US-Dollar. Der Kunde ist anonymisiert.
