Ci sono un paio di cose che vanno considerate attentamente.

Anzitutto, ci sono 'funzioni' che sono disponibili solo su ben precisi cloud, e che nessun team, benché talentuoso e popoloso, potrebbe implementare sul ferro o su infrastruttura Iaas.

Ad esempio, alcune funzioni di NLP (Natural Language Processing) richiedono modelli linguistici neurali così grandi e complessi da costruire che ben pochi possono permetterseli, basti pensare al famoso GPT-3 (Microsoft). Molta ricerca in quel settore è indirizzata proprio verso il gigantismo neurale, perché i GAM sanno che su quel terreno hanno chiari vantaggi.

Concordo (ovviamente!)

Ma come dicevo in altri messaggi [1][2], quello che scrivo lo scrivo avendo in mente un ben determinato target (la nostra PA, con focus sulla scala comunale/regionale [scuola ed Univ inclusi]) ed il contesto politico attuale (che --IMHO-- è animato da sani principi, come la centralizzazione delle risorse di calcolo, ma che sembra disorientato ed incapace di "controllare" le tecnologie sottostanti --a partire dalla buzzword "cloud"--).

In questo (mio) contesto, il bleeding-edge della AI (cui GPT-3 appartiene) è.... "fuori" :-)   [*]

Un altro problema è che i servizi applicativi su cloud (Saas) 'out of the box' sono spesso fatti bene. Alternative 'on prem' richiederebbero team e metodi di sviluppo applicativo moderni (DevOps) che non sono facili da costituire, specie in Paesi arretrati come il nostro.

Sono _PARZIALMENTE_ d'accordo (meno del 33%).

Certamente i servizi cloud blasonati "...sono fatti bene..." (Gmail, Gsuite, O365, Slack, DropBox & Co., Zoom, etc.)

_MA_

1: la stragrande maggioranza dei servizi "pubblici" (a partire dell'ambiente sanitario, passando per gli enti locali ed atterrando negli Atenei) è fatta _MALE_. Talmente "male" che è difficilissimo migrarli al SaaS "blasonato". Possono certamente migrare al SaaS, ma è' il SaaS dei fornitori "legacy" (si pensi agli hosting di ESSE3 e di UGOV che Cineca offre a tutti gli Atenei [lock-in al 100%]). Si pensi al SaaS dei software di gestione di anagrafe e tributi di molti Comuni (erogati via marketplace Agid dai rispettivi "fornitori" e assolutamente _NON_ interoperabili l'un-l'altro). Si pensi alle... procedure di gestione dei vaccini Covid, dove regna il caos (digitale) piu' totale.

È in questo contesto --se ho capito bene-- che la proposta del Governo di andare verso il cloud USA ("...perche' le migliori tecnologie sono straniere...") è da valutare con attenzione (IaaS => OK; altro => parliamone!)

Che poi si possa ragionare di allestire una piattaforma di DaD "nazionale" da offrire a tutte le scuole pubbliche e, quindi, con livelli di scalabilità da milioni di utenti concorrenti.... se ne puo' certamente parlare. Ma stiamo parlando di un servizio che "parte da zero". Tecnicamente stiamo parlando.... di una cosa "banale" da progettare (non avendo i (pesanti) lacci che vengono dal passato).

2: non si tratta di contrapporre i modelli "cloud-USA" e quello "on-prem". Perfino GARR si pone problemi nell'allestire piattaforme di calcolo in grado di sostenere work-load "nazionali". Figuriamoci altri player meno tecno-centrici.
Il problema --IMHO-- è di contrapporre il modello "cloud-USA" ad un modello "cloud-Italiano" (o "cloud-europeo"), dove la componente "datacenter" è quella che esiste gia' (e che, al piou', puo' essere marginalmente "integrata"). L'idea di costruire un nuovo DC esclusivamente per le esigenze della PA "centrale"... non mi appassiona particolarmente.... ma è comunque "accettabile";

...ma le mie riserve più forti sono relative a ques'ultimo suo passaggio:

3: "...team e metodi di sviluppo applicativo moderni (DevOps) che non sono facili da costituire, specie in Paesi arretrati come il nostro....".
Questo è il punto _CENTRALE_ della questione. Ho passato gli ultimi 18 anni dentro un Ateneo da 40K studenti (come "consulente" che aveva il compito di stare dietro alla parte di calcolo e di networking). Ho un debito di riconoscenza verso CINECA che è difficile da spiegare (ho lavorato in Cineca dal 96 al 2003, ed ho collaborato con CINECA negli anni successivi). Conosco _BENE_ molti miei "colleghi" (= gente che fa il mio stesso lavoro) sparsi in molti altri Atenei del nostro Paese [3]. Ho avuto contatti importanti con i sistemi-informatici delle ASL della mia Regione. Conosco molto bene i primi 5 Comuni per numero di abitanti della mia regione. So come scrivono le gare. So come "gestiscono" l'IT.

È il _MIO_ mondo. Mi ci muovo _perfettamente_.

...e non posso non dire che se il nostro Paese è "arretrato" e se oggi è difficile creare un team "...moderno (DevOps)...", le ragioni che hanno portato a tale situazione sono proprio quelle di una erratissima politica ICT nazionale. In tutti i contesti che ho citato (in _TUTTI_ quei contesti), l'ICT è un "costo da ridurre". _NESSUNO_ (...in _TUTTI_ quei posti) vede l'IT come "investimento a ROI garantito!". O meglio: per i miei interlocutori (ai piani bassi), la cosa appare ovvia.... perche' i nostri occhi vedono banalmente i margini di ottimizzazione ed efficientamento che esistono. Ma i miei interlocutori non solo non hanno potere decisionale... ma addirittura vengono visti come "tecnici da un tot-al-chilo". I loro "manager" non li conoscono; parlano lingue diverse; non si capiscono.... ed il risultato è l'ampliamento del divario fra lo status-quo (tecnologie e competenze ICT che la PA mette in campo) e l'offerta di tecnologia (che evolve a ritmi che alcuni tecnici vedono... ma che il management ignora brutalmente).

E quindi?

Quindi _NON_ è affatto difficile allestire:

1 - un team di sviluppatori il cui obiettivo è quello di lavorare con tecnologie (open-source) in grado di scalare orizzontalmente sia in ambito "compute" che in ambito "storage", per produrre "container" da deploiare da qualche parte (dove e come, non e' affar loro...)

2 - un team di sistemisti/infrastrutturisti in grado di allestire e mantenere una infrastruttura openstack/kubernetes esattamente simile a quella di GARR-Cloud, che nasce gia' distribuita geograficamente e che è in grado di ospitare sia workload classici (IaaS, grazie ad openstack) sia workload moderni (container orchestrati con kubernetes)

3 - un team di devops in grado di fare inizialmente da "collante" fra i team 1) (...che tipicamente non sanno pacchettizzare la propria APP in un container docker) e 2) (...che tipicamente potrebbero non aver idea dei problemi indotti da scalabilita', affidabilita', etc.) e che, pian pianino.... inizia ad "elevare" tutti verso i nuovi paradigmi (GitOps, CI/CD, unit-testing, etc. etc.)

