Salta al contenuto principale
AIAlessandro Iannacone
Dal blog

Superare il vendor lock-in: perché la migrazione cloud non è solo una questione di costi (Azure -> Hetzner)

Una migrazione cloud matura non confronta solo il prezzo orario. Analizziamo TCO, resilienza e neutralità del fornitore con un caso pratico da Azure a Hetzner.

Foto profilo di Alessandro IannaconeAlessandro Iannacone

Quando si parla di migrazione cloud, il dibattito parte quasi sempre dal costo: "quanto risparmio al mese?".

La domanda giusta, in realtà, e: quanto controllo strategico sto comprando o perdendo nei prossimi 24-36 mesi?

In questo articolo uso un caso reale molto comune (stack iniziale su Azure, target su Hetzner cloud/bare metal) per spiegare perché il tema centrale non è solo il listino, ma il bilanciamento tra TCO, resilienza e neutralità del fornitore.

1) Il mito dell'economia cloud: i crediti non sono una strategia

I crediti iniziali (startup program, grant, promo cloud) sono utili per accelerare il go-to-market. Il problema nasce quando diventano la base del tuo piano economico.

Succede spesso questo schema:

  • fase 1: VM semplici, costi prevedibili;
  • fase 2: adozione di servizi managed per velocizzare il team;
  • fase 3: dipendenza tecnica da API proprietarie, IAM e strumenti nativi;
  • fase 4: fine crediti, curva costi in salita e margine di manovra ridotto.

Il lock-in non è solo "tecnologico": e anche organizzativo. Processi, competenze e runbook si allineano a un unico ecosistema.

2) Dall'abbonamento al controllo: cosa cambia passando a Hetzner

Il passaggio verso provider più neutrali (Hetzner, Vultr bare metal, colocation) non è "retrocesso": e spesso una scelta di maturità.

Con Azure/AWS compri:

  • altissimo livello di automazione managed;
  • integrazioni profonde tra servizi;
  • time-to-market rapido.

Con Hetzner/bare metal compri:

  • controllo diretto di rete, host, storage e performance;
  • maggiore prevedibilita dei costi infrastrutturali;
  • più libertà di disegno architetturale multi-provider.

Tradotto: passi da un modello "abbonamento + convenience" a un modello "proprietà operativa + responsabilità".

3) TCO olistico: il foglio Excel da solo non basta

Confrontare solo $/vCPU o $/GB RAM porta a decisioni miopi. Un TCO corretto deve includere almeno quattro blocchi.

A) Costi infrastrutturali diretti

  • compute, storage, egress, backup, snapshot;
  • costi rete (LB, IP, transfer inter-zone/inter-region);
  • costi licenze e servizi security/monitoring.

B) Costi operativi

  • tempo team per imparare un nuovo modello operativo;
  • effort di hardening, patching, runbook e incident response;
  • costo reperibilita e supporto.

C) Costi di migrazione

  • data transfer iniziale (seed + delta sync);
  • refactor CI/CD e IaC;
  • modifica observability, alerting, logging e backup policy.

D) Costo opportunita (spesso ignorato)

  • minore potere negoziale se sei legato a un solo vendor;
  • maggiore rischio in caso di cambi pricing o policy;
  • minor velocità di pivot strategico (nuovi mercati, compliance, sovranità dato).

Quando includi anche D, molte migrazioni apparentemente "non urgenti" diventano razionali.

4) Architettura cloud-agnostic: progettare oggi per non pagare domani

La vera difesa dal lock-in non è il "lift-and-shift", ma l'architettura.

Pattern pratici:

  • Container first: packaging standard con Docker, deploy su K8s o orchestratori equivalenti.
  • IaC portabile: Terraform/OpenTofu + moduli astratti per provider.
  • Storage abstraction: usare client compatibili S3/OCI dove possibile, evitando coupling con SDK proprietari non necessari.
  • Message/API decoupling: introdurre adapter interni tra business logic e servizi esterni.
  • Observability indipendente: metriche, log e trace non devono dipendere da un solo backend SaaS.

Obiettivo: poter cambiare fornitore con refactoring controllato, non con un "rewrite emotivo" durante una crisi.

Caso Azure -> Hetzner: checklist decisionale sintetica

Prima di migrare:

  1. Classifica i componenti in tre gruppi: portabili, riscrivibili, da sostituire.
  2. Stima TCO a 24 mesi con scenario best/base/worst.
  3. Definisci SLO minimi post-migrazione (uptime, RTO, RPO, latenza).
  4. Esegui un pilot su workload non critici ma rappresentativi.
  5. Misura non solo i costi, ma anche lead time operativo e MTTR.

Se i numeri reggono su questi cinque punti, la migrazione e strategica, non tattica.

Conclusione

Il cloud hyperscale resta una scelta eccellente in molti contesti. Ma confondere "comodità iniziale" con "libertà strategica" è un errore costoso.

La migrazione verso infrastrutture più neutrali ha senso quando vuoi:

  • ridurre il rischio di lock-in;
  • aumentare il controllo architetturale;
  • costruire resilienza economica e operativa nel lungo periodo.

In altre parole: non è solo una questione di costi. È una decisione di governance tecnica.

Fonti e risorse web