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-lifecycle... [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@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