Die Umgebung: eine Vier-Schichten-Architektur an zwei Standorten

Vor der Migration betrieb das Team von Software Projects eine einzelne, klar definierte Architektur in zwei IBM-Cloud-Regionen, ausgelegt auf Ausfallsicherheit: ein größerer Primärstandort und ein kleinerer Sekundärstandort. Beide Standorte folgten demselben Vier-Schichten-Muster:

• Load Balancing: eine kleine Flotte von HAProxy-Instanzen, die Produktions-, Entwicklungs- und Tracking-Traffic getrennt voneinander bedienten.
• Applikation: Web- und Tracking-Server, ein Runner für geplante Jobs, ein Server für Codequalität (SonarQube) sowie ein VPN-Gateway (nur am Primärstandort vorhanden).
• Container-Orchestrierung: selbst verwaltete Docker-Swarm-Cluster – am Primärstandort als getrennte Produktions- und Entwicklungscluster, am Sekundärstandort als einzelnes Cluster.
• Daten: ein MySQL-Primary/Replica-Paar neben einem Cassandra-Cluster mit drei Knoten, an beiden Standorten repliziert.

Der Migrationsplan von DoiT sah einen originalgetreuen 1:1-Lift-and-Shift dieser Topologie in eine einzige AWS-VPC in us-east-1 vor – mit denselben Footprints von 24 und 16 Knoten, jedoch verteilt über mehrere Availability Zones innerhalb einer AWS-Region statt über zwei unabhängige, geografisch getrennte IBM-Cloud-Regionen. Die folgende Tabelle zeigt, wie die Zusammensetzung Schicht für Schicht unverändert übernommen wurde:

Diese Zahlen blieben auf beiden Seiten des Cutovers konstant – dieselben 24 und 16 Knoten, in denselben Proportionen pro Schicht, lediglich an einem neuen Ort. Diese Disziplin zahlte sich aus: Software Projects übernahm auf AWS eine Umgebung, die sich exakt so verhielt wie die, die das Team bereits kannte – während DoiT im Hintergrund eine ganze Ebene an Infrastrukturkomplexität entfernte, indem zwei Rechenzentrumsregionen in einer einzigen AWS-Region über mehrere Availability Zones hinweg zusammengeführt wurden. Zugleich bereitete das die Modernize-Phase sauber vor: Die Roadmap sah bereits vor, die selbst verwalteten Docker-Swarm-Cluster zugunsten einer verwalteten Container-Plattform abzulösen, sobald die Umgebung auf AWS stabil lief.

Der Ansatz: AWS MAP, durchgängig umgesetzt

DoiT führte das Projekt über alle drei AWS-MAP-Phasen hinweg durch, wobei jede Phase die technische und finanzielle Grundlage für die nächste schuf – durchgängig umgesetzt vom Forward-Deployment-Engineering-Team von DoiT.

1. Assess: ein belastbares Migrationsbudget aufbauen

Bevor auch nur ein Workload umzog, brauchte das Team von Software Projects einen klaren Überblick pro Service, was Storage und Compute auf AWS kosten würden. DoiT erstellte eine detaillierte Kostenaufschlüsselung für EBS und EFS – mit Modellierung der monatlichen Kosten für Storage, IOPS und Durchsatz über Volume-Typen und Storage-Klassen hinweg –, damit Software Projects die kurz- und mittelfristigen Ausgaben für seine Migrations-Roadmap prognostizieren konnte. Zudem arbeitete DoiT die Rabattstrategie für das Datenbank-Compute von Software Projects durch: DoiT Flexsave (ein rabattiertes Äquivalent zu Compute Savings Plans ohne Vorab-Commitment) im Vergleich zu Standard- und Convertible-Reserved-Instance-Preisen – inklusive der jeweiligen Trade-offs mit Blick auf einen möglichen späteren Wechsel zu einem verwalteten Datenbankservice.

2. Mobilize: Cross-Cloud-Konnektivität lösen

