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

esempi senza cloud, app e webapp (was Re: The Cost of)

by 380°

Buongiorno, Stefano Maffulli <smaffulli(a)gmail.com> writes: [...] > Uno dei problemi che hanno i piccoli centri radiologici sono le > immagini perse e l'archivio lento. Esempio pratico banale: zia fa la > radiografia all'anca, le danno il CD ma lo perde. Già il buon vecchio CD, quanta plastica sprecata... Peccato, dovremmo aiutare zia a farsi una copia locale con tanto di backup della sua intera cartella clinica (assieme agli altri documenti); ci sarebbe tanto da fare in questo senso e come best practice prenderei il sistema di fatturazione elettronica, dove i referti però sono crittografati con crittografia forte (OpenPGP). Certo alcune (molte?) zie, cugini, padri hanno bisogno di aiuto per queste cose, per questo ci vedrei bene un mediatore digitale familiare che si prende cura dei propri cari /anche/ per questi aspetti (via CIE o SPID con un sistema di delega). Io per alcune cose lo sto facendo per mamma, ma è una corsa a ostacoli con 'sti sistemi del menga senza API decenti: banche, fornitori di utenze (acqua, luce, gas, connettività); funziona benino giusto col fascicolo sanitario regionale. [...] > Questi centri spesso sono organizzati come descrivi tu: un piccolo box > in locale con le ultime immagini su un piccolo NAS e qualche batch > script che deposita i dati su archivi remoti dove fanno qualche altro > accrocchio con NAS più grandi e tape libraries per il lungo termine. Sarebbe un caso d'uso perfetto per git-annex [1] (use case: The Archivist) che con il location tracking permetterebbe loro di rimpiazzare i nastri con dischi USB3 da circa 30€ al terabyte e salvare più copia dell'archivio su più dischi, recuperando le copie nel giro di un "git annex whereis <copia>" Con l'estensione [2] per rclone [3] poi potrebbero utilizzare uno dei circa 40 provider di storage supportati da quest'ultimo (anche tutti quelli basati su protocollo WebDAV o S3) per salvare ulteriori copie di backup, crittografate ovviamente. > Le ore spese a trafficare tra nastri antichi sono ore bruciate senza > produrre niente di utile. Giusto, ma non è detto che le ore/operatore liberate da queste attività siano impiegabili in altre cose utili, secondo me è più importante la perdita di tempo per l'utente. [...] > Ti seguo ma fino a un certo punto. Altro esempio banale: prendi mezza > giornata di ferie per andare a fare un certificato nella [PA a caso]. Già questo è tempo buttato via, dover prendere le ferie per accedere a un servizio che nell'ufficio comunale erogano con "sistemi online" è sbagliato in partenza: dateci identità digitale (è dal 1998 che se ne parla) INTEROPERABILE [2] e API e formati per accedere ai servizi... ... e poi ci pensiamo noi a farci le applicazioni che ci fanno comodo, ESATTAMENTE come con la fatturazione elettronica; anche solo definire una interfaccia (specialmente grafica) significa in qualche modo LIMITARE la libertà dell'utente. > Arrivi e ti comunicano che l'applicazione è bloccata e non possono fare > certificati. Anche le banche periodicamente devono effettuare fermi dei servizi e /qualche volta/ perfino senza riuscire a programmarli: a me negli ultimi 15 anni è successo diverse volte di compilare un modulo web per una operazione e all'invio ricevere un bel "spiacenti, provate più tardi"; non ho dubbi che ciascuno di quelli che leggono abbia proprie esperienze in merito. Già che parliamo di banche, vogliamo dirlo quanto fa schifo essere costretti ad installare una app PROPRIETARIA di 2FA (two factor auth) PER OGNI FORNITORE?!?! Ma che diamine (e infatti io non la installo)! Possibile che non siano capaci di fornirci un sistema OTP interoperabile come fanno già altri (GitLab, Gandi, OVH): il software lato server (e client ovviamente) è pure libero! E già che parliamo di banche, sono l'unico qui dentro che trova INSOPPORTABILE che per accedere all'estratto conto, alla ricevuta di un F24 o effettuare bonifici si sia /costretti/ ad aprire una interfaccia web?!? :-O Voglio API interoperabili anche per le banche [5], non solo per le fatture elettroniche. [...] Saluti, 380° [1] https://git-annex.branchable.com/ [2] https://github.com/DanielDent/git-annex-remote-rclone [3] https://rclone.org/ [4] significa SOPRATTUTTO che i "driver" per utilizzare l'hardware DEVONO essere liberi, PER LEGGE [5] eh sì, in TEORIA è tutto previsto ma nel 2021 siamo ANCORA messi così: https://dashdevs.com/blog/the-future-of-banking-and-financial-services-now-… https://www.openbankproject.com/customers/ -- 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>.

June 13, 2021

Re: [nexa] The Cost of Cloud, a Trillion Dollar Paradox

by Antonio Iacono

