WEBVTT 00:00:01.360 --> 00:00:03.439 Salve a tutti, siete all'ascolto di 00:00:03.439 --> 00:00:05.759 INSiDER - Dentro la Tecnologia, 00:00:05.759 --> 00:00:08.000 un podcast di Digital People e 00:00:08.000 --> 00:00:09.199 io sono il vostro host, 00:00:09.199 --> 00:00:10.240 Davide Fasoli. 00:00:16.934 --> 00:00:18.774 Oggi cercheremo di capire se la 00:00:18.774 --> 00:00:20.695 frequenza dei disservizi di Internet a 00:00:20.695 --> 00:00:22.614 cui stiamo assistendo negli ultimi mesi 00:00:22.614 --> 00:00:24.294 sia dovuta a una maggior fragilità 00:00:24.294 --> 00:00:26.695 delle infrastrutture odierne rispetto al passato 00:00:26.695 --> 00:00:28.695 o a un mero errore di percezione. 00:00:29.250 --> 00:00:32.369 Analizzeremo l'evoluzione dell'infrastruttura di Internet, 00:00:32.369 --> 00:00:33.969 provando a capire cosa causa i 00:00:33.969 --> 00:00:35.810 blackout su larga scala e quali 00:00:35.810 --> 00:00:37.570 possono essere le strategie per rendere 00:00:37.570 --> 00:00:39.250 il web più resiliente. 00:00:39.329 --> 00:00:40.784 Prima di passare alle notizie che 00:00:40.784 --> 00:00:42.784 più ci hanno colpito questa settimana, 00:00:42.784 --> 00:00:44.545 vi ricordo che potete seguirci su 00:00:44.545 --> 00:00:48.304 Instagram a @dentrolatecnologia, iscrivervi alla newsletter 00:00:48.304 --> 00:00:49.984 e ascoltare un nuovo episodio ogni 00:00:49.984 --> 00:00:51.824 sabato mattina, su Spotify, 00:00:51.824 --> 00:00:54.704 Apple Podcast, YouTube Music oppure direttamente 00:00:54.704 --> 00:00:55.824 sul nostro sito. 00:01:08.790 --> 00:01:10.754 La crisi dei semiconduttori e le 00:01:10.754 --> 00:01:13.394 recenti tensioni geopolitiche hanno spinto l'Europa 00:01:13.394 --> 00:01:15.795 a rivedere le priorità in questo settore, 00:01:15.795 --> 00:01:17.394 dove la sua dipendenza da Asia 00:01:17.394 --> 00:01:19.474 e Stati Uniti è in costante crescita. 00:01:19.555 --> 00:01:21.474 Per questo motivo, questa settimana è 00:01:21.474 --> 00:01:23.510 stato inaugurato un nuovo impianto che 00:01:23.510 --> 00:01:25.270 rappresenta un passo verso una maggiore 00:01:25.270 --> 00:01:28.549 autonomia tecnologica nella produzione di semiconduttori. 00:01:28.549 --> 00:01:30.950 La struttura in questione è NanoIC 00:01:30.950 --> 00:01:32.870 ed è stata costruita a Leuven, 00:01:32.870 --> 00:01:34.630 in Belgio, come linea pilota del 00:01:34.630 --> 00:01:35.349 Chips Act. 00:01:35.584 --> 00:01:37.506 Per questo progetto, l'Unione Europea ha 00:01:37.506 --> 00:01:39.745 stanziato 700 milioni di euro, 00:01:39.745 --> 00:01:41.625 ai quali si aggiungono ulteriori 700 00:01:41.625 --> 00:01:44.064 milioni dai governi nazionali e contributi 00:01:44.064 --> 00:01:46.305 da aziende private come ASML, 00:01:46.305 --> 00:01:48.459 per un totale di 2,5 miliardi 00:01:48.460 --> 00:01:49.260 di euro. 00:01:49.260 --> 00:01:51.420 NanoIC è inoltre il primo impianto 00:01:51.420 --> 00:01:54.140 europeo dedicato alla progettazione e produzione 00:01:54.140 --> 00:01:56.140 di chip oltre i due nanometri 00:01:56.140 --> 00:01:58.299 di dimensione, un obiettivo ampio che 00:01:58.299 --> 00:02:01.420 spazia dall'intelligenza artificiale ai veicoli autonomi, 00:02:01.545 --> 00:02:04.665 dalla sanità avanzata alle future reti 6G. 00:02:04.665 --> 00:02:07.864 Un'altra particolarità che caratterizza NanoIC è 00:02:07.864 --> 00:02:09.705 il principio di accesso aperto. 00:02:09.784 --> 00:02:11.784 Non solo grandi aziende potranno infatti 00:02:11.784 --> 00:02:14.344 utilizzare il laboratorio, ma anche start-up, 00:02:14.599 --> 00:02:16.439 piccole e medie imprese e istituti 00:02:16.439 --> 00:02:19.000 di ricerca, abbassando notevolmente le barriere 00:02:19.000 --> 00:02:21.400 all'ingresso per l'innovazione nel settore e 00:02:21.400 --> 00:02:24.200 rafforzando la sovranità tecnologica europea. 00:02:27.319 --> 00:02:29.254 Spesso non ne siamo consapevoli, 00:02:29.254 --> 00:02:30.694 ma proprio in questi mesi si 00:02:30.694 --> 00:02:32.534 sta muovendo qualcosa di concreto per 00:02:32.534 --> 00:02:34.614 evitare che i nostri oggetti finiscano 00:02:34.614 --> 00:02:37.415 in discarica al primo guasto fuori garanzia. 00:02:37.495 --> 00:02:39.414 Esiste infatti un progetto attivo fino 00:02:39.414 --> 00:02:42.180 a settembre 2026, chiamato REPper, 00:02:42.180 --> 00:02:44.580 che sta costruendo una rete transfrontaliera 00:02:44.580 --> 00:02:46.580 di servizi per la riparazione con 00:02:46.580 --> 00:02:48.739 l'intento di invertire la logica dell'usa 00:02:48.739 --> 00:02:49.460 e getta. 00:02:49.539 --> 00:02:51.219 Si tratta di un'iniziativa che sta 00:02:51.219 --> 00:02:53.539 implementando hub fisici e punti di 00:02:53.539 --> 00:02:56.019 contatto digitali per testare nuove modalità 00:02:56.019 --> 00:02:58.625 di assistenza e manutenzione su vasta scala. 00:02:58.625 --> 00:03:00.544 L'idea alla base è formare le 00:03:00.544 --> 00:03:02.784 piccole e medie imprese attraverso percorsi 00:03:02.784 --> 00:03:05.504 specifici chiamati "Factory", così da creare 00:03:05.504 --> 00:03:07.584 competenze e posti di lavoro legati 00:03:07.584 --> 00:03:08.704 all'economia circolare. 00:03:08.990 --> 00:03:10.750 Il progetto punta a modificare i 00:03:10.750 --> 00:03:13.949 comportamenti di noi consumatori attraverso incentivi 00:03:13.949 --> 00:03:15.949 e strumenti pratici che rendano l'atto 00:03:15.949 --> 00:03:18.270 di riparazione più semplice e immediato. 00:03:18.270 --> 00:03:20.030 Questo è un tassello fondamentale per 00:03:20.030 --> 00:03:22.564 dare alle persone la consapevolezza che 00:03:22.564 --> 00:03:26.165 molto spesso esistono alternative valide alla sostituzione. 00:03:29.284 --> 00:03:31.685 La NASA ha ufficialmente autorizzato l'utilizzo 00:03:31.685 --> 00:03:33.844 di smartphone personali a bordo delle 00:03:33.844 --> 00:03:35.044 prossime missioni spaziali. 00:03:35.289 --> 00:03:38.569 L'annuncio è stato confermato dall'amministratore dell'agenzia 00:03:38.569 --> 00:03:41.770 e riguarderà gli equipaggi della missione Crew-12, 00:03:41.770 --> 00:03:44.169 diretta alla Stazione Spaziale Internazionale, 00:03:44.169 --> 00:03:46.729 e soprattutto la missione Artemis II, 00:03:46.729 --> 00:03:48.969 la cui partenza verso l'orbita lunare 00:03:49.004 --> 00:03:50.444 è prevista per marzo. 00:03:50.525 --> 00:03:52.844 Questa decisione consentirà agli astronauti di 00:03:52.844 --> 00:03:54.925 catturare momenti personali per le proprie 00:03:54.925 --> 00:03:57.645 famiglie e condividere contenuti fotografici e 00:03:57.645 --> 00:04:00.044 video con il pubblico attraverso i social. 00:04:00.044 --> 00:04:02.310 In passato, gli astronauti disponevano già 00:04:02.310 --> 00:04:04.229 di tablet per uso personale e 00:04:04.229 --> 00:04:07.030 fotocamere professionali Nikon o action cam 00:04:07.030 --> 00:04:09.430 come GoPro, che utilizzavano per documentare 00:04:09.430 --> 00:04:10.870 le attività in orbita. 00:04:10.949 --> 00:04:12.949 Altri precedenti includono la presenza di 00:04:12.949 --> 00:04:15.509 due iPhone 4 sull'ultimo volo dello 00:04:15.509 --> 00:04:17.604 Shuttle nel 2011 e dell'impiego di 00:04:17.604 --> 00:04:19.125 un iPhone 12 da parte di 00:04:19.125 --> 00:04:21.285 un astronauta durante una missione privata 00:04:21.285 --> 00:04:23.285 SpaceX nel 2021. 00:04:23.365 --> 00:04:25.444 Tuttavia la nuova decisione rappresenta una 00:04:25.444 --> 00:04:27.604 svolta definitiva, perché a partire dalla 00:04:27.605 --> 00:04:30.600 Crew-12 potremmo finalmente seguire alcuni aspetti 00:04:30.600 --> 00:04:32.680 della vita in orbita mai visti prima. 00:04:53.615 --> 00:04:54.975 Quante volte ci è capitato, 00:04:54.975 --> 00:04:57.535 durante le nostre sessioni di navigazione online, 00:04:57.535 --> 00:04:59.069 di trovarci davanti a un sito 00:04:59.069 --> 00:05:01.310 web che semplicemente non carica o 00:05:01.310 --> 00:05:04.189 fornisce messaggi di errore spesso incomprensibili. 00:05:04.269 --> 00:05:05.709 Occasioni che, tra l'altro, 00:05:05.709 --> 00:05:08.990 di frequente, capitano nei momenti più inopportuni, 00:05:08.990 --> 00:05:10.909 come controllare documenti di lavoro, 00:05:10.909 --> 00:05:13.425 fare acquisti, compilare moduli o consultare 00:05:13.425 --> 00:05:14.865 informazioni importanti. 00:05:15.024 --> 00:05:17.024 E molte volte ci accorgiamo subito 00:05:17.024 --> 00:05:18.625 dopo che non era solo quello 00:05:18.625 --> 00:05:20.625 specifico sito a non funzionare, 00:05:20.625 --> 00:05:22.384 ma anche centinaia di altri servizi 00:05:22.384 --> 00:05:23.584 a livello globale. 00:05:23.664 --> 00:05:25.185 Tutti con il medesimo errore. 00:05:25.410 --> 00:05:27.089 La sensazione è quella che negli 00:05:27.089 --> 00:05:29.089 ultimi anni Internet sia diventato, 00:05:29.089 --> 00:05:31.009 tra virgolette, più "fragile", 00:05:31.009 --> 00:05:32.370 che si rompa più spesso. 00:05:32.449 --> 00:05:34.529 E i dati confermano almeno apparentemente 00:05:34.529 --> 00:05:35.650 questa teoria. 00:05:35.730 --> 00:05:38.050 Solo negli ultimi mesi del 2025, 00:05:38.050 --> 00:05:40.395 infatti, abbiamo assistito a una moltitudine 00:05:40.395 --> 00:05:41.835 di eventi di questo tipo. 00:05:41.835 --> 00:05:44.154 A ottobre, Amazon Web Services, 00:05:44.154 --> 00:05:45.835 il servizio cloud di Amazon che 00:05:45.835 --> 00:05:47.435 serve a centinaia di migliaia di 00:05:47.435 --> 00:05:50.074 servizi web, ha reso irraggiungibili milioni 00:05:50.074 --> 00:05:51.835 di siti per oltre 15 ore. 00:05:52.099 --> 00:05:53.699 Stessa sorte per Azure, 00:05:53.699 --> 00:05:55.539 l'infrastruttura cloud di Microsoft, 00:05:55.539 --> 00:05:57.379 che nello stesso periodo ha causato 00:05:57.379 --> 00:05:59.379 un disservizio di circa 9 ore. 00:05:59.379 --> 00:06:00.740 A novembre e dicembre è stato 00:06:00.740 --> 00:06:02.259 il turno di Cloudflare, 00:06:02.259 --> 00:06:04.180 altro servizio cloud che ha causato 00:06:04.180 --> 00:06:06.584 problemi rispettivamente per 5 ore e 00:06:06.584 --> 00:06:08.504 per 20 minuti, con impatti su 00:06:08.504 --> 00:06:10.425 servizi web di tutto il mondo. 00:06:10.504 --> 00:06:11.944 E i siti colpiti non sono 00:06:11.944 --> 00:06:14.425 certamente servizi minori o di nicchia, 00:06:14.425 --> 00:06:16.425 ma parliamo di applicazioni come Canva, 00:06:16.425 --> 00:06:19.620 ChatGPT o Zoom, e-commerce come Shopify, 00:06:19.620 --> 00:06:21.459 ma anche social come LinkedIn. 00:06:21.459 --> 00:06:23.540 Ma veramente Internet negli ultimi anni 00:06:23.540 --> 00:06:24.740 è diventato più fragile? 00:06:24.740 --> 00:06:27.139 O è solamente una sensazione condivisa? 00:06:27.139 --> 00:06:29.220 In questa puntata cercheremo di rispondere 00:06:29.220 --> 00:06:30.580 proprio a questa domanda, 00:06:30.740 --> 00:06:32.979 analizzando come Internet è cambiato negli 00:06:32.979 --> 00:06:35.775 ultimi decenni e approfondendo cosa succede quando, 00:06:35.775 --> 00:06:37.375 tra virgolette, "si rompe". 00:06:37.375 --> 00:06:39.295 Per comprendere il perché questi disservizi 00:06:39.295 --> 00:06:42.814 sembrano così frequenti, ma soprattutto così impattanti, 00:06:42.895 --> 00:06:45.535 dobbiamo innanzitutto analizzare come l'infrastruttura di 00:06:45.535 --> 00:06:47.295 rete è cambiata nel corso del tempo, 00:06:47.529 --> 00:06:49.769 aiutandoci con un esempio e paragonando 00:06:49.769 --> 00:06:51.610 Internet a una rete elettrica. 00:06:51.610 --> 00:06:53.850 Quando il concetto di web è nato, 00:06:53.850 --> 00:06:55.129 per i primi anni ogni sito 00:06:55.129 --> 00:06:57.370 web aveva la propria infrastruttura, 00:06:57.449 --> 00:06:59.370 fatta di server e sistemi di sicurezza. 00:06:59.774 --> 00:07:02.254 Se quindi un server smetteva di funzionare, 00:07:02.254 --> 00:07:05.214 il disservizio era limitato al singolo servizio, 00:07:05.375 --> 00:07:07.214 mentre il resto della rete continuava 00:07:07.214 --> 00:07:08.735 a funzionare correttamente. 00:07:08.894 --> 00:07:10.495 Nel nostro esempio è come se 00:07:10.495 --> 00:07:12.414 in una città ogni casa avesse 00:07:12.414 --> 00:07:13.935 il proprio generatore di corrente. 00:07:14.250 --> 00:07:15.449 Con l'avvento del cloud, 00:07:15.449 --> 00:07:18.330 però, questo concetto è profondamente cambiato. 00:07:18.410 --> 00:07:20.410 Aziende come Amazon, Microsoft, 00:07:20.410 --> 00:07:23.449 Google, Oracle, IBM o Cloudflare, 00:07:23.449 --> 00:07:25.129 forti anche dei grossi investimenti in 00:07:25.129 --> 00:07:27.324 datacenter e sicurezza, hanno iniziato a 00:07:27.324 --> 00:07:29.485 mettere a disposizione le proprie infrastrutture 00:07:29.485 --> 00:07:32.045 a chiunque, di fatto affittandone potenza 00:07:32.045 --> 00:07:32.685 di calcolo. 00:07:32.685 --> 00:07:34.764 E i vantaggi sono indubbiamente enormi 00:07:34.764 --> 00:07:36.444 e li abbiamo analizzati più volte 00:07:36.444 --> 00:07:37.725 in diverse puntate. 00:07:37.805 --> 00:07:39.819 Invece di acquistare un server fisico, 00:07:39.819 --> 00:07:42.300 infatti, un'azienda può affidarsi al cloud 00:07:42.300 --> 00:07:45.180 e ottenere la potenza computazionale necessaria 00:07:45.180 --> 00:07:47.019 a far girare il proprio servizio, 00:07:47.019 --> 00:07:49.339 pagando in base al consumo delle risorse. 00:07:49.419 --> 00:07:51.419 Più il sito web viene visitato, 00:07:51.419 --> 00:07:53.675 più pago, senza tra l'altro dovermi 00:07:53.675 --> 00:07:55.435 preoccupare se il server regga o 00:07:55.435 --> 00:07:57.514 meno un aumento improvviso degli utenti. 00:07:57.595 --> 00:07:59.915 Oltre alla scalabilità, i provider cloud 00:07:59.915 --> 00:08:01.595 si occupano anche di sicurezza e 00:08:01.595 --> 00:08:04.394 manutenzione dell'infrastruttura, forti non solo della 00:08:04.394 --> 00:08:06.875 disponibilità economica, ma anche di competenze 00:08:06.875 --> 00:08:09.089 tecniche che spesso in una piccola 00:08:09.089 --> 00:08:10.129 azienda mancano. 00:08:10.129 --> 00:08:12.209 Ecco quindi che nella nostra analogia, 00:08:12.209 --> 00:08:13.649 passiamo da una città dove ogni 00:08:13.649 --> 00:08:15.490 casa ha il proprio generatore elettrico, 00:08:15.490 --> 00:08:17.170 ad una dove esiste un grande 00:08:17.170 --> 00:08:20.050 generatore centrale che serve tutte le case: 00:08:20.050 --> 00:08:21.810 più sicuro, più affidabile, 00:08:21.810 --> 00:08:22.930 economico ed efficiente. 00:08:23.345 --> 00:08:25.025 Ma cosa succede se questo unico 00:08:25.025 --> 00:08:26.944 generatore smette di funzionare? 00:08:27.025 --> 00:08:28.865 Ecco quindi che arriviamo alle situazioni 00:08:28.865 --> 00:08:31.105 che abbiamo vissuto negli ultimi mesi. 00:08:31.185 --> 00:08:32.465 Non uno, non due, 00:08:32.465 --> 00:08:34.465 ma centinaia di migliaia di servizi 00:08:34.465 --> 00:08:37.345 web smettono di rispondere perché dipendenti 00:08:37.345 --> 00:08:38.465 da un unico provider. 00:08:38.610 --> 00:08:39.649 Per fare un esempio, 00:08:39.649 --> 00:08:42.209 Cloudflare, che fornisce servizi di protezione 00:08:42.210 --> 00:08:44.370 d'attacchi e sistemi per ottimizzare le 00:08:44.370 --> 00:08:46.529 prestazioni dei siti, gestisce circa il 00:08:46.529 --> 00:08:48.929 20% del traffico web mondiale. 00:08:48.929 --> 00:08:50.850 Ma com'è possibile che aziende così 00:08:50.850 --> 00:08:53.089 strutturate e sofisticate vadano in tilt 00:08:53.089 --> 00:08:53.889 così facilmente? 00:08:54.324 --> 00:08:56.245 Anche in questo caso abbiamo dedicato 00:08:56.245 --> 00:08:58.804 una puntata proprio ai bug informatici, 00:08:58.884 --> 00:08:59.764 dove è emerso che, 00:08:59.764 --> 00:09:02.404 nonostante gli sforzi, soprattutto in sistemi 00:09:02.404 --> 00:09:03.924 così complessi come quelli di un 00:09:03.924 --> 00:09:06.565 provider cloud, è impossibile prevedere tutti 00:09:06.565 --> 00:09:07.524 i possibili scenari. 00:09:07.740 --> 00:09:09.580 Può quindi capitare che durante una 00:09:09.580 --> 00:09:11.179 normale attività di routine, 00:09:11.179 --> 00:09:13.740 come l'aggiornamento o l'ottimizzazione dei sistemi, 00:09:13.740 --> 00:09:15.740 modifiche nei file di configurazione o 00:09:15.740 --> 00:09:18.779 manutenzione delle infrastrutture, qualcosa vada storto, 00:09:18.779 --> 00:09:20.700 attivando una serie di eventi a 00:09:20.700 --> 00:09:23.164 catena che portano a un disservizio globale. 00:09:23.245 --> 00:09:24.924 Analizziamo quindi i problemi che sono 00:09:24.924 --> 00:09:26.605 capitati negli ultimi mesi. 00:09:26.605 --> 00:09:28.924 Cloudflare, durante una modifica di routine 00:09:28.924 --> 00:09:31.004 a una configurazione, ha prodotto un 00:09:31.004 --> 00:09:32.605 file più grande del previsto e 00:09:32.605 --> 00:09:34.524 che il sistema non riusciva a gestire, 00:09:34.839 --> 00:09:36.519 causando un crash di tutti i 00:09:36.519 --> 00:09:37.799 servizi di proxy. 00:09:37.799 --> 00:09:39.799 Un errore che nessuno aveva previsto, 00:09:39.879 --> 00:09:42.600 tantomeno i sistemi di protezione automatica che, 00:09:42.600 --> 00:09:46.360 tecnicamente, consideravano la configurazione come valida. 00:09:46.360 --> 00:09:48.440 Per quanto riguarda Amazon Web Services, 00:09:48.440 --> 00:09:50.625 invece, un mal funzionamento nella gestione 00:09:50.625 --> 00:09:52.544 dei DNS per il suo servizio 00:09:52.544 --> 00:09:54.625 di database ha causato un effetto 00:09:54.625 --> 00:09:56.304 domino che ha interrotto i servizi 00:09:56.304 --> 00:09:57.665 di tutto il suo data center 00:09:57.665 --> 00:09:59.904 in Virginia, uno dei più popolosi. 00:09:59.985 --> 00:10:01.585 Un problema simile è capitato anche 00:10:01.585 --> 00:10:03.024 a Microsoft con Azure, 00:10:03.024 --> 00:10:04.384 causando, sempre a ottobre, 00:10:04.529 --> 00:10:06.050 ulteriori interruzioni. 00:10:06.129 --> 00:10:07.889 I problemi, poi, possono non essere 00:10:07.889 --> 00:10:09.810 solo software, ma anche hardware. 00:10:09.810 --> 00:10:11.570 Pensiamo a server che si rompono, 00:10:11.570 --> 00:10:14.930 linee internet bloccate, blackout energetici prolungati. 00:10:14.930 --> 00:10:15.730 E non solo. 00:10:15.730 --> 00:10:17.730 Cosa succede se vengono meno sistemi 00:10:17.730 --> 00:10:19.485 di protezione a danni fisici? 00:10:19.485 --> 00:10:20.926 Un esempio emblematico è quanto è 00:10:20.926 --> 00:10:23.324 successo ad OVH nel 2021, 00:10:23.324 --> 00:10:25.565 principale provider cloud europeo, 00:10:25.565 --> 00:10:27.324 quando il suo data center principale 00:10:27.324 --> 00:10:29.964 di Strasburgo è stato completamente distrutto 00:10:29.964 --> 00:10:31.964 da un incendio, cancellando con sé 00:10:31.964 --> 00:10:33.565 i dati di migliaia di clienti. 00:10:33.860 --> 00:10:35.860 Eventi quasi più unici che rari, 00:10:35.860 --> 00:10:37.140 considerando tutte le norme e i 00:10:37.140 --> 00:10:38.899 sistemi di sicurezza moderni, 00:10:38.899 --> 00:10:40.100 ma che - come abbiamo visto 00:10:40.100 --> 00:10:41.620 - non sono mai da escludere. 00:10:41.620 --> 00:10:43.059 Con la differenza, però, 00:10:43.059 --> 00:10:44.419 che mentre la maggior parte di 00:10:44.419 --> 00:10:46.019 questi provider ha dei sistemi di 00:10:46.019 --> 00:10:47.940 backup distribuiti in più zone del mondo, 00:10:48.125 --> 00:10:50.204 una realtà più piccola difficilmente può 00:10:50.204 --> 00:10:52.524 strutturarsi allo stesso modo per garantire 00:10:52.524 --> 00:10:54.605 una corretta protezione dei dati. 00:10:54.605 --> 00:10:56.684 Ma è possibile evitare questi problemi? 00:10:56.684 --> 00:10:58.125 Nella maggior parte dei casi la 00:10:58.125 --> 00:10:59.164 risposta è sì. 00:10:59.164 --> 00:11:01.004 Questi provider cloud, infatti, 00:11:01.004 --> 00:11:02.204 come abbiamo appena anticipato, 00:11:02.399 --> 00:11:04.240 non possiedono uno ma decine di 00:11:04.240 --> 00:11:05.680 data center sparsi in tutto il 00:11:05.680 --> 00:11:07.440 mondo e tra loro isolati. 00:11:07.519 --> 00:11:09.759 Ogni data center prende solitamente il 00:11:09.759 --> 00:11:11.040 nome della regione. 00:11:11.040 --> 00:11:12.639 Le regioni permettono da una parte 00:11:12.639 --> 00:11:14.240 di offrire i propri servizi in 00:11:14.240 --> 00:11:16.399 luoghi geograficamente più vicini agli utenti, 00:11:16.684 --> 00:11:19.084 garantendo tempi di risposta più rapidi. 00:11:19.084 --> 00:11:22.205 Dall'altra, l'isolamento garantisce una maggior resilienza. 00:11:22.284 --> 00:11:23.644 Se una regione ha problemi, 00:11:23.644 --> 00:11:25.804 il traffico può essere reindirizzato verso 00:11:25.804 --> 00:11:28.605 altre regioni funzionanti, in modo automatico 00:11:28.605 --> 00:11:31.164 o quasi, garantendo la continuità dei servizi. 00:11:31.460 --> 00:11:32.980 Tant'è che nell'esempio di Amazon, 00:11:32.980 --> 00:11:34.980 il problema si è verificato solamente 00:11:34.980 --> 00:11:36.820 nella regione della Virginia, 00:11:36.820 --> 00:11:39.299 mentre non ha colpito altri data center. 00:11:39.299 --> 00:11:40.740 Per questo motivo, spesso, 00:11:40.740 --> 00:11:42.899 per un'azienda non dovrebbe bastare affidarsi 00:11:42.899 --> 00:11:44.179 a un unico provider o a 00:11:44.179 --> 00:11:46.495 un'unica regione, ma dovrebbe strutturare la 00:11:46.495 --> 00:11:48.654 propria infrastruttura per essere quanto più 00:11:48.654 --> 00:11:50.095 resiliente possibile. 00:11:50.254 --> 00:11:51.855 E a questo proposito sono nati 00:11:51.855 --> 00:11:54.654 degli standard e delle certificazioni proprio 00:11:54.654 --> 00:11:56.575 per aiutare le aziende a perseguire 00:11:56.575 --> 00:11:57.215 questo obiettivo. 00:11:57.669 --> 00:11:59.269 I più importanti sono gli standard 00:11:59.269 --> 00:12:04.309 ISO 27001, 27017 e 27018. 00:12:04.309 --> 00:12:06.230 Questi standard aiutano le aziende a 00:12:06.230 --> 00:12:07.590 definire quali sono i rischi di 00:12:07.590 --> 00:12:11.190 un'interruzione di servizio, implementare controlli appropriati, 00:12:11.190 --> 00:12:12.870 testare e migliorare questi controlli, 00:12:13.034 --> 00:12:14.794 ma anche definire e redigere delle 00:12:14.794 --> 00:12:16.235 regole da seguire in caso di 00:12:16.235 --> 00:12:18.475 disastro e dei piani di ripristino, 00:12:18.475 --> 00:12:20.475 stabilendo tempi e modalità. 00:12:20.475 --> 00:12:22.554 E le certificazioni prevedono che questi 00:12:22.554 --> 00:12:24.634 piani non solo vengano definiti, 00:12:24.634 --> 00:12:26.954 ma vengano anche regolarmente testati per 00:12:26.954 --> 00:12:28.475 garantire che in caso reale di 00:12:28.475 --> 00:12:31.110 disservizio sia possibile tornare online nel 00:12:31.110 --> 00:12:32.389 più breve tempo possibile. 00:12:32.470 --> 00:12:34.629 E la modalità solitamente prevede di 00:12:34.629 --> 00:12:36.870 avere dei server di backup costantemente 00:12:36.870 --> 00:12:39.350 allineati al server principale in termini 00:12:39.350 --> 00:12:40.790 di configurazioni e dati, 00:12:40.965 --> 00:12:43.045 ma in luoghi completamente diversi, 00:12:43.045 --> 00:12:45.365 che possono essere regioni alternative dello 00:12:45.365 --> 00:12:46.965 stesso provider o, ancora meglio, 00:12:46.965 --> 00:12:48.884 provider cloud differenti. 00:12:49.045 --> 00:12:50.404 Proprio a questo proposito, 00:12:50.404 --> 00:12:52.245 negli ultimi mesi, Amazon, 00:12:52.245 --> 00:12:54.639 Google e Microsoft stanno lavorando per 00:12:54.639 --> 00:12:57.679 rendere lo scenario "multi-cloud" più semplice 00:12:57.679 --> 00:12:59.920 da gestire per gli addetti ai lavori. 00:12:59.920 --> 00:13:02.160 Tenere attivi due servizi cloud differenti, 00:13:02.160 --> 00:13:04.320 infatti, non è affatto semplice e 00:13:04.320 --> 00:13:06.720 servono figure tecniche molto competenti. 00:13:06.800 --> 00:13:09.125 Oltretutto, spesso i provider cloud cercano 00:13:09.125 --> 00:13:11.204 di fornire quante più soluzioni possibili, 00:13:11.204 --> 00:13:12.964 per coprire tutte le esigenze di 00:13:12.964 --> 00:13:15.284 un'azienda e costringerla a utilizzare i 00:13:15.284 --> 00:13:17.684 servizi cloud a 360°. 00:13:17.764 --> 00:13:19.764 Questa crescente preoccupazione di andare verso 00:13:19.764 --> 00:13:21.204 un internet più fragile, 00:13:21.204 --> 00:13:23.669 tuttavia, ha spinto queste aziende a collaborare, 00:13:23.669 --> 00:13:26.230 per facilitare l'integrazione di servizi cloud 00:13:26.230 --> 00:13:28.789 da provider diversi e semplificare ai 00:13:28.789 --> 00:13:30.870 propri clienti la creazione di infrastrutture 00:13:30.870 --> 00:13:31.990 più resilienti. 00:13:31.990 --> 00:13:34.149 Ma se il cloud è così problematico, 00:13:34.149 --> 00:13:35.669 perché allora non torniamo allo scenario 00:13:35.669 --> 00:13:36.789 in cui internet è nato, 00:13:36.914 --> 00:13:38.914 dove ognuno aveva un proprio server? 00:13:38.914 --> 00:13:39.794 La verità è che, 00:13:39.794 --> 00:13:41.074 paragonando pro e contro, 00:13:41.074 --> 00:13:43.394 l'ago della bilancia pende nettamente verso 00:13:43.394 --> 00:13:44.195 i benefici. 00:13:44.195 --> 00:13:45.714 Come abbiamo detto all'inizio, 00:13:45.714 --> 00:13:47.794 avere un proprio server significa garantire 00:13:47.794 --> 00:13:49.960 anche la manutenzione, gli aggiornamenti, 00:13:49.960 --> 00:13:52.519 l'adeguamento infrastrutturale e la sicurezza, 00:13:52.519 --> 00:13:54.759 temi che richiedono grandi capacità economiche 00:13:54.759 --> 00:13:56.200 e competenze tecniche. 00:13:56.200 --> 00:13:58.440 Il cloud, invece, garantisce di base 00:13:58.440 --> 00:14:01.159 questi aspetti, ed è forse controintuitivamente 00:14:01.160 --> 00:14:02.440 molto più affidabile. 00:14:02.519 --> 00:14:04.324 La differenza è che quando Amazon 00:14:04.324 --> 00:14:07.444 Web Services o Google smettono di funzionare, 00:14:07.444 --> 00:14:09.605 le ripercussioni si estendono a catena 00:14:09.605 --> 00:14:12.004 su centinaia di migliaia di altri servizi, 00:14:12.004 --> 00:14:14.084 e anche l'attenzione mediatica che ne 00:14:14.084 --> 00:14:15.204 consegue è altissima. 00:14:15.600 --> 00:14:18.159 Dall'altro lato, invece, quanti servizi indipendenti 00:14:18.159 --> 00:14:20.399 smettono quotidianamente di funzionare, 00:14:20.399 --> 00:14:21.679 ma non fanno notizia perché, 00:14:21.679 --> 00:14:23.839 magari, usati da poche centinaia o 00:14:23.839 --> 00:14:24.879 migliaia di persone? 00:14:24.879 --> 00:14:27.279