[nexa] Colonialismo digitale US nel Cloud Italiano e Schrems - II

Damiano Verzulli damiano at verzulli.it
Thu May 27 11:00:15 CEST 2021


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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://server-nexa.polito.it/pipermail/nexa/attachments/20210527/965cdc1f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://server-nexa.polito.it/pipermail/nexa/attachments/20210527/965cdc1f/attachment.sig>


More information about the nexa mailing list