"Fabio Pietrosanti (naif)" <lists@infosecurity.ch> writes:

Ottime e fresche riflessioni da parte di Inno Genna sul tema.

Cloud nazionale: quanti equivoci, dal Cloud Act a Gaia-X:

https://www.huffingtonpost.it/entry/cloud-nazionale-quanti-equivoci-dal-clou...

--8<---------------cut here---------------start------------->8--- Il modello francese si basa sull’idea che i dati della PA siano completamente fuori del controllo delle aziende straniere, anche quando queste forniscano della tecnologia. In altre parole, le chiavi crittografiche e gli strumenti per decidere circa il trattamento dei dati saranno completamente nelle mani delle aziende europee, mentre quelle straniere si limiteranno a fornire la tecnologia. Se non fosse così, i dati della PA francese sarebbero attaccabili dalle giurisdizioni americane. --8<---------------cut here---------------end--------------->8--- Mi mancano i dettagli su cosa significhi "modello francese" in questo contesto, però direi che sostenere che sia sufficiente avere "le chiavi crittografiche" per fare in modo che i dati NON siano sotto il controllo di chi gestisce le infrastrutture "cloud" (se c'è una azienda statunitense, soggetta a Cloud Act) è quantomeno fuorviante. Chi controlla il software che gestisce l'infrastruttura IT?!? Sono io che non capisco o cosa? Saluti, 380° [...] -- 380° (Public Giovanni Biscuolo alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

Ulteriore approfondimento, dopo l'analisi con Francesi e Statunitensi, e quanto il tema sia difficile da risolvere per ri-ottenere indietro la sovranità dei dati in Europa rispetto agli Stati Uniti D'America: https://www.agendadigitale.eu/sicurezza/cloud-i-dati-delle-pa-gestiti-da-azi... Fabio On 26/05/2021 17:22, Fabio Pietrosanti (naif) wrote:

Ottime e fresche riflessioni da parte di Inno Genna sul tema.

Cloud nazionale: quanti equivoci, dal Cloud Act a Gaia-X:

https://www.huffingtonpost.it/entry/cloud-nazionale-quanti-equivoci-dal-clou...

Fabio

On 26/05/2021 15:57, Fabio Pietrosanti (naif) wrote:

...

Di fronte ai piani di digitalizzazione massiva del paese (e dei relativi fondi d’emanazione comunitaria), non si può non notare come ci troviamo di fronte ad un pesante colonialismo digitale di matrice statunitense:

- TIM si allea con Google - Leonardo si allea con Microsoft - Fincantieri si allea con Amazon

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

Grazie Damiano per questo tuo messaggio che mi aiuta a chiarire alcuni temi. On Thu, May 27, 2021 at 2:00 AM Damiano Verzulli <damiano@verzulli.it> wrote:

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

Il contesto che ho in mente in questi giorni sono le applicazioni nuove della PA centrale italiana, PagoPA, IO e le novità annunciate da INPS. Queste applicazioni nuove non girano sui semplici IaaS. non parlo di VM da prendere e spostare in datacenter remoti: per questo tipo di workload penso ci siano abbastanza infrastruttura e competenze in Italia. Già quando parli di Gdrive/Onedrive e posta però, basandomi sulla mia esperienza personale, inizio ad avere dubbi... ma non divaghiamo. Quando leggo i proclami del governo di una strategia "cloud first", penso al megacatalogo di prodotti che offrono i megacloud. AWS ha iniziato con EC2 e S3, ma ora il catalogo è immenso e continua a crescere. La spinta al cloud la interpreto così: iniziate togliendovi il server dallo sgabuzzino transformandolo in una VM nel datacenter di un altro e comprate SaaS appena possibile; e se dovete sviluppare nuove applicazioni, guardate questo catalogo infinito, sviluppate applicazioni con architetture moderne.

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_;

Concordo su questo: sicuramente ci sono applicazioni legacy che si possono sollevare e spostare su VM senza problemi, magari pure con qualche vantaggio contabile. È il primo passo da fare.

Lo scenario che avevo in mente è quello di un salto generazionale, finanziato dal PNRR. In pratica immaginavo che la strategia del cloud first significasse in pratica: saltate il lift-and-shift dal ferro alla VM (quello andava fatto 15 anni fa) e usate questi fondi per riscrivere le applicazioni di protocollo, gestione prenotazioni delle ASL, cartelle mediche ecc su cloud. E a cloud assegno il significato di oggi, non quello di 15 anni fa, ovvero il catalogo completo dei GAM.

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?

Nello scenario che ho in mente, un comune che vuole aggregarsi a PagoPA non andrà a farsi sviluppare un'applicazione LAMP da far girare su una VM ma sarà incentivato a usare quei fondi per saltare direttamente a sistemi moderni. Molto più probabile però che la maggior parte delle PA italiane useranno i fondi per lift-and-shift, e per quello basta Aruba e Binario Etico.

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).

Perchè i paradigmi del F/OSS sono ben in mente a Jassy, Pichai e Nadella (e ai colossi cinesi, guarda le sponsorizzazioni che fanno). Queste sono le aziende al top dell'innovazione mondiale. Il caso Microsoft è emblematico che prova il nesso di causalità tra open source, innovazione e successo commerciale nei servizi cloud (inteso in senso molto lato): fino alla svolta di Nadella e l'adozione tattica di progetti open source, Microsoft era indietro.

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

Il compito credo sia nostro di fare la Politica e suggerire soluzioni.

On Thu, May 27, 2021 at 10:35 AM Giacomo Tesio <giacomo@tesio.it> wrote:

In sostanza, stai riproponendo le brochure commerciali dei colossi USA rivendute come "modernità".

Il vero problema, in Italia, è che per i "C-level" le tue parole possono avere la stessa credibilità di quelle di Giuseppe Attardi, ma mentre lui li spinge ad investire nel nostro Paese, tu li inviti ad affidare soldi, dati e competenze future a note aziende straniere minimizzando il proprio rischio personale ancor prima di quello delle aziende o delle PA che dovrebbero servire.

Fermo lì! :) non sto invitando nessuno a dare soldi ai GAM. Capiamoci. Sto solo sollevando dubbi per discutere di soluzioni. Ulteriore chiarimento necessario: sto partendo dal presupposto che il PNRR sia un finanziamento per un moonshot, una sorta di programma Apollo di modernizzazione globale della PA italiana. Per un moonshot non mi aspetto di classificare come innovazione usare gdrive o spostare il database Access dallo sgabuzzino in una VM su Aruba. Da questa conversazione mi rendo conto che il mio presupposto è sbagliato. Se con questi fondi si finanzia il "forklifting" di semplici VM non vedo grossi ostacoli operativi o di competenze. Sarei proprio curioso di leggere quali dubbi tu abbia.

I rant sulle applicazioni di calendario, indirizzi, posta e sincronizzazione file li dedichiamo alla prossima volta che ci troviamo di persona con sufficienti birre o vini che è più divertente :)

Ma siamo davvero tutti nati ieri?

Chi non è nato ieri ricorderà di sicuro le vicende del Sistema Pubblico di Connettività e Cooperazione applicativa (anni 2000): web services, buste di e-governement, accordi di servizio, porte di dominio, registri wsdl con annotazioni semantiche eccetera. Tutta quella architettura (sanamente) decentralizzata restò sostanzialmente sulla carta, ma intanto vennero fatte gare e spesi soldi. Ora la domanda è: se non si riuscì a ottenere che le amministrazioni facessero un wrapping dei loro servizi legacy, come si potrà ottenere che li trasferiscano su un cloud? Chi andrà a sbullonare i mainframe dal CED di INPS? Come si otterrà che un grande Comune o una Regione provvedano alla migrazione di tutto ciò che hanno sviluppato e messo in esercizio sulle loro infrastrutture, con i loro fornitori e le loro in-house, in decine e decine di anni? Non è una questione infrastrutturale: per un'organizzazione complessa, un sistema informativo è un ganglio vitale socio-tecnico che, una volta in funzione, non è facile trapiantare. Il rischio più concreto è che vengano impegnate risorse ingenti per ottenere risultati socialmente trascurabili. E' una storia che abbiamo già visto.

