Infrastrutture IT, il dilemma della PA: ferro o nuvole?
"... cose semplici e con pochi fronzoli, concrete, solide, anche non seducenti, ma che non si rompono mai, il cui TCO (Total Cost of Ownership) è al giusto livello, e senza forti vincoli futuri." Non posso non apprezzare l'articolo di Simone Brunozzi [1]. La frase che ho citato mi contraddistingue da sempre. Sono/siamo una minoranza? Può essere. Siamo quelli che ritengono che la tecnologia debba essere un mezzo, uno strumento, e non il fine? Può darsi. Una strada non deve essere lastricata d'oro ma in un brutto asfalto nero. Antonio [1] https://www.agendadigitale.eu/infrastrutture/infrastrutture-it-il-dilemma-de...
On 21/06/21 11:08, Antonio Iacono wrote:
"... cose semplici e con pochi fronzoli, concrete, solide, anche non seducenti, ma che non si rompono mai, il cui TCO (Total Cost of Ownership) è al giusto livello, e senza forti vincoli futuri."
Non posso non apprezzare l'articolo di Simone Brunozzi [1]. La frase che ho citato mi contraddistingue da sempre. Sono/siamo una minoranza? Può essere. Siamo quelli che ritengono che la tecnologia debba essere un mezzo, uno strumento, e non il fine? Può darsi. Una strada non deve essere lastricata d'oro ma in un brutto asfalto nero.
Antonio
[1] https://www.agendadigitale.eu/infrastrutture/infrastrutture-it-il-dilemma-de...
Ciao Antonio, grazie per la segnalazione dell'interessante articolo, che traccia uno scenario forse incompleto. Buono il riferimento a tecnologie concrete (Linux, BSD, Xen, Kuebernetes, PostgreSQL e Redis), anche se potrei chiedere, perché proprio Xen? Ottima tecnologia, ma certamente non l'unica possibile. Purtroppo non entra nel tema privacy, consapevolmente, motivando così: si tratta di temi che definisce giuridici e geopolitici che afferma di non conoscere. Direi che questo è il tema centrale, però. Ho infine una critica sostanziale all'articolo. Offre due soluzioni che in realtà non differiscono granché (o forse non le ho capite): 1) Usare AWS, GCP e Azure come IaaS, garantendosi sconti quantità. Il resto dello stack lo fai da te. 2) Cito testualmente: "legarsi mani e piedi a una tecnologia di una azienda specifica, sposarne la filosofia di sviluppo, e ritrovarsi in un matrimonio dal quale non si può più uscire, con rischi di vario tipo." A cosa si riferisce? A un Public Cloud? Quindi è la stessa di cui in 1)? Oppure? Roba fatta in casa in modo tradizionale (no Cloud)? Mistero. Io mi sarei immaginato in 2) qualcosa del tipo: costruirsi i propri sistemi distribuiti usando ferro di proprietà e tecnologie Open (OpenStack e Kubernetes), secondo gli standard CNCF e Open Infrastructure. La dicotomia sarebbe stata evidente. Voglio comunque concordare con te e con l'autore che le scelte non devono essere aprioristiche, ma risolvere problemi concreti in modo semplice. Cercando, magari, di aderire agli standard in modo da non rimanere con il cerino in mano. D.
Purtroppo non entra nel tema privacy, consapevolmente, motivando così: si tratta di temi che definisce giuridici e geopolitici che afferma di non conoscere. Direi che questo è il tema centrale, però.
Un tema, la privacy, su cui comunque non sono mancati approfondimenti, anche da parte della stessa rivista (vedi ad es. [1] o gli articoli di Guido Scorza [2]) Quella che invece è deficitaria nel dibattito pubblico, e l'articolo di Brunozzi, pur con le lacune da te evidenziate, prova a portarla alla ribalta, è la presenza di "alternative tecniche" al public cloud (o GAM cloud). Qualche giorno fa, Gianni Riotta, rispondendo ad una ascoltatrice in un programma radiofonico ha detto che le tecnologie cloud sono essenzialmente americane. Questo non è corretto ed è giusto che le persone, i non addetti, magari un po' alla volta, ne vengano a conoscenza. Antonio [1] https://www.agendadigitale.eu/sicurezza/privacy/i-nostri-dati-sul-cloud-dell... [2] https://www.agendadigitale.eu/giornalista/guido-scorza-2/
On 21/06/21 16:49, Antonio Iacono wrote:
Purtroppo non entra nel tema privacy, consapevolmente, motivando così: si tratta di temi che definisce giuridici e geopolitici che afferma di non conoscere. Direi che questo è il tema centrale, però.
Un tema, la privacy, su cui comunque non sono mancati approfondimenti, anche da parte della stessa rivista (vedi ad es. [1] o gli articoli di Guido Scorza [2])
Assolutamente, ottimi lavori.
Quella che invece è deficitaria nel dibattito pubblico, e l'articolo di Brunozzi, pur con le lacune da te evidenziate, prova a portarla alla ribalta, è la presenza di "alternative tecniche" al public cloud (o GAM cloud). Qualche giorno fa, Gianni Riotta, rispondendo ad una ascoltatrice in un programma radiofonico ha detto che le tecnologie cloud sono essenzialmente americane. Questo non è corretto ed è giusto che le persone, i non addetti, magari un po' alla volta, ne vengano a conoscenza.
Eh sì. E a proposito di radio, c'è un programma radiofonico in cui se ne parla: <https://www.ondarossa.info/newstrasmissioni/entropia-massima/2021/06/tecnolo...>. D.
[1] https://www.agendadigitale.eu/sicurezza/privacy/i-nostri-dati-sul-cloud-dell... [2] https://www.agendadigitale.eu/giornalista/guido-scorza-2/
Il 21/06/21 16:09, D. Davide Lamanna ha scritto:
[....] due soluzioni che in realtà non differiscono granché (o forse non le ho capite):
1) Usare AWS, GCP e Azure come IaaS, garantendosi sconti quantità. Il resto dello stack lo fai da te.
è IaaS, appunto. Prendi le macchine virtuali, le accendi, ci metti sopra il sistema operativo che ti pare... e ci metti sopra gli applicativi che ti scrivi. Ti smazzoli da solo i problemi di backup, di scalabilita' (della tua applicazione), di affidabilita', etc. etc. Insomma: anziche' comprarti del ferro ed attaccarlo alla tua 220v, prendi questo (ed e' cosa buona e giusta). Domani ti stufi? Problemi zero: passi da AWS a Aruba con uno schiocco delle dita (previo cambio di indirizzo IP). SeeWeb ti fa un'offerta che non puoi rifiutare? Problemi zero... accendi + migri + cambi IP ... ed il gioco e' fatto. Vuoi provare qualcosa di interessante su GARR-Cloud? ...problemi zero. Sintesi: liberta' massima, a fronte di un impegno di "gestione" tuttosommato semplice (dentro gli uffici di un Ateneo trovi almeno 1 persona per ogni 100 dipendenti strutturati in grado di fare queste operazioni) ....e se qualcuno pensa che questo "non è 'cloud'", si sbaglia! Se si e' "moderni", si puo' --ad esempio-- utilizzare degli strumenti di "automazione" (sto pensando a Terraform) con cui si dice (+ o -): "questa e' la API key di SeeWeb, questa è la API key di Aruba; accendi tre VM 'grandi' su Aruba e due VM "medie" su SeeWeb. Mettici sopra una CentOS 8 e poi esegui questo job. Questo job è scritto con ansible e l'obiettivo è aggiornare la VM, installare i pacchetti che servono e scaricare e avviare la mia applicazione meravigliosa" Per quest'ultimo tipo di attivita', le competenze negli Atenei le trovi ma... passiamo a una/due persone al massimo, in un Ateneo che ha almeno 50K studenti (in quelli piu' piccoli, non le trovi). Tutto questo (la prima parte) è quello che ricade nel primo scenario descritto dall'autore
2) Cito testualmente: "legarsi mani e piedi a una tecnologia di una azienda specifica, sposarne la filosofia di sviluppo, e ritrovarsi in un matrimonio dal quale non si può più uscire, con rischi di vario tipo."
A cosa si riferisce? A un Public Cloud? Quindi è la stessa di cui in 1)? Oppure? Roba fatta in casa in modo tradizionale (no Cloud)? Mistero.
No. Non e' "mistero". È lo scenario nel quale un team di sviluppo decide di scrivere una applicazione (...e fin qui tutto bene....). Solo che --a differenza di quello che era lo standard fino a pochi mesi fa [*], decide di utilizzare delle librerie prendendole _direttamente_on_line_. Occhio: intendo che la chiamata alla libreria (chiamate effettuate dalla mia applicazione) viene fatta ad un qualcosa che sta "su cloud". Intendo che la mia applicazione _NON_ funzionera' se quella chiamata a quelle librerie "fallisce" (perche', ad esempio, il cloud-provider ha chiuso il servizio o c'e' un qualche problema di rete fra la mia APP ed il cloud-provider [**] La buzzword è "serverless-computing", 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. Se fossi io il CIO che ha la responsabilità di un team del genere.... tendenzialmente cercherei un nuovo team-leader, in quanto l'attuale evidentemente ignora il termine "vendor-lock-in". Purtroppo, esistono anche contesti meno "netti". Ad esempio: scrivo una APP, ma siccome non sono capace di gestire un cluster elasticsearch che possa gestire qualche miliardo di documenti e renderli ricercabili in tempi dell'ordine del sub-secondo.... finisco per comprare un servizio cloud (ad esempio, quello di elastic) e... i dati li infilo la. Questo scenario è meno grave rispetto al precedente: se ho l'accortezza di utilizzare servizi cloud basati su tecnologie open (come con elastic), tornare indietro (perche' ho finalmente messo in piedi un team di tre persone che è capace di tirare su quel cluster e di stargli dietro....) non è particolarmente complesso. L'aspetto delicato, a mio avviso, è che queste (nuove) dinamiche di (forte) lock-in partono dagli sviluppatori: sono loro a _chiedere_ di utilizzare tecnologie "pericolose". E per dirgli: "No! State facendo una sciocchezza!" servono competenze che --tipicamente-- _MANCANO_ sulla linea gerarchica cui tipicamente rispondono. Quindi, per chiudere, il primo concetto introdotto dall'autore... ci piace (ed e' cloud). Il secondo NON ci piace (ed e' cloud pure lui).
Io mi sarei immaginato in 2) qualcosa del tipo: costruirsi i propri sistemi distribuiti usando ferro di proprietà e tecnologie Open (OpenStack e Kubernetes), secondo gli standard CNCF e Open Infrastructure. La dicotomia sarebbe stata evidente.
L'elemento che trascuri è proprio "l'applicazione": l'infrastruttura che hai descritto puo' essere allestita al 100% con ferro "di proprieta'" e con tecnologie 100% open-source. Ma se poi lo sviluppatore ci mette sopra una applicazione che usa tecnologie di "serverless-computing".... tu sei "fritto" lo stesso... ...sono convinto, pero', che ora lo scenario e' piu' chiaro (almeno a noi tecnici!). Un caro saluto, DV [*] ...ossia scrivo la APP, ma nel farlo, uso delle "librerie" che recupero dal mercato e che finiscono nel codice della mia APP, e lo faccio perche' non voglio riscrivere la ruota ogni volta [**] ogni riferimento al down recente di Fastly [1] è puramente voluto! [1] https://www.corriere.it/tecnologia/21_giugno_08/fastly-down-cdn-37a99d86-c84... -- 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
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
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. 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. Davanti a cose di questo genere la tentazione di consegnarsi con le mani alzate al GAM lock-in è forte. Quello che personalmente non capisco è perché questo debba essere narrato come una fatalità, una necessità, o addirittura un segno di spigliato cosmopolitismo, come si trattasse di comprarsi, negli anni '60, un macchinone americano e fumare le Camel (con i soldi di mammà) 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? G. 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
ho difficolta' a trovare nelle applicazioni della PA una richiesta di funzioni avanzate erogate as a service del tipo NLP. io non ne conosco. di certo non e' diffuso quanto le autorizazzioni edilizie o lo stato civile. On 22/06/21 09:38, Guido Vetere wrote:
Quello che personalmente non capisco è perché questo debba essere narrato come una fatalità, una necessità, o addirittura un segno di spigliato cosmopolitismo, come si trattasse di comprarsi, negli anni '60, un macchinone americano e fumare le Camel (con i soldi di mammà)
ha ha ha!
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?
mai attribuire a cattiveria ciò che può essere spiegato con ignoranza... ciao!,s .
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.
OpenNLP, NLTK, TextBlob, SpaCy, PyTorch-NLP, CogCompNLP, ecc. non credo manchino alternative open. Certo, il problema sono i dati, e vorrei vedere, miliardi di persone che continuamente "cercano", "chattano", "parlano" agli assistenti vocali, ecc. altro che BigData ... Fermo restando che, come ha scritto Stefano, applicazioni della PA che abbisognano di funzioni NLP non è che ce ne siano molte in giro, e comunque creare un "set di dati" solo in italiano non dovrebbe essere un ostacolo insormontabile. Basterebbe dare in pasto a qualcuno dei sistemi lì sopra la legislazione italiana ;) Se poi dovesse servire "insegnare alle macchine come parlano le persone nella vita reale" si potrebbe "donare la voce" al progetto "Common Voice" [1] e usare DeepSpeech Italian [2].
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.
Inizi anni duemila, Apache era installato nel 60% dei siti, mentre IIS nel 20%, eppure, in Italia, nella PA italiana, c'era ovunque IIS ... Antonio [1] https://commonvoice.mozilla.org/it [2] https://github.com/MozillaItalia/DeepSpeech-Italian-Model/blob/master/DeepSp...
Il 22/06/21 09:38, Guido Vetere ha scritto:
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/presentazion... [4] Ferlini: https://www.garrnews.it/rubriche-interne-12/contributi-video-12/video/24-out... [5] Spinelli: https://www.garrnews.it/rubriche-interne-12/contributi-video-12/video/19-uni... [6] https://www.linkedin.com/in/simone-spinelli-b8887a68/ [7] https://en.wikipedia.org/wiki/Hanlon%27s_razor [*] Avrei diverse osservazioni al riguardo. Vorrei, ad esempio, parlare del workload tipici dell'infrastruttura HPC di Cineca. O di quella di ENI. Vorrei parlare del mondo della ricerca universitaria e di come questa _NON_ riesca ad uscire da vecchi schemi mentali di chi pensa "mi faccio le cose da me, con il mio server da 10K€ sotto la scrivania... perche' io sono bravo, e non posso cedere ai dettagmi di Cineca, o dei miei colleghi di Informatica, di Ingegneria, o chicchessia...". 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 <mailto: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 <mailto: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
Grazie, Damiano, davvero interventi illuminanti, i tuoi! On 22/06/21 11:52, Damiano Verzulli wrote: [cut]
È 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!)
Permettimi solo di dissentire su IaaS => Ok a prescindere. Per me l'IaaS in Public Cloud è critico, andrebbe adottato solo se non se ne può davvero fare a meno e SOLO valutando attentamente la criticità dell'information disclosure. IaaS in Private Cloud tutta la vita, tutte le volte che è possibile. [cut]
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'.
Applausi a scena aperta! 0// Dopo che l'abbiamo detto, però, come la risolviamo? Io dico la mia. Abbiamo bisogno che persone non-tecniche si interessino di questa tema e lavorino a fianco dei tecnici per imparare insieme e mettere in pratica nuove modalità di coordinamento. Ao', non-tecnici!!! E a voi che parlo! Ve interessa 'sta cosa?!! Fatevela interessà, perché a noi ce servite!!! :-) E' come con la Cybersecurity: qualcuno dei poco-tecnici o (meglio ancora!) non-tecnici, se na sta occupando sempre di più. E per fortuna! Se non fosse per loro saremmo persi! E stanno implementando meccanismi di governance fatti bene, ma BENE. Proprio perché hanno una mentalità organizzativa che il tecnico NON HA. Punto. E' complementare, non in constrasto. Il tecnico storce il naso perché vorrebbe smanettare, ma il tecnico bravo sa che affidarsi ad un bravo architetto, significa mandare le palle in buca. Altrimenti il suo lavoro sarà poco più che un bell'artigianato da mostrare orgogliosamente ai propri amichettx. Si può vivere felici, molto felici, anche così. Solo che non si risolvono i problemi, così.
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.
Esatto!
Ma come è possibile non rendersi conto che tale approccio significa ammettere la propria incapacità (manageriale) di gestire questo processo?
Non lo so come è possibile, ma è quello che avviene. E mi ci faccio il sangue amaro!
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 ?
Esatto.
C'e' molta, _MOLTA_, ignoranza. A livello politico, giornalistico e... ahime', anche fra tecnici addetti ai lavori....
Quindi comunque un po' di ignoranza anche tra i tecnici c'è. Ma quella si risolve facilmente, non mi preoccupa. E l'altra che vedo problematica.
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.
Love. D.
puro vangelo On 21/06/21 23:23, Damiano Verzulli wrote:
L'aspetto delicato, a mio avviso, è che queste (nuove) dinamiche di (forte) lock-in partono dagli sviluppatori: sono loro a_chiedere_ di utilizzare tecnologie "pericolose". E per dirgli: "No! State facendo una sciocchezza!" servono competenze che --tipicamente--_MANCANO_ sulla linea gerarchica cui tipicamente rispondono.
2) Cito testualmente: "legarsi mani e piedi a una tecnologia di una azienda specifica, sposarne la filosofia di sviluppo, e ritrovarsi in un matrimonio dal quale non si può più uscire, con rischi di vario tipo."
A cosa si riferisce? A un Public Cloud? Quindi è la stessa di cui in 1)? Oppure? Roba fatta in casa in modo tradizionale (no Cloud)? Mistero.
No. Non e' "mistero".
È lo scenario nel quale un team di sviluppo decide di scrivere una applicazione (...e fin qui tutto bene....). Solo che --a differenza di quello che era lo standard fino a pochi mesi fa [*], decide di utilizzare delle librerie prendendole _direttamente_on_line_. Occhio: intendo che la chiamata alla libreria (chiamate effettuate dalla mia applicazione) viene fatta ad un qualcosa che sta "su cloud". Intendo che la mia applicazione _NON_ funzionera' se quella chiamata a quelle librerie "fallisce" (perche', ad esempio, il cloud-provider ha chiuso il servizio o c'e' un qualche problema di rete fra la mia APP ed il cloud-provider [**]
La buzzword è "serverless-computing", e servizi di questo genere sono presenti sia a catalogo AWS (lambda) che Microsoft (azure functions).
Fatico a rintracciare nel testo dell'articolo un chiaro riferimento al serverless. Nè il giro di parole (che ho riportato testualmente) suggerisce che si stesse parlando di questo. Ciononostante, è stato proficuo che tu abbia introdotto il tema, perché è interessante, innanzi tutto, e perché c'entra con la questione del Cloud.
L'elemento che trascuri è proprio "l'applicazione": l'infrastruttura che hai descritto puo' essere allestita al 100% con ferro "di proprieta'" e con tecnologie 100% open-source.
Ma se poi lo sviluppatore ci mette sopra una applicazione che usa tecnologie di "serverless-computing".... tu sei "fritto" lo stesso...
...sono convinto, pero', che ora lo scenario e' piu' chiaro (almeno a noi tecnici!).
Sicuramente è stato utile. Personalmente concordo con il tuo punto di vista sul serverless. A questo punto, già che ci siamo, aggiungo un ulteriore elemento di riflessione. Anche il serverless si può fare con strumenti open e self-hosted [1]. Quindi mi concince di più la conclusione, che è stata tratta, che stiamo sparando ad una mosca con un cannone. Ma in assoluto il tema meriterebbe qualche approfondimento in più. D. [1] Solo un esempio: https://wiki.openstack.org/wiki/Faas
Ciao Damiano, On Mon, 21 Jun 2021 23:23:16 +0200 Damiano Verzulli wrote:
L'aspetto delicato, a mio avviso, è che queste (nuove) dinamiche di (forte) lock-in partono dagli sviluppatori: sono loro a _chiedere_ di utilizzare tecnologie "pericolose".
d'istinto specificherei "sviluppatori junior", ma purtroppo l'esperienza di uno sviluppatore spesso non è correlata con l'età anagrafica. Ho visto sviluppatori con decenni di esperienza seguire le mode del momento come adolescenti terrorizzati dall'idea di essere "out" e sviluppatori giovanissimi ricchi di sano scetticismo ed idee brillanti ed innovative.
Se fossi io il CIO che ha la responsabilità di un team del genere.... tendenzialmente cercherei un nuovo team-leader, in quanto l'attuale evidentemente ignora il termine "vendor-lock-in". [...] E per dirgli: "No! State facendo una sciocchezza!" servono competenze che --tipicamente-- _MANCANO_ sulla linea gerarchica cui tipicamente rispondono.
Oltre a sostituire il team-leader, dovresti sostituire chi l'ha selezionato ed assunto o quanto meno chi l'ha promosso, nonché riconsiderare le competenze dei vari membri del team, come minimo per approntare un piano di formazione adeguato. E questo imporrebbe costi misurabili all'azienda/PA. Il costo di tecnici o team-leader incompetenti invece NON è misurabile. Né direttamente riconducibile ad una decisione di un qualche manager. Per questo non c'è alcun pericolo che un tecnico competente possa diventare CIO, proprio perché capace di dire "No" e più in generale avvezzo a rendere espliciti ed affrontare costi che si preferisce ignorare e nascondere sotto il tappeto.
ogni riferimento al down recente di Fastly [1] è puramente voluto!
O al down di Google. O di Microsoft Teams. O di OVH. Il cloud viene spesso propagandato come una soluzione low risk, ma in realta si intende SEMPRE low-personal-risk-for-the-incompetent-manager. Infatti espone SEMPRE chi lo adotta ad un sistematico ed ineludibile incremento degli eventi HILP (high-impact low-probability) di cui non è possibile mitigare i danni proprio a causa del vendor lock-in. E quando questi avvengono (perché AVVENGONO)... chi ne risponde? Nessuno! Così si smantellano infrastrutture pubbliche resilienti e distribuite nella speranza di minimizzare costi/rischi, adottando al loro posto soluzioni fragili e centralizzate fuori dal controllo pubblico. Occhio non vede, cuore non duole, giusto? E sì, sto ancora parlando di informatica. E sì, sto parlando ANCHE di sanità pubblica ed istruzione. Giacomo
participants (6)
-
Antonio Iacono -
D. Davide Lamanna -
Damiano Verzulli -
Giacomo Tesio -
Guido Vetere -
Stefano Quintarelli