Stiamo formando esperti di servizi, non più sistemisti

C'è una mutazione silenziosa che attraversa il nostro mestiere da almeno un decennio, e quasi nessuno la chiama con il suo nome. Le aziende non cercano più sistemisti. Cercano Cloud Engineer: persone che sanno orchestrare i servizi gestiti di un provider specifico — AWS, Azure, GCP — ma che spesso non saprebbero ricostruire lo stesso servizio in locale con strumenti propri. Sanno consumare un servizio. Non sanno costruirlo.

Non è una sfumatura accademica. È una perdita di competenza che ha conseguenze tecniche, economiche e strategiche molto concrete per chi quelle infrastrutture le deve pagare e mantenere nel tempo.

La differenza tra usare un servizio e capire un sistema

Un buon sistemista conosce il sistema operativo, la rete, lo storage, i meccanismi di replica, il funzionamento di un database sotto carico, le logiche di un load balancer, la differenza tra un failover automatico e uno pilotato. Quando deve mettere online un servizio in alta disponibilità, sa perché lo sta facendo in un certo modo, e saprebbe rifarlo su hardware diverso, con software diverso, da un altro fornitore.

Un Cloud Engineer puro, invece, conosce la console e l'API di un brand. Sa quale checkbox spuntare per ottenere un database replicato, ma non necessariamente sa cosa succede dietro quella checkbox. E qui nasce il problema: nel momento in cui quella checkbox non c'è — perché si cambia provider, perché si torna on-premise, perché serve un comportamento che il servizio gestito non offre — la competenza svanisce, perché non era mai stata davvero competenza sistemistica. Era familiarità con un'interfaccia.

Il paradosso è che quei pochi sistemisti che hanno imparato anche a usare i servizi cloud si ritrovano oggi a dirigere team che “vivono e pensano cloud”, incapaci di immaginare lo stesso risultato senza un servizio gestito che glielo confezioni.

Il lock-in non è un effetto collaterale: è il modello di business

Quando un'azienda costruisce sopra i servizi proprietari di un provider, non sta solo scegliendo una tecnologia. Sta firmando un vincolo. Più si usano servizi specifici e integrati — il database serverless, la coda gestita, la funzione as a service, l'autenticazione gestita — più il codice e l'architettura si modellano attorno a quel provider. Il giorno in cui si vuole cambiare, non si “sposta” l'applicazione: la si riscrive, in parte o del tutto.

È esattamente l'effetto desiderato da chi vende il servizio. E lo si vede chiaramente in una voce di costo che quasi nessuno guarda al momento della scelta: il traffico in uscita.

Far uscire i dati da un grande hyperscaler costa nell'ordine di 90 $/TB di egress. Su un provider bare-metal europeo lo stesso traffico, entro le soglie incluse, costa 0 €, e oltre soglia circa 1 €/TB. Una differenza fino a 90 volte. Non è un dettaglio: è la corda che ti tiene legato. Migrare costa, e costa apposta.

Quando il cloud serve davvero (e quando no)

Sia chiaro: questo non è un articolo anti-cloud. Un'infrastruttura cloud progettata e configurata a dovere offre un'altissima disponibilità e un disaster recovery efficiente che in casa è oggettivamente più faticoso da raggiungere. Per certi carichi — picchi imprevedibili, presenza geografica multi-regione, scalabilità elastica reale — il cloud è la risposta giusta.

Il punto è un altro: non tutti i servizi hanno bisogno del cloud, e quasi nessuno ha bisogno di un servizio gestito del cloud. Database as a service, cache volatili, orchestrazione di container, code di messaggi: troppo spesso vengono scelti come servizio “chiavi in mano” non perché sia la soluzione migliore per quel caso specifico, ma perché manca in azienda la figura capace di costruirla. Si compra il servizio per supplire a una competenza assente, non per una scelta architetturale ragionata.