E se facessimo ALTRO?

Infatti, ma il problema è che l'ALTRO che andrebbe fatto è qualcosa che non si può mettere banalmente a gara. G. On Thu, 27 May 2021 at 22:37, Giacomo Tesio <giacomo@tesio.it> wrote:

On May 27, 2021 5:49:07 PM UTC, Stefano Maffulli wrote:

...

sto partendo dal presupposto che il PNRR sia un finanziamento per un moonshot, una sorta di programma Apollo di modernizzazione globale della PA italiana.

"Modernizzazione globale della PA italiana" è uno slogan vuoto quanto è bello.

Se prendesse piede ci ritroveremmo a buttare milioni di euro per seguire le mode IT del momento.

Mode guidate da interessi commerciali (e non) altrui.

Inseguire le magnifiche sorti e progressive promesse dai pifferai del momento è un'ottima strategia per buttare via soldi e opportunità.

Più che un moonshot, è uno USA-shot.

Infatti la massima aspirazione che proponi... sono loro.

E se facessimo ALTRO?

Se massimizzassimo resilienza e diffusione di competenze approfondite invece di efficienza computazionale e scalabilità planetaria?

Potremmo persino scoprire che il cloud non ci serve poi così spesso!

...

Da questa conversazione mi rendo conto che il mio presupposto è sbagliato.

Credo di sì.

Ma probabilmente parliamo di presupposti diversi. ;-)

...

...

Sarei proprio curioso di leggere quali dubbi tu abbia.

I rant sulle applicazioni di calendario, indirizzi, posta e sincronizzazione file li dedichiamo alla prossima volta

Peccato.

Mi resterà il dubbio sulla natura dei tuoi dubbi...

Ma non credo che siano comparabili con i gravissimi problemi di natura strategico militare delle soluzioni fornite da Google, Amazon e Microsoft.

Ci sorprendiamo che Google rinunci ai profitti [1] per sovvenzionare il cloud? Che valore ha per una nazione controllare l'infrastruttura informatica della PA di un'altra nazione?

Ma siamo davvero tutti nati ieri?

Giacomo

[1] https://www.econotimes.com/Googles-cloud-business-is-losing-money-1601526 _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Buongiorno Guido, per favore avresti qualche puntatore ad articoli di analisi, anche "vecchi", in merito allo stato (pietoso?) del SPC? Qui in brianza gli umarell, che sanno il fatto loro e non sono nati ieri, usano dire: «Fà e disfà l'è tücc un lavurà» (fare e disfare è tutto un lavorare), sono sicuro che per ogni zona d'Italia gli umarell hanno un modo di dire analogo. ...eh sì, io sono /solo/ un umarell "digitale" :-D Guido Vetere <vetere.guido@gmail.com> writes:

...

Ma siamo davvero tutti nati ieri?

Chi non è nato ieri ricorderà di sicuro le vicende del Sistema Pubblico di Connettività e Cooperazione applicativa (anni 2000): web services, buste di e-governement, accordi di servizio, porte di dominio, registri wsdl con annotazioni semantiche eccetera.

Ammetto la mia ignoranza di quel sistema e me ne vergono un po' visto che è da un po' che studio il tema... ma era proprio fuori dal mio radar perché lo avevo percepito come /mera/ connessione in rete e quindi ignorato di proposito (vedi sotto) :-( ... quindi grazie! Io ho trovato questa pagina di Wikipedia: https://it.wikipedia.org/wiki/Sistema_pubblico_di_connettivit%C3%A0 Immagino proprio che sia a questo sistema che ti riferisci, giusto? Perccato che in quell'articolo di Wikipedia si dipinga SPC come se fosse solo un provvedimento che si occupa di "attaccare la PA al doppino in rame (o alla fibra)": è così che è ridotto quel Sistema?!? A me non pare proprio che SPC si limiti a quello descritto da Wikipedia E mi pare che sia tuttora in vigore, sbaglio? https://www.agid.gov.it/sites/default/files/repository_files/documentazione/... --8<---------------cut here---------------start------------->8--- Sistema pubblico di cooperazione: TERMINI E DEFINIZIONI - Versione 1.1 Nel presente documento sono descritti i concetti ed i termini utilizzati nei seguenti documenti di specifica del SPCoop: 1. Sistema Pubblico di Cooperazione: QUADRO TECNICO D’INSIEME, Pubblicato, V. 1.1 del 25/07/2011 https://www.agid.gov.it/sites/default/files/repository_files/documentazione/... 2. Sistema Pubblico di Cooperazione: TERMINI E DEFINIZIONI Pubblicato V. 1.1 del 25/07/2011 https://www.agid.gov.it/sites/default/files/repository_files/documentazione/... 3. Sistema Pubblico di Cooperazione: ACCORDO DI SERVIZIO Pubblicato V. 1.1 del 25/07/2011 https://www.agid.gov.it/sites/default/files/repository_files/documentazione/... 4. Sistema Pubblico di Cooperazione: PORTA DI DOMINIO Pubblicato V. 1.1 del 25/07/2011 https://www.agid.gov.it/sites/default/files/repository_files/documentazione/... 5. Sistema Pubblico di Cooperazione: BUSTA DI E-GOV Pubblicato V. 1.2 del 25/07/2011 https://www.agid.gov.it/sites/default/files/repository_files/documentazione/... 6. Sistema Pubblico di Cooperazione: SERVIZI DI REGISTRO Pubblicato V. 1.1 del 25/07/2011 https://www.agid.gov.it/sites/default/files/repository_files/documentazione/... 7. Sistema Pubblico di Cooperazione: SERVIZI DI SICUREZZA Pubblicato V. 1.1 del 25/07/2011 https://www.agid.gov.it/sites/default/files/repository_files/documentazione/... 8. Sistema Pubblico di Cooperazione: CONVENZIONI DI NOMENCLATURA E SEMANTICA Pubblicato V. 1.1 del 25/07/2011 https://www.agid.gov.it/sites/default/files/repository_files/documentazione/... 9. Sistema Pubblico di Cooperazione: ESERCIZIO E GESTIONE Pubblicato V. 1.1 del 25/07/2011 https://www.agid.gov.it/sites/default/files/repository_files/documentazione/... --8<---------------cut here---------------end--------------->8--- In merito, ho trovato anche questo documento: https://intranet.icar.cnr.it/wp-content/uploads/2016/11/TechReport-12_05.pdf --8<---------------cut here---------------start------------->8--- Sistema Pubblico di Cooperazione (SPC): Implementazione e testing su piattaforma Open Source A. Messina, P. Storniolo Rapporto Tecnico N.: RT-ICAR-PA-12-05 Dicembre 2012 [...] Il progetto 'IDS - Innovative.Document.Sharing', a cui sta partecipando l'Istituto di Calcolo e Reti ad Alte Prestazioni (ICAR) di Palermo insieme ad altri partner, ha come obiettivo la realizzazione di una piattaforma di gestione documentale innovativa per l'automatizzazione di tutte le fasi di gestione dei documenti digitali delle imprese. [...] Al fine di garantire la interoperabilità anche con il settore pubblico, l'infrastruttura di cooperazione è basata sulle specifiche del Sistema Pubblico di Cooperazione (SPCoop), definite dal CNIPA, che consente all'intero sistema di gestione di essere predisposto ad interagire con l'infrastruttura SPC (Sistema Pubblico di Connettività) di cui si sta dotando la P.A [...] 1.2 Il Sistema Pubblico di Connettività e Cooperazione Il Sistema Pubblico di Connettività (SPC) e di Cooperazione (SPCoop) è una architettura progettata dal CNIPA con lo scopo di regolare, attraverso delle specifiche, l’erogazione e la fruizione di servizi delle pubbliche amministrazioni italiane. Costituisce l’infrastruttura che permette la cooperazione applicativa, che consente uno scambio di servizi tra applicazioni informatiche appartenenti sia a soggetti privati che a enti amministrativi. La definizione di questo standard di cooperazione include la specifica di una rete sicura di trasporto tra le amministrazioni (Connettività) e di un livello di comunicazione a messaggi (application layer) che permetta protocolli di comunicazione a livello applicativo (Cooperazione). Il modello di riferimento dell’architettura del Sistema pubblico di cooperazione si basa sulla tecnologia dei Web Services. --8<---------------cut here---------------end--------------->8--- Cioè era già tutto ben definito (compresa la /rete sicura di trasporto/, che non può che essere INTRANET) già più di un decennio fa.

Tutta quella architettura (sanamente) decentralizzata restò sostanzialmente sulla carta, ma intanto vennero fatte gare e spesi soldi.

Quindi tutta 'sta roba è rimasta praticamente vaporware (soldi a parte... che però effettivamente sempre carta sono :-D)? Io ho provato a cercare diferimenti a SPC sul sito https://developers.italia.it/ ma non ho trovato nulla: non sono capace io o non lo considerano nemmeno? ...e ora ricominciamo da capo "sul Cloud" come se /tutti/ i requisiti normati fino a ieri non fossero mai esistiti ma SOPRATTUTTO come se non ci fosse non solo uno ieri ma manco un domani (che sarà la copia dell'oggi)? Ho dato un'occhiata alle FAQ di CloudSPC https://www.cloudspc.it/FAQ.html ma non mi pare che si faccia minimamente riferimento alla normativa SPC di AgID elencata sopra: anche in questo caso non sono capace io? Sapete che sembra fatto tutto apposta per confondere e basta, vero?!? :-O [...] Grazie, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

