È questo contesto pubblico/economico che ho in mente quando leggo
l'articolo citato [1] ed è per questo che, nel mio contesto, lo
trovo defocalizzante:
A questo contesto io penso vada aggiunta la scarsa crescita di produttività italiana, che credo sia unanimemente riconosciuta come una causa prima del declino socio economico del paese. Altra cosa importante da tenere a mente: il contesto accettabile di oggi non è necessariamente il migliore possibile o nemmeno il desiderato futuro.
- _NESSUNO_ ha bisogno di scalabilità world-wide;
- _NESSUNO_ ha bisogno di "elasticità" nel carico computazionale
(ci sono i click-day di INPS; ma quelli stanno fuori dal
contesto che descrivo);
- _NESSUNO_ ha bisogno di SLA al 100% (con l'eccezione dei
sistemi hardware/software posti a gestire le Terapie Intensive
delle ASL e, in parte, dei Pronto Soccorso; ma parliamo comunque
di una "minoranza" di sistemi che sono gia' appannaggio di
realta' "particolari")
Trascuro i primi due punti perchè siamo d'accordo ma sul terzo mi soffermo: secondo me sulla questione uptime e continuità di servizio tralasci i piccoli problemi quotidiani che sommati fanno un totale aberrante.
Negli ultimi anni ho lavorato per un fornitore di software di storage per apparecchi medicali. Uno dei problemi che hanno i piccoli centri radiologici sono le immagini perse e l'archivio lento. Esempio pratico banale: zia fa la radiografia all'anca, le danno il CD ma lo perde. Dopo 5 anni deve fare una nuova radiografia e la fa. Il suo ortopedico ha dei dubbi e chiede di vedere la radiografia storica. Zia si rivolge al centro e chiede l'archivio... Loro da qualche parte ce l'hanno, per legge ma per trovarlo ci vogliono ore di ricerca tra nastri antichi che chissà chi ha visto. Questi centri spesso sono organizzati come descrivi tu: un piccolo box in locale con le ultime immagini su un piccolo NAS e qualche batch script che deposita i dati su archivi remoti dove fanno qualche altro accrocchio con NAS più grandi e tape libraries per il lungo termine.
Le ore spese a trafficare tra nastri antichi sono ore bruciate senza produrre niente di utile.
Ci sono invece soluzioni più moderne di storage always-up, rapide, economiche ed efficienti. E che (aggiungo per chiarezza) non dipendono da GAM ma si comportano esattamente come uno di questi (private cloud).
E quei "livelli di servizio" si migliorano con il cloud? Ne siamo
davvero sicuri?
Dobbiamo forse smettere di usare il termine cloud senza qualificarlo :) OpenStack e Kubernetes, minio, ceph... on-prem per me questa roba è cloud, private cloud per essere precisi.
In un mondo ideale, il Direttore Generale della ASL2Abruzzo (la
mia ASL) creerebbe una task-force di 5 umani a cui demandare il
compito di "razionalizzare" il parco software installato in lungo
ed in largo per la ASL,
[...]
da quello che ho letto, AgID sta spingendo per fare proprio questo.
Conosco, viceversa, _MOLTE_ startup (di cui un buon 90%
"universitarie") i cui prodotti e servizi possono essere erogati
con l'infrastruttura di rete esistente (tipicamente GARR, ma anche
quella dei vari Aruba, TopHost, SeeWeb, Register, etc. etc.), con
gli SLA ampiamente dimostrati (>98%) e, soprattutto, a fronte
di un carico computazione che sta _AMPISSIMAMENTE_ all'interno di
un Odriod HC2 (on-prem) [4] o su una VM che i provider citati
danno a meno di 10€/mese.
Ti seguo ma fino a un certo punto. Altro esempio banale: prendi mezza giornata di ferie per andare a fare un certificato nella [PA a caso]. Arrivi e ti comunicano che l'applicazione è bloccata e non possono fare certificati. Bon, mezza giornata buttata per un patetico SLA al 98%. Fai la somma di tanti 2% di downtime per servizi "non essenziali" e scommetto si arrivi vicino a mezzo punto di PIL :)
Quindi suggerirei di focalizzarsi _NON_ sull'infrastruttura di
erogazione.... ma, piuttosto, sulla soluzione vera e propria:
cominciamo a costruire i microservizi che servono per la "nuova"
produzione. Costruiamoli affinche' siano cloud-native (elastici,
affidabili, resilienti). E quando abbiamo la ragionevole certezza
di riuscirci (cosa di cui dubito....), a quel punto decideremo:
[...]