On 27 May 2021, at 12:00, <nexa-request@server-nexa.polito.it> <nexa-request@server-nexa.polito.it> wrote:

Date: Thu, 27 May 2021 11:00:15 +0200
From: Damiano Verzulli <damiano@verzulli.it>
To: nexa@server-nexa.polito.it
Subject: Re: [nexa] Colonialismo digitale US nel Cloud Italiano e
Schrems - II
Message-ID: <08c6937a-544f-56f4-96f0-1d9b37441c5d@verzulli.it>
Content-Type: text/plain; charset="utf-8"

Il 26/05/21 19:37, Stefano Maffulli ha scritto:

[....]
Serve tenere presente che *oggi* non ci sono alternative alle cloud di
Google, Amazon e Microsoft.

Nel contesto di questa lista, questa affermazione è troppo generica.

Che significa: "non ci sono alternative alle cloud di Google, Amazon e
Microsoft"?

 * Significa che il Comune di XYZ (da 1000 abitanti), deve _PER_FORZA_
   avere GDRIVE o ONEDRIVE sui PC del segretario comunale? Non ci sono
   alternative?

 * Significa che il Comune di KKK (da 20.000 abitanti), non è più in
   grado di far girare delle VM su infrastrutture locali (perche' non
   puo' comprare HW) e, spinto dalla norma che gli dice di "mandare
   tutto su cloud", _DEVE_ spostare il workload su delle VM (perche' e'
   di questo che parliamo!) su Google, Amazon o Microsoft? Perche'
   Hetzner no? Perche' OVH no? Perche'... Aruba no?

 * Significa che il Ministero dell'Istruzione --dopo che ha deciso di
   _NON_ essere in grado di gestire localmente la propria
   infrastruttura di posta-- la _DEVE_ portare su piattaforme
   Microsoft? Non ci sono alternative? Ne siamo _VERAMENTE_ sicuri?
   Come hanno fatto, fino a ieri?

 * Significa che l'Ateneo YYY (magari da 30k studenti e 1200 unita' di
   personale docente e amminsitrativo) --dopo che ha
   (inconsapevolmente) annientato il proprio IT interno-- _DEVE_
   mandare on-line gli stream delle lezioni utilizzando Microsoft Teams
   o Google Classroom perche' NON ci sono alternative? Ne siamo proprio
   sicuri? (hint: magari facciamo questa domanda _ANCHE_ a PoliTO)

 * Significa che la mia locale ASL, non ha alternative rispetto
   all'esternalizzazione di VM (perche', di nuovo, è di questo che
   parliamo....) su Amazon, Google o Microsoft?

....oppure

 * significa che il sistema di gestione del "protocollo informatico"
   del Comune XYZ è "cloud-native" e richiede, per funzionare, servizi
   a-la "Server-less computing", ad oggi offerti solo dai big player
   made-in-USA?

 * significa che la ASL sta riscrivendo il proprio software di gestione
   del tracciamento COVID e lo sta facendo in modalita' "cloud-native",
   ed ha bisogno di provider che gli consentano di deploiare la propria
   applicazione in modalità "ultra-scalabile"?

 * significa che il l'Agenzia delle Entrate sta riscrivendo tutto il
   software del "Cassetto Fiscale" e lo sta facendo con architetture
   cloud-native che --di nuovo-- richiedono una infrastruttura di
   "cloud-computing" che NON è quella di Aruba, di Hetzner (e, forse,
   di OVH [che non conosco direttamente])?

...e potrei continuare.


Secondo me ci sono dei fattori che non possono essere trascurati (e che
vedo trattati _pochissimo_ nelle discussioni, anche qui, fra tecnici):

 * tutti parlano di cloud. Nessuno parla di applicazioni (quelle
   "running", _OGGI_). Nessuno dice che quelle applicazioni, oggi,
   _NON_ possono essere mandate su cloud, se non utilizzando servizi
   IAAS (sposto la VM dal mio DC al DC di un altro). Per questo
   "problema", i DC di Aruba, i DC di TopHost, i DC di Hetzner, di OVH,
   (...i DC di SOGEI, i DC di CINECA, etc.) vanno _benissimo_;

 * la "scala" di Amazon, Google e Microsoft è "il mondo". Il nostro
   problema (cloud nella PA) è la PA Italiana. Siete proprio sicuri che
   5 datacenter "piccoli" (ma ben connessi fra loro, e ben
   "amministrati") non possano sostenere il workload dell'80% della PA
   Italiana? Siete proprio sicuri che il problema sia "il ferro"
   (numero e dimensione dei DC e loro capacità computazione e di storage)?

 * se è vero (come è vero) che le "competenze" in ambito "architetture
   cloud-native" sono merce rarissima, nessuno dice che _NON_ è
   necessario che queste competenze scalino linearmente con l'aumentare
   della dimensione delle infrastrutture gestite e del carico
   computazione: lo stesso gruppo di "20 tecnici giusti", può gestire
   una infrastruttura che sta in un armadio rack da 42", o in 10 armadi
   rack, o in 50 rack sparsi in 5 DC. _SE_ (ripeto: _SE_)
   l'architettura poggia sulle basi dell'automazione e
   dell'orchestrazione, non cambia niente! (o comunque cambia
   _pochissimo_). Insomma: per (ri)portare l'IT "pubblico" del nostro
   Paese sui binari giusti, _NON_ servono 10.000 tecnici. Ne servono
   meno (molto meno) di 100. Chiaramente serve qualcuno che li guidi
   (ma questa e' un'altra storia. Che non c'entra con Google, Microsoft
   e Amazon).

