L'ambiente: un'architettura a quattro livelli su due siti

Prima della migrazione, il team di Software Projects gestiva un'unica architettura ben definita in due region IBM Cloud, dimensionata per la resilienza: un sito primario più grande e un sito secondario più piccolo. Ogni sito seguiva lo stesso schema a quattro livelli:

• Bilanciamento del carico: un piccolo parco di istanze HAProxy che gestivano separatamente il traffico di produzione, sviluppo e tracking.
• Applicazione: server web e di tracking, un runner per job pianificati, un server per la qualità del codice (SonarQube) e un gateway VPN (presente solo sul sito primario).
• Orchestrazione dei container: cluster Docker Swarm autogestiti, eseguiti come cluster separati di produzione e sviluppo sul sito primario e come cluster singolo sul sito secondario.
• Dati: una coppia MySQL primario/replica insieme a un cluster Cassandra a tre nodi, replicati su entrambi i siti.

Il piano di migrazione di DoiT prevedeva un lift-and-shift fedele 1:1 di questa topologia in un'unica VPC AWS in us-east-1 — mantenendo gli stessi footprint da 24 e 16 nodi, ma distribuendoli su più Availability Zone all'interno di un'unica Region AWS anziché su due region IBM Cloud indipendenti e geograficamente separate. La tabella seguente mostra come la composizione livello per livello sia stata trasferita senza modifiche:

Questi numeri sono rimasti costanti su entrambi i lati del cutover: gli stessi 24 e 16 nodi, nelle stesse proporzioni livello per livello, semplicemente ricollocati. Una disciplina che ha fatto la differenza: Software Projects ha ereditato su AWS un ambiente che si comportava in modo identico a quello che il team già conosceva, mentre DoiT, dietro le quinte, eliminava un livello di complessità infrastrutturale consolidando due region di data center in un'unica Region AWS distribuita su più Availability Zone. Questo ha inoltre preparato al meglio la fase Modernize, dato che la roadmap prevedeva già il ritiro dei cluster Docker Swarm autogestiti a favore di una piattaforma container gestita, una volta stabilizzato l'ambiente su AWS.

L'approccio: AWS MAP, realizzato end to end

DoiT ha condotto il progetto attraverso le tre fasi di AWS MAP, in cui ogni fase ha costruito le fondamenta tecniche e finanziarie della successiva — realizzate end to end dal team di Forward Deployment Engineering di DoiT.

1. Assess: costruire un budget di migrazione difendibile

Prima di spostare qualsiasi workload, il team di Software Projects aveva bisogno di una visione chiara, per singolo servizio, dei costi di storage e compute su AWS. DoiT ha elaborato un'analisi dettagliata dei costi per EBS ed EFS — modellando i costi mensili di storage, IOPS e throughput tra tipi di volume e classi di storage — così che Software Projects potesse prevedere la spesa a breve e medio termine per la propria roadmap di migrazione. DoiT ha inoltre lavorato sulla strategia di sconto per il compute dei database di Software Projects, confrontando DoiT Flexsave (un equivalente scontato dei Compute Savings Plans senza impegno anticipato) con i prezzi delle Reserved Instance standard e convertibili, spiegando i compromessi di ciascuna opzione nell'ottica di un possibile futuro passaggio a un servizio di database gestito.

2. Mobilize: risolvere la connettività cross-cloud

La connettività tra IBM Cloud e AWS era il percorso critico dell'intera migrazione, e non esisteva una soluzione pronta all'uso. DoiT ha condotto una valutazione strutturata delle opzioni — AWS Direct Connect, un circuito dedicato IBM Direct Link, appliance di routing virtuali e una mesh VPN leggera — soppesando per ciascuna costi, stabilità e complessità di configurazione:

• Ha valutato AWS Direct Connect e IBM Direct Link Dedicated (inclusi i vincoli su BGP, range IP e fatturazione) come opzione a circuito dedicato.
• Ha sperimentato un overlay mesh VPN come soluzione di ripiego rapida e a costo zero mentre venivano valutate le opzioni a lungo termine.
• Ha guidato Software Projects nel deployment e nel tuning di una appliance di routing virtuale sul lato IBM, incluso il comportamento del routing VLAN e il troubleshooting di livello 2 con il supporto IBM.
• Ha aiutato Software Projects a passare da IBM Classic Infrastructure a IBM VPC per ottenere un networking più flessibile, per poi attivare una VPN site-to-site IPSec tra IBM VPC e una VPC AWS.
• Ha diagnosticato e risolto una sovrapposizione di subnet e un gap di routing tra IBM Classic e AWS allocando un range IP dedicato e non sovrapposto e correggendo le rotte statiche — l'intervento che ha finalmente sbloccato il traffico bidirezionale tra i tre ambienti.

Il risultato è stato un percorso di rete privato stabile e verificato che collegava IBM Classic Infrastructure, IBM VPC e AWS — la base che ha permesso al team di Software Projects di spostare i workloads secondo i propri tempi senza perdere la connettività verso i sistemi ancora in esecuzione su IBM.

Mantenere la produzione stabile durante la transizione

