Open source, software libero e altre libertà/Nuvole aperte, nuvole chiuse e nuvole nere

Da Wikisource.
Nuvole aperte, nuvole chiuse e nuvole nere

../API e nuvole, la faccia chiusa del web ../Lista delle più comuni abbreviazioni IncludiIntestazione 13 maggio 2019 100% Da definire

API e nuvole, la faccia chiusa del web Lista delle più comuni abbreviazioni

[p. 141 modifica]

Nuvole aperte, nuvole chiuse
e nuvole nere

La discussione del capitolo precedente sulle API e sulla loro chiusura presenta notevoli continuità con il diverso, ma consimile, quantomeno in termini di apertura o non apertura, tema del cloud computing, in particolare sul cosiddetto cloud pubblico, il quale presenta serie problematiche concorrenziali e di interoperabilità.

Affrontiamo quindi in questo capitolo più in generale tutte le declinazioni e le problematiche di openness nei sistemi cloud.

Cos’è il cloud

Il cloud non esiste. Non a caso in rete circola il meme “there is no cloud; it is only someone else’s computer”.

Esiste una serie di tecnologie di virtualizzazione, di condivisione e di interscambio di dati e di servizi che vanno sotto il nome comune di “cloud”, ma da un punto di vista tecnico e giuridico sono molto diverse tra loro. Qui ci occupiamo esclusivamente di quel tipo di cloud denominato “pubblico”, ovvero in cui il software e i dati sono in tutto o in parte “ospitati” da fornitori di servizi non controllati da chi li utilizza, e sono regolati da rapporti contrattuali in cui non vi è consegna di software (se non marginalmente). Il cloud privato è invece solamente un modo di [p. 142 modifica]organizzare il software, con tecnologie magari identiche a quelle usate nel pubblico, ma in cui non vi è una separazione tra il fornitore e l’utilizzatore del servizio a sua volta fornito dal software; che poi è la principale ragione per cui ci occupiamo specificamente di cloud con gli accenti a volte negativi che troveremo in seguito.

“Pubblico”, in questa accezione, non riguarda dunque la natura legale del soggetto che si avvale o che fornisce i servizi in cloud, ma si riferisce al fatto che i servizi siano offerti “pubblicamente”. Dunque “pubblico” nel senso di “sulla (metaforica) pubblica piazza”, “a disposizione di tutti”.

In particolarmente ci occupiamo di “Software as a Service” (SaaS) e di “Platform as a Service” (Paas), secondo una nomenclatura ormai accettata universalmente. Servizi in luogo di software.

Le libertà del cloud

Nel cloud (e da qui in avanti useremo questo termine per intendere solo PaaS e SaaS) tutto quello che abbiamo detto in precedenza in termini di openness nel software non vale. Nel software reso disponibile via cloud, infatti, non vi è distribuzione di software, ma soltanto un’esposizione via rete dei servizi che il fornitore decide di mettere a disposizione, e solo con le interfacce e i protocolli da questi predisposti. Pertanto, il “cliente” non può certamente beneficiare delle quattro libertà1: non può usare il software, se non per quello che gli è consentito dal fornitore; non può distribuire il software, perché non lo riceve lui stesso; non può studiare né modificare il software, perché [p. 143 modifica]non ha né il codice oggetto, né il codice sorgente; non può infine distribuire copie modificate, perché non le può modificare.

Con una disponibilità di banda sempre più elevata a costi sempre più bassi, lo spostamento di un sempre maggior numero di servizi dal software gestito in locale a software gestito in remoto via Internet, dunque “nella nuvola”, diventa un paradigma con il quale fare i conti costantemente, ma verso il quale gli strumenti ormai consolidati e che abbiamo analizzato in precedenza hanno poco impatto.

È dunque tutto perduto, tutto inutile? Non dobbiamo usare il cloud o rassegnarci a un mondo non libero? Andiamoci piano.

Se nel cloud dunque non possiamo utilizzare le categorie logiche e giuridiche del software “distribuito”, abbiamo tuttavia alcune caratteristiche che ci consentono di discriminare un “buon” cloud da uno non molto buono. Vi sono una serie di “libertà” che dobbiamo tenere presente per valutare se, giuridicamente e tecnicamente, si possa ottenere una situazione simile a quella che avremmo in una situazione di software libero.

Migrazione: anche una questione di costi

