Menu

Caso studio · cliente anonimo

Da AWS al bare metal, senza toccare l’applicazione.

Come abbiamo migrato un workload di produzione da AWS a server dedicati Leaseweb, con un cutover senza downtime.

Durata~3 mesi
DowntimeNessuno al cutover
ProviderLeaseweb
ClienteAnonimo
05 Bare metal04 Rete03 Dati e storage02 Kubernetes01 Applicazione

Contesto

Piattaforma di produzione su AWS: istanze EC2, RDS per PostgreSQL, S3 e servizi gestiti. Spesa mensile nell’ordine delle decine di migliaia di euro, traffico con curva giornaliera prevedibile.

Decisione

Pagare un’elasticità non utilizzata non aveva più senso. Migrare su bare metal dedicato, cambiando solo il livello infrastrutturale.

Approccio: stessa applicazione, nuova infrastruttura

Kubernetes su bare metal con le stesse immagini container, gli stessi chart Helm e le stesse pipeline CI/CD. Ogni servizio gestito è stato sostituito da un componente open source e portabile.

AWS → BARE METAL · LEASEWEB

EC2
Kubernetes · kubeadm
EBS
Longhorn
S3
MinIO
RDS PostgreSQL
PostgreSQL + Patroni
ALB
HAProxy + Keepalived
CloudWatch
Prometheus + Grafana
VPC / NAT
WireGuard

Fasi del progetto · circa 3 mesi

Assessment · 2wCostruzione · 3wParallelo · 4wDati · 2wCutover · 1d

Il processo

  1. 01

    Assessment · 2 settimane

    Inventario dei servizi, dipendenze e flussi dati.

  2. 02

    Costruzione · 3 settimane

    Server, cluster Kubernetes, rete, storage, observability.

  3. 03

    Parallelo · 4 settimane

    Stack in shadow mode, test di carico e tuning.

  4. 04

    Dati · 2 settimane

    Replica PostgreSQL da RDS, sync S3 → MinIO.

  5. 05

    Cutover · 1 giorno

    Switch DNS con TTL breve e monitoraggio 24h.

Benefici descritti

  • Spesa mensile passata da decine di migliaia a poche migliaia di euro
  • Tempo di diagnosi degli incidenti ridotto: da ore a minuti
  • Infrastruttura interamente come codice e runbook documentati
  • Latenza più costante tra applicazione e database

Benefici come documentati nell’articolo, per questo specifico carico e team.

Trade-off e limiti

  • Alta affidabilità da progettare e testare in proprio (Patroni, Longhorn, Keepalived)
  • Backup e disaster recovery autogestiti (pgBackRest, restic, replica offsite)
  • Più responsabilità operativa: servono competenze Linux e reperibilità
  • Non adatto a traffico molto variabile o prodotti con requisiti ancora incerti