Domanda: per tu quanto ne sappia il "catalogo" di openstack può essere considerato sufficientemente moderno? Il 27/05/21 19:35, Giacomo Tesio ha scritto:

In sostanza, stai riproponendo le brochure commerciali dei colossi USA rivendute come "modernità".

On 26/05/21 19:37, Stefano Maffulli wrote:

Il messaggio di Fabio solleva punti molto importanti con scenari plausibili. Come altri dicono nella discussione, gli accordi così come annunciati portano alti rischi e confermano una sudditanza tecnologica.

Totale.

Per ribattere, oltre alla critica, bisogna poter offrire un'alternativa o soluzioni tampone nel breve periodo. Serve tenere presente che *oggi* non ci sono alternative alle cloud di Google, Amazon e Microsoft. Le alternative locali sono indietro di oltre 10 anni, sia per dimensioni sia per funzionalità.

Verissimo.

E il PNRR mette "cloud" al centro della strategia digitale del paese.

E mantiene un profilo ambiguo. Parla di Hybrid Cloud perché sa bene che non si può pretendere un Private Cloud italiano, ma neanche si può dare il messaggio che mettiamo tutto in Public Cloud estero. Che di fatto, purtroppo, sarà quello che succederà, al netto dei buoni propositi dell'approccio Hybrid dichiarato...

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.

E' così. Ma quello che io dico sempre è: se mai cominciamo, mai erodiamo il ritardo accumulato. Quindi ben vengano i propositi di cominciare a fare qualcosa di autonomo.

Mai come oggi c'è stato così tanto software libero che in pochi però sanno far funzionare a scala.

E' questo che mi fa arrabbiare! Come mai non siamo incisivi in queste cose? Perché è difficile?!? Ma no, dai, non scherziamo... Anzi è divertente e formativo per un sistemista o per un architetto del software esplorare questo campo. Inoltre aggiungo che le licenze software di OpenStack e Kubernetes sono Apache License 2.0, compatibili, quindi, con GPLv3. Perché FSF non ci ha mai fatto un pensierino?

On Wed, May 26, 2021 at 6:57 AM Fabio Pietrosanti (naif) <lists@infosecurity.ch <mailto:lists@infosecurity.ch>> wrote:

Prendiamo un esempio, spacchettiamolo, TIM e Google costituiscono una società assieme, creando un datacenter apposito (CAPEX come se piovesse) con dentro cemento, fibre, server, rack e quant’altro. Dentro quella “infrastruttura as a service” ci gira software e tecnologia proprietaria di Google.

E che altra tecnologia ci vuoi far girare in un datacenter e con quale manodopera? Queste competenze sono rare.

Mai iniziamo, mai ci saranno...

Non ricordo di aver mai visto nessuno dei tre grandi nomi (TIM, Fincantieri e Leonardo) tra gli sponsor di progetti open source a scala "cloud". Non ricordo nemmeno di aver mai sentito questi nomi dare presentazioni alle conferenze di OpenStac/OpenInfra o Linux Foundation. I nomi non ci sono nella lista di soci di OpenStack o CNCF, per esempio.

Vero. In generale di italiani che vivono e lavorano in Italia se ne sono visti pochi in queste conferenze. Gli unici italiani che incontravi erano quelli residenti all'estero.

Gli italiani in OpenStack erano Garr, INFN ed Enter, tutte con pochi spiccioli.

E Binario Etico. ;-) https://openinfra.dev/companies/ B-) Possiamo aggiungere i nostri (pochissimi) 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.

Cloud architects e scalability engineers hanno stipendi che superano i 200mila dollari in USA. Quelli più esperti portano a casa tranquillamente pure il doppio. Chi ci viene a mettere in piedi da zero un'infrastruttura su progetti open source tipo Kubernetes in Italia con gli stipendi medi italiani?

Quello dello stipendio è un tema, ma non può essere l'unico. Per un italiano vivere in Italia è importante; per alcuni italiani lo è di più del denaro. Però aumentare gli stipendi italiani di chi ha competenze in materia, aiuterebbe in effetti.

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?

Affatto.

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

Ce l'hanno. Tanto è vero che si butteranno sul Public Cloud. Non possono fare altrimenti. Però, e su questo dobbiamo insistere, dobbiamo iniziare a farci le nostre cloud. D.

Lungi da me lo sventolare --in ambito PA-- la bandiera dei cloud-provider made-in-USA. Cio' premesso.... Il 28/05/21 08:37, Marco Ciurcina ha scritto:

In data mercoledì 26 maggio 2021 10:37:09 CEST, Stefano Maffulli ha scritto:

...

Serve tenere presente che *oggi* non ci sono alternative alle cloud di Google, Amazon e Microsoft. Non è vero in assoluto che in Italia non c'è niente all'altezza dei cloud USA:

da tecnico che si sporca le mani con le tecnologie di cui parliamo, sostenere che in _ITALIA_ ci sia qualcosa "all'altezza dei cloud USA" (tout-court, senza specificare il contesto, e quindi riferendosi al 100% dei servizi made-in-USA) è pericolosamente errato. A mio avviso il problema _NON_ è: "Siamo Italiani; siamo bravi; possiamo fare quello che fa AWS!". Questo, ad _OGGI_, è _IMPOSSIBILE_. Il problema è: "Per la PA Italiana _DI_OGGI_, ossia per coloro che hanno detto di avere 11.000 datacenter up-and-pseudo-running e per i quali AGID riscontra problemi di (TLS-based)-security, e sulla base dei quali AGID ha impostato tutta la strategia di "migrazione al cloud" delle PP.AA", esiste una alternativa che NON sia made-in-USA?" A questa seconda domanda, la risposta è "_SI_; ASSOLUTAMENTE _SI_". Ed è "SI", perché per risolvere questo problema: 1: _NON_ serve la scalabilità su scala "globale" (world-wide) di AWS; 2: _NON_ servono le tecnologie software ultra-moderne (disaccoppiamento delle componenti applicative con relativa distribuzione su scala geografica e con annessi add-on che garantiscono scalabilità orizzontale praticamente illimitata) ossia _NON_ servono i due elementi che rendono AWS "unica" (ed inavvicinabile da noi Europei nei prossimi 3/5 anni). E allora... cosa serve? I miei occhi vedono un problema che si puo' inquadrare cosi': i 6.700 comuni con meno di 10.000 abitanti hanno (quasi) _TUTTI_ un PC di fianco il carrello delle pulizie, nell'antibagno (che AGID ha deciso di chiamare "Datacenter"). In quel PC ci sono i dati dell'anagrafe, dei tributi e di altri sistemi (protocollo, etc.). Ci sono anche altri dati (oltre alle foto del cellulare del segretario comunale). Il problema sono quei _DATI_. Non si possono perdere. Sento gia' l'eco di chi dice: "Ma anagrafe, tributi, etc. sono gia' disponibili a catalogo AGID! Possono migrare li!". A questi rispondo dicendo che il termine "migrazione" ha --in questo settore-- un significato molto particolare (in sintesi: il PC, nel sottoscala, ci deve restare... per la consultazione dei dati vecchi). Se non è possibile spostare i soli dati (spegnendo e buttando il PC del sottoscala - e quindi "chiudendo un datacenter"), a quel punto il piano B diventa: "ti sposto il PC, con tutti i dati". Questa operazione banale è fattibile con _CENTINAIA_ di fornitori nazionali (Cloud-provider di servizi IAAS). Chiaramente sto semplificando, ma il concetto è quello... Lo step 0 --nel mondo reale, della PA Italiana del 2021-- è IAAS. Bisogna _CORRERE_ a _SPEGNERE_ il 70/80% dei sistemi (non)gestiti in periferia e centralizzarli da qualche parte. E' la soluzione migliore del mondo? No. E' la soluzione che io preferirei? No. E allora perche' la proponi? ...perchè è l'unica cosa che oggi puo' funzionare. E, come plus, si riesce ad effettuare anche con una politica 100% "nazionale". E come ulteriore plus... la si ottiene pure a costi ridottissimi. Tra l'altro, avrebbe il vantaggio di rendere subito evidente che il problema _NON_ e' "tecnico". È politico (perche' bisogna prendere delle decisioni e avere la forza di imporle!) e organizzativo (perche' già la sola organizzazione di questa banale operazione di migrazione "fisica/locale => virtuale/remota" è ai limiti delle capacità disponibili oggi sul territorio). Poi possiamo indossare il cappello dei disegnatori del futuro e cominciare a dire: "mi piacerebbe una amministrazione pubblica che sia interoperabile ed a misura dei cittadini! Che sia sicura e che agisca come leva per lo sviluppo del Paese".... Ok. Ma questo e' un altro problema. Poi possiamo dire: "Mi piacerebbe che al prossimo click-day gli hacker non si sveglino e mandino in crisi il sistema" Ok. Ma questo e' un altro problema, molto piu' semplice da risolvere. Poi possiamo dire: "La digitalizzazione del Paese deve migliorare. Voglio il Gigabit a Roccacalascio". Ok. Ci stiamo lavorando. Ma se non usiamo questo Gigabit per trasportare i dati dell'anagrafe del Comune di Calascio da/verso il cloud/IAAS.... non mi è chiarissimo a che serve.... ma fa niente. Mi fido. Chiudo dicendo che ho semplicemente "scalfito" lo scenario attuale prendendo ad esempio i piccoli Comuni. La realta' è molto piu' drammatica: la totalità degli Atenei Italiani (con la sola eccezione di PoliTO) --che dai Comuni e dalle ASL vengono visti come "eccellenze"-- non è stata in grado (ne singolarmente; ne in forma aggregata) di erogare flussi audio/video in streaming a qualche decina di migliaia di studenti! E non l'hanno fatto nonostante avessero capacità trasmissive piu' che compatibili (GARR e banda "simmetrica") + infrastrutture computazionali che si possono comprare al prezzo di un tozzo di pane (con 50K€, su MEPA, un Ateneo puo' comprare risorse di calcolo sovradimensionate rispetto a questo problema) + fossero disponibili una pletora di soluzioni applicative F/OSS. Sento gia' l'eco: "Ma scusa! Allora perche' non lo hanno fatto?" Semplice: perche' (politicamente parlando) è molto piu' semplice firmare un documento e risolvere il problema in ottica-short-term acquistando un servizio (con l'ulteriore vantaggio di avere anche qualcuno su cui banalmente scaricare eventuali responsabilità di disservizi), piuttosto che pensare in ottica di "sistema Paese", di "competenze da coltivare", di "tutela dei dati".... DI INTERESSE PUBBLICO.... come ha fatto il Rettore del Politecnico di Torino. Unico caso in Italia. Insomma: vedo un sacco di problemi.... ma certamente _NON_ vedo il problema di andare a fare la concorrenza ad AWS per implementare i servizi che lei vuole (giustamente) vendere al mondo e che, in questo momento, alla nostra PA (almeno a quella degli 11.000 datacenter), non servono. Mi taccio. Scusate. 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

On Thu, May 27, 2021 at 11:37 PM Marco Ciurcina <ciurcina@studiolegale.it> wrote:

In data mercoledì 26 maggio 2021 10:37:09 CEST, Stefano Maffulli ha scritto:

...

Serve tenere presente che *oggi* non ci sono alternative alle cloud di Google, Amazon e Microsoft. Non è vero in assoluto che in Italia non c'è niente all'altezza dei cloud USA: dipende da quali sono le caratteristiche che cerchi.

Credevo di aver chiarito nei messaggi successivi il contesto della mia affermazione. In termini *assoluti*, non puoi paragonare i cloud GAM con quello che c'è oggi in Europa. Puoi fare paragoni sulle necessità specifiche delle pubbliche amministrazioni. Sono perfettamente d'accordo con te, Verzulli, Tesio che tutto dipende da che ci devi far girare. Se l'anagrafe del comune di Roccacalascio oggi gira su un serverino nello sgabuzzino, ovvio che lo sposti su Nivola senza problemi. Chiamalo "cloud", soddisfi le norme e magari si comincia a diffondere un po' di cultura "moderna", seppur datata 15 anni (ma da qualche parte si deve iniziare).

On 28/05/21 19:40, Giacomo Tesio wrote:

On Fri, 28 May 2021 09:11:17 -0700 Stefano Maffulli wrote:

...

In termini *assoluti*, non puoi paragonare i cloud GAM con quello che c'è oggi in Europa.

No.

Non c'è NULLA che la pubblica amministrazione di una Nazione europea non possa fare senza i servizi cloud dei GAM in modo più efficiente, efficace ed economico. NULLA.

Concordo, ma vorrei aggiungere: precisazioni, facilitazioni, invettive. Partiamo col dire che in questa lista nessunx (correggetemi se sbaglio) prova simpatia per i GAM. Anzi tuttx cercano alternative ai GAM. Quindi quando parliamo di cloud lo facciamo tenendo fermi almeno due presupposti: 1) Tutto il software con cui è COSTRUITO il cloud (oltre a qualsiasi software che giri SOPRA il cloud, ovviamente) deve essere FLOSS; 2) L'hardware su cui si costruisce il cloud deve essere nel controllo di chi lo costruisce (sovranità digitale o autonomia digitale, che dir si voglia); questo perché su quel ferro girano dati (-> privacy). Ciò premesso, guardiamo alle soluzioni FLOSS esistenti per costruire dei cloud. E ne troviamo una VALANGA: fondamentalmente tutto ciò che gira intorno all'Open Infrastructure (OpenStack e dintorni) e al cloud-native Open Source (Kubernetes e dintorni). Quando dico "dintorni" non intendo una galassia: intendo un UNIVERSO intero di software e soluzioni pazzesche! Tutta 'sta roba è licenziata Apache License v2.0, compatibile con GPLv3. Quindi potenzialmente la PA italiana potrebbe muoversi così: 1) Approvvigionare l'hardware (e recuperare quello che ha già); 2) Studiare; 3) Implementare il suo cloud con l'universo di software di cui sopra. Ora, mentre 1) è piuttosto veloce, 2) è mooooolto oneroso. Quando si dice che AWS sta troppo avanti, si intende che ha fatto ciò di cui in 2) per 20 anni. Mentre la PA ha fatto ciò di cui in 2) per 0 anni (zero). Quindi AWS ha un vantaggio netto di 20 anni rispetto ciò di cui in 2). E senza il 2), il 3) non può esserci, oppure (peggio ancora) può esserci con output disastrosi. Ci vogliono anni? Sì. Ci vogliono lustri? Forse. Ma non è impossibile. Se l'albero non è stato piantato 20 anni fa, si può piantare oggi (cit.). Facciamo un passo avanti. Quando si parla di cloud, spesso si pensa a Data Center molto grandi e a scenari di scalabilità globali. Questo non è sbagliato, perché in effetti il cloud FINORA si è sviluppato _prevalentemente_ così. FINORA! Supponiamo che a noi non piaccia il modello centralizzato. Gioco facile con questa supposizione, perché so benissimo che qui a pochx (se non a nessunx) piace il modello centralizzato. A chi dicesse: "Fanculo il cloud, è centralizzato", io risponderei: "Ma chi te l'ha detto?!". - Il progetto Massively Distributed Open Stack, per esempio, lavora su scenari di Fog Computing [1]. - Stack4Things dell'Università di Messina (un'assoluta eccellenza italiana) fa IoT-cloud integration su OpenStack [2]. Fanno cose pazzesche come questa: IoTronic: FaaS for the IoT in the Fog [3]. - Con Kubernetes puoi realizzare quello che vuoi, decentrato quanto vuoi. Basta studiare [4] e implementare [5]. Tutto questo per dire che cosa? - Certamente possiamo prendere il cloud Open Source, buttarlo nel secchio e ricominciare da capo con qualcosa di completamente diverso. - Certamente si può fare di meglio di chi negli ultimi 10 anni ha puntato sul cloud Open Source: perché non era Free Software, ma Open Source, perché partiva da logiche prevalentemente commerciali, perché aveva in testa un obiettivo industriale di omologazione. - Certamente siamo più fighi della Linux Foundation (perché noi siamo sempre più fighi degli altri, no? :-P ) Solo che io in queste posizioni non vedo software, vedo parole. E allora aggiungo altre parole anche io: - Posto che il software c'è, perché qualcuno si è preso la briga di svilupparlo e lo ha anche rilasciato open, perché devo ricominciare da capo? - Perché non posso partire da quello che c'è (che è tanto) e usarlo per quello che voglio ottenere? - Perché non posso avvantaggiarmi di un'esperienza globale di 10 anni? 10 ANNI!!! Un'era geologica! Software, documentazione, competenze, comunità, modelli di adozione, esperienze, interesse... - Perché non posso forkare se non mi piace qualcosa, ma devo necessariamente dire che fa cacare e che io saprei fare di meglio? Dire no a tutto questo è sbagliato. Da un punto di vista di Free Software, profondamente sbagliato. Con un po' di umiltà e ragionevolezza, si fanno le cose. Come si sono sempre fatte: non buttando, ma migliorando e aggiungendo. D. [1] <https://wiki.openstack.org/wiki/Fog_Edge_Massively_Distributed_Clouds>. [2] <http://stack4things.unime.it/>. [3] <https://www.youtube.com/watch?v=3-kzC95ZOow>. [4] <https://dl.acm.org/doi/abs/10.1145/3375555.3383585>. [5] <https://github.com/ls1intum/fogernetes>.

