Il tema del LOCK-IN, su questa lista, è certamente noto, e spesso fonte di discussione. Viene solitamente declinato in due forme: 1 - relativo "ai DATI": utilizzo applicativi a cui affido un set di dati... e quegli applicativi li "frullano" e li "organizzano" affinché, per ottenerli indietro, io sia costretto ad utilizzare quegli stessi appilcativi (oppure altri, scelti e "controllati" unicamente dello stesso fornitore); 2 - relativo "al Servizio": contrattualizzo l'utilizzo di un determinato "software/servizio" (es.: un strumento di office-automation) che mi viene erogato da remoto. Piu' tale utilizzo diventa importante per il mio core-business, piu' il fornitore acquisisce "potere di intervento" sullo stesso, ad esempio aumentando il prezzo/canone da pagare, oppure limitandone/restringendone l'utilizzo. Contestualmente, rendendo sempre piu' complicata la possibilita', per me, di "migrare" ad altro fornitore. Con l'avvento del cloud, si stà diffondendo una nuova forma di "lock-in", a mio avviso piu' subdola delle due precedenti, in quanto: a - molto piu' complessa da detectare, da parte di "dirigenti"/"policy-makers"; b - molto, _MOLTO_,  allettante da parte dei livelli "tecnici". Mi riferisco al "serverless computing", ossia alla possibilita' di scrivere applicativi che deliberatamente affidano una parte del proprio funzionamento ad un componente remoto, offerto da terzi, e richiamato dinamicamente al momento dell'utilizzo. Ad esempio, se sto scrivendo un applicativo web o una APP che deve autenticare i propri utenti... posso limitarmi al solo "disegno" del "form di autenticazione", e poi appoggiarmi a FireBase (di Google) che mi offre tutto quello che serve per gestire gli utenti, conservare le relative password (cifrate), e darmi gli strumenti per implementare banalmente le funzionalita' di "login", "logout" e "registrati come nuovo utente". Agli occhi di uno sviluppatore tutto cio' è meraviglioso: non ha bisogno di mettere in piedi un DB, e di allestire la parte di backend che si occupa, appunto, di autenticazione e servizi accessori. Anzi: il fatto che lo faccia Google... lo rende molto tranquillo! Addirittura "contento". Agli occhi miei, pero', lo scenario è diverso: liberarsi da Firebase equivale a _RISCRIVERE_ parte dell'applicazione, con un impatto che è estremamente significativo, e certamente maggiore di quello che avrei dovuto "pagare" se, dall'inizio, avessi scelto di utilizzare tecnologie di cui avevo il controllo. D'altronde, i fautori del serverless computing sostengono vantaggi notevoli in termini di tempi di rilascio inferiori, standard di sicurezza maggiori, scalabilità, costo inferiore (specialmente all'inizio, grazie al modello pay-per-use). Da notare che questo problema ha gia' avuto un impatto non-trascurabile: Firebase (ed i Google Play Services.... ) sono utilizzati dall'APP-IO e questo ne impedisce la pubblicazione su store alternativi (come F-Droid), vincolandone la fruizione attraverso il play-store di Google (almeno questo è quello che io capisco, da qui [1][2] - confesso, pero', di non aver approfondito). Il risultato, è che l'installazione dell'APP-IO sul mio smartphone de-googled... non è banalissima. Discorso analogo (ma ancora piu' subdolo) rispetto allo sviluppo di APP da utilizzare ufficialmente come secondo fattore di autenticazione SPID e che richiedono di girare su smartphone android dotati dei "Google Play Services" (...che sul mio cellulare NON voglio far girare, in quanto "proprietari"). Anche in questo caso (Google Play Services) si tratta di servizi offerti da Google per semplificare la vita dello sviluppatore.... al prezzo di "vincolare" l'APP sviluppata, appunto, all'esecuzione di tali servizi Tornando al serverless computing, la spinta a scrivere questo messaggio è arrivata da un evento che si terra' on-line il 13/12/2022, organizzato da una piccola associazione emiliana, estremamente attiva nei settori di punta dell'ICT moderno (cloud, sviluppo a microservizi, automazione/orchestrazione, etc.). L'evento è questo:     "serverless @ 127.0.0.1"     https://www.grusp.org/localhost_/serverless-2022/ e prevede: - 2 talk targati Amazon/AWS - 2 talk targati Google/CGP - 1 talk targato Microsoft/Azure - 1 talk tarkato Alibaba/Alibaba_Cloud     Per avere un'idea di quanto dirompenti possano essere questi servizi, si puo' spendere un paio di minuti ad osservare come --nell'ambito dei corsi di formazione _GRATUITI_ organizzati da COGITA [3]--, uno dei giovani sviluppatori mostra quanto sia semplice, appunto, aggiungere l'autenticazione ad una propria applicazione web (il link è al segmento che introduce firebase - dura ~2 minuti): => EP. 08 - Autenticazione con Firebase: gestire Login Utenti https://youtu.be/MjvQH5vTRWc?t=124     Ci tengo a sottolineare che il mio NON vuole essere un "attacco" verso i tecnici che utilizzano Firebase, oppure altre soluzioni di serverless computing... È evidente che, ad un tecnico che deve implementare un modulo di autenticazione, interessa poco o nulla il tema del "lock-in".     Ma se quel tecnico lavora per una azienda che prende in mano una commessa pubblica.... allora il discorso diventa piu' complesso.     Mi piacerebbe discutere di questa complessita'...     Un saluto,     DV [1] https://github.com/pagopa/io-app/issues/1718#issuecomment-727852093 [2] https://github.com/pagopa/io-app/issues/1718#issuecomment-873632698 [3] https://www.cogita.it/ -- 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