Le alternative locali sono indietro di oltre 10 anni, sia per
dimensioni sia per funzionalità. E il PNRR mette "cloud" al centro
della strategia digitale del paese. Ci sono da recuperare 15 anni di
arretratezza, anni in cui anche l'open source si è fermato a guardare,
lasciando la *pratica* del cloud in mano ai colossi. Mai come oggi c'è
stato così tanto software libero che in pochi però sanno far
funzionare a scala.

Se allarghiamo il discorso a tutto l'IT del Paese (e non, quindi, alla
sola PA), allora è chiaro che i servizi di Aruba (o di TopHost, o di
Hetzner, o di OVH) _NON_ sono paragonabili a quello di AWS. Ed
un'azienda "moderna" (la prima che mi viene in mente, è Bending Spoons)
tende necessariamente a guardare in direzione USA (perche' è li che
trova quello di cui ha bisogno)

Ma il nostro focus _NON_ è l'IT del Paese. È quello della PA. Una PA che
è indietro millemila anni, in ambito IT. E paradossalmente questo è un
vantaggio, perche' in questo contesto, "cloud" = "IAAS". E l'"IAAS" è
_DISPONIBILE_ gia', nel nostro territorio (e in Europa).

A quale "arretratezza" ti riferisci? Forse al fatto che nelle ASL, negli
Atenei, al Ministero delle Finanze, e in tanti altri posti "pubblici",
la parola LAMP fa ancora tendenza? Se si, che relazione ha questo
"problema" con il fatto che Amazon, Google e Microsoft rappresentino 
scelte obbligate?

Attenzione: _NON_ sto dicendo che non esista un ritardo. Tutt'altro. È
solo che quel ritardo _NON_ si colma adottando massicciamente le
piattaforme GAM. Quel ritardo puo' essere colmato solo passando dalla
realizzazione di nuove applicazioni (cloud-native) e dalla
predisposizione di piani di adozione/migrazione "adeguati". E dovrei
pensare che questo _NON_ sia possibile nel nostro Paese? Oggi?

 Gli italiani in OpenStack erano Garr, INFN ed Enter, tutte con pochi
spiccioli. Il che mi fa supporre che nelle 3 grosse aziende citate non
ci sono le competenze di scala al livello necessario ad offrire
servizi alternativi agli ultra-scale.

La missione di GARR _NON_ è quella di essere il "cloud-provider della
P.A.". È quella di fornire connettività (e servizi "accessori") alla
Comunità della Ricerca. E già solo per fare questo, ha (da tempo)
metabolizzato il fatto che "automazione" e "orchestrazione" sono
indispensabili (per fare efficacemente il suo lavoro). Probabilmente
l'avvicinamento ad OpenStack (ed a K8S) va letto in questa ottica, ossia
funzionale alle proprie necessita'. Non al fatto di candidarsi ad essere
cloud-provider verso terzi.

Ci saranno sicuramente ottimi ingegneri e dipartimenti forti a
TIM/Fincantieri/Leonardo, ma ho l'impressione che il C-level negli
ultimi 10 anni non ha sviluppato le competenze necessarie a gestire un
cloud in grande scala con progetti open source, anche solo
compute+storage+network (non parlando dei servizi tipo dbaas,
serverless, etc)?  Sbaglio?

Da almeno 20 anni l'IT del nostro Paese è "attività commerciale". Fare
IT, nel privato, significa "comprare software" e "rivenderlo", a volte
arricchito con una percentuale piu' o meno trascurabile di valore
aggiunto. Fare IT significa _VENDERE_ hardware e software
pacchettizzato. I nomi che hai citato sono eccellenze in questo ambito
(aka: comprano e vendono _molto_). Non ho alcun dubbio (e, con me, molti
altri "tecnici") sul fatto che i paradigmi che stanno alla base del
F/OSS manchino totalmente nelle agende dei C-level citati: perche'
dovrebbero esserci? (non e' una domanda retorica).

Questi temi, pero', sono _POLITICI_. È compito della Politica affrontare
(e risolvere, ammesso che li condivida) questi problemi.

E l'infrastruttura cloud su cui poggiare l'IT pubblico del Paese.... è
probabilmente la prima decisione che dovrà essere presa (ammesso che non
sia stata gia' fatta).

A me terrorizza il fatto che continuo a sentire, ovunque, che nel nostro
Paese ci sono "11.000 datacenter" e che "molti di questi non sono
sicuri". Nessuno dice che, quasi certamente, in quei 11.000 datacenter è
incluso l'antibagno del Comune XYZ (che, insieme alla scopa ed al
carrello delle pulizie, vede a terra anche il server con il locale
gestionale). E nessuno riflette sul fatto che la "sicurezza" è stata
misurata valutando il livello di TLS supportato (quando supportato) sul
sito web istituzionale.

Questa (del magazzino delle scope, e del TLS istituzionale) è la realta'
nella PA di oggi. Non è quella delle architetture cloud-native. E
contrattualizzare i rapporti con google, microsoft e amazon, non credo
risolverà molto (anzi).

Secondo me bisogna avere bene in mente questo stato di fatto per poter
offrire piani credibili di indipendenza tecnologica all'Italia e
all'Europa.

mi piacerebbe vederne almeno uno di questi "piani credibili". Finora io
non ho visto nulla, se non articoli (generici), mail (generiche) e
qualche chiacchiera. Ma di "piani" --almeno per come intendo io la
parola "piano"-- _zero_.


Scusate la prolissità

My 0.02€

Bye,
DV


-- 
Damiano Verzulli
e-mail: damiano@verzulli.it
---
possible?ok:while(!possible){open_mindedness++}
---
"...I realized that free software would not generate the kind of
income that was needed. Maybe in USA or Europe, you may be able
to get a well paying job as a free software developer, but not
here [in Africa]..." -- Guido Sohne - 1973-2008
  http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html