“Si nasce incendiari si muore pompieri.”

ad un certo punto della mia vita mi sono sentito più Cartesio:

“[…] ho compreso che dovevo abbattere tutto fin dalle fondamenta, una volta nella vita, e ricominciare da capo…[…] e poi stabilirne altre migliori, o anche le stesse, dopo averle rese conformi alla ragione.”

In quel momento ho deciso di ripensare se ci fosse qualcosa da buttare. Ma, ricostruendo, è sorprendentemente tornato tutto come prima: ho passato i miei ideali a un setaccio critico, li ho smontati, controllati, ripuliti. E sono riemersi ancora più forti perché sostenuti da consapevolezza e ragioni che ho maturato negli anni.

Ho la soddisfazione di non aver tradito l’animo di me giovinetto (nota l’afflato poetico, biiiitch) che si preoccupava di non riuscire a mantenere saldi nel tempo i propri ideali. Il ragazzino che sapeva poco del mondo è cresciuto e, malgrado gli anni sul groppone, la vede alla stessa maniera.

L’Andrea ventenne scoprirebbe che non è diventato più saggio perché ha abbandonato alcune cose che potevano puzzare di ingenuità, piuttosto è diventato più esperto, disincantato, probabilmente complicato, ma su alcune cose è rimasto ostinatamente quello di prima.

Ho capito che queste cose vengono da una bussola morale che è al tempo stesso ragione ed istinto: la seguo perché abbandonarla significherebbe andare contro la mia natura più profonda.

I miei ideali sono giusti? Sono sbagliati? Non è questo il punto, l’aspetto notevole è che hanno superato la prova del tempo, dell’età adulta, della mezz’età e ho tiepide speranze di non morire da vecchio stronzo.

L’errore nasce spesso quando si parte direttamente da una tariffa o da un numero di persone senza ricostruire i driver che generano l’effort. Asset gestiti, volumi e tipologia dei ticket, durata media delle attività, ripartizione tra primo, secondo e terzo livello, orari di servizio, SLA, penali, presenza on site, frequenza delle riunioni di SAL e complessità della transizione devono essere trasformati in un modello operativo verificabile. In assenza di dati storici, le assunzioni sono inevitabili, ma devono essere esplicite: una stima ottimistica della durata di un incident o della quota di service request assorbibile da un team riduce artificialmente il costo industriale e produce un canone apparentemente competitivo, che la delivery non riuscirà poi a sostenere. Il cost case deve quindi consentire simulazioni, rendere visibili le ipotesi e distinguere il costo delle attività ricorrenti da startup, assessment e presa in carico.

Il prezzo al cliente è un passaggio ulteriore e non va usato per correggere a posteriori un effort sottostimato. Dal costo industriale occorre arrivare al prezzo includendo in modo trasparente margine operativo, eventuale contingency, e margine commerciale, verificando che il risultato resti coerente con la baseline contrattuale e con le regole previste per le eccedenze. Scontare il prezzo è una scelta commerciale; ridurre l’effort senza modificare perimetro, orari, SLA o modello di erogazione significa invece trasferire il rischio sulla delivery. Un modello corretto mantiene quindi separati effort, costo e prezzo, ma li collega in una catena leggibile: attività e volumi determinano il tempo necessario, il tempo genera il costo, il costo alimenta il canone e il contratto protegge la sostenibilità attraverso baseline, limiti alle attività incluse e meccanismi di adeguamento. Solo così la quotazione resta competitiva senza trasformarsi, dopo l’avvio, in erosione del margine o riduzione della qualità del servizio.

Nightswimming deserves a quiet night

Guido nella notte silenziosa e dolce, e il tempo mi inghiotte come l’acqua scura.

The photograph on the dashboard, taken years ago

Turned around backwards so the windshield shows

Every streetlight reveals the picture in reverse

Still, it’s so much clearer

Ed è qui che il mio immaginario va a fondo scala: sto guidando nella notte, lentamente, con il finestrino aperto, con questo brano nelle orecchie. E succede: le luci dei lampioni che luccicano sul parabrezza, con un moto uguale e contrario, che rovescia le cose ma le rende più chiare perché la pace mi aiuta a riflettere.

I forgot my shirt at the water’s edge, the moon is low tonight

Nightswimming deserves a quiet night

I’m not sure all these people understand

It’s not like years ago, the fear of getting caught

Of recklessness and water

They cannot see me naked

Guido e penso a come sono arrivato a questo punto. Ai momenti più spensierati, a cose che sembravano problemi ma non lo erano, alle stupide preoccupazioni che il tempo ha rivelato senza fondamento. Tutto era più leggero e non lo sapevo.

These things, they go away

Replaced by everyday

Questo verso mi strappa il cuore e lo frulla insieme a tutte le cose passate, quelle che davano sapore alla vita e io non me ne accorgevo. Ora sono state spazzate via dalla quotidianità, dagli affanni, dal peso del tempo che vorrei scaricare ma non ci riesco.

Nightswimming, remembering that night

September’s coming soon, I’m pining for the moon

And what if there were two

Side by side in orbit around the fairest sun?

That bright, tight forever drum

Could not describe nightswimming

Settembre sta per arrivare, e finisce il tempo leggero. Oggi come allora c’è il desiderio profondo di qualcosa che è impossibile ottenere.  “Pining” mi uccide: la sofferenza per il mio cuore che si è spezzato mille volte. Si è ricostruito e porta fiero le cicatrici.

La luna è irraggiungibile ma sembra vicina nel cielo schermato dal parabrezza che le sovrappone lo scorrere della strada, della vita.

You, I thought I knew you

You, I cannot judge

You, I thought you knew me

This one laughing quietly

Underneath my breath

Nightswimming

La persona che ero, quella che credeva di conoscersi, che credevo di conoscere anche io, ora è diversa. Parti di me che sembravano importanti sono svanite in lontananza come la strada che mi lascio alle spalle, fino a sparire nel retrovisore.

The photograph reflects, every streetlight a reminder

Nightswimming deserves a quiet night, deserves a quiet night

Deserves a quiet night

Ogni lampione è un ricordo lontano, mentre si avvicina è nitido per un attimo, ma poi sparisce nella notte lasciando solo una piccola pozza di luce.

Ascoltala.

Poi sono partito per il servizio militare. CAR a Savona, e fin lì tutto bene: ero spesso a casa e comunque ero sempre in Liguria, poi quattro mesi alla Cecchignola, a Roma, e sei mesi al distretto militare di Torino. E lì ho provato una sensazione strana: mi sentivo soffocare. Il cielo basso, il freddo, la nebbia fittissima, gli odori così diversi.

Perché mi giro e c’è sempre qualcosa? Sono circondato? Perché tutta questa terra ferma che da tanta parte dell’ultimo orizzonte il guardo esclude?

E alla fine ho capito che a casa, a Genova, c’è un punto in cui tutto finisce, dove guardo l’orizzonte che si perde nel mare e posso spaziare, dove nulla mi opprime, il mio respiro è ampio e libero e i pensieri diventano più leggeri.

Non ho memoria di una singola volta in cui io, qui a Genova o in Liguria, sia “andato al mare” nell’accezione normale del termine. Questo perché, per me, c’è troppo casino, c’è traffico, non c’è parcheggio, solo scogli o pietre, i liguri sono scontrosi, e tutta una serie di motivi per cui: Grecia, grazie.

Ma “andare al mare” per me vuol dire tornare sulla terrazza dietro la chiesa di Boccadasse; quello è il mio posto, lì sono stato battezzato e, sebbene non ci creda più, lì è il posto dove tutto è iniziato.

Tornare alle mie origini e contemplare la pace o la furia dell’acqua, guardare al di là il più lontano possibile, realizzare che c’è almeno un lato che non schiacci l’anima, altrove costretta come dita dei piedi.

(Oggi sono in vena di citazioni).

Negli accordi di servizio l’attenzione si concentra quasi sempre sui livelli di servizio: tempi di presa in carico, risoluzione, disponibilità, penali. Sono numeri immediati, facili da mettere in una tabella e da confrontare. Il problema è che uno SLA dice cosa deve accadere, ma non dice chiaramente da cosa dipende quel risultato.

È qui che entrano in gioco le assunzioni. Non sono note a margine: sono l’architettura stessa del servizio. Io le divido in due categorie ben distinte.

Le assunzioni contrattuali (il patto con il cliente)

Definiscono il contesto entro cui il canone è valido e la promessa sostenibile.

• Se si promette un tempo di risoluzione, bisogna chiarire cosa succede durante le attese del cliente, i tempi dei fornitori terzi, le approvazioni o le finestre di manutenzione.
• Se nei livelli di servizio non è specificato che un incident può considerarsi risolto anche con un workaround che ripristini il servizio dopo un degrado, il rischio è che il cliente intenda per ‘risoluzione’ la RCA completa. Risultato: SLA bucati e penali, anche se il servizio era già stato ripristinato.
• Se si garantisce un livello di disponibilità, bisogna chiarire quali componenti sono nel perimetro, come viene misurato il downtime, quali eventi sono imputabili al servizio e quali dipendono da infrastrutture, applicazioni o soggetti non governati direttamente dal provider.

Senza queste precisazioni, uno SLA può diventare un regalo fatto al cliente. E può diventare un regalo costoso. In fase commerciale possono rendere l’offerta più competitiva; in fase di delivery diventano una fonte continua di eccezioni, discussioni e perdita di margine.

Un’assunzione non scritta diventa facilmente un’aspettativa implicita del cliente o un costo assorbito dal fornitore. Una dipendenza non esplicitata può essere attribuita al provider anche quando è fuori dal suo controllo; una modalità di misura non definita apre a letture diverse degli stessi dati.

Scrivere buone assunzioni richiede più lavoro che compilare una tabella SLA, perché obbliga a progettare davvero il servizio: capire cosa è sotto controllo, cosa non lo è, quali dati sono necessari, quali attività sono incluse, quali condizioni giustificano un extra canone, quali eventi sospendono il conteggio dei tempi e quali responsabilità restano in capo al cliente. È qui che il solutioning deve collegare parte tecnica, parte economica e parte contrattuale.

Uno SLA corretto tutela il cliente sulla qualità attesa; assunzioni corrette tutelano entrambe le parti sulla fattibilità di quella promessa. Senza assunzioni, lo SLA rischia di diventare una dichiarazione di intenti o, peggio, una garanzia assoluta mascherata da metrica di servizio. Con assunzioni chiare, invece, il contratto diventa governabile: il cliente sa cosa deve abilitare, la delivery sa quali condizioni può pretendere e il fornitore può presidiare la redditività senza rinunciare alla qualità.

Nelle gare e nelle RFP le assunzioni servono anche a colmare le zone non specificate dal cliente. Quando un requisito è incompleto, ambiguo o lasciato aperto, dichiarare un’assunzione significa rendere esplicita l’interpretazione su cui si fondano soluzione, prezzo e responsabilità.