On 31/05/21 10:29, Giacomo Tesio wrote:

Ciao Davide,

grazie anzitutto degli ottimi link...

Con i link si cerca di colmare le lacune, che sul tema sono piuttosto estese. Io ho avuto la fortuna 10 anni fa di cominciare un percorso complesso e interessante, voglio condividere quello che ho appreso.

On Sat, 29 May 2021 14:18:37 +0200 D. Davide Lamanna wrote:

...

Quindi potenzialmente la PA italiana potrebbe muoversi così:

1) Approvvigionare l'hardware (e recuperare quello che ha già); 2) Studiare; 3) Implementare il suo cloud con l'universo di software di cui sopra.

Ora, mentre 1) è piuttosto veloce, 2) è mooooolto oneroso. [...]

Ci vogliono anni? Sì. Ci vogliono lustri? Forse.

No.

Enrico Venuto del Politecnico di Torino ha impiegato un paio di giorni.

Conosco molto bene questo progetto. Penso che qui lo conoscono un po' tuttx... :-)

...

- Certamente siamo più fighi della Linux Foundation (perché noi siamo sempre più fighi degli altri, no? :-P )

Perché ti metti in competizione con la Linux Foundation?

Ehm... Era una battuta. Volevo dire esattamente il contrario! Solo che non l'hai capita perché evidentemente non sai che la Linux Foundation sta dietro alla Cloud Native Computing Foundation [1] che cura Kubernetes e dintorni. La Linux Foundation ha fatto un lavoro straordinario sul cloud [2]. La Linux Foundation non è stata a sentire le sirene dell'anti-cloud. Dieci anni fa si è messa a lavorare e ha prodotto un universo di software [3]. La battuta era: noi ci sentiamo più fighi della LF?

Peraltro, sulla base di quali criteri?

...

Solo che io in queste posizioni non vedo software, vedo parole. E allora aggiungo altre parole anche io: [...]

Dire no a tutto questo è sbagliato. Da un punto di vista di Free Software, profondamente sbagliato. Con un po' di umiltà e ragionevolezza, si fanno le cose. Come si sono sempre fatte: non buttando, ma migliorando e aggiungendo.

Credo Davide che nella foga dialettica, tu ti sia inavvertitamente lanciato in un lungo strawman.

Non si tratta di buttare via tutto. Non subito almeno! ;-)

Si tratta di diventare consapevoli delle dinamiche tecno-politiche su cui si regge l'egemonia tecnologica statunitense.

Si tratta di renderle esplicite, riconoscerle e sottolinearle quando agiscono nella nostra società per mantenerla e potenziarla.

Certo possiamo e dobbiamo usare il software esistente per costruire l'infrastruttura che ci serve.

Meno male... Ma dobbiamo iniziare a pensare a questo

software in modo critico, ad esplicitarne le assunzioni e discuterle.

E quando le dinamiche che quel software non sono compatibili con i nostri interessi strategici, DOBBIAMO pensare e realizzare alternative.

Perché POSSIAMO farlo.

Chi sostiene il contrario MENTE (più o meno consapevolmente).

Il software è il più malleabile degli artefatti umani.

Il fatto che la maggioranza delle persone lo viva e lo pensi come immutabile, un fatto dato, incontrovertibile ed arcano costituisce la più grande allucinazione collettiva della nostra epoca.

Ma no, ma no... Non qui almeno, dai... :-) D. [1] <https://www.cncf.io/>. [2] <https://landscapeapp.cncf.io/lf/card-mode?grouping=license&license=open-sour...>. [3] Questo non è che un piccolo assaggio: <https://collabnix.github.io/kubetools/>.

On 31/05/21 11:56, Giacomo Tesio wrote:

On Mon, 31 May 2021 11:36:01 +0200 D. Davide Lamanna wrote:

...

...

...

- Certamente siamo più fighi della Linux Foundation (perché noi siamo sempre più fighi degli altri, no? :-P )

Perché ti metti in competizione con la Linux Foundation?

Ehm... Era una battuta. Volevo dire esattamente il contrario! Solo che non l'hai capita perché evidentemente non sai che la Linux Foundation sta dietro alla Cloud Native Computing Foundation [1] che cura Kubernetes e dintorni.

La Linux Foundation ha fatto un lavoro straordinario sul cloud [2]. La Linux Foundation non è stata a sentire le sirene dell'anti-cloud. Dieci anni fa si è messa a lavorare e ha prodotto un universo di software [3].

La battuta era: noi ci sentiamo più fighi della LF?

Ehm... no, lo so e forse la mia domanda non era chiara se ha prodotto questo fraintendimento: la Linux Foundation persegue obiettivi strategici determinati dai suoi fondatori e maggiori finanziatori.

Ciò che ha fatto non è affatto "figo" se non persegui tali obiettivi.

Quali sono questi obiettivi?

Quali architetture cibernetiche determinano?

E' ciò che vogliamo per l'Europa e l'Italia dei nostri figli?

Se la risposta a quest'ultima domanda dovesse essere "no" (come personalmente ritengo [1]) allora ciò che la Linux Foundation realizza può esserci utile (entro certi limiti) ma non è né qualcosa con cui competere, né qualcosa da perseguire.