Die Konnektivität zwischen IBM Cloud und AWS war der kritische Pfad der gesamten Migration – und dafür gab es keine Lösung von der Stange. DoiT führte eine strukturierte Bewertung der Optionen durch – AWS Direct Connect, eine dedizierte IBM-Direct-Link-Leitung, virtuelle Router-Appliances und ein leichtgewichtiges Mesh-VPN – und wog für jede Option Kosten, Stabilität und Einrichtungsaufwand ab:

• Bewertete AWS Direct Connect und IBM Direct Link Dedicated (einschließlich BGP-, IP-Range- und Abrechnungsrestriktionen) als Option mit dedizierter Leitung.
• Pilotierte ein Mesh-VPN-Overlay als schnelle, kostenfreie Übergangslösung, während längerfristige Optionen geprüft wurden.
• Begleitete Software Projects beim Deployment und Tuning einer virtuellen Router-Appliance auf IBM-Seite, einschließlich VLAN-Routing-Verhalten und Layer-2-Troubleshooting mit dem IBM-Support.
• Half Software Projects beim Wechsel von IBM Classic Infrastructure zu IBM VPC für flexibleres Networking und richtete anschließend ein IPSec-Site-to-Site-VPN zwischen IBM VPC und einer AWS-VPC ein.
• Diagnostizierte und behob eine Subnetz-Überlappung samt Routing-Lücke zwischen IBM Classic und AWS, indem ein dedizierter, überlappungsfreier IP-Bereich zugewiesen und statische Routen angepasst wurden – der Fix, der bidirektionalen Traffic zwischen allen drei Umgebungen endlich möglich machte.

Das Ergebnis: ein stabiler, verifizierter privater Netzwerkpfad zwischen IBM Classic Infrastructure, IBM VPC und AWS – die Grundlage, auf der das Team von Software Projects Workloads im eigenen Tempo verschieben konnte, ohne die Verbindung zu Systemen zu verlieren, die noch auf IBM liefen.

Stabiler Produktivbetrieb während der Übergangsphase

Während des Migrationszeitraums leistete DoiT auf AWS-Seite auch schnellen operativen Support. In einem Fall verlor eine EC2-Instanz unerwartet die SSM-Konnektivität – ohne verfügbaren SSH-Fallback. DoiT identifizierte die Ursache per Konsolen-Output-Diagnose: Das Root-Volume war vollgelaufen, wodurch der SSM-Agent nicht mehr starten konnte. DoiT lieferte einen Schritt-für-Schritt-Plan zur Behebung (Volume-Erweiterung und Dateisystem-Resize) sowie proaktive CloudWatch-Alarme zur Festplattenauslastung und SNS-Benachrichtigungen, um eine Wiederholung zu verhindern – mit besonderem Augenmerk darauf, Produktionssysteme vor demselben Fehlerbild zu schützen.

3. Modernize: Container und kontinuierliche Kostenoptimierung

Nach Abschluss der Migration ging das Projekt in die Modernize-Phase über. Die Produktions- und Entwicklungs-Stacks von Software Projects liefen noch auf selbst verwalteten Docker-Swarm-Clustern – funktional, aber mit dem operativen Overhead manuell gepatchter Manager und Worker. DoiT unterstützt das Team von Software Projects nun dabei, diese Swarm-Cluster durch eine verwaltete Container-Plattform auf AWS (Amazon EKS) abzulösen – aufbauend auf der konsolidierten Multi-AZ-VPC aus der Mobilize-Phase, statt die Architektur von Grund auf neu zu entwerfen.

Im Rahmen derselben Modernisierung hält DoiT die Cloud-Ausgaben diszipliniert, während sich die Umgebung weiterentwickelt. Mit DCI Insights überprüfte DoiT die AWS-Detective- und GuardDuty-Konfiguration von Software Projects und stellte fest, dass die Kosten für das Security-Tooling auf einen erheblichen Anteil der Gesamtausgaben angewachsen waren – vor allem getrieben durch die Ingestion großer Mengen an Flow-Logs, nicht durch tatsächlich gelieferten Sicherheitsmehrwert. DoiT quantifizierte die Trade-offs – einschließlich der Frage, welche Finding-Typen mit hohem Schweregrad von welchen Datenquellen abhingen – und lieferte Software Projects klare, evidenzbasierte Optionen für das Right-Sizing der Security-Abdeckung, ohne die wertvollsten Detections zu verlieren. Derselbe disziplinierte, evidenzbasierte Ansatz setzt sich in der Containerisierung fort: von Anfang an richtig dimensioniert statt nachträglich optimiert.

