WEBVTT

00:00.090 --> 00:00.923
Istruttore: Al

00:00.923 --> 00:02.880
giorno d'oggi, il cloud computing si

00:02.880 --> 00:05.580
trova ovunque, e questo perché l'uso del cloud computing

00:05.580 --> 00:07.290
offre molti vantaggi.

00:07.290 --> 00:09.510
Ed è su questo che ci concentreremo in questa lezione,

00:09.510 --> 00:10.343
quando inizieremo

00:10.343 --> 00:12.930
a parlare delle diverse caratteristiche del cloud.

00:12.930 --> 00:15.160
Quando parliamo di cloud computing, ci sono

00:15.160 --> 00:17.670
una serie di vantaggi o caratteristiche che vediamo

00:17.670 --> 00:19.680
quando scegliamo di usare il cloud.

00:19.680 --> 00:23.460
Questi includono alta disponibilità, scalabilità, elasticità,

00:23.460 --> 00:24.750
utilizzo misurato, risorse

00:24.750 --> 00:27.540
condivise e sincronizzazione dei file.

00:27.540 --> 00:29.040
Diamo un'occhiata a questi.

00:29.040 --> 00:31.350
In primo luogo, abbiamo l'alta disponibilità.

00:31.350 --> 00:32.749
L'alta disponibilità si riferisce

00:32.749 --> 00:34.410
al fatto che i servizi hanno tempi

00:34.410 --> 00:37.800
di inattività molto ridotti quando si utilizza il cloud.

00:37.800 --> 00:39.690
Questo perché la maggior parte dei servizi costruiti

00:39.690 --> 00:41.670
sul cloud sono costruiti per essere altamente affidabili

00:41.670 --> 00:43.200
e molto tolleranti agli errori.

00:43.200 --> 00:45.900
Questo significa che possiamo garantire un alto livello di disponibilità.

00:45.900 --> 00:47.610
Quando si parla di disponibilità,

00:47.610 --> 00:50.160
di solito la si misura in termini di percentuale

00:50.160 --> 00:53.760
di uptime rispetto al downtime.

00:53.760 --> 00:55.920
Ad esempio, il gold standard all'interno

00:55.920 --> 00:58.860
delle reti è noto come cinque nove.

00:58.860 --> 01:02.970
Cinque nove significa 99. 999% di uptime o disponibilità

01:02.970 --> 01:06.390
come sperimentato dai vostri utenti finali.

01:06.390 --> 01:09.030
Ciò significa che ogni anno possiamo avere

01:09.030 --> 01:11.980
solo cinque minuti e 15 secondi di inattività.

01:11.980 --> 01:15.090
Esatto, solo cinque minuti e 15 secondi

01:15.090 --> 01:18.570
in tutti i 365 giorni dell'anno.

01:18.570 --> 01:20.400
Per farlo, è necessario disporre di

01:20.400 --> 01:23.430
sistemi altamente affidabili e altamente disponibili.

01:23.430 --> 01:25.330
Quindi, se avete un sito web,

01:25.330 --> 01:29.123
avrete almeno due server web che lo ospitano.

01:29.123 --> 01:30.300
In questo modo, se uno dei

01:30.300 --> 01:32.160
due si guasta, l'altro continua a sostenere

01:32.160 --> 01:35.730
il carico e l'utente finale non subisce alcun downtime.

01:35.730 --> 01:36.690
È a questo che ci riferiamo

01:36.690 --> 01:38.640
quando parliamo di alta disponibilità.

01:38.640 --> 01:42.210
Ad esempio, con il mio sito web, diontraining. com, abbiamo una configurazione

01:42.210 --> 01:44.760
ad alta disponibilità che è stata creata

01:44.760 --> 01:47.280
utilizzando i servizi cloud.

01:47.280 --> 01:50.070
Quindi, a seconda della vostra provenienza nel mondo, raggiungerete

01:50.070 --> 01:51.060
uno dei nostri server multipli

01:51.060 --> 01:53.160
situati in tutto il mondo e più vicini a voi per ottenere

01:53.160 --> 01:55.680
un'esperienza migliore.

01:55.680 --> 01:57.627
Ora, se il vostro server non funziona per qualche

01:57.627 --> 02:00.300
motivo, verrete automaticamente reindirizzati verso un altro che

02:00.300 --> 02:02.490
si trova un po' più lontano da voi, ma è ancora attivo.

02:02.490 --> 02:04.980
In questo modo si ottiene comunque il servizio desiderato,