> Altro esempio banale: prendi mezza giornata di ferie per andare a fare un certificato nella [PA a caso]. Arrivi e ti comunicano che l'applicazione è bloccata e non possono fare certificati. Bon, mezza giornata buttata per un patetico SLA al 98%. Fai la somma di tanti 2% di downtime per servizi "non essenziali" e scommetto si arrivi vicino a mezzo punto di PIL :) La settimana scorsa ho perso la patente. Panico. Chissà quanto tempo perderò tra uffici, denunce, ecc. Lungo respiro, calma e gesso, cominciamo a vedere se è possibile fare la denuncia online. Sito dei carabinieri. Denuncia vi@ Web [1], pagina in ASPX, va beh, nessuno è perfetto ;) Compilo, stampo, fisso l'appuntamento (sempre tramite l'applicazione web) al comando più vicino a casa mia. Il giorno dopo, al termine dell'orario lavorativo vado in caserma, dieci minuti, tutto fatto, mi stampano il permesso provvisorio di guida, tra un mese mi arriverà a casa e pagherò direttamente al postino i 17 euro. Il PIL è salvo :) Questa mia esperienza non aggiunge nulla alla discussione ma ci tenevo a segnalarlo come piccola "good news" Antonio [1] https://extranet.carabinieri.it/DenunciaViaWeb/denuncia.aspx

June 12, 2021

Re: [nexa] Certificazioni verdi: Disposto il blocco provvisorio per l’App IO

by 380°

380° <g380(a)biscuolo.net> writes: > Buongiorno, > > https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9668146 > --8<---------------cut here---------------start------------->8--- > > Certificazioni verdi: via libera del Garante, con adeguate garanzie > Disposto il blocco provvisorio per l’App IO [...] Grazie alla segnalazione di Damiano Verzulli in altro thread [1], ieri il garante ha pubblicato la relazione tecnica: «Relazione tecnica sulle interazioni dell'App IO con i servizi di Google, Mixpanel e Instabug» https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb… --8<---------------cut here---------------start------------->8--- 1. PREMESSA Preliminarmente, si evidenzia che le considerazioni di seguito riportate sono effettuate a seguito dell’analisi tecnica dell’App IO nella sua versione 1.24.0.6 per dispositivi con sistema operativo Android. Tuttavia, alcune di esse sono verosimilmente riferibili anche all’App IO per dispositivi con sistema operativo iOS. In un primo momento, è stato analizzato il contenuto del file “AndroidManifest.xml” che, tra le altre cose, indica le componenti, fornite anche da terze parti, utilizzate da un’app per dispositivi Android, constatando all’interno dell’App IO (versione 1.24.0.6) la presenza di elementi relativi a servizi forniti dalle società Google LLC (di seguito “Google”), Mixpanel Inc. (di seguito “Mixpanel”) e Instabug Inc. (di seguito “Instabug”). Nei seguenti paragrafi sono descritte e analizzate le interazioni dell’App IO con i servizi forniti delle predette società. --8<---------------cut here---------------end--------------->8--- Saluti, 380° [1] https://server-nexa.polito.it/pipermail/nexa/2021-June/021773.html Message-id: 918af0f4-273d-61ea-099f-48c41153605d(a)verzulli.it -- 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>.

June 12, 2021

Re: [nexa] The Cost of Cloud, a Trillion Dollar Paradox

by Stefano Maffulli