Una cosa è certa: non staremo per sempre con lo stesso fornitore di servizi. Dunque i costi di migrazione sono “sunk cost”. Significa che si tratta di costi inevitabili, in quanto non dipendono da una decisione futura, ma dipendono da una decisione passata e non più modificabile. Ad esempio, i costi di migrazione devono essere valutati sin dal giorno in cui concludo un contratto con il nuovo fornitore. “Addebitare” i [p. 144 modifica]costi di migrazione al vecchio fornitore comporta scelte irrazionali, in quanto induce a scegliere il fornitore con i costi di ingresso più bassi, ma i costi di uscita alti. Il che è irrazionale.

Vi è infatti un incentivo per il fornitore ad alzare i costi di uscita, abbassando l’interoperabilità e la migrabilità dei servizi. Ciò crea una dipendenza dal fornitore in capo al cliente: anche se vi fosse una soluzione più efficiente ed economica, aggiungendo i costi di migrazione la nuova soluzione sarebbe sempre handicappata rispetto a quella attuale, perché sopporterebbe costi di migrazione che non si affrontano restando presso l’attuale fornitore.

Come evitare i costi della migrazione? Purtroppo non è possibile se non includendo previsioni adeguate nelle condizioni contrattuali, ad esempio, addossando al fornitore attuale il costo e gli oneri di migrare i servizi verso una soluzione standard. La migrazione non deve essere dalla soluzione “proprietaria” ad ogni n soluzioni proprietarie di operatori; ciò sarebbe assurdo e impossibile. La migrazione a carico del fornitore uscente deve essere contrattualmente stabilita fino a un “punto di raccolta”. Questo punto di raccolta deve essere visto in una situazione standard di dati e di servizi. Usando questa strategia il futuro fornitore uscente è incentivato a usare sin da subito open standard, o quantomeno a usare soluzioni che consentano di realizzare in modo sufficientemente spedito ed economico soluzioni basate su standard aperti2 che garantiscano una piena interoperabilità. Invece di avere incentivi tra loro congruenti e favorevoli al lock-in, continuiamo ad avere un [p. 145 modifica]incentivo “naturale” verso il lock-in, ma equilibrato da un incentivo opposto, che tende ad evitarlo, perché il costo del lock-in verrebbe comunque pagato alla fine dal fornitore attuale.

Interoperabilità

Anche nei servizi cloud esiste una questione di interoperabilità, ovvero di far “parlare” i servizi per scambiarsi dati e funzionalità. Per avere interoperabilità occorrerà dunque avere anche qui servizi standard, o quantomeno adeguatamente documentati (standard de facto), e formati di file altrettanto standard (per i documenti latamente intesi).

L’interoperabilità deve essere valutata sia durante la fase di conduzione normale del servizio, sia durante la fase di migrazione (o cosiddetta “ripresa” dei dati e di servizi). L’interoperabilità in fase di conduzione è quella che consente di utilizzare i servizi di un determinato fornitore considerato in congiunzione (in cooperazione) con i servizi di un terzo. Ciò riduce la dipendenza in caso di aumento delle esigenze e di nuovi workload che dovessero rendersi necessari.

L’interoperabilità in fase di migrazione, invece, consente di esportare e importare sia i dati che i servizi (il concetto di migrazione dei servizi può sembrare ostico, ma è una cosa abbastanza naturale) senza perdita di fedeltà né nei dati, né nella business logic associata ai servizi. Nei costi di migrazione da considerare è ovviamente da comprendere quello di indisponibilità del sistema nella fase di migrazione (totale o parziale). È appunto di questa situazione che abbiamo parlato nel punto precedente. [p. 146 modifica]

Certo, non sarà possibile ottenere una piena interoperabilità e migrabilità sulla base di interfacce e soluzioni di interscambio valide per tutti, ma sempre di più si stanno affacciando tecnologie mature ed esempi di successo di approcci basati su interfacce standard e persino open source nei servizi cloud. La loro adozione diretta è una soluzione per determinare l’interoperabilità, certo, ma la presenza di tali iniziative fa sì che ci sia un sistema (o più sistemi) di riferimento verso i quali i produttori di soluzioni proprietarie possono creare interfacce. Una di queste soluzioni è il progetto Open Stack3.

Sicurezza e privacy

Mentre scrivevo queste righe in un post in cui mi occupavo esattamente di questo tema, arrivò la notizia che Amazon (AWS) stava sperimentando4 estese interruzioni del servizio. Come noto, sui servizi di Amazon sono basati migliaia di siti di tutti i tipi. Un adagio popolare vuole che non si mettano tutte le uova nello stesso cesto, ma è esattamente ciò che stiamo facendo. Certo, è conveniente. Certo, è comodo. Certo, è sicuro. Dipende però da ciò che si considera “sicuro”. La sicurezza non è una dimensione lineare, è un insieme di fattori che vanno bilanciati. Si suole dire che la sicurezza di un sistema è simile alla robustezza di una catena: si misura dal più debole dei suoi anelli.