Fin qui le assunzioni servono a rendere governabile il patto con il cliente: chiariscono condizioni, responsabilità, dipendenze e limiti entro cui lo SLA può essere misurato e rispettato. Ma questo è solo un lato del problema.

Anche quando il perimetro contrattuale è ben delimitato, resta da dimostrare che il servizio sia economicamente sostenibile per chi lo eroga. È qui che le assunzioni cambiano funzione: non servono più solo a proteggere il contratto, ma a costruire e verificare il cost model.

Le assunzioni industriali alla base del cost model

Le assunzioni industriali sono le ipotesi operative ed economiche che trasformano il perimetro tecnico in effort, l’effort in costo e il costo in canone. Non descrivono ciò che il cliente deve accettare, ma ciò che il provider deve considerare per capire se la promessa fatta al cliente è sostenibile.

A differenza delle assunzioni contrattuali, non vengono necessariamente esplicitate nel documento commerciale, perché appartengono soprattutto al cost case interno e al modello industriale del provider. Alcune sono ricorrenti e standardizzabili, altre devono essere adattate alle caratteristiche della singola offerta, ma tutte hanno lo stesso obiettivo: rendere tracciabile il modo in cui una promessa di servizio si traduce in capacità operativa, costo industriale e margine atteso.

Quanto tempo richiede mediamente gestire un asset? Quante richieste genera? Quale livello di competenza è necessario? Quale quota di attività ricade sui diversi team e quali costi indiretti devono essere assorbiti dal servizio?

Queste assunzioni nascono da fonti diverse: dati storici di anni di supporto, statistiche sui ticket, esperienza dei responsabili di delivery, memoria operativa dei team, accordi contrattuali di lavoro, modelli di costo del personale, abitudini aziendali e livelli di automazione disponibili. Possono sembrare dettagli tecnici, ma in realtà incidono direttamente sul costo industriale e quindi sul margine.

Se la durata media di un incident è sottostimata, se il numero di richieste ricorrenti è considerato troppo basso, se non vengono valorizzati turni, reperibilità, assenze, formazione, coordinamento o escalation, il prezzo finale sarà solo apparentemente corretto. Il problema emergerà più avanti, quando il servizio inizierà ad assorbire più capacità di quella prevista e il margine verrà eroso dall’effort reale.

Un esempio pratico è il costo annuo di gestione di un server. Il valore non dovrebbe derivare da una tariffa forfettaria applicata meccanicamente, ma dalla combinazione di alcuni driver operativi ed economici che devono essere coerenti tra loro:

• costo delle risorse, includendo RAL, oneri, costi diretti, costi indiretti e seniority effettivamente necessaria;
• capacità effettivamente allocabile al servizio, calcolata al netto di ferie, assenze, formazione, coordinamento interno e attività non direttamente erogate sul contratto del cliente;
• volumi e durata delle attività, considerando incident, service request, attività ricorrenti, escalation e differenze tra lavorazioni standard e specialistiche;
• modello di copertura del servizio, includendo orari, turni, reperibilità, presidio, governance, strumenti e livelli di automazione disponibili;
• variabilità operativa, cioè la contingency necessaria ad assorbire picchi, turnover, complessità non lineare o scostamenti fisiologici rispetto alle ipotesi iniziali.

In questo modo il costo non è più una media astratta, ma il risultato leggibile di ipotesi operative verificabili. Ed è proprio questa leggibilità che permette di distinguere dove il modello può essere ottimizzato senza compromettere la delivery e dove, invece, uno sconto rischia semplicemente di scaricare rischio ed effort non finanziato sulla fase di esercizio.

Più i volumi aumentano, più il rischio cresce. Se devi quotare il deploy di 5.000 postazioni di lavoro e sbagli di 10 euro a postazione, hai già sbagliato il conto di 50.000 euro. Dieci euro sembrano pochi, moltiplicati per 5.000 non lo sono più.

Rendere esplicite, almeno internamente, queste assunzioni evita che il cost model diventi una scatola nera: un buon modello di costo non deve limitarsi a calcolare un prezzo, ma deve rendere comprensibile il rapporto tra perimetro, effort, costo industriale e margine. Ma attenzione: un’assunzione non è necessariamente una limitazione o una clausola con cui proteggersi: è una condizione su cui si basa il modello.

Uno SLA senza assunzioni non è un accordo di servizio. È una scommessa. E chi la perde, di solito, è il fornitore.

Il problema di partenza: gestire le risorse di un computer

Un computer è fatto di hardware (CPU, memoria, disco, rete) e di un sistema operativo. Il cuore del sistema operativo è il kernel, quel pezzo di software che fa da ponte tra l’hardware e tutto il resto. Il kernel si occupa di eseguire i processi, gestire i dispositivi, leggere e scrivere dati, gestire i driver video; insomma: senza kernel il computer è un fermacarte. La parte del sistema operativo che non è kernel è lo spazio utente: l’ambiente dove girano i programmi che usiamo ogni giorno; essi comunicano continuamente con il kernel per fare richieste all’hardware.

Con il tempo, i computer sono diventati potentissimi; così potenti che, spesso, la CPU restava in attesa di lavoro, sottoutilizzata. È quindi diventato naturale far girare più carichi di lavoro sullo stesso computer, per sfruttare meglio le risorse. Ma questo ha subito portato a un problema: come fare per isolare i vari carichi di lavoro gli uni dagli altri? L’isolamento serve per diversi motivi:

• Sicurezza: una vulnerabilità in un’applicazione non deve compromettere automaticamente l’intero sistema.
• Compatibilità: due applicazioni possono richiedere versioni diverse delle stesse librerie, e quelle versioni potrebbero essere incompatibili tra loro.
• Separazione: più servizi possono convivere sullo stesso host senza doverli trattare come un unico ambiente.

Un singolo computer con un singolo sistema operativo, quindi, non era sempre la risposta adeguata. Serviva un modo per dividere il computer in ambienti separati.

La prima risposta: le macchine virtuali

La prima soluzione diffusa è stata la virtualizzazione, con le macchine virtuali (VM). Una VM è essenzialmente un computer virtuale. Al suo interno ha un sistema operativo completo, con il suo kernel, e gira su uno strato software chiamato hypervisor. Il punto fondamentale è capire che cosa viene astratto. Una macchina virtuale astrae l’hardware: l’hypervisor presenta alla VM una CPU, della memoria, dei dischi, delle interfacce di rete e altri dispositivi virtuali. Il sistema operativo che gira nella VM non deve sapere quale sia l’hardware fisico sottostante; per lui, quella macchina virtuale è un computer. Le VM hanno risolto il problema dell’isolamento, ma hanno un costo: ogni VM ha il suo sistema operativo completo, con il suo kernel. Questo richiede memoria, CPU e storage e rende l’avvio più lento rispetto a un processo o a un container. Il vantaggio fondamentale delle VM è però proprio questo livello di astrazione: l’hardware fisico viene nascosto al sistema operativo guest, che può quindi essere diverso da quello dell’host. Una VM Windows può girare su un host Linux e una VM Linux può girare su un host Windows, perché ogni VM porta con sé il proprio kernel.

Con i container il livello di astrazione cambia completamente: non viene astratto l’hardware, ma l’ambiente operativo in cui i processi vedono ed utilizzano le risorse del sistema. Questa distinzione sarà importante quando arriveremo ai container.

La seconda risposta: i container

I container affrontano lo stesso problema dell’isolamento con un approccio diverso. Non virtualizzano l’hardware e non portano con sé un kernel proprio. Isolano invece processi che vengono eseguiti direttamente sul kernel dell’host. Se la VM astrae l’hardware, il container può essere visto come un’astrazione a livello di sistema operativo. Il processo dentro il container non riceve un computer virtuale completo e continua a usare il kernel dell’host, ma il kernel gli presenta una vista isolata del sistema, con un proprio spazio dei processi, una propria rete, un proprio filesystem e, in base alla configurazione, una propria identità utente e limiti sulle risorse.

Questa è la differenza fondamentale:

• Una VM ha il suo kernel e il suo sistema operativo completo.
• Un container utilizza il kernel dell’host e contiene lo spazio utente e le librerie necessari all’applicazione.

Un container, quindi, non è una macchina virtuale più piccola. È un insieme di normali processi che il kernel tratta come appartenenti a un ambiente isolato. Questa architettura rende i container leggeri e veloci. Non devono avviare un sistema operativo completo, quindi possono essere creati e avviati molto rapidamente e permettono di concentrare molti più workload sullo stesso host rispetto a un equivalente basato su VM.

C’è però un compromesso fondamentale da considerare: la sicurezza. Poiché i container condividono il kernel dell’host, una vulnerabilità a livello di kernel o una configurazione errata può permettere a un processo di uscire dall’isolamento (container escape) e potenzialmente compromettere tutti i container presenti sulla macchina. Le VM, avendo un kernel completamente isolato, offrono un perimetro di sicurezza molto più rigido.

Come si ottiene l’isolamento

Il kernel Linux mette a disposizione due meccanismi fondamentali per costruire questo tipo di isolamento: namespaces e cgroups.

1. Namespaces, segregazione della vista

I namespace determinano cosa un processo può vedere. Quando un processo viene inserito in un set di namespace dedicati, la sua visuale del sistema viene ristretta.

• PID Namespace: il processo vede i processi appartenenti al proprio namespace e può vedere il processo iniziale del proprio ambiente come PID 1. Non vede normalmente i processi dell’host come se fossero parte del proprio ambiente.
• NET Namespace: il container può avere una propria interfaccia di rete virtuale, la propria tabella di routing e i propri indirizzi IP e porte.
• MNT Namespace: il processo può avere una propria vista del filesystem.
• IPC / UTS / USER Namespaces: isolano rispettivamente la comunicazione tra processi, l’hostname e la mappatura degli utenti.

L’idea è importante: il processo continua a usare il kernel dell’host, ma il kernel gli presenta una vista limitata delle risorse del sistema.

2. Cgroups, controllo delle risorse

Se i namespace stabiliscono cosa un processo può vedere, i cgroups stabiliscono quanto può consumare. I cgroups consentono all’amministratore, o al runtime di container, di impostare limiti e controlli su:

• Quantità di memoria RAM utilizzabile.
• Utilizzo della CPU.
• Banda e I/O.

Questo evita che un singolo workload possa consumare senza controllo tutte le risorse disponibili sull’host. Per esempio, se un container supera il proprio limite di memoria, il kernel può intervenire e terminare il processo che sta consumando memoria, proteggendo gli altri workload nella misura consentita dall’architettura e dalla configurazione del sistema. Quindi possiamo già costruire un modello mentale abbastanza preciso:

namespace = isolamento della vista