Durante la finestra di migrazione, DoiT ha fornito anche un supporto operativo tempestivo sul lato AWS. In un caso, un'istanza EC2 ha perso inaspettatamente la connettività SSM senza alcun fallback SSH disponibile. DoiT ha utilizzato la diagnostica dell'output di console per identificare la causa principale — il volume root aveva esaurito lo spazio su disco, impedendo l'avvio dell'agente SSM — e ha fornito un piano di remediation passo dopo passo (espansione del volume e ridimensionamento del filesystem), insieme ad allarmi proattivi CloudWatch sull'utilizzo del disco e notifiche SNS per prevenire il ripetersi del problema, con particolare attenzione a proteggere i sistemi di produzione dalla stessa modalità di guasto.

3. Modernize: container e ottimizzazione continua dei costi

Completata la migrazione, il progetto è entrato nella fase Modernize. Gli stack di produzione e sviluppo di Software Projects giravano ancora su cluster Docker Swarm autogestiti — funzionali, ma gravati dall'overhead operativo di manager e worker aggiornati manualmente. DoiT sta ora aiutando il team di Software Projects a dismettere quei cluster Swarm a favore di una piattaforma container gestita su AWS (Amazon EKS), costruendo direttamente sulla base VPC consolidata e multi-AZ creata durante la fase Mobilize, invece di riprogettare tutto da zero.

Nell'ambito della stessa spinta alla modernizzazione, DoiT mantiene la disciplina sulla spesa cloud mentre l'ambiente evolve. Utilizzando DCI Insights, DoiT ha esaminato la configurazione di AWS Detective e GuardDuty di Software Projects e ha rilevato che i costi degli strumenti di sicurezza erano cresciuti fino a rappresentare una quota significativa della spesa complessiva, trainati principalmente dall'ingestione di flow log ad alto volume più che dal valore di sicurezza effettivamente generato. DoiT ha quantificato i compromessi — inclusi quali tipi di rilevamenti ad alta severità dipendessero da quali fonti di dati — e ha fornito a Software Projects una serie di opzioni chiare e basate su evidenze per fare right-sizing della copertura di sicurezza senza perdere i rilevamenti di maggior valore. Lo stesso approccio disciplinato e basato sulle evidenze prosegue ora nel lavoro di containerizzazione: dimensionamento corretto fin dall'inizio, anziché ottimizzazione a posteriori.

La soluzione: powered by DoiT Cloud Intelligence (DCI)

Accanto al lavoro di engineering sul campo, Software Projects ha sfruttato diverse funzionalità di DoiT Cloud Intelligence (DCI) durante tutto il progetto — affiancando a un team di delivery esperto la visibilità self-service sul proprio ambiente AWS:

Le ultime due funzionalità sono in uso ogni giorno: mentre il team di Software Projects porta avanti la modernizzazione verso i container, DCI AWS Intelligence e DCI Datadog Insights offrono visibilità continua sulla spesa cloud e di observability complessiva, senza dover attendere la fattura mensile per far emergere un problema.

• Stabilito il primo percorso di rete privato funzionante tra IBM Cloud Infrastructure e AWS, dopo che i precedenti tentativi autogestiti avevano funzionato in una sola direzione.
• Migrati tutti i 40 server — l'intera topologia a quattro livelli di bilanciamento del carico, applicazione, orchestrazione e dati — su AWS con la composizione livello per livello invariata, permettendo al team di ereditare un ambiente familiare fin dal primo giorno.
• Consolidate due region IBM Cloud geograficamente separate in un'unica VPC AWS distribuita su più Availability Zone, semplificando la rete e il footprint operativo senza sacrificare la resilienza di un design a doppio sito.
• Fornito a Software Projects un modello di costi granulare e difendibile per storage e compute prima della migrazione, riducendo le sorprese di budget durante il passaggio.
• Risolta un'interruzione SSM con impatto sulla produzione, identificandone con chiarezza la causa principale, e lasciato a Software Projects un monitoraggio proattivo per intercettare prima lo stesso guasto in futuro.
• Realizzate tutte e tre le fasi AWS MAP — Assess, Mobilize e Modernize — in un unico progetto continuativo, mantenendo il contesto della migrazione invece di azzerarlo a ogni passaggio di fase.
• Preparato il cliente a dismettere i cluster Docker Swarm autogestiti a favore di una piattaforma container gestita, con postura di sicurezza e costi già correttamente dimensionati prima dell'inizio della fase successiva.
• Lasciata al cliente la visibilità self-service sul proprio ambiente — DCI Cloud Diagrams per la mappatura dell'infrastruttura, e DCI AWS Intelligence e DCI Datadog Insights per il monitoraggio continuo della spesa cloud e di observability.

L'ambiente AWS di Software Projects è ora la base stabile per la prossima fase di modernizzazione. DoiT continua ad affiancare il cliente nel passaggio dei workloads ai container, applicando la stessa combinazione di delivery tecnica e disciplina continua sui costi che ha accompagnato la migrazione dalla valutazione iniziale fino a un ambiente AWS completamente connesso e pronto per la produzione.

Software Projects è un'organizzazione di servizi software che gestisce un ambiente misto di produzione e non produzione, storicamente ospitato su IBM Cloud Infrastructure. Nell'ambito di una strategia cloud più ampia, l'organizzazione ha incaricato DoiT di migrare i propri workloads su AWS nel quadro dell'AWS Migration Acceleration Program (MAP), con DoiT a realizzare tutte e tre le fasi MAP: Assess, Mobilize e Modernize.