Perché, anche accettando la competizione come fine ultimo della nostra vita ("essere più fighi"), competere sul terreno scelto dall'avversario e con le regole decise unilateralmente dall'avversario è... molto miope.

Per me Linux Foundation non è un avversario. Piuttosto un alleato. Con tutti i distinguo del caso, ma pur sempre un alleato. Sono consapevole che ci sono dietro capitali finanziari ingenti, afferenti all'area geopolica statunitense e interessi strategici non certo "militanti". E che questo certamente si ripercuote sulle scelte architetturali. Ma lo stesso vale per il kernel Linux, ad esempio, che è licenziato GPLv2 e sviluppato in massima parte da RedHat. E per una tonnellata di altro software Open Source. D.

Buongiorno, rispetto al "core" iniziale questo messaggio devia un pochino ma tocca uno degli aspetti molto importanti delle infrastrutture IT, Cloud compreso Stefano Zacchiroli <zack@upsilon.cc> writes: [...]

I contributi delle aziende a Linux restano massivi *in totale*: quelli da indipendenti e volontari sono regolarmente pochi punti percentuali, tutto il resto viene da aziende. Ma tra le aziende non c'è un vero campione che domini sugli altri.

Dal punto di vista geopolitico questo non ci aiuta molto perché la maggior parte di tali aziende sono americane (e membri della Linux Foundation...), ma a volte aiuta, per esempio in caso di conflitti di interessi tra aziende.

Queste considerazioni di Stefano sono molto, molto importanti, perché non dobbiamo certo aspettarci che i contributi più significativi arrivino da volontari... però le istituzioni pubbliche (indipendenti?) potrebbero (dovrebbero?) fare molto di più e molto meglio, essere DECISAMENTE più presenti nello sviluppo del kernel Linux *e* possibilmente di /almeno/ un altro kernel libero alternativo [1]. In questo io osservo una certa qual miopia da parte delle istituzioni perché non è il caso di lasciare che il 90% (80%? 70%) dei contributi a Linux o in generale al software libero (possibilmente copyleft) siano finanziati da aziende statunitensi. Vedo anche una certa assenza (disinteresse?) [2] dell'Università, come se lo sviluppo di Linux e altri kernel migliori non facesse parte della sua missione: sbaglio, ho una visione distorta? Per non parlare, INSISTO, del fatto che dall'Università, anche nella EU, vengono un sacco di idee e progetti innovativi, che però sono /asfittici/ perché non adeguatamente sostenuti politicamente e /quindi/ sottofinanziati (come tutta la ricerca in generale). Anche da questo viene la mia delusione per il piano Next DEgeneration EU: se non usiamo questa occasione per un piano pubblico di (r)innovazione tecnologica stiamo davvero degenerando. [...] Saluti, 380° P.S.: sui problemi che IBM, proprietaria di RedHat, sta causando ad alcuni progetti software e del suo supporto ai brevetti software meglio soprassedere, basta non ignorarli però. [1] sparo una previsione decisamente A CASO: la complessità di Linux lo metterà in crisi seria entro i prossimi 5/6 anni. [2] oppure potrebbe essere anche soltanto dignitoso silenzio :-) -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

In termini *assoluti*, non puoi paragonare i cloud GAM con quello che c'è oggi in Europa.

Scusa Stefano, neanche a me è chiaro a cosa ti riferisci per *assoluto". Economicamente sono dei giganti, ma a noi (Italia) poco importa. Fanno prezzi concorrenziali, e mi sembra ovvio, l'economia di scala non l'hanno certo inventata loro. Hanno più "ingegneri" e pagati profumatamente, e grazie, con i ricavi miliardari se lo possono permettere. I chirurghi hanno stipendi molti diversi da un paese all'altro, non per questo le persone vanno tutte a farsi operare dal "più bravo e più caro" al mondo. Quindi è l'offerta dei servizi, dei prodotti? Tu dici "megacatalogo di prodotti che offrono i megacloud. AWS ha iniziato con EC2 e S3, ma ora il catalogo è immenso e continua a crescere" Da una pagina pubblicitaria di Amazon [1] "S3 è progettato per una durabilità del 99,999999999% (undici nove) e per memorizzare i dati di milioni di applicazioni delle aziende in tutto il mondo". Durabilità? "undici nove"?. Ma ci prendono per scemi? Io ho sempre ridondato tutto e in trent'anni (e 30 anni fa Amazon non era nemmeno nata) non ho mai perso un byte, sono al 100% (un uno e due zeri) :) Ribadisco quanto scritto da Giacomo: "Non c'è NULLA che la pubblica amministrazione di una Nazione europea non possa fare senza i servizi cloud dei GAM in modo più efficiente, efficace ed economico. NULLA" Antonio [1] https://aws.amazon.com/it/s3/

On 28/05/2021 21:04, Stefano Maffulli wrote:

Tu dici che S3, Blob e le centinaia di servizi dei GAM non servono. Io ti ho portato l'esempio che già *oggi* la PA italiana usa Azure Functions per IO (pagopa): c'è l'equivalente di Functions su Nivola? Non lo vedo nella lista dei servizi.

Per te alla PA basta (ora e in futuro) qualche VM e robe come Lambda &co, managed kubernetes, i vari DBaaS (SQL e nosql), datalake vari, loadbalancer ecc per non parlare dei vari servizi di machine learning, video transcoding con una chiamata API non servono alla PA. OK! Viviamo chiaramente in mondi diversi :)

Credo che nessuna funzionalità erogata "per convenienza di sviluppatori frontend" non sia implementabile in modo autonomo, basata su software libero, avendo una clientela captive su cui puntare (tutta la utenza interna della PA). Se hai alcuni miliardi di euro all'anno di servizi, ingegnerizzare API di roba "stuff" è solo "ingegneria", e in un tempo ragionevole hai un payback rispetto che pagare servizi di "convenience dello sviluppatore frontend" . Dove risparmi in competenza usando API di cloud US, ne perdi in costi di OPEX che si sarebbero ripagati come knowledge CAPEX in un tempo molto rapido. Almeno IMHO, proprio perché parliamo di commodities di computing, niente di fantascientifico, potendo contare su una clientela captive che ammortizza i costi di R&S . No? Fabio

380° <g380@biscuolo.net> writes: [...]

Comunque, si da il caso che lo scorso 26 Febbraio Jonah Edwards del Core Infrastructure Team di IA abbia presentato la loro infrastruttura

Ad onor di cronaca, per chi non lo sapesse già, aggiungo che il team di Internet Archive ha progettato e utilizza il sistema di storage Petabox: https://archive.org/web/petabox.php --8<---------------cut here---------------start------------->8--- A few highlights from the Petabox storage system: Density: 1.4 PetaBytes / rack Power consumption: 3 KW / PetaByte No Air Conditioning, instead use excess heat to help heat the building. Raw Numbers as of August 2014: 4 data centers, 550 nodes, 20,000 spinning disks Wayback Machine: 9.6 PetaBytes Books/Music/Video Collections: 9.8 PetaBytes Unique data: 18.5 PetaBytes Total used storage: 50 PetaBytes --8<---------------cut here---------------end--------------->8--- Perché non copiarlo (e/o migliorarlo con i servizi che mancano) per farne un bel PAtabox? :-D [...] Saluti, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

On Sat, May 29, 2021 at 3:27 AM Giacomo Tesio <giacomo@tesio.it> wrote:

Detti così, senza fonte, sembrano i numeri a caso sparati sulle brochure commerciali.

non fanno mistero del sistema di archiviazione che usano, è lo stesso descritto su https://blog.archive.org/2016/10/25/20000-hard-drives-on-a-mission/ e https://blog.archive.org/2011/03/31/how-archive-org-items-are-structured/ Scrivigli pure se hai dubbi. Qualche anno fa partecipai insieme ad altri alla stima di un progetto che