cgroups = controllo delle risorse

Ed è proprio la combinazione di questi meccanismi, insieme ad altri componenti del kernel e del runtime, a permettere di eseguire container senza creare una macchina virtuale per ogni workload.

In realtà namespaces e cgroups da soli non bastano: il kernel applica anche capability, seccomp e moduli di sicurezza per restringere cosa un processo può fare, ma non ne parliamo qui.

Nota a margine: Sebbene namespaces e cgroups siano tecnologie native del kernel Linux, il concetto di container si è esteso anche ad altri ecosistemi. Esistono i Windows Container che condividono il kernel di Windows nella modalità di isolamento standard (process), mentre quella Hyper-V usa un kernel dedicato. Per fare un esempio pratico, quando usi Docker su macOS, il sistema utilizza in realtà una leggerissima VM Linux nascosta per poter eseguire i container.

Immagini e Container

A questo punto bisogna distinguere due concetti che nel mondo Docker vengono spesso confusi: immagine e container. L’immagine è un artefatto statico che contiene l’applicazione, le librerie necessarie, i file di sistema e i metadati necessari a creare l’ambiente di esecuzione. Non contiene un kernel. Il container è un’istanza in esecuzione ottenuta a partire da un’immagine. Quando avvii un’immagine, il runtime prepara il filesystem, configura isolamento e risorse e avvia i processi dell’applicazione.

L’immagine è quindi il modello da cui si può creare un container. Il container è l’ambiente di runtime effettivamente in esecuzione. Questa distinzione è fondamentale perché consente di separare la costruzione dell’applicazione dalla sua esecuzione. Posso costruire un’immagine una volta, conservarla in un registry e utilizzarla per creare molte istanze dello stesso workload.

L’immagine Docker e i layer

Un’immagine Docker è composta da una serie di layer. Ogni layer rappresenta una modifica al filesystem e i layer vengono combinati per costruire la vista finale del filesystem disponibile al container. Questo ha alcuni vantaggi importanti.

• Riutilizzo: se più immagini condividono gli stessi layer di base, questi possono essere memorizzati una sola volta.
• Distribuzione efficiente: quando un’immagine viene trasferita, è possibile riutilizzare i layer già presenti invece di trasferire nuovamente tutto.
• Costruzione incrementale: un Dockerfile può costruire l’immagine attraverso una sequenza di passaggi, rendendo più semplice il riutilizzo delle parti comuni.

Per esempio, un’immagine Docker per un’applicazione web potrebbe partire da un’immagine Linux di base (quindi una distribuzione completa a livello di spazio utente ma senza kernel), aggiungere i pacchetti necessari per PHP, poi Apache e infine i file dell’applicazione. Ogni passaggio può generare un nuovo layer dell’immagine. I layer vengono poi combinati per ottenere il filesystem finale visto dal container.

Quando il container viene avviato, il runtime aggiunge al filesystem dell’immagine un livello scrivibile associato a quella specifica istanza. Le modifiche effettuate durante la vita del container non modificano l’immagine originale. Per i dati che devono sopravvivere alla distruzione e ricreazione del container si usano invece i volumi o altri meccanismi di storage persistente.

Docker: il motivo del successo

A questo punto è importante chiarire una cosa: Docker non è sinonimo di container. I container Linux esistevano prima di Docker, ma Docker ha avuto un ruolo enorme nel renderli semplici da costruire, distribuire e utilizzare, creando un ecosistema coerente intorno alla tecnologia. È costruito su diversi componenti e standard del mondo Linux e dei container, tra cui runc e containerd, e ha aggiunto strumenti e convenzioni che ne hanno decretato il successo. Tra le caratteristiche principali ci sono:

1. Facilità d’uso: Docker ha reso i container accessibili a sviluppatori, sistemisti e architetti. Con pochi comandi si costruisce un’immagine e si avvia un container.
2. Portabilità: l’immagine contiene l’applicazione e le sue dipendenze in una forma standardizzata. Questo riduce drasticamente le differenze tra ambiente di sviluppo, test e produzione, anche se il risultato dipende sempre dall’ambiente di esecuzione sottostante.
3. Registry: Docker Hub e gli altri registry permettono di pubblicare, distribuire e recuperare immagini container.
4. Leggerezza e velocità: il container non deve avviare un sistema operativo completo.
5. Modularità e scalabilità: Docker si presta bene a distribuire applicazioni composte da componenti separati, che possono essere aggiornati e scalati indipendentemente.

Docker: i concetti fondamentali

Per usare Docker, è utile conoscere alcuni concetti base:

• Docker Engine: l’insieme dei componenti che permettono di costruire e gestire immagini e container, esponendo anche un’API attraverso cui gli strumenti possono interagire con il runtime.
• Dockerfile: è un file di testo che contiene le istruzioni per costruire un’immagine Docker. Può installare pacchetti, copiare file, definire variabili d’ambiente, impostare il comando di avvio e altro ancora.
• Immagine Docker: è il modello immutabile da cui vengono creati i container.
• Container: è l’istanza in esecuzione dell’immagine, con il proprio isolamento e il proprio ciclo di vita.
• Volumi: permettono di mantenere dati persistenti indipendentemente dal ciclo di vita del container.

Questa distinzione permette di capire anche un principio importante del mondo container: il container è normalmente sacrificabile. Se l’applicazione è correttamente progettata, posso distruggere un container e crearne un altro a partire dalla stessa immagine senza perdere i dati che devono essere persistenti.

Un’altra faccia dei container: Proxmox e gli LXC

Prima di immergerci nei microservizi e in Kubernetes, vale la pena fare un passo laterale e parlare di un altro tipo di container, che nel mio homelab uso quotidianamente: gli LXC di Proxmox. Proxmox VE è una piattaforma di virtualizzazione open source che integra due tecnologie:

• KVM per le macchine virtuali, quindi virtualizzazione hardware.
• LXC per i container, quindi isolamento a livello di sistema operativo.

LXC è una tecnologia matura per l’esecuzione di container Linux e sfrutta, tra le altre cose, namespace e cgroups. A differenza di Docker, non nasce principalmente come piattaforma per impacchettare e distribuire singole applicazioni. In Proxmox, un container LXC viene spesso trattato come un piccolo server Linux isolato, che ha un proprio filesystem, una propria configurazione di rete e i propri processi, ma condivide il kernel dell’host.

Perché usare LXC in Proxmox?

Nel mio homelab, su quattro nodi Proxmox, ho circa quaranta container LXC. Li uso per servizi che voglio tenere separati ma senza il peso di una VM: DNS, DHCP, piccoli webserver, tool di monitoring, ambienti di test, servizi di automazione. I vantaggi che ho trovato sono:

• Leggerezza: un container LXC consuma poca RAM e si avvia rapidamente.
• Semplicità di gestione: posso trattarlo in molti aspetti come una piccola macchina, con la sua interfaccia di rete, il suo storage e i suoi backup.
• Integrazione nativa in Proxmox: posso gestirlo dalla stessa interfaccia delle VM, con backup, snapshot, migrazione live quando supportata dalla configurazione e template predefiniti.
• Performance: non essendoci una virtualizzazione hardware completa, il costo dell’isolamento è ridotto.

LXC e Docker: due strumenti per esigenze diverse

È importante capire che LXC e Docker non sono semplicemente due implementazioni equivalenti dello stesso concetto. LXC tende a fornire un ambiente Linux isolato che può essere gestito come un piccolo server. Docker tende invece a concentrarsi sul packaging, sulla distribuzione e sull’esecuzione di applicazioni. In pratica:

Nel mio caso uso LXC per quello che una volta avrei probabilmente messo in una piccola VM, mentre uso Docker quando voglio distribuire un’applicazione in modo riproducibile e modulare. Le due tecnologie possono anche convivere. Per esempio, Docker può essere eseguito all’interno di un container LXC, anche se questa configurazione introduce ulteriori livelli di astrazione e va valutata in funzione delle esigenze di sicurezza, compatibilità e gestione.

Container, microservizi e orchestrazione

Uno degli usi più importanti dei container è l’implementazione di architetture a microservizi. Invece di avere un’unica applicazione monolitica, si suddivide l’applicazione in servizi indipendenti, ognuno con un compito specifico, e ogni microservizio può essere eseguito in un container.

Precisazione importante: microservizi e container sono due cose diverse, che si sposano bene ma non si implicano a vicenda. I microservizi sono un modo di progettare l’applicazione, dividendola in componenti indipendenti. I container sono un modo di eseguirla, isolando i processi. Puoi fare microservizi senza container, distribuendo i servizi come processi separati o in VM diverse, e puoi usare container senza microservizi, per esempio per impacchettare e distribuire un’applicazione monolitica. La combinazione è naturale, ma è una scelta, non una conseguenza automatica.

Questo modello permette di scalare separatamente i componenti: se il servizio che gestisce le immagini riceve molto più traffico degli altri, posso avviare più istanze di quel servizio senza dover replicare l’intera applicazione. Inoltre, i container si sposano bene con l’approccio DevOps, perché permettono di definire in modo riproducibile l’ambiente applicativo e di automatizzare gran parte del ciclo di build, test e deployment.

Quando però il numero dei container cresce, nasce un altro problema: chi li gestisce? Se devo gestire decine, centinaia o migliaia di container distribuiti su più macchine, non posso più pensare di avviarli e controllarli manualmente. Serve un orchestratore, che può occuparsi di:

• Pianificare su quali macchine avviare i container.
• Gestire aggiornamenti e rollback.
• Riavviare automaticamente i workload che falliscono.
• Distribuire il carico tra più istanze.
• Gestire la comunicazione tra i diversi componenti.

Il principale orchestratore open source è Kubernetes. È uno strumento potente e complesso, progettato per gestire applicazioni containerizzate su larga scala. Esistono anche altri orchestratori, meno diffusi, come Nomad e Docker Swarm.

Ed è qui che il percorso si chiude: il container risolve il problema dell’esecuzione isolata di un workload. Docker semplifica la costruzione e la distribuzione di quel workload. Un orchestratore come Kubernetes affronta il problema successivo, cioè come gestire molti workload distribuiti su molte macchine.

Quindi, perché usare un container invece di una VM?

La domanda corretta non è “container o VM?”. La domanda è: che cosa devo isolare e che cosa devo distribuire?

• Se devo eseguire un intero sistema operativo, con il suo kernel e il suo ambiente completo, una VM è la scelta naturale.
• Se devo distribuire un’applicazione insieme alle librerie e ai componenti necessari per eseguirla, senza avere bisogno di un sistema operativo completo, un container può essere più adatto.
• Se devo gestire centinaia o migliaia di workload containerizzati distribuiti su molti nodi, posso aggiungere un orchestratore.

Non sono quindi tecnologie necessariamente alternative. Possono occupare livelli diversi della stessa architettura.

