June 2021 - nexa - server-nexa.polito.it

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by Stefano Quintarelli

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 .

June 22, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by Stefano Quintarelli

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.

June 22, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by Guido Vetere

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(a)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(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >

June 22, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by Antonio Iacono

> 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

June 22, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by Damiano Verzulli

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-c8… -- Damiano Verzulli e-mail: damiano(a)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

June 21, 2021

Amazon destroying millions of items of unsold stock in one of its UK warehouses every year, ITV News investigation finds

by J.C. DE MARTIN

*Amazon destroying millions of items of unsold stock in one of its UK warehouses every year, ITV News investigation finds* [...] continua qui: https://www.itv.com/news/2021-06-21/amazon-destroying-millions-of-items-of-…

June 21, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by D. Davide Lamanna

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/tecnol…>. D. > [1] https://www.agendadigitale.eu/sicurezza/privacy/i-nostri-dati-sul-cloud-del… > [2] https://www.agendadigitale.eu/giornalista/guido-scorza-2/

June 21, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by Antonio Iacono

> 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-del… [2] https://www.agendadigitale.eu/giornalista/guido-scorza-2/

June 21, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by D. Davide Lamanna

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-d… 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.

June 21, 2021

Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by Antonio Iacono

"... 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-d…

June 21, 2021