02:04.980 --> 02:08.460
e questo è un modo per garantire un'elevata disponibilità.

02:08.460 --> 02:10.590
La seconda caratteristica del cloud di

02:10.590 --> 02:12.480
cui parleremo è la scalabilità.

02:12.480 --> 02:15.150
Quando parliamo di scalabilità, ci riferiamo

02:15.150 --> 02:17.370
al fatto che possiamo aumentare il

02:17.370 --> 02:19.080
numero di persone o il numero

02:19.080 --> 02:23.220
di oggetti nel nostro sistema a un tasso lineare o meno.

02:23.220 --> 02:24.053
Con questo intendo

02:24.053 --> 02:26.850
dire che, per esempio, ho 100 utenti che utilizzano il mio

02:26.850 --> 02:28.620
sistema e mi costa 10 dollari.

02:28.620 --> 02:31.282
Beh, se metto 200 utenti sul mio sistema, dovrebbe

02:31.282 --> 02:35.010
costarmi 20 dollari o meno, e si tratterebbe di una scala lineare.

02:35.010 --> 02:37.860
Ora, se passassi da 100 utenti a 200 utenti e il prezzo

02:37.860 --> 02:40.500
passasse da 10 a 100 dollari, si tratterebbe di una

02:40.500 --> 02:42.240
scala esponenziale, e noi non vogliamo

02:42.240 --> 02:43.380
questo.

02:43.380 --> 02:45.180
Quindi, mentre costruiamo i nostri sistemi

02:45.180 --> 02:47.070
cloud, siamo sempre alla ricerca della scalabilità,

02:47.070 --> 02:49.860
e questo significa che anche se oggi abbiamo solo 10 utenti, domani potremmo

02:49.860 --> 02:51.090
averne 100.

02:51.090 --> 02:52.590
Il giorno dopo ne abbiamo 1.000,

02:52.590 --> 02:55.260
il giorno dopo ancora 10.000 e così via.

02:55.260 --> 02:56.093
Se si considerano

02:56.093 --> 02:58.800
alcune grandi aziende come Facebook, Google, LinkedIn

02:58.800 --> 03:02.160
e UNI, hanno milioni di utenti finali che accedono alle loro piattaforme

03:02.160 --> 03:04.710
ogni singolo giorno e sono in grado di scalare grazie

03:04.710 --> 03:07.422
alla scalabilità dei servizi cloud, perché non devo

03:07.422 --> 03:10.710
comprare un altro server da 10.000 dollari da collocare nel mio

03:10.710 --> 03:16.650
data center locale, perché invece posso usare quello di Amazon e utilizzare una parte della loro capacità quando

03:16.650 --> 03:19.560
ne ho bisogno.

03:19.560 --> 03:20.970
Per quanto riguarda la scalabilità,

03:20.970 --> 03:22.650
ci sono due modi per scalare.

03:22.650 --> 03:25.560
Uno è quello di scalare verso l'alto, noto come scala verticale.

03:25.560 --> 03:27.090
Questo avviene aggiungendo più

03:27.090 --> 03:29.010
risorse a un particolare server o nodo.

03:29.010 --> 03:31.020
Ad esempio, se si utilizza un server

03:31.020 --> 03:32.970
basato sul cloud con due CPU virtuali,

03:32.970 --> 03:35.730
è possibile aumentarle a quattro.

03:35.730 --> 03:37.170
Questa è l'idea di scalare.

03:37.170 --> 03:38.610
Si aggiungono più risorse, che

03:38.610 --> 03:41.040
si tratti di più processori, più RAM, più memoria,

03:41.040 --> 03:43.110
più larghezza di banda o cose del genere.

03:43.110 --> 03:45.120
D'altra parte, si può anche scalare verso l'esterno,

03:45.120 --> 03:47.100
il che è noto come scalatura orizzontale.

03:47.100 --> 03:49.440
In questo caso si utilizzano ancora macchine più

03:49.440 --> 03:50.280
piccole, ma più macchine

03:50.280 --> 03:53.400
che lavorano in tandem dietro un bilanciatore di carico.

03:53.400 --> 03:55.080
Quindi, invece di avere un server che

03:55.080 --> 03:57.316
gestisce tutto il carico e di scalare verso l'alto

03:57.316 --> 04:00.180
aumentando le CPU e la memoria, potete invece scalare verso

04:00.180 --> 04:02.520
l'esterno e passare da un server a due server o da due

04:02.520 --> 04:05.970
server a quattro, o da quattro a otto, e continuare a muovervi verso l'esterno,