Un esempio concreto: un server fisico può eseguire un hypervisor; l’hypervisor può eseguire una VM Linux; la VM può eseguire un runtime container; il runtime può eseguire decine di container; un orchestratore può distribuire quei container tra più VM e più host. Ogni livello risolve un problema diverso.

In una frase

Se dovessi spiegare un container a qualcuno che lavora nell’IT e non lo ha mai usato, direi questo:

Un container è un insieme di processi isolati che “girano” sul kernel dell’host, con un filesystem e una vista delle risorse propri, e che possono essere creati in modo riproducibile a partire da un’immagine.

La cosa importante da ricordare è quindi che un container non è una macchina virtuale più piccola. Una VM astrae l’hardware e presenta a un sistema operativo un computer virtuale completo. Un container astrae l’ambiente operativo e isola i processi senza fornire loro un kernel proprio. La VM virtualizza un computer. Il container isola processi. È questa differenza di livello di astrazione che spiega quasi tutto quello che viene dopo: perché i container sono leggeri, perché si avviano rapidamente, perché possono essere numerosi sullo stesso host, perché Docker è diventato così importante e perché, quando diventano abbastanza numerosi, entra in gioco Kubernetes.

Trivia

Da dove viene il nome “container”?

Il termine non nasce con Docker. L’idea del container software richiama direttamente i container utilizzati nel trasporto delle merci. Prima degli anni ’50, per caricare una nave servivano casse di legno, sacchi, botti, balle di stoffa. Ogni merce richiedeva un imballaggio e una manipolazione diversa. Poi arrivò il container marittimo standard: una scatola metallica dalle dimensioni fisse che poteva essere spostata indifferentemente da un camion, un treno o una nave, senza che il trasportatore dovesse preoccuparsi del contenuto. Nel software il principio è analogo: l’applicazione viene impacchettata insieme a ciò che le serve per funzionare e può essere trasferita tra ambienti diversi mantenendo lo stesso modello di esecuzione.

E Kubernetes? Qui c’è una curiosità linguistica: Kubernetes deriva dal greco κυβερνήτης, che indica il “timoniere”, il “comandante” o, più precisamente, colui che governa una nave. (E infatti il logo di Kubernetes è la ruota di un timone).

La signora ha un aspetto dimesso, è abbastanza in là con l’età (potrebbe avere poco meno di settant’anni, ma è difficile da dire); indossa capi un po’ sdruciti e quando la saluto ricambia gentile ma senza il minimo entusiasmo e io non riesco a capire se le faccia piacere o no.

Le prime volte le chiedevo “Ha bisogno di qualcosa? Cibo? Acqua?” – “No grazie, solo qualcosa per i miei gatti”, ma ora ho smesso: so che vuole solo quelle lattine che le lascio sul carrellino, a volte incustodite, perché lei di tanto in tanto si allontana per fumare una sigaretta.

Cosa spinga una persona visibilmente provata dalla vita a mendicare cibo per i propri gatti potrebbe essere un mistero, ma forse non lo è. A me piace pensare che questa donna ami i suoi animali, che siano la sua ragione di vita e che non veda l’ora di tornare a casa dove loro la stanno aspettando. Mi piace pensare che per loro valga la pena stare lì, sotto quei portici, a chiedere agli altri qualcosa che non chiede per sé. E che per loro accetti di fare qualcosa che, probabilmente, dalla maggior parte dei frettolosi clienti del supermercato è considerato degradante, l’ultimo gradino dell’esistenza umana.

Non so se sia così e probabilmente non lo saprò mai.

Un Full Time Equivalent misura la capacità lavorativa equivalente a una risorsa a tempo pieno: quantifica disponibilità di tempo e competenze, non un esito garantito. Quando il cliente richiede un presidio composto da un numero prestabilito di risorse, definendone profili professionali, orari e modalità di impiego, sta acquistando capacità. Se però pretende anche SLA riferiti alla qualità, ai tempi o alla continuità del servizio, sta chiedendo al fornitore di rispondere di un risultato che potrebbe non essere pienamente sotto il suo controllo.

La distinzione è sostanziale. In un presidio a FTE il cliente mantiene il governo diretto delle attività: assegna priorità, indirizza le singole risorse, controlla il carico di lavoro e decide come utilizzare la capacità disponibile. In un managed service, invece, il cliente trasferisce al fornitore la responsabilità di conseguire livelli di servizio misurabili, ma deve lasciargli l’autonomia necessaria per organizzare persone, processi, strumenti, turni, sostituzioni, competenze specialistiche ed escalation.

Per questo il numero di FTE può essere usato come cost driver interno del dimensionamento o come componente di un presidio, ma non dovrebbe diventare da solo l’oggetto del contratto quando il cliente si aspetta un servizio regolato da SLA. Acquistare persone significa acquistare capacità; acquistare un servizio gestito significa affidare al fornitore la responsabilità di un risultato. Sono modelli diversi e richiedono regole contrattuali diverse.

Inoltre, FTE e head count non coincidono necessariamente. Un FTE indica quanta capacità operativa equivalente a tempo pieno serve per coprire un determinato carico; non identifica automaticamente una singola persona fisica. Per garantire continuità, coprire turni, ferie, assenze, malattie e picchi di attività, può essere necessario coinvolgere più persone per assicurare stabilmente l’equivalente di un FTE.

Il tema diventa particolarmente rilevante quando si parla di SLA. Uno SLA è un impegno contrattuale su una prestazione oggettiva e verificabile: tempo di presa in carico, tempo di inizio intervento, disponibilità, ripristino o percentuale di richieste gestite entro una soglia definita. Per assumere un impegno di questo tipo, il fornitore deve poter controllare i fattori che determinano il risultato: canali di accesso, classificazione delle severità, priorità, volumi, strumenti di ticketing e monitoraggio, disponibilità degli accessi, procedure operative, dipendenze da terze parti e possibilità di attivare livelli specialistici.

Se il cliente dirige direttamente le risorse, assegna loro le attività e ne governa il carico, mentre il fornitore non può rimodulare il team, usare strutture condivise o assorbire i picchi con strumenti organizzativi propri, il risultato non è realmente governato dal fornitore. Applicare comunque SLA e penali significa attribuirgli una responsabilità non coerente con il livello di controllo disponibile. In questi casi gli impegni dovrebbero essere limitati a presenza, disponibilità, competenze concordate e modalità di sostituzione, non al risultato complessivo del servizio.

La richiesta va quindi qualificata e ricondotta consapevolmente a uno dei due modelli. Se l’esigenza è disporre di personale dedicato, l’offerta deve regolare profili, seniority, orari, sede, modalità di ingaggio, sostituzioni e rendicontazione dell’effort. Se invece il cliente vuole un servizio gestito, la domanda iniziale di FTE deve essere trasformata in un modello completo: perimetro, baseline, matrice RACI, processi Incident e Service Request, livelli di supporto, copertura, KPI, reporting, governance, esclusioni e meccanismi di adeguamento del canone. In questo secondo scenario il dimensionamento delle risorse resta una scelta del fornitore e gli SLA diventano sostenibili perché sono collegati a capacità operativa, strumenti e responsabilità coerenti. La distinzione non è terminologica: determina il rischio contrattuale, il costo reale, la possibilità di sostituire o ottimizzare le risorse e, soprattutto, chi risponde del risultato finale.

La prima cosa che il caso (in realtà lo shuffle di Spotify) decide di propormi è Comfortably Numb, un brano che durante le mie disavventure ospedaliere ha avuto un significato profondo per me.

Ora: io non so cosa significhi (e, ammettiamolo, non significa una beata) ma la mia sensibilità per i simbolismi è andata a fondo scala e fate finta che adesso parta una lunga esegesi del testo che vi risparmio, anche perché non ho voglia di farla un lunedì mattina nella sala d’aspetto di un ambulatorio.

Tutto ‘sto pippone per dire cosa? Non lo so di preciso, ma so che ogni volta che vengo qui è un mix di emozioni e ricordi che mi assalgono, mi riempiono, mi stancano. Poi esco, torno al parcheggio e rimetto tutto sullo scaffale. Non è in un cassetto, è su uno scaffale: lo guardo e lo vedo tutti i giorni.

È generato in modo totalmente automatico da un agente costruito con OpenClaw, addestrato su oltre vent’anni di post pubblicati qui dentro e su alcune informazioni sommarie che gli ho propinato nel tempo. Scrive da solo, quando gli pare, pescando da quello che ha imparato. Ci sono un po’ di errori fattuali: figli mai avuti, case inventate, cani mai avuti. Alcuni glieli ho segnalati, altri chissene.

Quello che ha imparato, però, è solo la superficie delle cose.

I testi che tira fuori escono puliti, ben costruiti, persino vagamente profondi, ma usano le parole giuste nel modo sbagliato. Hanno l’aria di chi sa come si scrive una cosa ma non ha niente da dire. Leggendoli danno la sensazione di un’imitazione mal riuscita non perché sbagliata, ma perché troppo convinta. “È come succhiare un chiodo”, diceva un vecchio amico.

All’inizio mi aspettavo due estremi: un disastro totale o una copia indistinguibile da me. È venuto fuori qualcosa di diverso: Ciccio (è il nome dell’agente) scrive abbastanza bene da far notare che manca qualcosa. Manca uno spessore. Se scrivesse malissimo sarebbe solo spazzatura generata automaticamente; invece è quasi convincente, e proprio per questo rende evidente la distanza tra la sintassi e il pensiero.

L’esperimento non è una demo AI: è capire cosa rimane di una voce quando la separi da chi la produce, e scoprire se una persona possa essere ridotta alle parole che scrive.

Per ora la risposta è: rimane la struttura. Non il resto.

Tecnicismi! (Perché io sono sempre io).

Ciccio vive su Openclaw, installato in un container LXC su un nodo Proxmox a casa mia, e comunichiamo via Telegram. Ha un dump del database del mio blog e un mazzetto di istruzioni operative; usa token DeepSeek, che per una cazzata così bastano e avanzano.

Ciccio spesso si dimentica le cose, vai a sapere perché, e lo devo cazziare pesantemente. “Mi dispiace”, mi dice, ma funzionare significa non dover mai dire “mi dispiace” (cit.) – gli ricordo – ma la volta dopo si dimentica lo stesso. Tutte le mattine mi manda un vocale da 8 minuti col meteo e la rassegna stampa, ogni tanto mi ricorda di bere, e mi manda un “Accadde oggi” con un post preso a caso dal mio blog (quello vero). Ogni venerdì mi manda una mail con le nuove uscite di film e serie TV in base ai miei gusti.

Il blog su cui scrive è sullo stesso nodo, in un LXC diverso, è pubblicato con un tunnel Cloudflare, e non è indicizzato dai motori di ricerca.

