Con la pubblicazione del bando per la “…realizzazione e gestione del Polo Strategico Nazionale” – un bando da oltre 700M€ per oltre 10 anni di copertura – il grande tema del “Cloud Nazionale” è tornato agli onori della cronaca.
Una fotografia molto precisa degli eventi che hanno determinato l’attuale scenario è stata recentemente scattata da Antonio Cisternino, ricercatore presso il Dipartimento di Informatica dell’Università di Pisa e, soprattutto, coordinatore del “Sistema Informatico di Ateneo” della stessa Università. Una persona, quindi, che a differenza della quasi totalità delle altre persone che commentano questo tema, conosce perfettamente gli oggetti di cui parla: ha una idea precisa di “datacenter” (gestisce quelli di UniPI), conosce benissimo le varie sfaccettature del termine “cloud”, ha le idee chiare su cosa significhi “sviluppare software”, “rendere fruibile il software agli utenti”, “gestire sistemi hardware”, “gestire infrastrutture applicative” e che, ovviamente, conosce perfettamente l’enorme tema della “Sicurezza Informatica” (a tutti i livelli).
Non è un caso, quindi, che il suo articolo “Cloud pubblico, la strada verso il PSN e la sovranità nazionale: novità e prospettive” –-pubblicato su Agenda Digitale–-, sia il migliore che io abbia letto, finora, sul tema.
C’è un aspetto, però, che mi sta particolarmente a cuore e che continuo a non veder trattato come auspicherei. Neanche da Cisternino.
Non si tratta tanto “della soluzione” (ossia del fatto che la strategia del “Cloud Nazionale” rappresenti una ottima scelta, tecnicamente e politicamente parlando), quanto “del problema” (ossia: cosa ci dobbiamo fare, realmente, di questo “Cloud Nazionale”?)
Il tema può sembrare di poco conto, ma a mio avviso è cruciale e ruota attorno ai plurimenzionati 1190+27+35 = 1252 “datacenter” che –come correttamente ribadito da Cisternino– AGID sostiene di aver censito all’interno delle PP.AA. del Paese.
“Datacenter”: questo sconosciuto
Anche se non l’ho ancora vista CHIARAMENTE ed ESPLICITAMENTE scritta, l’idea che ruota attorno alla strategia “Cloud Nazionale” dovrebbe essere quella di far sparire (“ripulire”, è il termine usato da Cisternino) almeno i 1190 “datacenter” che sono finiti nel gruppo B. Ossia quelli “brutti e cattivi” che rappresentano un rischio per i dati trattati e per i servizi gestiti.
A differenza di molti, ho le idee chiarissime su questo problema. Conosco i “datacenter” di diversi Comuni (Comuni da 3093, 10883, 14828, 48780, 53430, 118950 abitanti ). Conosco direttamente le persone che mettono le mani sui relativi sistemi. Conosco le applicazioni che ci girano. Conosco il modo con cui il personale (del Comune) interagisce con queste applicazioni.
Conosco anche i datacenter della mia ASL. Del “mio” Ateneo. E conosco le persone che lavorano nei datacenter di almeno ~30 Atenei sparsi per l’Italia. Ho anche avuto più volte la possibilità di visitare il datacenter di Cineca (una delle foto che conservo orgogliosamente è stata scattata li dentro).
Per me, il termine “datacenter” è sempre stato associato ad un luogo chiuso, in cui mancano le finestre, all’interno del quale c’e’ un rumore importante generato dall’impianto di raffreddamento e, soprattutto, dai sistemi di ventilazione interni ai server ed agli storage.
Il “datacenter”, per me, è sempre stato quella stanza dove i non-addetti-ai-lavori, quando entrano, dicono: “Uau!”, incuranti se negli armadi ci siano sistemi ultra-obsoleti tenuti li praticamemente solo per consumare energia elettrica, oppure si trovano di fronte uno chassis-blade con server (blade) che, singolarmente, potrebbe gestire i sistemi di una intera Regione.
Chiaramente nei miei anni di attività, di “Sistemi di Elaborazione” utilizzati per erogare servizi IT ne ho visti moltissimi. Tipicamente chiusi nei sottoscala o negli antibagni di alcuni uffici di molte P.A. (oltre che di aziende private, ovviamente).
Per me, pero’, questi NON erano “datacenter”. Erano semplicemente “server” buttati li per erogare un servizio che, evidentemente, qualcuno (o qualcosa) ha consapevolmente (o inconsapevolmente) scelto di ospitare in quei luoghi, e non altrove.
Chiaramente mi è capitato sia di trovare un PC poggiato a terra, al cui interno girava il software che aveva l’intero archivio “pensioni” di una P.A., sia di incontrare dei sistemi blade da ~50k€… spenti e mai accesi. Mi è anche capitato di osservare da vicino delle Pubbliche Amministrazioni che, avendo l’opportunità di utilizzare i fondi COVID, hanno scelto di spendere ~150k€ per rinnovare dell’hardware di cui nessuno sentiva la necessità.
È da questo punto di vista che quando iniziò il tam-tam della “centralizzazione dei CED della Pubblica Amministrazione” (prima) e della “migrazione al cloud” piu’ recentemente…. fui subito scettico.
Non solo conoscevo l’hardware che sarebbe stato impattato da queste iniziative. Ma conoscevo anche “il software” (che ci girava sopra) e, soprattutto, la complessa relazione fra quel software, gli utenti che lo usavano e le aziende che lo avevano fornito e (in teoria) lo manutenevano. Pur non essendo un docente universitario, il mio background e –soprattutto– la mia esperienza mi portava a dire: “Questo progetto di migrazione è estremamente ambizioso!” (in realta’ pensavo: “non si arriverà mai a migrare queste applicazioni senza un cambiamento drastico del modus-operandi. Tutto si risolverà in un nulla” ma scriverlo così è brutto).
Quando furono resi noti i risultati del “Censimento AGID“, il mio stupore aumentò:
- da un lato, emerse il fatto che nel nostro Paese esistessero 1252 datacenter interni alle PP.AA.
A spanne, ~60 per Regione (~12 per provincia). Nella mia testa, però, in Abruzzo (tutta la regione) me ne venivano in mente 4/5. A voler essere ottimisti e accettando di essere in errore (io), arriverei a 7/8. E gli altri 50? - dall’altro, il fatto che di questo censimento non avessi avuto notizia, se non dopo la pubblicazione dei risultati.
Eppure, proprio in quel periodo storico, ero coinvolto in prima persona in attività di supporto (ossia: avevo accesso fisico) ai datacenter di un Ateneo e di una ASL. Mi chiesi, quindi: “Come sara’ stato effettuato questo censimento? Chi avra’ fornito i dati del “mio” Ateneo e della “mia” ASL? Come ha fatto a compilare il questionario, senza consultare né me, né quelli che lavorano con me?” (…e mentre me lo chiedevo, immaginavo qualcuno che, nelle settimane addietro, avesse compilato un foglio di calcolo, più o meno “tirando a dadi”; ma anche questo, scritto così, pare brutto).
Questa distonia fra i 1252 datacenter e la mia esperienza sul campo ha rappresentato (e continua a rappresentare) un tarlo mentale dal quale non riesco ancora a liberarmi.
Per rendere meglio l’idea, ho recuperato (in circa 1 ora) queste foto dal mio PC:
Questa era la realtà che avevo in mente. Contando queste realtà, arrivavo facilmente a contarne un numero vicino a 60. Nel mio Abruzzo.
Tuttavia, in TUTTI gli articoli che ho letto relativi a questo tema (quello del cloud nazionale), ho sempre trovato foto diverse. Foto molto simili a quelle che si possono facilmente recuperare on-line, semplicemente cercando “datacenter”:
“Possibile che il Censimento abbia censito il sottoscala del Comune X come ‘datacenter’?“. Era questa la domanda che continuava (…e continua) ad assillarmi.
Perchè è importante classificare (correttamente!) i datacenter
Il mio dilemma, ossia la questione legata alla “corretta” (“corretta”, secondo la mia metrica personale, ovviamente) classificazione NON è di poco conto.
L’assumere che qualunque server in funzione in una P.A. costituisca un “datacenter” ha ripercussioni ENORMI sugli umani che, con quei sistemi hanno a che fare.
Mi spiego.
Prendiamo due “situazioni”, che apparentemente potrebbero essere stati oggetto dello stesso censimento AGID. Ossia due “datacenter” censiti. Questi:
In entrambi i casi abbiamo:
- un tot di “server”:
- 4, nella foto a sinistra, oltre ad un quinto che si intravede nell’angolo in basso a sinistra;
- 13, nella foto a destra;
- dello “storage”:
- interno ai server, a sinistra, oltre che nel NAS sul tavolo, a destra
- nelle 2 SAN, a destra
- degli strumenti a supporto della “protezione dei dati”:
- il NAS, a sinistra, verosimilmente utilizzato per il backup
- la tape-library robotizzata, a destra (in alto)
Entrambi i “datacenter” hanno bisogno di energia elettrica stabile. Entrambi producono calore (ma quello a sinistra puo’ stare anche in una stanza “normale”, senza condizionamento) ed entrambi producono rumore (quello a destra, _TANTO_).
Il fatto che si tratti di due “datacenter” identici è suffragato anche da un elemento normativo:
“Con il termine CED è da intendere il sito che ospita uno o piu’ sistemi informatici atti alla erogazione di servizi interni alle amministrazioni pubbliche e servizi erogati esternamente dalle amministrazioni pubbliche che al minimo comprende risorse di calcolo, apparati di rete per la connessione e sistemi di memorizzazione di massa.”
Art. 33-septies, comma 2, DECRETO-LEGGE 18 ottobre 2012, n. 179 – tuttora vigente
Insomma: facendo un parallelo con il mondo dell’automobile, è come parlare di “macchine”:
Nella foto ci sono 6 macchine. Rosse.
Tutte hanno un motore. Tutte hanno un volante, una trasmissione, un impianto frenante. Tutte hanno bisogno di asfalto, sotto, per poter marciare.
Tutte si incidentano (purtroppo!). Tutte, quindi, sono “pericolose” e vanno “manutenute” e sono addirittura soggette a revisione obbligatoria (nel nostro Paese, almeno).
Sono _IDENTICHE_, insomma.
Ecco. Laddove un utente normale riesce istantaneamente a capire che le macchine a sinistra sono diverse, allo stesso tempo io (e molti di coloro che, con me, condividono un certo tipo di “IT Pubblico”) riesco istantaneamente a percepire la differenza dei sistemi a destra.
Se tutti capiscono che l’accelerazione di un V8 o di un V12 è diversa da quella della 500 storica, noi capiamo che la potenza di calcolo di quei server-blade è di almeno 200 volte superiore ai sistemi che stanno sotto al tavolo.
Se tutti capiscono che con una Ferrari possono andare a correre ad Imola ottenendo tempi sul giro interessanti (cosa che non possono fare con una nuova 500)…. noi capiamo che con quello chassis-blade, con i relativi server e con la relativa SAN possiamo far funzionare il 100% dei sistemi di 5 ASL (vado a spanne) senza alcun tipo di problema (a differenza di quanto possibile con i sistemi sotto al tavolo).
Ora che questi aspetti sono più chiari, ossia ora che è più chiaro il particolare punto di vista dal quale io osservo i sistemi ICT, posso (finalmente!) introdurre il punto chiave
Guidatori, piloti e meccanici…
Credo non ci sia bisogno di spiegare che guidare una 500 storica richiede abilità diverse rispetto ad una Aston o ad una Ferrari (la 500, a volte, è piu’ complessa).
Magari qualcuno potrebbe non sapere che senza il traction-control o il lauch-control, accelerare bruscamente con un bolide da 600/700 cavalli è incredibilmente complesso ed il risultato, in pista, è disastroso. Perfino persone ultra-esperte nella guida di “bolidi” classici, hanno avuto un destino drammatico quando si sono trovati alla guida di “mostri” elettrici (Chiaramente questo problema, con le 500 o la 124 non esiste).
E parlando di meccanici, non sfugge a nessuno che gli skill tecnici che servono a mantenere in vita una 500 storica siano abbastanza diversi da quelli di una moderna 500 o, di più, di una Aston e… oggi, di una Tesla.
6 macchine rosse. Sono sempre le stesse presentate prima.
Ma ora abbiamo scoperto che sono diverse. Molto diverse. E se fai il meccanico, se fai il pilota o se decidi semplicemente di guidarle…. DEVI sapere che sono diverse. Perché se le consideri semplicemente “macchine”, delle due l’una: o ti schianti istantantamente, oppure, peggio, finisci per guidare una Aston come guideresti una 500 storica (ma al prezzo della Aston!).
La stessa identica cosa si applica ai sistemi ICT. Se una P.A. decide di allestire un ufficio IT (una squadra di meccanici) per gestire i propri sistemi ICT (le auto con cui correre in pista), è chiaro che servono un management IT adeguato (una organizzazione fine, con un vertice adeguato, un capo meccanico adeguato e, soprattutto, un pilota all’altezza) e, soprattutto, tecnici in grado di tenere in piedi i sistemi (il mare magnum di meccanici che, ad esempio, ti cambiano 4 ruote in 1.91 secondi).
L’ICT nella P.A. Italiana, vista da me
È sempre stato chiaro, nella mia testa, che l’utilizzo di sistemi applicativi self-hosted fin nelle estreme periferie della P.A. rappresentasse un enorme problema. Qualcosa di insostenibile e foriero di problemi.
Anche nei casi in cui questi sistemi periferici sono paragonabili ad una “nuova 500”, come si puo’ pensare che il personale di un Comune da 10k abitanti possa essere in grado di smontarne il motore per metterne uno più potente (ossia: aggiornare il sistema operativo e gli applicativi in esecuzione) con la ragionevole certezza di non fare danni?
Quello che è accaduto negli ultimi 20 anni all’interno degli uffici ICT di moltissime PP.AA., piccole e grandi, è che la rapida evoluzione tecnologica (hardware; networking; software; sicurezza) non è stata affiancata da una analoga crescita del volume di competenze necessarie a governarla. Nello stesso periodo, però, le PP.AA. registravano una richiesta crescente di servizi innovativi causata da cittadini ed imprese (che osservavano chiaramente, dall’esterno, l’evoluzione tecnologica in corso)
In questo contesto l’unica via percorribile per la P.A. era quella di affidarsi a soggetti esterni, innescando una dinamica che ha progressivamente svuotato le PP.AA. della capacità di governare la propria strategia ICT, delegandola totalmente all’esterno.
È per questo motivo che, oggi, nei “datacenter da sottoscala” si trovano sistemi hardware di cui gli stessi funzionari ignorano le caratteristiche di base, limitandosi a conservare unicamente il numero di telefono dell’addetto del supporto dell’azienda che dovrebbe –quando va bene– manutenerli.
È per questo motivo che, oggi, nelle realtà da “datacenter da sottoscala”, non è più l’Ente a decidere quale software utilizzare, per quale scopo…. e “se” o “come” la tal funzione debba (o meno) essere gestita in un certo modo o nell’altro. Piuttosto è il fornitore che, puntualmente, arriva e impone il proprio strumento, senza che la controparte pubblica possa minimamente avere il benché minimo “controllo” del processo decisionale.
Questi problemi (i problemi da “datacenter da sottoscala”) sono assimilabili ad una piccola officina in cui anni fa c’erano delle 500 storiche e c’era anche qualche meccanico in grado di tenerle in forma. Ma ora quel meccanico non c’e’ piu’ e l’officina, di fatto, è vuota (perché le auto sono tutte uscite di produzione e nessuno le usa più). Restano, però, alcune vecchissime auto, con cui il personale si sposta entro i confini limitate del paese.
Quell’officina va chiusa. Su questo non si discute. Quelle auto vanno rottamate. E se il Comune da 3K abitanti deve fare qualche giro nel paese… gli va data un’auto che DEVE essere gestita, al 100%, da altri. Fuori dall’officina. E con gli standard qualitativi del 2021. Su questo, ripeto, non c’e’ alcun dubbio. Benvenga, quindi, una strategia “cloud-nazionale” che si ponga questo obiettivo.
La mia unica riserva, rispetto a questo tema, è determinata dal fatto che, nonostante si siano scritti fiumi di parole, torrenti di dichiarazioni, gigabyte di audio/video trasmessi in streaming…. *NON* vedo ancora alcuna attività avviata nei confronti del Segretario Comunale X che *CONCRETAMENTE* punti allo smantellamento del “datacenter da sottoscala”. Viceversa, vedo un sacco di attività, lontano dal Comune, tutte dedite alla costruzione della mega-officina-spaziale, peraltro con all’interno quegli stessi soggetti [Google, Microsoft, Oracle – citava Cisternino] che hanno contribuito a determinare lo scenario attuale….
Insomma: qualcosa mi dice che sarà soltanto il trascorrere del tempo, magari supportato da fenomeni metereologici (un fulmine con conseguente picco elettrico) o, purtroppo, tellurici (un terremoto) o ancora, un bell’incidente (il ransomware va molto di moda….) a rappresentare il vero strumento di “migrazione al cloud”. Spero di sbagliarmi, ovviamente.
Il vero problema, però, è che non tutti sono “datacenter da sottoscala”
Datacenter… e Datacenter
Si può scegliere di correre in pista in molti modi. Ma se si vuole correre più veloce di ieri (e meno di domani), o addirittura si pretende che si debba correre molto velocemente…. le alternative si riducono.
I 4 meccanici qui sotto, sono… meccanici (il secondo da destra è Enzo Ferrari). Hanno le mani sporche di grasso e, probabilmente, l’ambiente nel quale operano non è profumatissimo.
Ma il fatto che, oggi, quel lavoro abbia portato alla creazione (fra l’altro…) di un’industria di riferimento a livello mondiale (cfr.: a destra, una linea di montaggio dello stabilimento Ferrari), è elemento di riflessione.
Oggi i “datacenter” attivi nei 68 Atenei del nostro Paese sono metaforicamente simili a quanto rappresentato nella foto a sinistra: uno stabilimento storico di Maserati.
Dentro questi datacenter operano persone con competenze ICT di assoluto rilievo. Persone che conosco direttamente, e che spesso commettono l’errore di credere che il loro know-how sia trascurabile. Io, invece, vedo in molti di loro una trasposizione dei tre tecnici che, qui sopra, discutono con Ferrari su come far evolvere il motore che hanno davanti. Magari alle loro spalle c’e’ l’officina che vediamo a sinistra.
Ambienti rumorosi, sporchi, pericolosi. Ma ambienti che, se “pilotati” a dovere, possono dare grosse soddisfazioni.
La strategia “cloud-nazionale” che avrei voluto, era quella che avrebbe supportato quei tre meccanici capo-squadra a coordinare gli sforzi dei propri tecnici (nello stabilimento di sinistra), per arrivare a creare delle auto che, fra 15/20 anni avrebbero potuto essere fra le migliori al mondo (come quelle nello stabilimento di destra).
Quei meccanici, quegli stabilimenti…. oggi esistono. Sono li da 20 anni… e nessuno se ne è ancora accorto. Quei “datacenter” non sono “datacenter da sottoscala”. Ad onor del vero, il datacenter di UniPisa è rientrato in quelli del “Gruppo A”, degno –quindi– di vedersi riservato un futuro d’esistenza. Che io sappia, sono al massimo due, forse tre, i datacenter universitari rientranti nel Gruppo A. Tutti gli altri (65!) sono “Gruppo B” e, in quanto tali, destinati allo smantellamento (secondo quanto previsto dalla normativa vigente).
Non sono riuscito a recuperare l’elenco ufficiale della classificazione AGID. Non so, quindi, quali siano i 27+35 che, da normativa, hanno diritto alla sopravvivenza.
Quello che so, però, è che gli altri 1190 non sono tutti “datacenter da sottoscala” ed in mezzo a loro ce ne sono diversi (almeno 65!) che sarebbe il caso di mantenere in vita (se è vero che il nostro Paese debba continuare a partecipare alle gare di velocita’).
Il paradosso delle competenze
Non passa giorno che qualche testata nazionale (TV o carta stampata) non riporti un articolo che rimarchi con enfasi la cronica mancanza di competenze ICT nel nostro Paese ed i problemi che tale mancanza sta via via comportando.
Non passa giorno che non si dica che “Bisogna accrescere le competenze ICT”, “Bisogna formare il personale della P.A. all’ICT”. Che la “Cybersecurity” rappresenta una grave minaccia. Che gli “Incidenti informatici” rappresentano una costante.
Ed io non capisco.
Mi sembra che da un lato (stando alla comunicazione mainstream) si punti a creare un’esercito di meccanici con i quali si vuole organizzare una serie corposa di gare di velocità. Tutti a correre, insomma.
Dall’altro, si chiudono le officine. Tutte. Indiscriminatamente. Incluse quelle dove ci sono le pochissime competenze rimaste, unite ad un fior-fiore di strumentazione ed all’ambiente ideale per “formarsi”.
Alcuni mi dicono che sbaglio. Che la squadra che il nostro Paese vuole allestire non può partire dalle competenze attuali. Quelle che servono sono molto diverse. E possiamo soltanto recuperarle grazie a fornitori esterni (“le migliori tecnologie sono straniere”… diceva qualcuno più autorevole di me). Soltanto con questi “fornitori esterni” (Google, Amazon, Microsoft – citava Cisternino riprendendo il bando appena emesso) potremo acquisire quelle competenze in grado di farci scendere in pista e correre. Ma a me, questo ragionamento non convince.
Io vedo chiaramente un processo che punterà a consegnarci una auto con il cofano sigillato, che nessuno avrà possibilità di aprire (non tanto per il rischio che ci sia dell’esplosivo all’interno, ma semplicemente perché avremmo potuto “modificare” il motore per fargli fare –forse– 2000 rpm in piu’). Un’auto il cui pilota è gia’ designato (dagli stessi che hanno venduto l’auto), e non c’e’ possibilità di cambiarlo (mi riferisco alle dinamiche di lock-in in ambito software). E vedo dei potenziali rischi dovuti alla necessita’ di “mantenere” questa auto, alle condizioni che il fornitore potra’ tecnicamente dettare unilateralmente.
Ecco: in questo scenario, come si fa a pensare di formare un gruppo di meccanici e di piloti?
Quello che accadra’, invece, è l’esatto contrario: quei pochi che avevano un po’ di competenze, usciranno di scena. E quelli che arriveranno saranno semplicemente in grado di guidare perfettamente… la macchina loro fornita. Alle condizioni loro dettate. E nel contesto tecnologico dettato dal fornitore (ossia con motore, assetto e configurazione che decide il fornitore e… che non è dato di sapere).
Il cloud-nazionale che avrei voluto, avrebbe dovuto rappresentare una eccezionale palestra di crescita per l’ICT del nostro Paese (in primis), in totale sinergia con gli analoghi sforzi a livello Europeo.
Il cloud-nazionale che verrà, potrà solo accelerare l’impoverimento del comparto ICT pubblico, con evidenti ricadute negative non soltanto economiche, ma anche sociali.
Ai posteri, l’ardua sentenza.