04:05.970 --> 04:07.170
aggiungendo altri server

04:07.170 --> 04:09.840
dietro il vostro bilanciatore di carico con cui potete gestire

04:09.840 --> 04:11.940
altro traffico.

04:11.940 --> 04:13.710
Questo ci porta alla terza area,

04:13.710 --> 04:15.864
nota come elasticità rapida.

04:15.864 --> 04:18.960
Quando parliamo di elasticità rapida, ci riferiamo al fatto

04:18.960 --> 04:20.160
che possiamo aumentare

04:20.160 --> 04:22.731
o diminuire le dimensioni molto rapidamente.

04:22.731 --> 04:25.454
Questo avviene perché utilizziamo l'automazione e

04:25.454 --> 04:28.110
l'orchestrazione con molte macchine virtuali su

04:28.110 --> 04:29.970
questi server fisici di proprietà di

04:29.970 --> 04:32.220
Amazon, Google, Microsoft e altre aziende

04:32.220 --> 04:35.040
che ci permettono di utilizzare porzioni o tutti i loro

04:35.040 --> 04:38.104
servizi in base alle nostre esigenze, su richiesta.

04:38.104 --> 04:41.040
E questo ci dà una rapida elasticità.

04:41.040 --> 04:43.200
Quando si parla di elasticità rapida

04:43.200 --> 04:46.290
o di elasticità in generale, si pensa alla capacità del

04:46.290 --> 04:48.785
sistema di gestire le variazioni della domanda

04:48.785 --> 04:50.370
in tempo reale.

04:50.370 --> 04:51.410
Torniamo quindi all'esempio

04:51.410 --> 04:54.780
dell'utilizzo del mio sito web, diontraining. com.

04:54.780 --> 04:56.490
Se in questo momento controllo

04:56.490 --> 04:58.770
il mio sito web e ho 1.000 studenti connessi,

04:58.770 --> 05:00.330
e tra cinque minuti ne ho 10.000,

05:00.330 --> 05:03.774
i miei sistemi sono progettati per attivare risorse cloud

05:03.774 --> 05:07.230
aggiuntive e spingere parte del carico dei nuovi utenti su

05:07.230 --> 05:10.230
questi servizi aggiuntivi.

05:10.230 --> 05:12.810
Questa è l'idea di elasticità rapida.

05:12.810 --> 05:14.580
In genere, quando si lavora nel cloud,

05:14.580 --> 05:16.470
se i sistemi sono stati progettati correttamente,

05:16.470 --> 05:18.949
si ha la possibilità di avere un'elasticità e di scalare

05:18.949 --> 05:21.150
molto velocemente, e poi, allo stesso modo, quando

05:21.150 --> 05:24.750
la domanda diminuisce, ci si può liberare rapidamente di quei server in più

05:24.750 --> 05:27.120
e riportarli giù.

05:27.120 --> 05:28.680
Il motivo per cui lo si vuole fare è che

05:28.680 --> 05:31.166
tutti quei server extra vi costeranno di più e se non avete

05:31.166 --> 05:33.390
abbastanza utenti per averli, non volete pagare

05:33.390 --> 05:34.500
per questo, quindi li rilascerete

05:34.500 --> 05:37.410
e li restituirete al vostro fornitore di servizi in modo che possa

05:37.410 --> 05:40.140
affittare il servizio a qualcun altro.

05:40.140 --> 05:42.750
Se invece si utilizza un modello on premise,

05:42.750 --> 05:45.000
diciamo che oggi ho 1.000 studenti.

05:45.000 --> 05:48.150
Beh, per 1.000 studenti potrei aver bisogno di tre server web.

05:48.150 --> 05:49.830
Ma se arrivo a 10.000 studenti,

05:49.830 --> 05:51.956
avrò bisogno di altri 15 server web.

05:51.956 --> 05:55.080
Per farlo, dovrei acquistare altri 15 server.

05:55.080 --> 05:55.950
Dovrei metterli in un rack.

05:55.950 --> 05:57.270
Dovrei installare tutto il software

05:57.270 --> 05:58.440
e configurarlo.

05:58.440 --> 05:59.580
Tutto questo richiede tempo,

05:59.580 --> 06:02.222
e quindi non è molto rapido in termini di elasticità per noi

06:02.222 --> 06:04.980
essere in grado di scalare per soddisfare la domanda.

06:04.980 --> 06:07.860
Se avete un modello di business a crescita molto lenta, va bene.