On Sat, Jun 12, 2021 at 1:35 AM Damiano Verzulli <damiano(a)verzulli.it> wrote: > È questo contesto pubblico/economico che ho in mente quando leggo > l'articolo citato [1] ed è per questo che, nel mio contesto, lo trovo > defocalizzante: > A questo contesto io penso vada aggiunta la scarsa crescita di produttività italiana, che credo sia unanimemente riconosciuta come una causa prima del declino socio economico del paese. Altra cosa importante da tenere a mente: il contesto accettabile di oggi non è necessariamente il migliore possibile o nemmeno il desiderato futuro. > > - _NESSUNO_ ha bisogno di scalabilità world-wide; > - _NESSUNO_ ha bisogno di "elasticità" nel carico computazionale (ci > sono i click-day di INPS; ma quelli stanno fuori dal contesto che descrivo); > - _NESSUNO_ ha bisogno di SLA al 100% (con l'eccezione dei sistemi > hardware/software posti a gestire le Terapie Intensive delle ASL e, in > parte, dei Pronto Soccorso; ma parliamo comunque di una "minoranza" di > sistemi che sono gia' appannaggio di realta' "particolari") > > Trascuro i primi due punti perchè siamo d'accordo ma sul terzo mi soffermo: secondo me sulla questione uptime e continuità di servizio tralasci i piccoli problemi quotidiani che sommati fanno un totale aberrante. Negli ultimi anni ho lavorato per un fornitore di software di storage per apparecchi medicali. Uno dei problemi che hanno i piccoli centri radiologici sono le immagini perse e l'archivio lento. Esempio pratico banale: zia fa la radiografia all'anca, le danno il CD ma lo perde. Dopo 5 anni deve fare una nuova radiografia e la fa. Il suo ortopedico ha dei dubbi e chiede di vedere la radiografia storica. Zia si rivolge al centro e chiede l'archivio... Loro da qualche parte ce l'hanno, per legge ma per trovarlo ci vogliono ore di ricerca tra nastri antichi che chissà chi ha visto. Questi centri spesso sono organizzati come descrivi tu: un piccolo box in locale con le ultime immagini su un piccolo NAS e qualche batch script che deposita i dati su archivi remoti dove fanno qualche altro accrocchio con NAS più grandi e tape libraries per il lungo termine. Le ore spese a trafficare tra nastri antichi sono ore bruciate senza produrre niente di utile. Ci sono invece soluzioni più moderne di storage always-up, rapide, economiche ed efficienti. E che (aggiungo per chiarezza) non dipendono da GAM ma si comportano esattamente come uno di questi (private cloud). E quei "livelli di servizio" si migliorano con il cloud? Ne siamo davvero > sicuri? > Dobbiamo forse smettere di usare il termine cloud senza qualificarlo :) OpenStack e Kubernetes, minio, ceph... on-prem per me questa roba è cloud, private cloud per essere precisi. > In un mondo ideale, il Direttore Generale della ASL2Abruzzo (la mia ASL) > creerebbe una task-force di 5 umani a cui demandare il compito di > "razionalizzare" il parco software installato in lungo ed in largo per la > ASL, > [...] da quello che ho letto, AgID sta spingendo per fare proprio questo. > Conosco, viceversa, _MOLTE_ startup (di cui un buon 90% "universitarie") i > cui prodotti e servizi possono essere erogati con l'infrastruttura di rete > esistente (tipicamente GARR, ma anche quella dei vari Aruba, TopHost, > SeeWeb, Register, etc. etc.), con gli SLA ampiamente dimostrati (>98%) e, > soprattutto, a fronte di un carico computazione che sta _AMPISSIMAMENTE_ > all'interno di un Odriod HC2 (on-prem) [4] o su una VM che i provider > citati danno a meno di 10€/mese. > Ti seguo ma fino a un certo punto. Altro esempio banale: prendi mezza giornata di ferie per andare a fare un certificato nella [PA a caso]. Arrivi e ti comunicano che l'applicazione è bloccata e non possono fare certificati. Bon, mezza giornata buttata per un patetico SLA al 98%. Fai la somma di tanti 2% di downtime per servizi "non essenziali" e scommetto si arrivi vicino a mezzo punto di PIL :) > Quindi suggerirei di focalizzarsi _NON_ sull'infrastruttura di > erogazione.... ma, piuttosto, sulla soluzione vera e propria: cominciamo a > costruire i microservizi che servono per la "nuova" produzione. > Costruiamoli affinche' siano cloud-native (elastici, affidabili, > resilienti). E quando abbiamo la ragionevole certezza di riuscirci (cosa di > cui dubito....), a quel punto decideremo: > [...] Siamo d'accordo su un sacco di punti :)

June 12, 2021

Re: [nexa] The Cost of Cloud, a Trillion Dollar Paradox

by Damiano Verzulli