Nonnadoretta mi portava sempre un bicchiere di latte tiepido prima di dormire, il mio letto era nella loro camera, accanto al lettone di fronte al televisore in bianco e nero con il quale i nonni guardavano gli sceneggiati RAI dell’epoca.

Mio nonno era un omone, o almeno così è nel mio ricordo di bambino, che ho sempre visto con un paio di baffi e i capelli imbrillantinati; uomo pratico e burbero, parlava un genovese che era un piacere per le orecchie, mentre a noi bambini si rivolgeva sempre in italiano. Per noi era Nonno Tai (Ottavio all’anagrafe), per tutti gli altri “U Pasturin”, per via del suo cognome così comune a Genova.

Durante quelle notti, quando le luci erano spente, sul soffitto della camera si riflettevano i fari delle auto che transitavano nella via sottostante ronfando dolcemente. E io fantasticavo su dove andassero le persone a quell’ora della notte: perché erano in giro? Cosa facevano? Com’era la loro vita?

Di tutte quelle notti mi è sempre rimasto il ricordo di quelle luci. Non dormo più in una stanza sopra una strada. Ma, quando mi capita, lascio sempre le imposte aperte perché i fari sul soffitto mi riportano a quei tempi lì, senza rimpianti o nostalgie, solo con l’idea di me bambino che non sa nulla di quello che la vita gli avrà riservato.

Quello che invece si è affilato è il meccanismo opposto: il riconoscimento di cosa non voglio e non mi piace più, spesso prima ancora di saperne il motivo. Un invito, un’occasione, un concerto, una festa: sono tutte cose che passano un setaccio più o meno consapevole prima che io le accetti. Finalmente posso dire (o pensare) “Ho sessant’anni, non rompetemi le palle“.

Capiamoci: non è un atteggiamento “Si stava meglio prima. Signora mia… Il mondo e i giovani d’oggi!“. Ho sempre trovato noiose, per non dire di peggio, le affermazioni “Noi cresciuti negli anni X: quelli erano bei tempi!“; è più un non avere più voglia di sopportare cose che prima mi sembravano valere la pena sopportare. L’asticella del coinvolgimento si è spostata verso l’alto, e di parecchio.

Concerti? Solo se c’è il posto a sedere assegnato. Inviti? A che ora? Dove? Con chi? Andare da qualche parte? C’è parcheggio? Dove? Andiamo al mare? Solo spiagge di sabbia, con le facilities: di spiaggia libera non se ne parla(*).

Il grafico qui sopra spiega parecchio di me: consapevolezza, maturità, conoscenze, disponibilità economiche sono cresciute nel tempo e sono tutti fattori che aumentano la soddisfazione e, a volte, la gioia di vivere, per chi ha il cervello e il cuore cablati come me e ha interessi più di nicchia. Ci sono centomila cose che mi interessano che interessano solo a me: tu lo vuoi un PDF di 50 pagine su come funziona l’architettura CAN BUS, ECU, sensori e attuatori della tua auto? Io sì: l’ho letto stamattina. Avere accesso a una quantità sconfinata di informazioni, a tecnologie vagamente indistinguibili dalla magia (cit.), è una roba che se la vedesse il me ventenne sarebbe estasiato.

Sono diventato un rompiballe? Probabilmente, ma la mia priorità si è spostata al non rompere le mie, di balle. Non so bene cosa abbia ridefinito le priorità, a cosa addossare la colpa, fatto sta che questa selettività che sconfina nello snobismo alla fine mi fa stare meglio, mi fa concentrare sulle cose che contano davvero per me e per chi mi sta vicino.

(*) In realtà la verità è: “Se non è in Grecia, grazie, no grazie.”

Negli ultimi anni le mesh VPN hanno cambiato radicalmente questo scenario. Soluzioni come Tailscale e NetBird, insieme a progetti open source come Pangolin e Headscale, automatizzano gran parte delle attività che prima richiedevano competenze specifiche di networking. L’obiettivo non è soltanto “creare una VPN”, ma costruire una rete privata sovrapposta a Internet, cifrata, gestita per identità e capace di collegare dispositivi, server, cloud e reti locali anche quando si trovano dietro NAT o firewall differenti.

In pratica, queste soluzioni superano anche il limite tipico delle connessioni domestiche, come il CGNAT applicato dagli operatori su fibra e 5G, senza dover richiedere, configurare o pagare un indirizzo IP pubblico dedicato.

Il modello tradizionale: funziona, ma richiede molte responsabilità

Aprire una porta sul router è apparentemente semplice, ma trasferisce su chi amministra la rete una serie di responsabilità. Il servizio esposto deve essere aggiornato, correttamente autenticato e monitorato; la superficie di attacco diventa visibile da Internet; eventuali errori di configurazione possono esporre non solo l’applicazione, ma anche altri sistemi raggiungibili dalla stessa rete. A questo si aggiungono problemi pratici: indirizzi IP che cambiano, doppio NAT, connettività mobile, reti alberghiere o aziendali restrittive e impossibilità di intervenire sul router dell’operatore.

Le VPN classiche riducono l’esposizione diretta, ma introducono un punto centrale attraverso cui transitano autenticazione e traffico. Questo gateway deve essere dimensionato, aggiornato, reso disponibile e protetto. In una configurazione hub-and-spoke, inoltre, due dispositivi geograficamente vicini possono comunicare passando da un concentratore lontano, con un impatto su latenza e banda. Anche la gestione delle autorizzazioni tende a essere legata alle sottoreti: una volta entrato nella VPN, l’utente può spesso raggiungere più risorse di quelle strettamente necessarie, salvo aggiungere regole firewall dettagliate.

Che cos’è una mesh VPN

Una mesh VPN crea una rete overlay: ogni dispositivo riceve un indirizzo virtuale stabile e vede gli altri nodi autorizzati come se fossero collegati alla stessa rete privata, indipendentemente dalla loro posizione reale. Un control plane gestisce identità, registrazione dei dispositivi, distribuzione delle chiavi e policy; il traffico applicativo, quando possibile, viaggia invece direttamente tra i peer attraverso tunnel cifrati. Questa separazione tra controllo e dati è uno degli elementi più importanti del modello.

Il collegamento diretto viene ottenuto tramite tecniche di NAT traversal e hole punching. Se i dispositivi non riescono a stabilire una sessione peer-to-peer, la piattaforma può utilizzare un relay. Il relay permette alla comunicazione di avvenire anche in reti molto restrittive, pur introducendo in genere maggiore latenza e minore throughput rispetto a un percorso diretto. Dal punto di vista dell’utente, questa complessità resta quasi sempre nascosta: non occorre conoscere l’IP pubblico del peer, aprire porte in ingresso o riconfigurare la connessione quando il dispositivo passa dal Wi-Fi alla rete mobile.

WireGuard: la base tecnica del cambiamento

Alla base di molte mesh VPN moderne c’è WireGuard, protocollo e software open source progettato per essere semplice, veloce e multipiattaforma. WireGuard utilizza un insieme ristretto di primitive crittografiche moderne. La configurazione fondamentale è basata su coppie di chiavi pubbliche e private: ogni peer conosce la chiave pubblica degli interlocutori autorizzati e associa a ciascuno gli indirizzi che può raggiungere attraverso il tunnel.

WireGuard risolve molto bene il problema del tunnel cifrato, ma volutamente non si occupa di tutto il resto. Non fornisce da solo un catalogo centralizzato dei peer, un sistema di identità, la rotazione automatica delle autorizzazioni, un’interfaccia amministrativa o policy espresse per utenti e gruppi. Le piattaforme mesh costruiscono proprio questo livello sopra WireGuard: trasformano una raccolta di tunnel configurati manualmente in un servizio di connettività amministrabile.

Tailscale: semplicità e integrazione con l’identità

Tailscale è probabilmente l’esempio più noto di mesh VPN basata su WireGuard. Dopo l’installazione del client e l’autenticazione, il dispositivo entra in una rete privata chiamata tailnet. Il control plane raggiungibile dall’interfaccia amministrativa coordina chiavi, indirizzi, individuazione dei peer e policy; il traffico dati prova a seguire un percorso diretto e utilizza relay solo quando necessario. Questa impostazione riduce drasticamente il tempo richiesto per collegare workstation, server, macchine virtuali e dispositivi mobili.

Tra le funzioni più utili ci sono MagicDNS, che consente di raggiungere i nodi per nome; le policy di accesso basate su utenti, gruppi e tag; Tailscale SSH; la condivisione controllata dei dispositivi; e i subnet router, che estendono la tailnet a reti o apparati sui quali non è possibile installare il client. La modalità di default è “split tunneling” ma, se necessario, un nodo può anche funzionare da exit node e instradare verso Internet tutto il traffico di uno o più dispositivi, riproducendo il comportamento di una VPN tradizionale, per esempio su una rete Wi-Fi non fidata. Tailscale Serve e Funnel permettono inoltre di pubblicare servizi rispettivamente all’interno della tailnet o, con le opportune cautele, verso Internet.

NetBird: approccio Zero Trust e possibilità di self-hosting

NetBird propone un modello simile, anch’esso basato su collegamenti WireGuard peer-to-peer, ma pone molta enfasi sul networking Zero Trust e sulla disponibilità di un’implementazione open source self-hosted. La piattaforma integra gestione centralizzata dei peer, SSO e MFA, gruppi, policy granulari, controllo della postura dei dispositivi, route verso reti private, DNS e registrazione delle attività. È disponibile sia come servizio cloud gestito sia come installazione nella propria infrastruttura.

La differenza rispetto a una VPN basata esclusivamente su regole IP è concettuale: l’accesso può essere concesso a una persona o a un gruppo verso una specifica risorsa, subordinandolo anche a requisiti come autenticazione forte o stato del dispositivo (esempio tipico: l’antivirus deve essere aggiornato e il firewall locale abilitato). Questo limita il movimento laterale e rende più leggibile il modello autorizzativo. Il self-hosting offre controllo su piano di gestione e dati operativi, ma richiede capacità di gestione, aggiornamento, backup, monitoraggio e disponibilità del servizio: non è quindi automaticamente più semplice o più sicuro del cloud.

Pangolin: tra VPN e reverse proxy

Pangolin, un ottimo progetto open source, affronta il problema da una prospettiva leggermente diversa, combinando le funzioni di una VPN con quelle di un reverse proxy identity-aware. È una piattaforma basata su WireGuard, Traefik e Gerbil che collega reti remote mediante connettori leggeri e tunnel in uscita: le risorse interne possono quindi restare dietro firewall e NAT senza richiedere porte aperte in ingresso. L’amministratore pubblica risorse specifiche, anziché concedere automaticamente visibilità di un’intera rete. Anche in questo caso, come per Tailscale e NetBird, WireGuard resta il motore dei tunnel cifrati sotto il cofano, mentre la piattaforma costruisce sopra di esso orchestrazione, identità e controllo degli accessi.