06:07.860 --> 06:10.200
Ma se avete a che fare con qualcosa ad alta velocità o con

06:10.200 --> 06:12.171
una di queste moderne piattaforme di social

06:12.171 --> 06:14.370
media, e qualcosa che avete fatto è diventato virale,

06:14.370 --> 06:16.920
e tutti vanno sul vostro sito web e iniziano a sommergervi,

06:16.920 --> 06:19.050
se non avete la capacità di scalare rapidamente,

06:19.050 --> 06:19.950
perderete la possibilità

06:19.950 --> 06:22.052
di catturare il traffico che proviene da quell'incidente

06:22.052 --> 06:23.880
virale.

06:23.880 --> 06:25.620
Quindi si vuole essere in grado di costruire

06:25.620 --> 06:27.360
le proprie cose in modo rapido ed elastico,

06:27.360 --> 06:29.700
e questo è ciò che il cloud ci permette di fare.

06:29.700 --> 06:32.910
La quarta cosa che abbiamo è nota come utilizzo misurato.

06:32.910 --> 06:33.810
Questo si riallaccia alla

06:33.810 --> 06:36.510
discussione sull'elasticità rapida che abbiamo appena fatto.

06:36.510 --> 06:38.686
Quando si parla di utilizzo a consumo,

06:38.686 --> 06:40.170
si intende il fatto che

06:40.170 --> 06:43.800
si paga un servizio in base all'utilizzo.

06:43.800 --> 06:46.650
Quindi, quando utilizziamo un servizio a pagamento come un database,

06:46.650 --> 06:47.730
possono addebitarci un costo

06:47.730 --> 06:49.170
in base al numero di utenti, al numero

06:49.170 --> 06:52.050
di connessioni o al numero di dati memorizzati.

06:52.050 --> 06:53.910
In sostanza, ci viene addebitato il

06:53.910 --> 06:56.910
costo in base all'effettivo utilizzo del servizio.

06:56.910 --> 06:59.262
E lo facciamo al secondo,

06:59.262 --> 07:03.480
al minuto, all'ora, al giorno o al mese.

07:03.480 --> 07:05.211
Ad esempio, utilizzo AWS Lambda

07:05.211 --> 07:08.153
per molte delle mie automazioni e funzioni di backend

07:08.153 --> 07:11.010
e mi addebita un costo in base all'utilizzo.

07:11.010 --> 07:13.290
Ora per ogni milione di richieste che faccio, mi

07:13.290 --> 07:14.760
fanno pagare 20 centesimi.

07:14.760 --> 07:16.200
Per me è un modo molto efficiente

07:16.200 --> 07:17.880
di realizzare le mie automazioni,

07:17.880 --> 07:20.092
perché è una cosa molto, molto economica.

07:20.092 --> 07:22.620
Posso avere milioni e milioni di richieste e mi

07:22.620 --> 07:24.960
costerebbe solo un paio di dollari, e questa

07:24.960 --> 07:27.090
è l'idea di un servizio a pagamento.

07:27.090 --> 07:28.334
Un'altra cosa che si nota

07:28.334 --> 07:30.120
è che a volte si fa una distinzione

07:30.120 --> 07:33.000
tra servizio con contatore e servizio misurato.

07:33.000 --> 07:35.640
Ora, quando si parla di servizi a pagamento o a misura,

07:35.640 --> 07:37.470
si parla in realtà della stessa cosa:

07:37.470 --> 07:38.700
la nostra capacità di pagare

07:38.700 --> 07:41.160
qualcosa in base al consumo.

07:41.160 --> 07:42.840
Ma qui c'è una differenza.

07:42.840 --> 07:44.850
Quando si utilizza un servizio

07:44.850 --> 07:46.073
a pagamento, si paga

07:46.073 --> 07:49.380
in base all'utilizzo effettivo di ciò che si fa.

07:49.380 --> 07:50.213
Se pensate alla bolletta

07:50.213 --> 07:52.500
dell'acqua o a quella dell'elettricità a casa vostra.

07:52.500 --> 07:53.880
Se questo mese avete aperto il tubo

07:53.880 --> 07:55.650
dell'acqua e avete riempito la piscina,

07:55.650 --> 07:56.730
pagherete molto di più la

07:56.730 --> 07:59.670
bolletta dell'acqua perché ne avete usata molta di più.

07:59.670 --> 08:02.314
Al contrario, quando si ha a che fare con un servizio misurato,

08:02.314 --> 08:04.950
questo è più simile al piano del telefono cellulare.