Il 12/06/21 14:39, Marco Delaurenti ha scritto: > > On Sat, 12 Jun 2021 at 09:35, <nexa-request(a)server-nexa.polito.it > <mailto:nexa-request@server-nexa.polito.it>> wrote: > > > Date: Sat, 12 Jun 2021 10:35:00 +0200 > From: Damiano Verzulli <damiano(a)verzulli.it > <mailto:damiano@verzulli.it>> > > [...] > Di nuovo: _NON_ conosco startup (abruzzesi) che partono _OGGI_ e che > dicono: "/Voglio conquistare il mondo, e siccome il mio > prodotto/servizio andra' su tutto il mondo... anziche' partire con la > mia infrastruttura, parto con AWS/". > > > Di nuovo, credo che nei discorsi fatti qui sulla ML si sia > parzialmente mancato il punto principale per me, che mi ha spinto a > scrivere il primo messaggio. Mi scuso, Marco, ma credo ci sia un mismatch di protocollo nelle nostre comunicazioni (cosa che capita non cosi' raramente, su questa lista). Il faro che mi guida nelle frequentazioni della ML NEXA e che mi porta a spendere alcune ore davanti alla tastiera è legato al fatto che attualmente la politica Italiana (da Colao, in giu) vuole adottare piattaforme cloud a trazione made-in-USA per sportarci sopra un corposo workload attualmente running su una pletora di sistemi distribuiti nelle varie PA (in particolare: Atenei ed Enti Locali [Regioni, Province, Comuni, Società Pubbliche], ASL). Questo processo è gia' in corso e, a mio modo di vedere, sta gia' comportando danni "sociali" che rischiano di essere drasticamente amplificati. L'imminente arrivo dei fondi del PNRR rischia, da questo punto di vista, di essere un eccezionale boomerang. Vorrei "lavorare" non dico per evitare questo scenario ma, almeno, provare a contribuire a sgombrare il campo da sgradevoli equivoci (molto diffusi, anche fra gli addetti ai lavori). E' di questo che parlo (io). Non di startup. Spero ora sia piu' chiaro. > Nessuna startup quando comincia pensa alla scalabilita', al 99.999% di > uptime o a raggiungere tutto il mondo, ma pensa alla _facilita' di > sviluppo e al time to market. > > L'alternativa e' tra affittare un piccolo rack, comprare l'hw, > assumere un sistemista, per avere poi un sistema subottimale su cui > gli sviluppatori devono lavorare, o assumere un developer full stack > che ha gia' usato AWS e puo' cominciare a sviluppare il prodotto > utilizzando tecnologie che richiedono pochi click per essere utilizzate. > > Il 100% delle startup (ma anche delle compagnie medio-grandi) > scegliera' la seconda alternativa. Le strategie delle startup (private) _NON_ mi interessano. Il mondo "privato" è liberissimo di fare tutte le scelte che vuole: pensera' il mercato a "premiarle" o a "sopprimerle". Certamente non impatteranno la mia vita allo stesso livello di quanto possa fare la scuola frequentata dai miei figli, il Comune dove vivo, la Regione dove vivo, la mia ASL, etc. etc.). Ciò premesso, se indosso il cappello da "tecnico", ritengo comunque fuorvianti alcuni passaggi del testo citato. Pensare che per sviluppare un servizio/prodotto software-centrico siano necessari, cito: "/...//un piccolo rack, comprare l'hw, assumere un sistemista, per avere poi un sistema subottimale su cui gli sviluppatori devono lavorare.../" mi pare eccessivo. Sul mio XPS 13" da 2K€ (un portatile), posso banalmente far girare 10 VM (o 50 container; o un mix delle due cose). Posso sviliuppare una applicazione di log-analysis che include tutto l'ambiente di sviluppo (parlo dell'IDE) all'interno del quale girano front-end (SPA) e back-end. Dove il back-end include due simulatori di stream di dati e dove è running anche un nodo elasticsearch. Tutto quello che sviluppo è versionato (GIT) e versionata è anche la documentazione. Un solo portatile. 2K€. Nessun rack. Nessun sistemista. Niente. Solo un XPS 13, il mio cervello ed un numero _ENORME_ di tecnologie open-source. Niente altro. Ad una startup serve di piu'? ...puo' essere, Ma se partisse focalizzandosi sul prodotto/servizio, e lo facesse con la consapevolezza di definirne l'architettura in modo da minimizzare le dinamiche di "lock-in", sarebbe gia' un ottimo risultato. Sul "/...avere poi un sistema subottimale su cui gli sviluppatori devono lavorare.../" ho tantissime riserve. Sul mio portatile posso far girare kubernetes (che è il layer utilizzato da google per gestire il suo workload); posso sviuppare ed eseguire elasticsearch; posso scrivere codice con almeno i primi 5 linguaggi piou' diffusi al mondo. Posso raccogliere e analizzare decine di milioni di eventi (a ritmi da diversi k per secondo). E posso condivere tutto con altri (colleghi, ad esempio). Perche' tutto questo sarebbe sub-ottimale? > Il grande vantaggio di AWS e' lo sviluppo nel tempo di un ecosistema > che rende estremamente facile fare qualsiasi cosa. Se ho un'esigenza, > sono quasi sicuro che esista un tool o una libreria nel mio linguaggio > preferito che mi permette di usare l'infrastruttura di AWS come IaaS. E' evidente che noi due [1][2] osserviamo il mondo da due punti di vista molto diversi. Non necessariamente l'uno è migliore dell'altro. Certo è che il terreno che forma la collina su cui poggio io _NON_ è fatto di AWS, di GCP, di Azure o cose del genere. Ma non per questo ho dubbi sulla qualità delle fondamenta (della collina): la quantità di tecnologie di cui dispongo _NON_ è certamente "un freno" che impedisce a me (ed alle PA che mi circondano) di "crescere". Tutt'altro. Se loro vogliono, con queste tecnologie possono crescere... avendo la possibilità di mantenere nelle proprie mani il proprio destino. > > [...] > utilizzando tecnologie che richiedono pochi click per essere utilizzate > [...] > Si tratta di fornire soluzioni alternative che introducano meno > sforzi, non di piu', altrimenti nessuno le scegliera' volontariamente, > ma solo se obbligato. > [...] Consentimi un ultimo commento su questi due passaggi, che pongono l'accento sul tema della "accessibilità della tecnologica". Nelle discussioni su questa ML, dovremmo definire se parliamo di: * andare a farci un giro, in macchina, nella Aygo di mia madre (classe 1949), che chiaramente è automatica e per la quale oggi ho "fotografato" una parte del cruscono per evidenziargli (in foto) il pulsante dell'aria condizionata (che comunque conosceva, me che non riusciva ad utilizzare perche' la temperatura segnava comunque 21°, indipendentemente dal fatto che il climatizzatore fosse operativo o no); oppure.... * prepararci per la "24 ore di Le Mans", dove.... non c'e' bisogno di indicare dov'e' il pulsante del clima e dove (spero!) non è stato il medico del pilota a rilasciare una "prescrizione medica" che dice: "Obbligo di guida di una auto da corsa, alla 24h di Le Mans". In altri termini: io credo che tutto l'enorme sforzo profuso per rendere semplice l'uso di tecnologie complesse.... debba essere "calibrato" rispetto all'obiettivo che ci si pone. La semplificazione è certamente auspicabile. Ma esiste un limite che --IMHO-- non puo' essere superato: se qualcosa è difficile... è giusto che vada affrontato per quello che è. Pensare ad uno sviluppatore dell'App-IO che _NON_ ha la piou' pallida idea delle problematiche di "privacy" che coinvolgono l'uso di Firebase [3] (o di Analytics), mi _TERRORIZZA_! Quello sviluppatore si trova dentro una Aygo (perche' è quello che sa guidare), senza rendersi conto che è a "Le Mans" e sta partecipando alla cosa. Ed è ancora piu' terribile se penso al fatto che la sua squadra non lo abbia "edotto" o, quantomeno, "corretto". Vedo molta schizofrenia. Dall'uso di stessi termini ("cloud", in primis) per riferirsi a contesti totalmente diversi, all'uso di "numeri" recuperati con tecnologie specifiche (es.: supporto dei livelli TLS dei siti web delle PA) ma poi utilizzati per scopi totalmente diversi (es.: "il 95% delle PA è insicuro"). Mi piacerebbe vedere diffondersi un processo rigoroso e razionale (come, su questa ML, _SICURAMENTE_ è possibile fare, stante la qualità elevatissima di chi la frequenta....) che aiuti a far chiarezza su questi temi... anche e soprattutto nell'interesse primo del nostro Paese (l'Italia). Saluti, DV [1] https://uk.linkedin.com/in/marcodelaurenti [2] https://it.linkedin.com/in/damianoverzulli [3] sul tema ci sono molti articoli. Questo e' un buon inizio: https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9668748 -- 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 12, 2021

Donne, matrici, interfacce

by Antonio Iacono

Segnalo questo interessante articolo: https://www.iltascabile.com/scienze/sadie-plant/ sul rapporto tra pensiero femminista e informatica, dagli anni Novanta a oggi. Sono "appunti" sul libro di Sadie Plant "Zero, Uno. Donne digitali e tecnocultura", edito per la prima volta nel 1997 da Fourth Estate e da poco pubblicato in italiano da LUISS University Press. Antonio

June 12, 2021

Re: [nexa] The Cost of Cloud, a Trillion Dollar Paradox

by Antonio Iacono

> ... o assumere un developer full stack che ha gia' usato AWS developer full stack che usano AWS? E' un ossimoro, vero? A parte che queste figure "mitologiche" vorrei tanto conoscerle, ma semmai esistessero certo non sarebbero persone da "accontentarsi" di pochi click o, detto in altri termini, d'aver "paura" di mettere su sistemi simili a quelli suggeriti da Damiano. Un amico sviluppatore, uno dei più grandi al mondo, all'incirca un anno fa ha deciso di abbandonare il suo progetto software di maggiore successo. Questo un passaggio del messaggio di addio [1]: "I write code in order to express myself, and I consider what I code an artifact, rather than just something useful to get things done. I would say that what I write is useful just as a side effect, but my first goal is to make something that is, in some way, beautiful. In essence, I would rather be remembered as a bad artist than a good programmer. Now I’m asked more and more, by the circumstances created by a project that became so important, to express myself less and to maintain the project more. And this is indeed exactly what Redis needs right now. But this is not what I want to do, and I stretched myself enough during the past years." Ecco, per un programmatore, uno bravo, fare il "manutentore", il "cliccatore", non è il massimo delle aspirazioni. Antonio [1] http://antirez.com/news/133

June 12, 2021

Re: [nexa] The Cost of Cloud, a Trillion Dollar Paradox

by Marco Delaurenti

On Sat, 12 Jun 2021 at 09:35, <nexa-request(a)server-nexa.polito.it> wrote: > > Date: Sat, 12 Jun 2021 10:35:00 +0200 > From: Damiano Verzulli <damiano(a)verzulli.it> > To: nexa(a)server-nexa.polito.it > Subject: Re: [nexa] The Cost of Cloud, a Trillion Dollar Paradox > Message-ID: <a78ff17e-7bc4-4a8d-78ee-4fc304df6eda(a)verzulli.it> > Content-Type: text/plain; charset="utf-8" > > > Una piccola azienda che comincia oggi puo' investire in una > > infrastruttura e aspettare un anno prima di poter cominciare a > > sviluppare? Oppure e' tentata dal fatto che puo' cominciare a > > sviluppare i suoi prodotti in tempo minino sul cloud? > Di nuovo: _NON_ conosco startup (abruzzesi) che partono _OGGI_ e che > dicono: "/Voglio conquistare il mondo, e siccome il mio > prodotto/servizio andra' su tutto il mondo... anziche' partire con la > mia infrastruttura, parto con AWS/". > > Di nuovo, credo che nei discorsi fatti qui sulla ML si sia parzialmente mancato il punto principale per me, che mi ha spinto a scrivere il primo messaggio. Nessuna startup quando comincia pensa alla scalabilita', al 99.999% di uptime o a raggiungere tutto il mondo, ma pensa alla _facilita' di sviluppo e al time to market. L'alternativa e' tra affittare un piccolo rack, comprare l'hw, assumere un sistemista, per avere poi un sistema subottimale su cui gli sviluppatori devono lavorare, o assumere un developer full stack che ha gia' usato AWS e puo' cominciare a sviluppare il prodotto utilizzando tecnologie che richiedono pochi click per essere utilizzate. Il 100% delle startup (ma anche delle compagnie medio-grandi) scegliera' la seconda alternativa. Il grande vantaggio di AWS e' lo sviluppo nel tempo di un ecosistema che rende estremamente facile fare qualsiasi cosa. Se ho un'esigenza, sono quasi sicuro che esista un tool o una libreria nel mio linguaggio preferito che mi permette di usare l'infrastruttura di AWS come IaaS. Si tratta di fornire soluzioni alternative che introducano meno sforzi, non di piu', altrimenti nessuno le scegliera' volontariamente, ma solo se obbligato. Saluti, -- Marco F. D. twitter @mf_dela # +1 (650) 260-3352 https://keybase.io/mfdela/chat

June 12, 2021

Re: [nexa] The Cost of Cloud, a Trillion Dollar Paradox

by Damiano Verzulli

Il 10/06/21 09:35, Marco Delaurenti ha scritto: > L'articolo e' preciso. Condivido che l'articolo [1] sia "preciso". Tuttavia il contesto dell'articolo è certamente fuorviante: non mi pare che nei discorsi CLOUD che si affrontano su questa mailing-list si parli di entità dimensionalmente paragonabili a DropBox o a cose simili a "/...//50 of the top public software companies//currently utilizing cloud infrastructure..../". La tipica "scala" che osservo quando mi guardo attorno (sono Abruzzese), è quella in cui i player piu' grossi sono pubblici: Atenei, ASL e Regione. Il workload di un Ateneo sta tranquillamente in un armadio rack "moderno". Quello di una ASL e leggermente più grande (un paio di rack moderni). La quantità di ferro che serve ad operare una Regione --pur non avendola mai vista direttamente-- scommetto che possa essere analoga. Ho una mezza idea di cosa sia necessario per l'operatività dei Laboratori Nazionali del Gran Sasso (L'Aquila; mi riferisco alla parte "amminitrativa", senza includere la parte "ricerca"), del Centro Nazionale Amministrativo dell'Arma dei Carabinieri (Chieti), dell'Azienda dei Trasporti Regionali. In tutte queste realta' "pubbliche", il rapporto fra "tonnellata di peso dell'hardware" e "modernità dello stack software attualmente in produzione" è incredibilmente alto, a la parola "tecnologie cloud" --quando presente al denominatore-- è sinonimo di IaaS. Evito di parlare di "privato": dalle mie parti, visti da me (ICT), i privati "interessanti" occupano soltanto il suolo, perché la parte ICT è gestita 100% dall'headquarter, fuori regione, con zero possibilità di intervento locale. I privati che restano (_TUTTI_), hanno un workload tipico che puo' essere _AMPIAMENTE_ gestito con un Datacenter-in-a-box: ~40Kg di ferro, ~20cm di altezza su rack, ~20/30K€ spalmati su 5/7 anni [2] È questo contesto pubblico/economico che ho in mente quando leggo l'articolo citato [1] ed è per questo che, nel mio contesto, lo trovo defocalizzante: * _NESSUNO_ ha bisogno di scalabilità world-wide; * _NESSUNO_ ha bisogno di "elasticità" nel carico computazionale (ci sono i click-day di INPS; ma quelli stanno fuori dal contesto che descrivo); * _NESSUNO_ ha bisogno di SLA al 100% (con l'eccezione dei sistemi hardware/software posti a gestire le Terapie Intensive delle ASL e, in parte, dei Pronto Soccorso; ma parliamo comunque di una "minoranza" di sistemi che sono gia' appannaggio di realta' "particolari") Se questo scenario non è chiarissimo nelle nostre teste, le discussioni che si fanno su questa lista --come dimostrano i recenti thread sul punto-- diventano scarsamente utili. Se questo scenario non è chiaro, si finisce per citare le tecnologie dell'APP-IO come fattore che impedirebbe l'erogazione on-prem di quel servizio (....cosa su cui certamente concordo, ma.... _NON_ mi interessa, perche' _NON_ è questo l'aspetto su cui la strategia sul "cloud Nazionale" impattera'). Se questo scenario non è chiaro, si finisce con il sostenere che AWS, Google e Microsoft offrono soluzioni cloud che nessun altro player sul mercato offre. Il che è _ASSOLUTAMENTE_VERO_, ma _TOTALMENTE_IRRILEVANTE_ nel contesto che ho descritto. Un contesto dove --ribadisco-- "cloud", quando esiste come termine, è equivalente a "IaaS". Se questo scenario non è chiaro.... se si trascura che il 99,99% del workload tipico dei contesti che ho descritto è architetturalmente ancorato ai paradigmi di 20 anni fa [*], allora si commette un errore: pensare che i problemi di ammodernamento di queste realtà si risolvano con uno schiocco delle dita grazie all'adozione delle tecnologie "cloud". > Il costo pero' e' solo una delle variabili e puntare solo su quello e' > imho riduttivo e non convincera' molti a non usare il cloud. Tutti lo pensiamo e lo sappiamo.... anche se nessuno ama dirlo esplicitamente: in ambito Pubblico, i soldi _NON_ sono mai un problema. Chi conosce bene la macchina Pubblica sa che nelle scelte --quelle discusse e condivise con i livelli apicali e da loro condivise-- il fattore "costo" _NON_ è una variabile in gioco. Potrebbe diventarlo.... Ma ad oggi non lo è. Quindi non solo sottoscrivo quanto citato, ma suggerisco proprio di "cassare" la parola "costo" dalle discussioni (chiaramente parlo al mondo della PP.AA.) > Per eempio, come dice l'articolo, migrare fuori dal cloud richiede un > team e delle conoscenze non banali. La gestione di una infrastruttura "on-prem" (sistemi, server, storage e reti) richiede certamente competenze rilevanti. Ma nel contesto che ho disegnato (quella della PA abruzzese del 2021) È GIA' COSI': l'infrastruttura oggi esiste e viene mantenuta. Si potrebbe discutere del "SE" tali infrastrutture vengano oggi gestite "correttamente"; "efficientemente"; "al meglio".... È evidente che _NON_ lo siano, non tanto per gli aspetti "di costo", ma soprattutto per i livelli di servizio erogati. E quei "livelli di servizio" si migliorano con il cloud? Ne siamo davvero sicuri? In un mondo ideale, il Direttore Generale della ASL2Abruzzo (la mia ASL) creerebbe una task-force di 5 umani a cui demandare il compito di "razionalizzare" il parco software installato in lungo ed in largo per la ASL, censendolo (passo 1), interfacciandosi con i fornitori per obbligarli all'integrazione (nell'ambito dei contratti quadro di manutenzione esistente) (passo 2), e pianificando l'evoluzione successiva (architettura a micro-servizi, cloud-native) (passo 3). Il tutto con l'assoluto rispetto della normativa vigente (privacy-first; API-first) (aspetto trasversale n. 1) e, soprattutto, con una logica full-open-source ed in totale e trasparente sinergia con le altre ASL (...e con gli altri vendor) (aspetto trasversale n. 2). 5 persone "giuste". 500K€/anno di costo. Autonomia decisionale [sugli aspetti tecnici] e possibilità di intervento [sui contratti in essere]. (...e un Direttore illuminato. Che non salta al prossimo cambio di Presidente di Regione. O di Ministro.). È di questo che stiamo parlando. È difficile? Puo' essere.... ma non esiterei a scommettere sulla fattibilità dell'operazione. > Una piccola azienda che comincia oggi puo' investire in una > infrastruttura e aspettare un anno prima di poter cominciare a > sviluppare? Oppure e' tentata dal fatto che puo' cominciare a > sviluppare i suoi prodotti in tempo minino sul cloud? Di nuovo: _NON_ conosco startup (abruzzesi) che partono _OGGI_ e che dicono: "/Voglio conquistare il mondo, e siccome il mio prodotto/servizio andra' su tutto il mondo... anziche' partire con la mia infrastruttura, parto con AWS/". Conosco, viceversa, _MOLTE_ startup (di cui un buon 90% "universitarie") i cui prodotti e servizi possono essere erogati con l'infrastruttura di rete esistente (tipicamente GARR, ma anche quella dei vari Aruba, TopHost, SeeWeb, Register, etc. etc.), con gli SLA ampiamente dimostrati (>98%) e, soprattutto, a fronte di un carico computazione che sta _AMPISSIMAMENTE_ all'interno di un Odriod HC2 (on-prem) [4] o su una VM che i provider citati danno a meno di 10€/mese. E quindi? Quindi suggerirei di focalizzarsi _NON_ sull'infrastruttura di erogazione.... ma, piuttosto, sulla soluzione vera e propria: cominciamo a costruire i microservizi che servono per la "nuova" produzione. Costruiamoli affinche' siano cloud-native (elastici, affidabili, resilienti). E quando abbiamo la ragionevole certezza di riuscirci (cosa di cui dubito....), a quel punto decideremo: * spendiamo 50K di ferro e storage e lo attacchiamo dietro la nostra "fibra" ed al nostro contatore enel da 3KW? ....sappiamo che funzionera' per il 99% dell'anno.... * troveremo un "sistemista" (interno) o un "partner" (esterno) che ci gestirà l'ambaradan? (hint: ce ne sono _TANTISSIMI_ [3]! Basta saperli cercare e trovare... * lasciamo perdere l'infrastruttura on-prem, ed utilizziamo soluzioni IaaS sparse per il mondo? (oggi su AWS, domani su Google, dopodomani su Aruba, poi ancora su SeeWeb, etc. etc.) * lasciamo perdere _TUTTO_ lo stack applicativo accessorio, e ci occupiamo _SOLO_ della nostra meravigliosa APP? (quindi utilizziamo l'elasticsearch di elastic, l'S3 di Amazon, e magari anche qualche lamba di AWS.... o anche il kubernetes di Google, etc. etc.) * etc. etc.... A mio avviso, il punto fondamentale è la realizzazione di architetture che _IN_NESSUN_MODO_ presentino delle dinamiche di "lock-in": la possibilità di switchare da una soluzione/fornitore (on-prem o cloud che sia) ad un'altra (on-prem o cloud che sia) _DEVE_ restare un punto centrale di tutta la strategia. Chiaramente questo tipo di "controllo" ha un costo (serve _UNA_ persona; proprio _UNA_ di numero) che abbia le idee chiare su tutta la big-picture e possa guidare il processo. Se non si e' disposti o capaci di trovare/gestire questa singola persona.... allora evidentemente il tema che stiamo affrontando _NON_ è di interesse e quindi.... abbiamo perso tempo... > Il mercato del lavoro e' un'altra variabile: non molti sviluppatori > sono interessati a fare lavoro di infrastruttura o aver a che fare con > problemi di infrastruttura, se devono scegliere un'azienda che usa AWS > e una che usa dei datacenter, probabilmente sceglieranno la prima. > > Potrebbe essere diverso per una grande azienda o la pubblica > amministrazione, ma credo richieda un'opera di educazione notevole. La PP.AA. _DEVE_ essere il centro di tutto questo processo. _SOLO_ la PP.AA. puo' fungere da "traino" per risollevare lo stato dell'ICT del nostro Paese. Senza una PP.AA: che "sposi" e "promuova" questo processo di rinnovamento, non c'e' chance alcuna di riuscire (almeno dalle mie parti!) E non posso non evidenziare che, fra le PP.AA., gli Atenei ne rappresentano l'eccellenza! E dovrebbero essere _LORO_ a mettersi alla guida di questo processo. Proprio loro --gli Atenei-- che pur essendo circondati, oggi, da realta' di eccellenza (GARR / Cineca) e pur avendo nel proprio organico dei tecnici certamente capaci di "abbracciare" questo processo di rinnovamento... stanno in realta' lavorando (gli Atenei) esattamente in direzione contraria: delocalizzare (e distruggere) tutto l'ICT, a partire da quello che e' rimasto al loro interno. Il fatto che PoliTO, a piu' di un anno di distanza, _NON_ abbia ancora fatto "scuola" negli altri Atenei.... grida vendetta! Lo trovo un segno evidente della difficoltà di avviare tale processo di rinnovamento. Ma _NON_ si tratta di difficolta' "tecniche". Si tratta di _NON_ avere il "coraggio" di effettuare scelte difficili.... (nonostante si sia liberamente scelto di fare questo di mestiere, e si venga remunerati per farlo!) Scusate la prolissita'. Buon fine settimana! Saluti, DV [1] https://a16z.com/2021/05/27/cost-of-cloud-paradox-market-cap-cloud-lifecycl… [2] https://www.dell.com/it-it/work/shop/productdetailstxn/poweredge-vrtx [3] ad esempio, non posso non citare https://opennebula.io/enterprise/ (europei) e https://www.sparkfabrik.com/it (italiani) [4] https://ameridroid.com/products/odroid-hc2 [*] intendo un browser che eroga una applicazione "legacy", erogata da un application server "legacy" il quale, a sua volta, utilizza un motore DBMS "legacy"; e per "legacy" intendo --quando va bene-- tecnologie three-tier costruite con ActiveX, Java/JSP/Servlet, .net, Oracle/SQL-Server... (giusto per fare qualche esempio...), dove la parole Linux è molto diffusa e la parola PHP viene sbandierata come "moderno".... ma dove anche la terminologia "SPA - Single Page Application" è pressoché sconosciuta.... per non parlare di container e "microservizi".... (che non compaiono neanche nei siti web d'informazione consultati regolarmente dai dirigenti ICT delle realtà indicate) -- 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 12, 2021

Re: [nexa] R: Re: Caso di censura su Facebook

by Marco A. Calamari

On Fri, 2021-06-11 at 13:10 +0200, Enrico Nardelli wrote: > Era certo un biochimico ma soprattutto uno scrittore, in questo senso un > "umanista" e non un "tecnico duro e puro". "Le proprietà endocroniche della Tiotimolina risublimata" ? https://it.wikipedia.org/wiki/Propriet%C3%A0_endocroniche_della_tiotimolina… > Ma non era, il mio, un giudizio riduttivo verso i tecnici (tra i quali mi > considero): solo una constatazione dell'importanza delle dimensioni artistiche > e non razionali nel ragionare sul futuro della società. > Ciao, Enrico > Il 11/06/2021 12:56, Giacomo Tesio ha scritto: > > Ciao Enrico > > On Fri, 11 Jun 2021 11:34:57 +0200 Enrico Nardelli wrote: > > > L'inizio della psicostoria (cfr Hari Seldon). > > > (perdonate la digressione, ma alle volte gli umanisti leggono ilfuturo > > > meglio dei tecnologi) > > > > Interessante considerazione, ma per la verità Asimov era un biochimicomentre > > tu ed io siamo informatici: a quali umanisti ti riferisci? > > E cosa intendi per "tecnologi"? > > Gli "astrologi della tecnologia" che scrivono solitamente sui giornali? > > > > Giacomo > > -- EN > =====================================================================Prof. > Enrico NardelliDipartimento di Matematica - Universita' di Roma "Tor > Vergata"Via della Ricerca Scientifica snc - 00133 Romatel: +39 06 > 7259.4204 fax: +39 06 7259.4699mobile: +39 335 590.2331 e-mail: > nardelli(a)mat.uniroma2.it > home page: http://www.mat.uniroma2.it/~nardelli > blog: http://www.ilfattoquotidiano.it/blog/enardelli/ > http://link-and-think.blogspot.it/ > =====================================================================

June 11, 2021