Con la concentrazione di servizi e funzioni (“workload”), si fa esattamente questo: si mettono un sacco [p. 147 modifica]di uova in uno stesso cesto. Il problema è che quando i sistemi su cui questo cesto si fonda si interrompono, un pezzo rilevante di Internet se ne va a fare un giro per un po’. E con esso un sacco di gente che ci lavora sopra. Il rischio di cui parliamo è dunque quello dell’indisponibilità (business continuity), che è un rischio esattamente come lo è quello della perdita di dati e della loro diffusione involontaria.

Parlando di diffusione, o meglio, di rivelazione involontaria, essa è un fatto indipendente dalla conoscenza “psicologica” di una persona determinata; è sufficiente che i dati siano conoscibili da un soggetto, ed ecco che per le leggi sulla protezione dei dati personali non sono conservati correttamente. Il nuovo Regolamento sulla protezione dei dati personali5 obbligherà in molti casi a fare un auto-accertamento dei livelli di rischio (frequenza, gravità dell’incidente e delle potenziali conseguenze) e la sicurezza andrà parametrata al livello auto-accertato, senza una soluzione unica per tutti. Per questo, i livelli di sicurezza da adottare potranno essere minori, ma in moltissimi casi saranno più elevati.

La possibilità che un terzo venga a conoscenza dei dati conservati è solo una delle possibili conseguenze di una cattiva conservazione. Anche la mancanza di “trasparenza” sulla catena di responsabilità nella gestione dei servizi è un elemento da tenere presente. Per dare trasparenza (ai propri interessati) occorre avere trasparenza in proprio. In altre parole, è necessario conoscere chi è investito dei compiti di rendere le varie componenti dei servizi resi, in tutta la catena di fornitura. [p. 148 modifica]

Tornando alla questione delle uova tutte in un cesto, però, ancora l’interoperabilità e la possibilità di migrare, o meglio, federare servizi diversi, senza avere degradata la qualità del servizio, è ciò che riduce di gran lunga anche il rischio di dipendenza da un unico fornitore esterno. I servizi che per loro natura sono “commodity”, ovvero forniti da un numero non limitato di soggetti e intercambiabile, danno intrinsecamente maggiore sicurezza e indipendenza, consentendo la ridondanza dei sistemi e dei fornitori. Si pensi alla connessione Internet, ai DNS, all’archiviazione dei dati, ai servizi di database eccetera. Tutti questi servizi sono disponibili e accessibili in quanto sono basati su standard interoperabili; che poi è un modo di definire una caratteristica degli standard aperti.

Conclusioni

L’uso di sistemi basati su paradigmi nuovi porta sfide e possibilità prima non concepibili. La tendenza a sfruttare sempre di più SaaS e PaaS nei servizi ad ogni livello, anche da parte della Pubblica Amministrazione, crea una serie di possibili punti di fallimento che – pur anticipati da molti – vengono accettati come reali solo quando gli eventi della cronaca, in modo ineluttabile rendono evidente.

Non si tratta di essere Cassandre o teorici del complotto. Né si tratta di essere faciloni improvvisati.

Conoscere le sfide, appunto, è il modo migliore di affrontarle. Siamo ancora in larga parte in terra incognita, questo fatto da solo merita rispetto e attenzione, e fa sì che solo un atteggiamento prudente – né [p. 149 modifica]luddista, né tantomeno stupidamente entusiasta e incosciente – sia quello da tenere.

Il faro che ci ha guidati sin qui, quello di prediligere sempre e comunque una scelta di apertura nella tecnologia e di tendenziale condivisione, dove possibile, sembra non aver ancora esaurito la sua luce. Se c’è una cosa su cui mi sento di scommettere è che questa luce ci guiderà ancora per tanto tempo, con buona pace di chi, decenni fa come oggi, pensa di avere la verità in tasca e scuote la testa quando parliamo di questi temi.

La storia ci ha dato ragione in passato, ci darà ragione anche in futuro.

  1. https://www.gnu.org/philosophy/free-sw.it.html.
  2. Vedi la relativa discussione nel capitolo che abbiamo dedicato a tale tema.
  3. https://www.openstack.org/.
  4. http://www.theverge.com/2017/2/28/14765042/amazon-s3-outage-causing-trouble.
  5. http://www.garanteprivacy.it/web/guest/home/docweb/-/ docweb-display/docweb/5187723.