08:04.950 --> 08:08.160
Nella maggior parte dei luoghi, si paga un canone mensile per una certa

08:08.160 --> 08:10.740
quantità di utilizzo del telefono cellulare, che si tratti

08:10.740 --> 08:14.100
del numero di SMS, minuti o dati che si possono consumare.

08:14.100 --> 08:15.390
Una volta raggiunto il limite,

08:15.390 --> 08:17.790
il servizio viene interrotto e non viene più erogato fino

08:17.790 --> 08:19.440
a quando non si paga di nuovo.

08:19.440 --> 08:21.300
Quindi, quando pensate a un servizio misurato,

08:21.300 --> 08:23.310
pensate al fatto che state pagando una certa

08:23.310 --> 08:25.920
quantità in anticipo, e che lo usiate o meno, avete già pagato

08:25.920 --> 08:27.660
per quella quantità.

08:27.660 --> 08:28.493
Ma quando si tratta di

08:28.493 --> 08:30.420
un servizio con contatore, si paga per l'esatta quantità

08:30.420 --> 08:31.253
di consumo.

08:31.253 --> 08:33.480
E questo è davvero uno dei vantaggi dell'utilizzo del

08:33.480 --> 08:35.527
cloud: la maggior parte delle cose viene eseguita

08:35.527 --> 08:37.883
su base metrica e si paga solo per ciò che si utilizza.

08:37.883 --> 08:41.160
La prossima cosa di cui parleremo sono le risorse condivise.

08:41.160 --> 08:43.740
Ora, quando parliamo di risorse condivise, stiamo parlando

08:43.740 --> 08:46.530
della possibilità di ridurre al minimo i nostri costi perché siamo

08:46.530 --> 08:48.330
in grado di mettere le nostre macchine virtuali

08:48.330 --> 08:50.220
sui server di qualcun altro.

08:50.220 --> 08:51.930
Se si considerano i server che

08:51.930 --> 08:54.238
utilizziamo per Amazon, Azure e Google

08:54.238 --> 08:56.022
Cloud, questi costano 10, 20,

08:56.022 --> 08:58.980
30.000 dollari per un server di buona qualità.

08:58.980 --> 09:00.151
Quindi, se dovete acquistarne

09:00.151 --> 09:02.640
uno per ospitare il vostro blog WordPress, non state utilizzando

09:02.640 --> 09:04.680
tutta questa capacità, perché se avete solo un

09:04.680 --> 09:06.420
paio di centinaia di lettori, il carico

09:06.420 --> 09:08.100
non sarà così elevato.

09:08.100 --> 09:10.020
Quindi ha molto più senso prendere

09:10.020 --> 09:12.660
quell'unico server molto costoso, tagliarlo

09:12.660 --> 09:14.550
in piccoli pezzi e distribuirlo

09:14.550 --> 09:16.158
in macchine virtuali a tutti

09:16.158 --> 09:18.450
coloro che vogliono usarlo.

09:18.450 --> 09:20.816
Quindi potremmo essere in grado di ospitare 50 o

09:20.816 --> 09:24.480
100 blog WordPress su quell'unico server, invece di ospitarne uno solo.

09:24.480 --> 09:26.760
Questa è l'idea di utilizzare risorse condivise.

09:26.760 --> 09:28.330
Quando si parla di risorse condivise,

09:28.330 --> 09:30.697
si parla di mettere insieme tutto l'hardware che

09:30.697 --> 09:33.150
compone il data center del cloud provider.

09:33.150 --> 09:35.215
In questo modo non è dedicato a un singolo individuo,

09:35.215 --> 09:37.987
ma tutti possiamo utilizzarlo in base a una rapida elasticità

09:37.987 --> 09:41.220
perché, si spera, ciò che Amazon, Google e Azure stanno pensando è

09:41.220 --> 09:42.690
che quando ci sono alti periodi

09:42.690 --> 09:44.970
di domanda per la mia azienda, potrebbero esserci

09:44.970 --> 09:48.090
bassi periodi per la vostra e viceversa.

09:48.090 --> 09:50.280
Così, invece di avere risorse hardware dedicate a

09:50.280 --> 09:51.480
ciascuna delle nostre aziende,

09:51.480 --> 09:54.009
possiamo condividere le risorse su tutta la linea.

09:54.009 --> 09:55.500
L'ultima caratteristica

09:55.500 --> 09:58.710
del cloud è la possibilità di sincronizzare i file.

09:58.710 --> 10:01.103
L'aspetto positivo dell'utilizzo di una risorsa