avrebbe dovuto girare su Azure: il costo in 10 anni risultava fra le 3 e le 5 volte SUPERIORE rispetto ad una soluzione in house (anche includendo l'acquisto di ~100k di nuovo hardware per i 3 datacenter esistenti e costi di sviluppo).

Oh, su questo siamo d'accordo e credo sia cosa nota che oltre una certa dimensione, conviene possedere il datacenter. Per tornare in tema del thread iniziato da Fabio, accanto alla protesta per gli accordi commerciali con GAM, va affiancata la proposta alternativa. Ovvio che ci sono: vanno fatte valere.

On 28/05/21 21:04, Stefano Maffulli wrote:

On Fri, May 28, 2021 at 11:33 AM Antonio Iacono <antiac@gmail.com <mailto:antiac@gmail.com>> wrote:

Quindi è l'offerta dei servizi, dei prodotti?

Esattamente, mi riferisco al catalogo prodotti. Non parlo di prezzi, economie di scala e quant'altro.

Io ho sempre ridondato tutto e in trent'anni (e 30 anni fa Amazon non era nemmeno nata) non ho mai perso un byte, sono al 100% (un uno e due zeri) :)

Buon per te :) Anche Internet Archive ridonda tutto e non usa object storage. A fargli le pulci, così facendo spendono almeno il triplo di quello che le tecnologie moderne consentirebbero. Uno fa le sue scelte e decide come spendere il suo denaro.

Ma siamo sicuri? Quello che rende economiche le soluzioni "as a service" è la possibilità di acquisire e rilasciare la risorsa al bisogno, più che la sua economicità: a chi sa esattamente quanto spazio (o cpu) gli serve conviene il più delle volte comprare il ferro che gli serve. Queste almeno sono le conclusioni cui sono giunto per le mie esigenze. Internet Archive immagino abbia un piano di espansione dello storage piuttosto prevedibile, e penso che anche loro abbiano fatto i loro conti. ciao, A

On Sun, May 30, 2021 at 11:42 PM Alberto Cammozzo via nexa < nexa@server-nexa.polito.it> wrote:

Quello che rende economiche le soluzioni "as a service" è la possibilità di acquisire e rilasciare la risorsa al bisogno, più che la sua economicità: a chi sa esattamente quanto spazio (o cpu) gli serve conviene il più delle volte comprare il ferro che gli serve.

Queste almeno sono le conclusioni cui sono giunto per le mie esigenze.

Internet Archive immagino abbia un piano di espansione dello storage piuttosto prevedibile, e penso che anche loro abbiano fatto i loro conti.

non ho scritto che IA dovrebbe considerare public cloud, ho scritto che dovrebbe considerare aggiornare i suoi sistemi di storage al nuovo millennio: passare da archiviare file su filesystem e fare rsync tra rack e datacenter. Il mio commento era riferito alla frase "io ho sempre ridondato" che ho inteso alludesse "non serve object storage che garantisce 11 9 di continuità." La discussione è ormai degenerata... Chiudo qui per me.

On 29/05/21 16:39, Antonio Iacono wrote:

...

Tu dici che S3, Blob e le centinaia di servizi dei GAM non servono.

Io la penso come tale jiggawatts [1] ...

Caro Antonio, le affermazioni che riporti e su cui dici di concordare, sono una sequela di panzane. Il cloud NON è closed source, il cloud NON è il nuovo mainframe, il cloud NON è opaco nell'implementazione delle sue funzionalità. Tutte queste caratteristiche sono caratteristiche proprie dei Public Cloud dei GAM. Ma il cloud non inizia e finisce con il Public Cloud dei GAM! Esistono Public Cloud che NON sono dei GAM e sono sviluppati con OpenStack e Kubernetes. Ma il cloud non inizia e finisce neanche con il Public Cloud! Esistono dei Private Cloud che sono di chi li implementa e sono sviluppati con OpenStack e Kubernetes. Dire che il cloud è closed source e in mano ai GAM, equivale a dire che la Office Automation è closed source e in mano a Microsoft, ignorando Libre Office. Molti fraintendimenti di questo thread sono a mio avviso dovuti a questo. Se vuoi una descrizione compatta di cloud te la do io: un sistema operativo sta alla singola macchina, come il cloud sta ad N macchine. Il sistema operativo fornisce all'utente delle astrazioni in forma di servizi. Un sistema cloud fa la stessa cosa con N macchine. Ma i servizi che si possono realizzare e fornire con il cloud non sono pari ad N moltiplicato per i servizi di una singola macchina: sono piuttosto N elevato ad una potenza positiva grande a piacere (!) moltiplicato per i servizi di una singola macchina. Un cloud fatto bene è strumento di automazione per l'IT, è uso efficiente delle risorse IT, è gestione efficace delle risorse IT, è federazione di risorse IT, è trasparenza, è potenza, è partecipazione. D.

"The cloud is the new time-share mainframe. Programming in the 1960s to 80s was like this too. You'd develop some program in isolation, unable to properly run it. You "submit" it to the system, and it would be scheduled to run along with other workloads. You'd get a printout of the results back hours later, or even tomorrow. Rinse and repeat. This work loop is incredibly inefficient, and was replaced by development that happened entirely locally on a workstation. This dramatically tightened the edit-compile-debug loop, down to seconds or at most minutes. Productivity skyrocketed, and most enterprises shifted the majority of their workload away from mainframes. Now, in the 2020s, mainframes are back! They're just called "the cloud" now, but not much of their essential nature has changed other than the vendor name. The cloud, just like mainframes: - Does not provide all-local workstations. The only full-fidelity platform is the shared server. - Is closed source. Only Amazon provides AWS. Only Microsoft provides Azure. Only Google provides GCP. You can't peer into their source code, it is all proprietary and even secret. - Has a poor debugging experience. Shared platforms can't generally allow "invasive" debugging for security reasons. Their sheer size and complexity will mean that your visibility will always be limited. You'll never been able to get a stack trace that crosses into the internal calls of the platform services like S3 or Lambda. Contrast this with typical debugging where you can even trace into the OS kernel if you so choose. - Are generally based on the "print the logs out" feedback mechanism, with all the usual issues of mainframes such as hours-long delays."

Antonio

[1] https://news.ycombinator.com/item?id=26857859 _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

-- Ing. D. Davide Lamanna - CTO mobile: 340 4830930 voip: 06 916504256 fax: 06 233225276 Via Flaminia, 48 - 00196 Roma www.binarioetico.it

On 31/05/21 13:02, 380° wrote:

Ciao Davide,

"D. Davide Lamanna" <davide.lamanna@binarioetico.it> writes:

[...]

...

Molti fraintendimenti di questo thread sono a mio avviso dovuti a questo.

Sì ma non prendertela con Antonio (o con me e altri) che - da prospettive e in forme diverse - facciamo di tutto per analizzare criticamente il concetto di "Cloud".

Ma certo che no! Sono ultra-felice di confrontarmi con persone che stimo. Credo che la critica "al cloud"

riportata da Antonio si riferisca chiaramente al "cloud di qualcun'altro".

I fraintendimenti mica sono tra noi: sono tra chi sostiene che l'infrastruttura migliore /per quanto in oggetto/ sia quella fornita dai GAM (il thread è partito da lì, dagli accordi con GAM) e /quindi/ che HybridCloud va bene,

E però non prendertela neanche con Stefano Maffulli, che conosce gli ambienti di Open Infra e di CNCF e non è certo un fautore dei GAM. Il suo sano realismo lo porta ad affermare che il percorso dell'Hybrid è obbligato. Ed è difficile dargli torto. Ma non per questo ci arrendiamo: VENCEREMOS! oppure che IL PROBLEMA sta /esattamente/ in questi

dettagli:

1. di chi sono FISICAMENTE le macchine che compongono l'infrastruttura [1]

2. chi ha accesso ai sistemi operativi e gestisce i servizi

3. il software usato è libero o no

4. chi ha accesso allo storage e al transito dati in rete, quando i dati non sono crittografati e2e (at rest e in transit)

Solo se non si entra nel merito si casca in fraintendimenti, è per questo che è necessario non limitarsi agli slogan.