Nel _MIO_ mondo (quello che ho disegnato piu' su...) ho "scovato" persone che potrebbero facilmente entrare a far parte di questi team. In GARR ce ne sono diversi. Negli Atenei ce n'e' piu' di qualcuno. Sul mercato se ne trovano tanti (ordine delle decine, facilmente).

Il problema è uno solo: io conosco gli _OPERATIVI_. Quelli in grado _DI_FARE_. Serve qualcuno che abbia la voglia e la possibilita' di mettersi alla guida e "guidare" (non solo "tecnicamente"; anche "amministrativamente").

E quindi, per tornare al punto: No! Non è difficile creare un gruppo di tecnici in grado di abbracciare questa rivoluzione. E se è difficile... non è certo per colpa delle competenze tecniche. È, viceversa, un problema di incapacità di coordinamento. E questo, è un problema che dovrebbe risolvere qualcuno che è pagato per questo. Non certo noi, 'tecnici'.

Davanti a cose di questo genere la tentazione di consegnarsi con le mani alzate al GAM lock-in è forte.

Non solo è forte. È già un default. Da molti anni.

Ma come è possibile non rendersi conto che tale approccio significa ammettere la propria incapacità (manageriale) di gestire questo processo?

Due Dirigenti di due importanti Atenei mi dissero, anni fa, che loro _NON_ avevano possibilita' di intervento: senza le persone, non avevano la possibilita' di promuvoere/gestire soluzioni "on-prem". Il problema era quello di concorsi (andati deserti) o, in altri casi, di concorsi per posizioni da categorie/livelli economicamente non-appetibili / fuori-mercato.

Ed è un problema "tecnico"? È un problema di "competenze"? ....oppure è un problema del _NON_ capire come deve essere fatto un certo organigramma e quale posto/ruolo debba essere assegnato all'IT ?

Si tenga conto, infine, che questo problema viene da lontano: 7 anni fa (2014), l'allora dirigente IT di UniPavia lo racconto' chiaramente durante il workshop GARR [4], parlando dei motivi che portarono lui (ripeto: _dirigente_) a mandare la posta all'esterno (Google). Invito tutti a sentire l'intervento di Ferlini, perche' mostra chiaramente che l'obiettivo di un Dirigente non è quello di fare "il bene del Paese". Piuttosto è quello di far funzionare i servizi di cui è responsabile. E qualcuno si sente di dargli torto? io no....

Nello stesso workshop, a quello stesso panel, partecipo' pure Simone Spinelli , ai tempi in forza ad UniPI, che raccontò la propria soluzione (100% on-prem e open-source) [5].

A 7 anni di distanza.... Ferlini è in pensione (da tempo), UniPI ha parzialmente migrato su cloud e Spinelli è andato a lavorare altrove (dove ha ovviamente fatto carriera) [6].

Dunque.... il problema è che i tecnici "non si trovano"? Ne siamo proprio sicuri?

Insomma: arrivo a comprendere l'ignavia tecnica ma non la coscienza di certi dirigenti, politici e giornalisti. Trattasi di incomprensione? Trattasi di malafede? Trattasi di collusione?

Ultimamente penso molto al Rasoio di Honlon [7]: l'evoluzione frenetica delle tecnologie ICT ha allargato drasticamente il GAP di know-how richiesto alla "politica" per governare i macro-processi di cui stiamo parlando.... e ancor piu' che i politici --IMHO-- i giornalisti fanno una fatica _ENORME_ a comprendere gli aspetti peculiari di questi temi (come puo', un giornalista, inquadrare le conseguenze indotte da una app sviluppata con tecnologie proprietarie e che usa le funzioni di microsoft, rispetto ad una app scritta con tecnologie open-source e deploiabile su cluster kubernetes standard?).

C'e' molta, _MOLTA_, ignoranza. A livello politico, giornalistico e... ahime', anche fra tecnici addetti ai lavori.... E se poi un presunto-tecnico arriva a dare consigli (errati) ad un buon politico (che pero' è incompetente nel dominio tecnico), a quel punto accadono dei disastri dai quali è veramente difficile riprendersi (e di queste situazioni, ne potrei narrare a decine...., su scale che vanno da un comunque, ad una ASL, ad un Ateneo... ad un Ministero...) :-(

Chiudo dicendo che mi piacerebbe molto "dibattere" su questi temi (che _NON_ sono tecnici). E se lo si facesse nel contesto di questo gruppo... sarebbe un eccellente inizio.

Magari se qualcuno conosce Riccardo Luna.... potrebbe proporgli un intervento "ad integrazione" di quello fatto con Colao....

Un caro saluto,
DV

[1] https://server-nexa.polito.it/pipermail/nexa/2021-May/021611.html

[2] https://server-nexa.polito.it/pipermail/nexa/2021-May/021630.html

[3] https://www.eventi.garr.it/it/ws20/home/materiali-workshop-2020/presentazioni-6/507-l-esperimento-social-della-community-il-bar-del-garrlab-d-verzulli

[4] Ferlini: https://www.garrnews.it/rubriche-interne-12/contributi-video-12/video/24-outsourcing-della-posta-elettronica-e-dei-servizi-per-la-collaborazione-online-flavio-ferlini-workshop-tecnico-garr-2014-roma

[5] Spinelli: https://www.garrnews.it/rubriche-interne-12/contributi-video-12/video/19-unipi-centralizzazione-del-sistema-di-posta-elettronica-di-ateneo-s-spinelli-workshop-garr-2014-roma

[6] https://www.linkedin.com/in/simone-spinelli-b8887a68/

[7] https://en.wikipedia.org/wiki/Hanlon%27s_razor

Ma non lo faccio, perche' siamo fuori tema e... l'altra discussione (quella sul cloud) è decisamente piu' importante (short-term)

On Tue, 22 Jun 2021 at 08:50, Antonio Iacono <antiac@gmail.com> wrote:

> La buzzword è "serverless-computing",

o, come dicono alcuni, "Function as a Service" (FaaS), la sostanza è la stessa.

> e servizi di questo genere sono
> presenti sia a catalogo AWS (lambda) che Microsoft (azure functions).
> Ci si potrebbe chiedere perche' mai un team di sviluppo dovrebbe
> decidere di adottare una soluzione simile... e la risposta non mi è
> chiara.

Una risposta, fin troppo ovvia, potrebbe essere, "elimini" il
sistemista dal team.
Non dovendoti più preoccupare di infrastruttura, di "hosting", di "app
servers" di sistemi operativi, a cosa ti serve uno specialista in
sistemi?
Qualcuno potrebbe sentenziare: "è il progresso, bellezza", il
sistemista come il ghiacciarolo o il lampionaio.
Peccato che a forza di astrazioni di livello superiore la prossima
volta potrebbe toccare allo sviluppatore web.
Se poi ci metti lo specchietto per le allodole (leggasi CEO), che
paghi solo la funzione/funzionalità solo quando è effettivamente in
esecuzione, il gioco è fatto.

Antonio
_______________________________________________
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

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