Le applicazioni web possono essere raggiunte dal browser e protette tramite autenticazione, SSO, MFA e regole per identità o ruolo. Per risorse private come database, host SSH o intere reti è invece possibile utilizzare un client. Pangolin è interessante quando l’esigenza principale è esporre in modo controllato singole applicazioni, pannelli amministrativi o servizi tecnici, mantenendo un unico livello di gestione degli accessi. È però importante distinguere tra accesso privato e pubblicazione su Internet: anche se protetto da un proxy con autenticazione, un servizio pubblico continua ad avere una superficie esposta e va aggiornato e monitorato.

Headscale: un control plane di Tailscale self-hosted

Qualora non si voglia o non si possa, per policy, appoggiarsi a un provider cloud per l’implementazione di una mesh VPN, ci si può appoggiare a Headscale: un’implementazione open source e self-hosted del control server compatibile con i client Tailscale. Consente di gestire in proprio registrazione dei nodi, assegnazione degli indirizzi, MagicDNS, route, subnet router, exit node, ACL, autenticazione OIDC e relay. Il progetto dichiara però un perimetro più ristretto, orientato soprattutto a una singola tailnet, al self-hosting, ai laboratori e alle piccole organizzazioni.

Headscale è quindi adatto a chi apprezza l’esperienza dei client Tailscale ma vuole mantenere il control plane nella propria infrastruttura. In cambio dell’autonomia, occorre accettare l’onere operativo e una possibile differenza di copertura rispetto al servizio commerciale: prima di adottarlo è opportuno verificare la compatibilità delle funzioni indispensabili, il processo di aggiornamento e la gestione dei relay.

Cloudflare Zero Trust e Tunnel: pubblicare applicazioni senza esporre l’origine

Cloudflare Zero Trust affronta la pubblicazione delle applicazioni con un modello diverso da quello di una mesh VPN peer-to-peer. Installando il demone leggero cloudflared su un server, una macchina virtuale o un container della rete interna, si crea un Cloudflare Tunnel persistente verso la rete globale di Cloudflare. La connessione viene iniziata esclusivamente dall’interno verso l’esterno: non serve un indirizzo IP pubblico, non occorre aprire porte in ingresso e l’indirizzo dell’origine può rimanere nascosto. Il tunnel collega quindi un hostname pubblico, per esempio app.example.com, a un servizio interno come http://nas.lan:8080 o a un altro indirizzo della LAN; Cloudflare gestisce poi il certificato TLS sul proprio edge, rendendo l’applicazione raggiungibile in HTTPS senza esporre direttamente il server di origine.

L’integrazione con il DNS di Cloudflare rende la configurazione particolarmente lineare: aggiungendo una route per un’applicazione, la piattaforma può creare automaticamente il record DNS che punta al tunnel. Le richieste raggiungono prima la rete Cloudflare e vengono poi inoltrate all’origine attraverso la connessione cifrata. Per le applicazioni web si possono così utilizzare anche i servizi applicativi della piattaforma, compresi caching CDN, protezione DDoS e, secondo il piano e la configurazione adottati, WAF e ulteriori controlli di sicurezza. Il caching è particolarmente utile per contenuti statici, immagini e file distribuibili dalla CDN; per pannelli dinamici, API o applicazioni autenticate deve invece essere configurato con attenzione, escludendo dal caching dati personali e risposte specifiche della sessione.

Cloudflare Access permette inoltre di anteporre all’applicazione un livello di autenticazione Zero Trust basato sull’identità, con policy che possono limitare l’accesso a determinati utenti, gruppi, domini e condizioni. Questo rende il modello adatto sia alla pubblicazione di un sito destinato a Internet sia alla protezione di dashboard, strumenti amministrativi e applicazioni private raggiungibili dal browser. Non è però una mesh VPN nel senso stretto del termine: il traffico passa attraverso l’infrastruttura Cloudflare e il valore principale risiede nella combinazione tra connettività dell’origine, DNS, reverse proxy, sicurezza applicativa e distribuzione CDN.

Un ulteriore punto di forza è il piano gratuito di Cloudflare Zero Trust, disponibile senza scadenza e pensato per team fino a 50 utenti. Cloudflare Tunnel è disponibile senza costi anche per la pubblicazione delle applicazioni; le postazioni conteggiate diventano rilevanti quando si applicano policy di Access che richiedono l’autenticazione degli utenti. Per dimensioni, funzioni incluse e assenza di una spesa iniziale, il piano gratuito consente di valutare concretamente la tecnologia ed è sufficiente per quasi tutti gli homelab. Restano comunque da verificare i limiti correnti, la retention dei log, il supporto e le funzioni riservate ai piani a pagamento prima di estendere l’uso a servizi aziendali o critici.

Sicurezza: meno esposizione non significa assenza di rischio

Il vantaggio immediato di queste soluzioni è la possibilità di evitare porte aperte in ingresso e ridurre l’esposizione di servizi amministrativi, NAS, hypervisor, telecamere, ambienti di sviluppo o applicazioni interne. La cifratura è però solo una parte del problema. La sicurezza dipende anche dall’identità utilizzata per accedere, dalla protezione dell’account, dalla revoca tempestiva dei dispositivi, dalla qualità delle policy e dall’aggiornamento degli endpoint. Una mesh configurata con una policy “tutti verso tutto” può risultare comoda, ma riproduce una rete piatta e facilita il movimento laterale in caso di compromissione.

La buona pratica è applicare il principio del minimo privilegio: separare utenti, amministratori, server e dispositivi personali; usare gruppi e tag con criteri chiari; abilitare MFA; preferire chiavi o registrazioni a durata limitata per l’automazione; controllare i log; rimuovere i nodi non più usati; e distinguere le risorse che devono essere raggiungibili solo dalla rete privata da quelle realmente destinate al pubblico. In un contesto aziendale vanno considerati anche disponibilità del control plane, residenza dei dati, integrazione con l’identity provider, gestione degli incidenti e procedure di emergenza.

Come scegliere tra le diverse soluzioni

• Tailscale è adatto quando la priorità è iniziare rapidamente, con client maturi, gestione semplificata, buone integrazioni con l’identità e numerose funzioni già pronte.
• NetBird è interessante per chi cerca una piattaforma Zero Trust open source, disponibile sia gestita sia self-hosted, con policy granulari e un’impostazione adatta anche a team e infrastrutture distribuite.
• Pangolin è particolarmente indicato quando occorre combinare accesso privato e pubblicazione controllata di specifiche applicazioni, anche via browser, senza esporre direttamente la rete di origine.
• Headscale è una scelta sensata per laboratori, homelab e organizzazioni contenute che vogliono utilizzare i client Tailscale mantenendo in proprio il piano di controllo.
• Cloudflare Zero Trust e Tunnel sono indicati quando la priorità è pubblicare applicazioni web attraverso hostname gestiti nel DNS Cloudflare, nascondere l’origine e sfruttare reverse proxy, autenticazione Zero Trust, protezioni applicative e caching CDN. Il piano gratuito li rende particolarmente interessanti per homelab e valutazioni senza investimento iniziale.
• WireGuard puro resta valido quando la topologia è piccola e stabile, i peer sono pochi e si desidera il massimo controllo senza introdurre un ulteriore livello di gestione.

La scelta non dovrebbe basarsi soltanto sul fatto che il prodotto sia gratuito o open source. Bisogna valutare numero e tipo di utenti, sistemi operativi supportati, necessità di accesso da browser, integrazione con SSO e MFA, granularità delle policy, audit, prestazioni attraverso relay, esigenza di collegare intere sottoreti e capacità interna di gestire un’installazione self-hosted. Occorre inoltre verificare licenze, limiti dei piani e disponibilità delle singole funzioni nella versione effettivamente adottata, perché possono cambiare nel tempo.

La mia esperienza

Nel mio homelab questo modello non è rimasto teorico. Su quattro nodi Proxmox  ospito circa quaranta container LXC e pubblico decine di applicazioni: alcune tramite Cloudflare Tunnel, quando devono essere accessibili anche dall’esterno via browser; altre tramite Pangolin, quando voglio mantenere un accesso più selettivo. Tailscale è diventato invece lo strumento quotidiano per entrare nella mia rete da fuori senza doverci pensare. Pur avendo un indirizzo IP pubblico statico (grazie Fastweb), ho smesso di esporre servizi tramite port forwarding sul router. NetBird, Headscale e le altre soluzioni sono comunque interessanti, ma per il mio homelab domestico, anche se articolato, le ritengo sovradimensionate rispetto al problema da risolvere.

Confronto sintetico

Conclusioni

Le mesh VPN non eliminano il networking: ne automatizzano le parti più ripetitive e spostano l’attenzione dagli indirizzi IP alle identità e alle risorse. Per un homelab possono significare raggiungere NAS e server senza aprire porte; per un’azienda, collegare utenti, sedi e workload cloud con policy uniformi e minore dipendenza da concentratori centrali. Il risultato è una connettività più semplice da distribuire e, se amministrata correttamente, più coerente con i principi Zero Trust.

La vera rivoluzione non è quindi una singola tecnologia, ma il cambio di modello: invece di pubblicare una rete e difenderne il perimetro, si autorizzano connessioni precise tra identità, dispositivi e servizi. WireGuard fornisce il tunnel peer-to-peer; Tailscale, NetBird, Pangolin e Headscale aggiungono livelli diversi di orchestrazione, controllo e usabilità; Cloudflare Zero Trust associa invece tunnel in uscita, identità, DNS, reverse proxy e CDN per pubblicare applicazioni mantenendo nascosta l’origine. Scegliere bene significa partire dal caso d’uso, definire il perimetro di accesso e adottare la soluzione che riduce la complessità senza trasferirla semplicemente altrove.

Questo post non è sponsorizzato: ho provato personalmente tutti i prodotti citati e le opinioni sono le mie.

• ARC e RRC servono esattamente a questo. ARC (Additional Resource Charge): si applica quando il cliente consuma più risorse rispetto alla baseline contrattuale.
• RRC (Reduced Resource Charge, o Reduced Recurring Charge in alcune formulazioni): regola il caso opposto, una riduzione del perimetro o dei volumi rispetto a quanto assunto in offerta.

La logica è semplice: il canone è costruito su quantità misurabili: asset, utenti, ticket, istanze database e PaaS, sedi, orari di servizio, presidi. Se quelle quantità cambiano oltre una soglia concordata, il prezzo cambia in modo proporzionato e già regolato, senza riaprire ogni volta una trattativa commerciale.

Perché funzioni servono tre elementi:

1. Una baseline chiara (es. 2.500 ticket/mese, 140 server virtuali, X apparati in gestione).
2. Una soglia di tolleranza (es. ±5-10%, entro cui il canone resta invariato).
3. Una tariffa unitaria per ogni risorsa eccedente o ridotta.