Die Lösung: Powered by DoiT Cloud Intelligence (DCI)

Neben der Hands-on-Umsetzung nutzte Software Projects während des gesamten Projekts mehrere Funktionen von DoiT Cloud Intelligence (DCI) – ein erfahrenes Delivery-Team kombiniert mit Self-Service-Transparenz über die eigene AWS-Umgebung:

Die letzten beiden Funktionen sind täglich im Einsatz: Während das Team von Software Projects seine Umgebung auf Container umstellt, liefern DCI AWS Intelligence und DCI Datadog Insights kontinuierliche Transparenz über die gesamten Cloud- und Observability-Ausgaben – statt darauf zu warten, dass erst die Monatsrechnung ein Problem sichtbar macht.

• Die erste funktionierende private Netzwerkverbindung zwischen IBM Cloud Infrastructure und AWS aufgebaut, nachdem frühere selbst verwaltete Versuche in eine Richtung gescheitert waren.
• Alle 40 Server – die vollständige Vier-Schichten-Topologie aus Load Balancing, Applikation, Orchestrierung und Daten – mit unveränderter Zusammensetzung pro Schicht zu AWS migriert, sodass das Team vom ersten Tag an eine vertraute Umgebung übernahm.
• Zwei geografisch getrennte IBM-Cloud-Regionen in einer einzigen AWS-VPC über mehrere Availability Zones hinweg konsolidiert – für ein einfacheres Netzwerk und weniger operativen Aufwand, ohne die Ausfallsicherheit eines Zwei-Standort-Designs zu opfern.
• Software Projects vor der Migration ein granulares, belastbares Kostenmodell für Storage und Compute an die Hand gegeben und damit Budgetüberraschungen während des Umzugs reduziert.
• Einen produktionsrelevanten SSM-Ausfall mit klarer Ursachenanalyse behoben und Software Projects proaktives Monitoring hinterlassen, um dasselbe Fehlerbild künftig früher zu erkennen.
• Alle drei AWS-MAP-Phasen – Assess, Mobilize und Modernize – in einem durchgängigen Engagement umgesetzt und den Migrationskontext über die Phasengrenzen hinweg mitgeführt, statt ihn bei jedem Phasenwechsel neu aufzubauen.
• Den Kunden in die Lage versetzt, selbst verwaltete Docker-Swarm-Cluster zugunsten einer verwalteten Container-Plattform abzulösen – mit einer Security- und Kostenstruktur, die schon vor Beginn der nächsten Phase richtig dimensioniert war.
• Dem Kunden Self-Service-Transparenz über die eigene Umgebung hinterlassen – DCI Cloud Diagrams für das Infrastruktur-Mapping sowie DCI AWS Intelligence und DCI Datadog Insights für das kontinuierliche Tracking der Cloud- und Observability-Ausgaben.

Die AWS-Umgebung von Software Projects ist heute das stabile Fundament für die nächste Modernisierungsphase. DoiT begleitet den Kunden weiterhin bei der Verlagerung von Workloads auf Container – mit derselben Kombination aus technischer Umsetzung und kontinuierlicher Kostendisziplin, die die Migration von der ersten Bewertung bis zur vollständig vernetzten, produktionsreifen AWS-Umgebung getragen hat.

Software Projects ist ein Software-Services-Unternehmen mit einer gemischten Produktions- und Nicht-Produktionsumgebung, die historisch auf IBM Cloud Infrastructure gehostet war. Im Rahmen einer umfassenderen Cloud-Strategie beauftragte das Unternehmen DoiT mit der Migration seiner Workloads zu AWS im Rahmen des AWS Migration Acceleration Program (MAP) – DoiT setzte dabei alle drei MAP-Phasen um: Assess, Mobilize und Modernize.