10:01.103 --> 10:02.760
basata sul cloud è che si può mettere

10:02.760 --> 10:04.649
qualcosa in un posto e poi diffonderla

10:04.649 --> 10:07.500
in altri posti in base a come la si configura.

10:07.500 --> 10:09.420
Nella mia azienda, ad esempio, facciamo molto

10:09.420 --> 10:11.428
affidamento sulla sincronizzazione dei file

10:11.428 --> 10:14.249
perché la maggior parte dei nostri dipendenti è composta da collaboratori

10:14.249 --> 10:17.640
remoti che lavorano in tutto il mondo, non solo nei nostri uffici.

10:17.640 --> 10:18.473
Quindi, mentre sono

10:18.473 --> 10:20.100
seduto qui nel mio ufficio e sto registrando,

10:20.100 --> 10:22.830
ho bisogno di un modo per dare questo file al mio grafico in modo

10:22.830 --> 10:24.690
che possa creare tutte le diverse cose che

10:24.690 --> 10:27.060
vedete sullo schermo mentre parlo.

10:27.060 --> 10:28.260
E poi andrà a spedirlo

10:28.260 --> 10:31.320
in un altro Paese dove si trova il mio editor video.

10:31.320 --> 10:33.060
Quando hanno finito, lo invieranno

10:33.060 --> 10:34.410
ai miei uffici dove uno dei miei

10:34.410 --> 10:36.870
collaboratori effettuerà i controlli di qualità e

10:36.870 --> 10:38.400
poi lo invieremo a un altro Paese

10:38.400 --> 10:39.300
che lo caricherà sul

10:39.300 --> 10:41.040
sito finale dove lo vedrete.

10:41.040 --> 10:43.779
Quindi questo video ha viaggiato probabilmente in

10:43.779 --> 10:46.680
quattro o cinque luoghi diversi per poter essere il prodotto

10:46.680 --> 10:49.470
finito che state vedendo ora sullo schermo.

10:49.470 --> 10:50.303
Questa è l'idea della

10:50.303 --> 10:52.950
sincronizzazione dei file, perché quando registro questo,

10:52.950 --> 10:55.129
lo registro su un server di file basato sul cloud,

10:55.129 --> 10:57.780
tutti i membri del mio team possono accedere a quel file perché

10:57.780 --> 11:00.360
abbiamo una copia sincronizzata su tutti i loro dispositivi

11:00.360 --> 11:03.030
e su tutti i nostri server in tutto il mondo, in modo che possano

11:03.030 --> 11:05.430
accedervi e fare ciò di cui hanno bisogno.

11:05.430 --> 11:06.630
E mentre lo fanno, non

11:06.630 --> 11:08.190
rimane solo sul loro computer,

11:08.190 --> 11:11.070
ma viene sincronizzato su tutti i nostri server cloud,

11:11.070 --> 11:13.710
in modo che tutto il percorso che deve avvenire tra

11:13.710 --> 11:15.510
la registrazione e la pubblicazione,

11:15.510 --> 11:16.920
e poi la visione, possa avvenire

11:16.920 --> 11:20.730
su tutti i server in modo molto semplificato.

11:20.730 --> 11:22.200
E questo è uno dei grandi vantaggi

11:22.200 --> 11:24.420
del cloud dal punto di vista aziendale: non

11:24.420 --> 11:26.970
si ha un server nel proprio ufficio.

11:26.970 --> 11:28.201
Ora si trova nel cloud,

11:28.201 --> 11:31.650
in un data center protetto, altamente disponibile, in grado

11:31.650 --> 11:32.980
di essere scalabile e di

11:32.980 --> 11:34.617
rispondere in modo elastico

11:34.617 --> 11:37.740
alle richieste di periodi più o meno lunghi.

11:37.740 --> 11:39.015
Dobbiamo pagare solo per quello

11:39.015 --> 11:41.177
che usiamo e possiamo condividere le risorse con altre

11:41.177 --> 11:42.537
persone che magari non conosciamo

11:42.537 --> 11:45.480
nemmeno, perché siamo tutti seduti sullo stesso server fisico.

11:45.480 --> 11:46.820
E questi sono tutti gli elementi di cui

11:46.820 --> 11:49.110
parliamo quando iniziamo a parlare delle caratteristiche del

11:49.110 --> 11:50.970
cloud e del motivo per cui c'è stata questa grande migrazione

11:50.970 --> 11:53.740
verso il cloud da parte di molte aziende in tutto il mondo.