In altre parole, "Cloud" va benissimo come sigla commerciale che ci permette di presentare la nostra offerta a chi è "altrimenti sordo", PERÓ dobbiamo ammettere che "Cloud" fa schifo come termine tecnico;

Beh, dai... C'è di peggio... :-D

noi è di quello che stiamo discutendo ci siamo addirittura permessi di entrare nel merito tecnico... ma tanto va sempre a finire che "litighiamo" tra di noi per i dettagli e alla fine la torta se la pappano sempre coi soliti metodi (adattati per ogni epoca)... perché non ci sono alternative ai servizi GAM, dicono.

...

Se vuoi una descrizione compatta di cloud te la do io: un sistema operativo sta alla singola macchina, come il cloud sta ad N macchine.

Perché non chiamarlo "sistema distribuito" allora? :-O

Ok, affare fatto! :-D Fosse così facile...

Comunque, per tornare al tecnico che è l'unica cosa su cui mi è dato esprimermi, te lo propongo io un termine alternativo che sono SICURO mette tutti i tecnici in lista d'accordo: non "Cloud", che fa schifo e non indica nulla, ma "Infrasrtucture as (full stack) free software code", che in pochi termini concisi descrive la natura del sistema informativo che stiamo descrivendo: io lato marketing faccio schifo, trovate coi una sigla per quella "roba" lì se è il caso.

Sai qual è il problema: non è Free Software, è Open Source. Può diventare Free Software se lo vogliamo. Ma lo vogliamo? O vogliamo continuare a fare gli schizzinosi? A dire che tanto si può fare tutto alla vecchia maniera?

...

Il sistema operativo fornisce all'utente delle astrazioni in forma di servizi. Un sistema cloud fa la stessa cosa con N macchine.

Macchine geograficamente distribuite sul territorio, per cui - per esempio - lo storage /locale/ (se vuoi, /localmente distribuito/ con un filesystem adeguato) è di almeno un ordine di grandezza più efficiente di un endpoint S3 tra il comune di Lecco e Roma (e non per es. NFS in /rete locale/ connessa in fibra come i data centre di Internet Achive).

Tieni presente che mettersi in casa (magari non nello sgabuzzino delle scope, ecco) oggi un rack di macchine POWER9 [2] che erogano i servizi di un'intera area metropolitana (magari non via web dentro un browser, ma è un'altra storia) costa come un tozzo di pane, come è stato detto altrove in questo thread :-)

...

Ma i servizi che si possono realizzare e fornire con il cloud non sono pari ad N moltiplicato per i servizi di una singola macchina: sono piuttosto N elevato ad una potenza positiva grande a piacere (!) moltiplicato per i servizi di una singola macchina.

Non ho capito il calcolo e siccome sono curioso ti chiedo di espandere il ragionamento con qualche esempio

Era una battuta. Per dire che i "sistemi distribuiti" sono sistemi complessi [1] per i quali il tutto è maggiore della somma delle singole parti. Con "potenza grande a piacere" intendo MOLTO maggiore di tale somma.

...

Un cloud fatto bene è strumento di automazione per l'IT, è uso efficiente delle risorse IT, è gestione efficace delle risorse IT, è federazione di risorse IT, è trasparenza, è potenza, è partecipazione.

...ma /a volte/ è anche una inutile complicazione, a meno che il concetto di semplificazione valga soltanto per la burocrazia ;-)

Fair enough. Su questo hai pienamente ragione.

Ribadisco: credo che sul concetto di "infrastructure as code" si riuscirebbero a fare dei ragionamenti migliori... purtroppo il PNRR parla di Cloud, oggi come oggi quando si parla di informatica c'è sempre qualcuno che "la butta in cloud" :-D

Ma è il PNRR, non un manifesto politico di un hacklab! :-) D. [1] https://it.wikipedia.org/wiki/Sistema_complesso

On 29/05/21 11:25, Antonio Iacono wrote: [...]

Penso tuttavia che se qualcuno volesse invitare in lista gente come Alex Barchiesi, Alberto Colla, Marco Lorini, Matteo Di Fazio ... un'alternativa ad Azure Functions te la troverebbero in pochissimo con gli strumenti open source già disponibili.

Citi tutti amici e colleghi che si occupano di cloud. Ops... Volevo dire di sistemi distribuiti. ;-) D.

On 27/05/2021 08:48, Stefano Zacchiroli wrote:

C'è un dibattito simile in corso qui in Francia, dove il governo sta sostanzialmente provando a vendere come "cloud sovrano francese" delle soluzioni cloud dei GAFAM, con accordi d'uso specifici che "garantiscono" che storage e altre risorse di calcolo siano geograficamente localizzate in Francia.

In Francia Orange ha costituito con Microsoft una società di scopo, sotto la diretta supervisione dell'ANSSI (Cybersecurity) e CNIL (Garante Privacy), all'esplicito scopo di sfuggire al U.S. Cloud Act:

*Microsoft partners with French companies Orange, Capgemini on cloud*

-- By Laura Kayali May 27, 2021, 11:39 am | View in your browser <https://urldefense.com/v3/__https://politico.us8.list-manage.com/track/click...>

PARIS — French consulting and IT company Capgemini and telecom operator Orange will partner with U.S. tech giant Microsoft to set up a cloud company called Bleu, that will not be subject to U.S. extraterritorial legislation.

The so-called /“Cloud de Confiance”/ service “will meet sovereignty requirements of the French State, public administrations and critical infrastructure companies with unique privacy, security and resiliency needs as determined by the French State,” the companies announced <https://urldefense.com/v3/__https://politico.us8.list-manage.com/track/click...> today.

Bleu would be “an unprecedented French hyperscale cloud, fully under French and European jurisdictions,” they added.

The French government has been long wary of the extraterritorial nature of the U.S. Cloud Act, which allows American authorities to access data hosted by U.S. companies even if they’re stored abroad.

Earlier this month, France unveiled <https://urldefense.com/v3/__https://politico.us8.list-manage.com/track/click...> its cloud strategy, which promotes a “trusted cloud providers” certification. The government, the cybersecurity agency ANSSI and data protection authority CNIL backed hybrid solutions where U.S. software such as Microsoft’s or Google’s is licensed by European companies to process the data — and therefore not subjected to the Cloud Act.

Guillaume Poupard, ANSSI’s general director, “enthusiastically welcomes this ambitious project,” he said in Bleu’s press release.

Economy Minister Bruno Le Maire and Digital Junior Minister Cédric O also gave their blessing, calling the partnership a “new step toward European sovereignty.”

Bleu’s data centers will offer the Microsoft Azure cloud platform’s services but will be “strictly separated” from the U.S. company’s global data center infrastructure, according to Capgemini and Orange.

Not everyone is won over, however, as some fear that behind the veneer of sovereignty is actually an open door to U.S. tech giants. “This false sovereignty is an absolute danger,” said <https://urldefense.com/v3/__https://politico.us8.list-manage.com/track/click...> the founder and president of French cloud company Scaleway Arnaud de Bermingham.

On 27/05/2021 17:41, Stefano Zacchiroli wrote:

On Thu, May 27, 2021 at 04:15:33PM +0200, Fabio Pietrosanti (naif) wrote:

...

In Francia Orange ha costituito con Microsoft una società di scopo, sotto la diretta supervisione dell'ANSSI (Cybersecurity) e CNIL (Garante Privacy), all'esplicito scopo di sfuggire al U.S. Cloud Act: Non ho capito se stai dicendo che questo tipo di soluzione ti soddisfa o meno. (A me per niente, ed è esattamente ciò contro cui i piccoli/medi provider cloud francesi ed attori FOSS stanno cercando, senza molto successo per ora, di mobilitarsi.)

Posto che la soluzione migliore è tutto FOSS, o quantomeno pieno stack tecnologico e operativo Europeo, nel modello Francese vi è quantomeno l'intervento degli enti preposti alla sicurezza nazionale e alla protezione dei dati per la supervisione dell'operazione. Questo significa che c'è un doppio binario di analisi procedurale, da cui deduco di impatto su ISO27001 e GDPR con DPIA di dettaglio. Meglio che niente, ma in Italia neanche questo! Fabio