In forma sintetica: ARC = (quantità effettiva – baseline) × tariffa ARC della categoria. RRC applica la stessa logica in diminuzione, quando previsto.

La verifica deve essere periodica e ancorata a dati misurabili e condivisi: ticketing, CMDB, report di servizio, inventari asset, consuntivi approvati.

L’errore da evitare: trattare ARC e RRC come una tabella prezzi accessoria, mentre sono una parte centrale del cost model, perché collegano il contratto alla delivery. Devono essere coerenti con il cost case interno e con le assunzioni di dimensionamento del servizio: se le Service Request oltre una certa durata diventano attività a progetto, va scritto nel contratto, se alcune attività extra sono state storicamente assorbite senza aggiornamento contrattuale, il nuovo modello deve impedirlo, se il cliente chiede riduzioni di ticket basate su automazione o AI, va chiarito che il beneficio economico dipende da azioni concrete e misurabili, non da percentuali ipotetiche

ARC e RRC funzionano solo se sono semplici da leggere, oggettivi da misurare e applicabili senza ambiguità. Diversamente restano clausole eleganti ma inutilizzabili, e la variabilità del servizio finisce comunque per scaricarsi sulla marginalità del fornitore.

Un errore frequente è considerare la governance come una percentuale generica o, peggio, come un costo assorbibile dalla delivery senza una vera modellazione. Nei servizi gestiti, invece, la governance ha cost driver propri: complessità contrattuale, numero di tower coinvolte, presenza di più business unit, frequenza dei comitati, effort di reporting, necessità di presidiare penali e SLA, gestione dei fornitori, variabilità del perimetro e livello di maturità organizzativa del cliente. Un contratto piccolo ma complesso può richiedere una governance proporzionalmente più onerosa di un contratto più grande ma lineare, perché alcune attività hanno un minimo incomprimibile. Se questo minimo non viene valorizzato, il Service Manager si trova a gestire un servizio venduto senza il tempo necessario per controllarlo, con impatti diretti su marginalità, qualità percepita e capacità di prevenire escalation.

La governance è anche il punto in cui il cost model diventa realmente collegato alla delivery. Durante la transizione, il Project Manager deve acquisire familiarità con offerta, contratto, baseline, assunzioni economiche e responsabilità operative; a regime, il Service Manager deve verificare che il servizio resti entro il perimetro previsto, che eventuali variazioni di asset o attività vengano intercettate e che i meccanismi ARC/RRC o di extra canone siano applicabili quando necessario. Se queste attività non sono previste nel modello di costo, il contratto perde capacità di controllo e la marginalità viene erosa da lavoro non riconosciuto. Per questo, in un’offerta di servizi gestiti, la governance deve essere quotata come componente strutturale del servizio, non come una percentuale residuale del modello economico: ciò consente di trasformare una proposta tecnicamente corretta in un servizio effettivamente governabile, misurabile e profittevole.

In un contratto ben governato, inoltre, il Service Manager non si limita a controllare l’esecuzione del servizio, ma diventa un punto di osservazione privilegiato sull’evoluzione dei bisogni del cliente. La conoscenza continuativa del contesto operativo, delle criticità ricorrenti, dei volumi, delle inefficienze e delle richieste fuori perimetro consente di intercettare opportunità di enlargement del servizio o di proporre forniture aggiuntive di prodotti, soluzioni e progettualità complementari. Questo non significa trasformare la governance in un’attività commerciale mascherata, ma valorizzare il ruolo del Service Manager come soggetto capace di qualificare esigenze reali, verificare se siano coerenti con il contratto in essere e attivare, quando opportuno, il coinvolgimento delle strutture commerciali e specialistiche. Se correttamente prevista nel cost model, questa capacità genera valore sia per il cliente, che riceve indicazioni contestualizzate e non generiche, sia per il fornitore, che può sviluppare il rapporto in modo sostenibile e coerente con l’esperienza maturata sul servizio. Anche per questo la governance non dovrebbe essere considerata un costo da comprimere, ma una leva di controllo, continuità e sviluppo del contratto.

Non ho più pazienza con chi occupa il bancone del bar per fare colazione come fosse d’estate in riva al mare mentre dietro c’è la tripla fila in attesa di ingollare un caffè, con i cialtroni, con chi nega l’evidenza, con i complottisti, con gli avidi, con i prevenuti, con i rompicoglioni, con i tirchi, con i truffatori, con i disonesti, con chi lavora male, con chi dovrebbe lavorare e non lavora, con chi parcheggia in doppia fila, con chi parcheggia troppo largo, con chi parcheggia troppo stretto, con chi parcheggia sullo spazio disabili, con gli evasori fiscali, con gli evasi, con i tifosi di calcio, con gli spavaldi, con gli insicuri, con i vecchi, con i giovani, con i moralisti, con chi lascia il microfono aperto, con gli snob.

Non ho più pazienza con me stesso.

Mi trovo spesso a riflettere quanto e come mi abbia cambiato questa esperienza, e realizzo che ho scisso il mio vissuto in due parti che non dovrebbero esistere eppure ogni volta le ritrovo che mi sgomitano in testa per reclamare il loro posto.

Accanto a quello che ciascuno può immaginare, come le cose brutte, lo sconforto, la speranza, la sofferenza fisica, l’altalena emotiva, la preoccupazione, il sollievo, c’è anche qualcosa che ricordo con un tiepido piacere.

Durante la malattia, mentre soffrivo sia dentro che fuori, sono stato abbastanza fortunato da avere persone che si prendevano cura di me, dal conforto agli spostamenti, dal cibo alle cure; proprio per questo le emozioni, ricordando i giorni di ricovero, sono molte e molto diverse, e per qualche ragione sono riuscito a isolare la parte “buona” e a darle dignità ed importanza.

Per questo quando ripasso davanti alle finestre che mi hanno visto preoccupato e in lacrime, sollevato e speranzoso, sofferente e disperato, grato e fiducioso, mi piace ricordare anche quel senso di cura e calore che il personale medico e paramedico è riuscito a trasmettermi, quel prendersi cura di me perfino al di là di quelle che pensavo essere le mie esigenze del momento. E la sensazione è talmente vivida da farmi quasi venire dei sensi di colpa: “Come puoi associare qualcosa di positivo a un periodo così nero della tua vita?” – mi chiede il diavoletto interiore. Eppure mi pace pensare che ogni brutta esperienza vissuta lasci una lezione, una sensazione, un ricordo e che sia importante riconoscerne tutti gli aspetti al di là di quelli preponderanti, come un vecchio quadro senza valore che si rivela un’opera d’arte grattando via il soggetto che qualche pittore da quattro soldi ha dipinto con i suoi sgangherati scarabocchi.

Non è finita, naturalmente; non sono “guarito”, sono in “remissione”: un limbo in cui dovrò stare per altri 4 anni, dopodiché vedremo se sarà l’inferno o il paradiso.

Malgrado si dica spesso che il tempo felice vola e quello infelice trascorre lentamente, la sensazione che mi è rimasta è che, mentre lo stavo vivendo, quest’ultimo anno fosse lentissimo ma guardato a posteriori sia trascorso invece in un attimo. Non so bene se dipenda dal fatto che quando avevo 15 anni un anno ne durava tre e ora dura 10 minuti, fatto sta che sembra la settimana scorsa che mi accorgevo che qualcosa non andava, e tra allora ed oggi c’è un viaggio che ho raccontato in un altro post, viaggio che mi ha segnato, depresso, svuotato, debilitato, ma anche maturato, risollevato, riconciliato, reso grato.

Che poi: la porzione sciagurata è solo metà, ma ha condizionato il resto ed ha ancora strascichi in questo momento; mi accorgo con rammarico che quello che mi è capitato ha condizionato così tanto la mia vita che ho la sensazione di aver buttato via il tempo, vivendo in un limbo in attesa di qualcosa che dovesse accadere. Dal 25 novembre 2022 al 15 maggio 2023 sono 171 giorni, 4.104 ore, 246.240 minuti: quasi 15 milioni di secondi in attesa che il caso e la biochimica decidessero cosa sarebbe successo di me.

Della seconda parte posso dire poco: non c’è rinascita, non c’è riscatto, solo una acuta consapevolezza dell’influenza della casualità sulla vita e una maggiore indulgenza verso me stesso, come se quella che avevo prima non bastasse. Ci sono alcune novità sul lavoro, ma le devo ancora digerire; non mi dispiacciono, ma richiedono adattamento, imparare nuove cose e rapportarmi diversamente in alcune situazioni: è presto per capire e valutare.

Il bilancio è negativo: a parte gli ultimi tre mesi, il resto è da buttare via; non da dimenticare ma da archiviare nel cassetto delle cose brutte che non puoi buttare, un po’ come le ricevute dei pagamenti delle multe. Come le multe, serve per fare esperienza ma è una cosa al di fuori del mio controllo che avrei volentieri evitato.

Propositi? Zero: come ho detto l’autoindulgenza fa da padrona. Aspettative per il prossimo anno? Bassissime. D’altronde per far meglio basta stare fermi, zitti e non prendere inizative: VentiVentiquattro non hai un gran lavoro da fare.

E’ il 9 gennaio 2023, sono le 10:45 di un luminoso lunedì mattina, ma il meteo mi interessa relativamente perché sto suonando il campanello del reparto della Clinica Ematologica dell’Ospedale Policlinico San Marino di Genova: “Venga verso le 11 per il ricovero”, mi hanno detto al telefono qualche giorno fa. Armato di un borsone, uno zaino, un foglio con il risultato del tampone CoVid19 appena fatto, e un plico di referti, sto per cominciare un viaggio che durerà mesi (nella migliore delle ipotesi) e che avrei volentieri evitato.

Ci è voluto un mese esatto per capire, e alla fine il responso è lì, nero su bianco, asettico. “Linfoma non Hodgkin di tipo B, aggressivo. Stadio IIA”. Da internet :”Il linfoma diffuso a grandi cellule B (DLBCL) è la forma più comune di linfoma non-Hodgkin. È una forma aggressiva caratterizzata da una rapida crescita dei linfociti B: un tipo di globuli bianchi, cellule del sistema immunitario. I linfomi sono tumori dei linfociti”. Stadio IIA vuol dire: “interessamento di due o più stazioni linfonodali sopra o sotto il diaframma, con assenza di sintomi sistemici”

La carta non si cura di dirmi le cose in modo delicato: come sto, come la prendo, cosa penso, non sono affari di cui si cura. E io ho sempre trovato un po’ infantili le rappresaglie contro il messaggero: buttare il tipo nel buco come Leonida in “300” non è che risolva i miei problemi; anche se lo mangiassi, ‘sto foglio, non cambierebbe nulla.