La mia posizione è netta: se posso costruirmi un cluster MongoDB a mano, lo farò sempre, invece di prendere il servizio gestito. Non per ideologia, ma perché il controllo, la portabilità e il costo lo giustificano — a patto di avere la competenza per farlo bene. E gli esempi sono tanti: Postgres in replica streaming, Redis Sentinel, un'orchestrazione Kubernetes self-managed, un object storage compatibile S3 on-premise.

Conti alla mano: un cluster MongoDB

Prendiamo un caso reale e mettiamo i numeri sul tavolo. Tutte le cifre sono indicative, di listino, IVA esclusa, e variano per regione e configurazione — ma l'ordine di grandezza è quello.

Opzione A — Servizio gestito (MongoDB Atlas, tier M30)

Un M30 offre 8 GB di RAM, ~2 vCPU, 40 GB di storage e include un replica set a 3 nodi.

→ Circa €5.500 l'anno, per un solo cluster, con nodi da 8 GB di RAM.

Opzione B — Servizio costruito in casa (Hetzner bare-metal)

Tre server dedicati AX42, ognuno con CPU 8-core, 64 GB di RAM e 2×512 GB NVMe in RAID 1, configurati a mano come replica set MongoDB.

→ Circa €1.760 l'anno, con nodi da 64 GB di RAM — otto volte la RAM dell'M30, a un terzo del costo.

Il delta: ~€460 contro ~€147 al mese significa circa €3.700–4.000 risparmiati all'anno su un singolo servizio, con per giunta hardware enormemente più capiente. E qui sta il punto vero: un'azienda non ha un servizio. Ne ha cinque, otto, dieci. Moltiplica quel delta e arrivi facilmente a €20.000–30.000 l'anno di differenza.

Il costo che non si vede: la competenza

A questo punto il sostenitore del cloud gestito ha l'argomento pronto, ed è un argomento serio: “Sì, ma il bare-metal non si gestisce da solo.” Vero. E onestamente va detto.

Il servizio gestito si paga di più perché ti vende tempo e rischio operativo: niente patching del sistema operativo, niente configurazione del replica set, niente hardening, niente test di failover, niente monitoraggio da costruire, niente notti in piedi quando un nodo cade. Fai tutto da un'interfaccia web. Per un team senza competenze sistemistiche profonde, è spesso l'unica scelta sensata — e il giorno che il sistemista bravo se ne va, l'azienda che ha fatto tutto in casa resta scoperta. Il bus factor è un costo reale.

Il servizio costruito in casa costa nettamente meno in infrastruttura, ma richiede una figura che sappia muoversi su più ambiti: OS, rete, sicurezza, database, backup, osservabilità. E qui i conti si chiudono anche sul personale.

Il paradosso economico finale è questo: l'azienda che va di servizi gestiti spende di più in infrastruttura e può cavarsela con un Cloud Engineer che costa relativamente meno (ma la lega al provider). L'azienda che costruisce in casa spende molto meno in infrastruttura, ma deve assumere un sistemista qualificato su più fronti — figura più rara e, se davvero brava, più costosa.

Ed è proprio sul cumulo che la bilancia pende: se i €20.000–30.000 l'anno risparmiati sull'infrastruttura coprono e superano il costo incrementale di un sistemista bravo rispetto a un cloud engineer puro, la scelta “in casa” non è solo più economica. È anche quella che lascia in azienda una competenza che resta, indipendente dal listino di un fornitore.

Concludendo

Il nemico non è il cloud. Il nemico è la perdita dei fondamentali. Stiamo formando una generazione di tecnici che sa accendere un servizio ma non sa cosa accende, e questo ci rende — come settore e come singole aziende — più fragili, più legati e alla lunga più cari.

Il cloud va usato perché è la scelta giusta, non perché è l'unica soluzione che abbiamo o quella più alla moda. E per poter scegliere davvero, serve qualcuno in azienda che sappia ancora costruire le cose con le proprie mani. Quel qualcuno, oggi, vale più di quanto il suo stipendio dica.

Luca Vitali