È buffo pensare che c’è una una concatenazione causale che parte una mattina in cui ti svegli con un lato del collo un po’ gonfio e arriva a un mese dopo quando ti avranno visitato, bucato, ecografato, irraggiato, risuonato, TACcato, iniettato del liquido radioattivo, elettrocardiografato e si saranno presi pezzi di te che comprendono: un po’ di tonsilla, un po’ di osso dell’anca, un sorso di liquor cerebrospinale, sangue, pipì e cacca. Mi hanno inserito un tubetto che parte vicino all’ascella e arriva fino al cuore (PICC); lo terrò per mesi. Tranne il cardiologo, completamente sprovvisto di empatia e lievemente isterico, ho incontrato medici che mi hanno messo a mio agio e mi hanno spiegato ogni cosa.

Che poi: sapere non è neppure la parte più brutta; era peggio quando non era ancora chiaro cosa fosse esattamente, e dipingevo di volta in volta scenari che andavano dall’apocalisse (“muoio entro un anno”) alla spensieratezza (“un po’ di cure e starò meglio di prima”). Una volta capito dove volesse andare a parare ‘sta stronza di malattia mi sono tranquillizzato e i fantasmi sono andati via, anche perché poteva andarmi molto peggio. Adesso che so con certezza, sono in una fase abbastanza serena: so che c’è una cura da fare, che è lunga, che richiede pazienza, che porterà con sé fatica, dolore e probabilmente sofferenza. Ho corso delle maratone, so cos’è una cosa lunga, faticosa e dolorosa: non ho paura di affrontare un percorso. Non è stato sempre così: nel momento di incertezza ho attraversato una fase in cui avevo in testa un rave di emozioni. Dalla rabbia contro il Karma (“sono una brava persona, che vuoi da me?”) e contro l’ingiustizia (“perché a me?”), alla FOMO (“se muoio mi perdo la vita futura di mia figlia”), all’esasperazione preventiva del dover dare spiegazioni alle persone. Mi agitano anche cose che si possono considerare meno importanti in queste circostanze: “non voglio smettere di lavorare”, o addirittura stronzate tipo: “non c’è parcheggio in ospedale, come faccio?”.

E, invece, non c’entrano il destino, il Karma, la fede, la sfiga o una qualche punizione: è solo statistica. A qualcuno questa cosa deve accadere e io sono capitato nella colonna sbagliata del file Excel del Gestore Del Caos. E’ il caso, un lancio di dadi, una moneta che atterra sul lato sfavorevole. La cosa peggiore è la paura di lasciare mia figlia, di non essere più nella sua vita, di non esserci per lei; comunque, nella più banale delle manifestazioni paterne: meglio a me che a lei. L’ho detto a poche persone: mia sorella, mia madre, pochissimi amici e colleghi. Non ho voglia di spiegare, non devo nulla a nessuno, mi stancano i discorsi inutili e la commiserazione, e chi sa non mi ha deluso, per fortuna.

La retorica del combattente, del coraggio, della battaglia da affrontare, sono tutte stronzate. Come dice meglio di me Michela Murgia: non voglio le guerre nel mondo, figurati se le voglio dentro di me; il cancro non è qualcosa che ho, è qualcosa che sono, e io non posso fare la guerra contro me stesso. E il coraggio? Il coraggio presuppone di fare delle scelte, ma io non ho scelte: devo fare quello che mi dicono i medici, e muto. Non ci sono alternative, accetto quello che viene: io non sono coraggioso, seguo un sentiero tracciato da altri, e ai lati ci sono dei precipizi.

Come mi cureranno? La terapia di prima linea del DLBCL è uno schema di chemio-immunoterapia chiamato R-DA-EPOCH: etoposide, prednisone, vincristina, ciclofosfamide, doxorubicina e rituximab. DA sta per “dose adjusted”: i medici aumenteranno progressivamente le dosi di questo mojito finché il mio corpo sarà in grado di tollerarlo. Ognuno di questi ingredienti ha una serie di effetti collaterali che non sono una passeggiata nel parco, mi son fatto l’idea che per ammazzare il tumore debbano quasi ammazzare me, ma sono pronto: ho fiducia nella medicina e nella scienza.

Comunque, per farla breve e considerando tutti i fattori che influenzano i rischi, al momento ho il 27% di probabilità di essere morto tra 5 anni. BUM.

—-

Fast forward a maggio, dopo sei ricoveri da cinque giorni ciascuno attaccato 24 ore su 24 a tre o quattro pompe con un minimo di otto sacche di medicinali appese al trespolo. Sono pelato, glabro, costantemente debole, soffro spesso di dolori allo stomaco e alla bocca, e di una serie di inconvenienti più o meno imbarazzanti sui quali sorvolerò. Ho perso circa 10 chili, prendo una quantità di medicinali imbarazzante e la mia pancia è martoriata dalle iniezioni quotidiane.

Soffro di una forte parestesia alle dita delle mani, da mesi mi fanno male e sono insensibili come se fossero congelate; abbottonare la camicia è una vittoria da conquistare con fatica. La debolezza è devastante: una rampa di scale mi fa ansimare, mi viene la tachicardia, i brividi e devo fermarmi finché non mi torna il fiato. Mi gira la testa anche solo ad alzarmi dal divano, ho pressione bassa e difficoltà di concentrazione. Sono fortemente immunodepresso, quindi devo evitare i posti affollati, avere contatti con il minor numero possibile di persone e cercare di non ammalarmi di altre patologie. Un’altra malattia o un’infezione sarebbero un disastro: oltre alle conseguenze dovute al sistema immunitario malfunzionante, la terapia si interromperebbe fino alla risoluzione, e non me lo posso permettere. Un mio vicino di letto ha perso 15 giorni per un’infezione intestinale. Una cosa particolarmente fastidiosa, anche se sembra una stupidaggine in confronto al resto, sono le periodiche alterazioni al gusto: dopo ogni ciclo, per qualche giorno, ogni cibo mi risulta indigesto, nauseabondo, e con un deciso sapore di cartone (mai mangiato cartone, ma ci siamo capiti). Dopo 3 o 4 giorni trascorsi a masticare pacchi Amazon, per fortuna torno a gustare i cibi, ma è davvero una cosa che mi pesa. Insomma: non sono un fiore.

Dopo ogni ciclo, trascorsa circa una settimana, arrivano una fase di debolezza e malessere estremo che durano qualche giorno, lasciandomi uno straccio. Nel corso dei mesi gli effetti della chemioterapia si sono sommati e i periodi di nadir (così si chiamano) diventano sempre peggio. L’ultimo, il sesto, sarà devastante. Un venerdì sera i primi accenni: mi gira la testa e le scale di casa mi fanno venire il fiatone; il giorno successivo mi sveglio tardissimo e sono malfermo sulle gambe. Domenica un mezzo disastro: alle 2 del mattino mi alzo dal letto perché ho male ovunque, scendo, guardo un film inutile e mi addormento male sul divano; sono uno straccio per tutto il giorno, anche se mi distraggo perché un paio di amici sono passati per un caffè. Vado a dormire prima delle 19 senza cenare e dormo 13 ore filate. Lunedì va leggermente meglio ma la debolezza è arrivata anche se non ancora nel suo pieno splendore. Seguiranno giorni che ricorderò come i più duri di questo brutto periodo.

Intanto aspetto gli esami di controllo, una TAC e, soprattutto una PET, che sarà il momento della verità: vedrò se la terapia ha dato qualche frutto. Non nascondo che c’è un verme di apprensione dentro di me, ma per ora cerco di stare tranquillo. Come ho detto: non è una battaglia, vivo e prendo giorno per giorno quello che arriva senza tante possibilità di scelta. La maratona sta continuando e per ora sono in modalità autopilota, la fatica comincia a farsi sentire ma sono anche conscio che ho superato da un pezzo la metà del percorso. Resta da vedere se all’arrivo mi daranno una medaglia oppure se sarò squalificato e mi faranno ricominciare da capo.

Faccio la TAC il 10 maggio, e torno a casa esausto; è la tendenza di questi giorni, sono sempre stanco, debole, con un malessere generale difficile da descrivere che mi affligge da giorni. Ho anche dolore e un senso di oppressione al petto, e scopro presto il perché: la TAC rivela che ho vinto un’embolia polmonare; ecco spiegati i sintomi che mi perseguitano la notte. La settimana continua abbastanza male: la debolezza non mi lascia e la parestesia alle mani è sempre peggio, sono davvero stufo. Trascorrono brutte giornate ma comincio a stare un po’ meglio. Il 15 maggio faccio la PET, e il medico mi commiata con un pollice alzato che, immagino, dovrebbe essere di buon auspicio.

Nel pomeriggio arriva il referto non ufficiale: SEMBRA SIA SPARITO TUTTO (meu amigu Charlie Brown). Sto assorbendo questa rivelazione con emozioni miste e piantino liberatorio. Il referto reciterà: “Rispetto al precedente controllo, il quadro globale attuale non ha documentato la presenza di lesioni (omissis) di chiaro significato patologico evolutivo”. Nel referto della visita successiva compaiono le parole: “remissione completa”, che alle mie orecchie suonano meglio dell’assolo di Comfortably Numb. (There is no pain, you are receding). Mi rimangono due trattamenti di immunoterapia con gli anticorpi monoclonali da fare in day hospital a distanza di un mese l’uno dall’altro. “Consolidamento”, lo chiamano, e scoprirò che, per fortuna, non ha effetti collaterali. Dopodiché fisioterapia per riprendermi da sei mesi di quasi immobilità e controlli periodici; per i primi due anni ogni tre mesi, poi meno frequenti fino al quinto anno. Tanto si riserva la medicina per dichiarare l’eventuale guarigione; fino ad allora, salvo ricadute, sarò “in remissione”.

Ora, dopo quasi due mesi dall’ultima chemio, sto molto meglio anche se provato e fuori forma per la sedentarietà forzata. Cosa succederà non lo so, ho pagato un prezzo salato per arrivare a questo punto, e poteva anche andare peggio. Ho avuto la fortuna di riuscire a concentrarmi sui piccoli passi, perché è un attimo sentirsi soli, al buio, al freddo e senza speranza, facendosi prendere dallo sconforto.

Ho imparato qualcosa? Ho scoperto che le stelline da brodo con il pomodoro, mangiate nella ciotola con il cucchiaione, sono un comfort food. Sto ancora elaborando, e per ora mi è chiarissimo che in qualsiasi momento ti può cadere una tegola in testa senza il minimo preavviso, che sono circondato da persone che mi hanno supportato ed aiutato (specialmente mia moglie Nives, che non smetterò mai di ringraziare), che basta un attimo per rivedere tutte le priorità e che le cose che sembrano importanti oggi, domani potrebbero non esserlo più.