WEBVTT

00:00.090 --> 00:00.923
Instructor: Hoy en día,

00:00.923 --> 00:02.880
la computación en nube se puede encontrar en todas

00:02.880 --> 00:05.580
partes, y es realmente porque hay tantos grandes beneficios para

00:05.580 --> 00:07.290
el uso de la computación en nube.

00:07.290 --> 00:09.510
Y en eso nos vamos a centrar en esta lección cuando

00:09.510 --> 00:10.343
empecemos a hablar

00:10.343 --> 00:12.930
de las diferentes características de la nube.

00:12.930 --> 00:15.160
Cuando hablamos de computación en nube, hay

00:15.160 --> 00:17.670
un puñado de beneficios o características que vemos

00:17.670 --> 00:19.680
cuando elegimos usar la nube.

00:19.680 --> 00:23.460
Entre ellas figuran la alta disponibilidad, la escalabilidad, la elasticidad,

00:23.460 --> 00:24.750
la utilización medida, los

00:24.750 --> 00:27.540
recursos compartidos y la sincronización de archivos.

00:27.540 --> 00:29.040
Veámoslos.

00:29.040 --> 00:31.350
En primer lugar, tenemos alta disponibilidad.

00:31.350 --> 00:32.749
Ahora bien, la alta disponibilidad

00:32.749 --> 00:34.410
se refiere al hecho de que los servicios

00:34.410 --> 00:37.800
experimentan muy poco tiempo de inactividad cuando se utiliza la nube.

00:37.800 --> 00:39.690
Esto se debe a que la mayoría de los servicios que se

00:39.690 --> 00:41.670
construyen en la nube se construyen para ser altamente

00:41.670 --> 00:43.200
fiables y muy tolerantes a fallos.

00:43.200 --> 00:45.900
Esto significa que podemos garantizar un alto nivel de disponibilidad.

00:45.900 --> 00:47.610
Cuando hablamos de disponibilidad,

00:47.610 --> 00:50.160
solemos medirla en términos de porcentaje de

00:50.160 --> 00:53.760
tiempo de actividad frente a tiempo de inactividad.

00:53.760 --> 00:55.920
Así, por ejemplo, el patrón oro dentro

00:55.920 --> 00:58.860
de las redes se conoce como cinco nueves.

00:58.860 --> 01:02.970
Cinco nueves significa 99. 999% de tiempo de actividad o disponibilidad

01:02.970 --> 01:06.390
según la experiencia de sus usuarios finales.

01:06.390 --> 01:09.030
Esto significa que sólo podemos tener unos cinco

01:09.030 --> 01:11.980
minutos y 15 segundos de inactividad al año.

01:11.980 --> 01:15.090
Así es, sólo cinco minutos y 15

01:15.090 --> 01:18.570
segundos en los 365 días del año.

01:18.570 --> 01:20.400
Para ello, hay que disponer de

01:20.400 --> 01:23.430
sistemas de alta fiabilidad y disponibilidad.

01:23.430 --> 01:25.330
Así que si tienes un sitio web, en

01:25.330 --> 01:28.290
realidad vas a tener al menos dos servidores web que

01:28.290 --> 01:29.123
lo alojen.

01:29.123 --> 01:30.300
Así, si uno se cae, el otro

01:30.300 --> 01:32.160
sigue soportando la carga, y eso significa

01:32.160 --> 01:35.730
que el usuario final no experimenta ningún tiempo de inactividad.

01:35.730 --> 01:36.690
A eso nos referimos cuando

01:36.690 --> 01:38.640
hablamos de alta disponibilidad.

01:38.640 --> 01:42.210
Por ejemplo, con mi propio sitio web, diontraining. com, en realidad tenemos una configuración

01:42.210 --> 01:44.760
de alta disponibilidad que se ha creado utilizando

01:44.760 --> 01:47.280
servicios en la nube.

01:47.280 --> 01:50.070
Así que, dependiendo del lugar del mundo de donde vengas, llegarás

01:50.070 --> 01:51.060
a uno de nuestros múltiples

01:51.060 --> 01:53.160
servidores situados en todo el mundo que esté más

01:53.160 --> 01:55.680
cerca de ti para obtener una mejor experiencia.

01:55.680 --> 01:57.627
Ahora, si tu servidor está caído por alguna razón,

01:57.627 --> 02:00.300
serás redirigido automáticamente a otro que esté un poco más

02:00.300 --> 02:02.490
lejos de ti, pero que siga funcionando.

02:02.490 --> 02:04.980
Y así, sigues teniendo el servicio que buscas,

02:04.980 --> 02:08.460
y es una forma de garantizar una alta disponibilidad.

02:08.460 --> 02:10.590
La segunda característica de la nube de la que vamos

02:10.590 --> 02:12.480
a hablar se conoce como escalabilidad.

02:12.480 --> 02:15.150
Ahora, cuando hablamos de escalabilidad, nos

02:15.150 --> 02:17.370
referimos al hecho de que podemos aumentar

02:17.370 --> 02:19.080
el número de personas o el número

02:19.080 --> 02:23.220
de cosas en nuestro sistema a un ritmo lineal o menos que lineal.

02:23.220 --> 02:24.053
Supongamos

02:24.053 --> 02:26.850
que 100 usuarios utilizan mi sistema y

02:26.850 --> 02:28.620
me cuesta 10 dólares.

02:28.620 --> 02:31.282
Bueno, si pongo 200 usuarios en mi sistema, debería

02:31.282 --> 02:35.010
costarme 20 dólares o menos, y eso sería una escala lineal.

02:35.010 --> 02:37.860
Ahora bien, si pasara de 100 a 200 usuarios y el

02:37.860 --> 02:40.500
precio subiera de 10 a 100 dólares, eso sería

02:40.500 --> 02:42.240
una escala exponencial, y no

02:42.240 --> 02:43.380
queremos eso.

02:43.380 --> 02:45.180
Por eso, cuando creamos nuestros sistemas

02:45.180 --> 02:47.070
en la nube, siempre buscamos la escalabilidad,

02:47.070 --> 02:49.860
y eso significa que aunque hoy solo tengamos 10 usuarios, mañana

02:49.860 --> 02:51.090
podríamos tener 100".

02:51.090 --> 02:52.590
Al día siguiente tenemos 1.000, al día

02:52.590 --> 02:55.260
siguiente puede que tengamos 10.000, y así sucesivamente.

02:55.260 --> 02:56.093
Si nos fijamos en

02:56.093 --> 02:58.800
algunas de las grandes empresas como Facebook y Google,

02:58.800 --> 03:02.160
LinkedIn y UNI, tienen millones de usuarios finales que acceden

03:02.160 --> 03:04.710
a sus plataformas todos los días y son capaces de

03:04.710 --> 03:07.422
escalar basándose en la escalabilidad de los servicios

03:07.422 --> 03:09.510
en la nube, porque no tengo que ir y comprar

03:09.510 --> 03:10.710
otro servidor de 10.000

03:10.710 --> 03:12.990
dólares para ponerlo en mi centro de datos local,

03:12.990 --> 03:14.490
porque en su lugar puedo usar

03:14.490 --> 03:16.650
el de Amazon y utilizar una parte de su capacidad

03:16.650 --> 03:19.560
según la necesite.

03:19.560 --> 03:20.970
Ahora, cuando se trata de escalabilidad,

03:20.970 --> 03:22.650
hay dos maneras de escalar.

03:22.650 --> 03:25.560
Una es aumentar la escala, lo que se conoce como escala vertical.

03:25.560 --> 03:27.090
Esto se consigue añadiendo más recursos

03:27.090 --> 03:29.010
a un servidor o nodo concreto.

03:29.010 --> 03:31.020
Por ejemplo, si utilizas un servidor

03:31.020 --> 03:32.970
basado en la nube que tiene dos CPU

03:32.970 --> 03:35.730
virtuales, puedes aumentarlas a cuatro.

03:35.730 --> 03:37.170
Esta es la idea de la ampliación.

03:37.170 --> 03:38.610
Estás añadiendo más recursos,

03:38.610 --> 03:41.040
ya sean más procesadores, más RAM, más almacenamiento,

03:41.040 --> 03:43.110
más ancho de banda o cosas por el estilo.

03:43.110 --> 03:45.120
Ahora, por otro lado, también puedes escalar hacia

03:45.120 --> 03:47.100
fuera, lo que se conoce como escalado horizontal.

03:47.100 --> 03:49.440
Aquí se siguen utilizando máquinas más pequeñas, pero

03:49.440 --> 03:50.280
se utilizan más de ellas

03:50.280 --> 03:53.400
trabajando en tándem detrás de un equilibrador de carga.

03:53.400 --> 03:55.080
Así, en lugar de tener un servidor que gestiona

03:55.080 --> 03:57.316
toda la carga y escalar hacia arriba mediante el aumento

03:57.316 --> 04:00.180
de las CPU y el aumento de la memoria, puede escalar hacia fuera y pasar

04:00.180 --> 04:02.520
de un servidor a dos servidores o dos servidores a cuatro,

04:02.520 --> 04:05.970
o cuatro a ocho, y puede seguir moviéndose hacia fuera, mediante la adición de

04:05.970 --> 04:07.170
servidores adicionales detrás

04:07.170 --> 04:09.840
de su equilibrador de carga con el que puede gestionar el tráfico

04:09.840 --> 04:11.940
adicional.

04:11.940 --> 04:13.710
Ahora, esto nos lleva a nuestra tercera

04:13.710 --> 04:15.864
área, que se conoce como elasticidad rápida.

04:15.864 --> 04:18.960
Cuando hablamos de elasticidad rápida, nos referimos al

04:18.960 --> 04:20.160
hecho de que podemos aumentar

04:20.160 --> 04:22.731
o reducir la escala muy rápidamente.

04:22.731 --> 04:25.454
Ahora esto se hace porque usamos automatización y orquestación

04:25.454 --> 04:28.110
con un montón de máquinas virtuales en estos servidores

04:28.110 --> 04:29.970
físicos que son propiedad de Amazon,

04:29.970 --> 04:32.220
Google, Microsoft y otras corporaciones que

04:32.220 --> 04:35.040
nos permiten usar porciones o todos sus servicios según

04:35.040 --> 04:38.104
necesitemos bajo demanda.

04:38.104 --> 04:41.040
Y esto nos da esa rápida elasticidad.

04:41.040 --> 04:43.200
Cuando oiga el término elasticidad rápida

04:43.200 --> 04:46.290
o elasticidad en general, piense en ella como el hecho de la capacidad

04:46.290 --> 04:48.785
del sistema para gestionar cambios en la demanda

04:48.785 --> 04:50.370
en tiempo real.

04:50.370 --> 04:51.410
Volvamos al ejemplo de utilizar

04:51.410 --> 04:54.780
mi sitio web en diontraining. com.

04:54.780 --> 04:56.490
Si ahora mismo consulto mi sitio web

04:56.490 --> 04:58.770
y tengo 1.000 estudiantes registrados, y dentro

04:58.770 --> 05:00.330
de cinco minutos hay 10.000 estudiantes

05:00.330 --> 05:02.520
registrados, mis sistemas están diseñados

05:02.520 --> 05:03.774
para poner en marcha recursos

05:03.774 --> 05:07.230
adicionales en la nube y transferir parte de la carga de esos nuevos usuarios

05:07.230 --> 05:10.230
a esos servicios adicionales.

05:10.230 --> 05:12.810
Esa es la idea de la elasticidad rápida.

05:12.810 --> 05:14.580
Generalmente, cuando se trabaja en la nube,

05:14.580 --> 05:16.470
si se han diseñado correctamente los sistemas,

05:16.470 --> 05:18.949
se tiene la capacidad de disponer rápidamente de elasticidad

05:18.949 --> 05:21.150
y escalar muy rápido, y luego, del mismo modo, cuando

05:21.150 --> 05:23.520
la demanda desaparece, se puede deshacer rápidamente

05:23.520 --> 05:24.750
de esos servidores adicionales

05:24.750 --> 05:27.120
y volver a reducirlos.

05:27.120 --> 05:28.680
Y la razón por la que querrías hacer eso

05:28.680 --> 05:31.166
es porque todos esos servidores extra te van a costar más dinero,

05:31.166 --> 05:33.390
y si no tienes suficientes usuarios para tenerlos,

05:33.390 --> 05:34.500
no quieres pagar por ello,

05:34.500 --> 05:36.510
así que vas a liberarlos, devolvérselos a tu proveedor

05:36.510 --> 05:37.410
de servicios para que

05:37.410 --> 05:40.140
pueda alquilar ese servicio a alguien más.

05:40.140 --> 05:42.750
En cambio, si estás haciendo un modelo on premise,

05:42.750 --> 05:45.000
digamos que hoy tengo 1.000 alumnos.

05:45.000 --> 05:48.150
Bueno, para 1.000 estudiantes, podría necesitar tres servidores web.

05:48.150 --> 05:49.830
Pero si llego a 10.000 alumnos,

05:49.830 --> 05:51.956
necesitaré otros 15 servidores web.

05:51.956 --> 05:55.080
Pues para eso tendría que comprar 15 servidores más.

05:55.080 --> 05:55.950
Tendría que atormentarlos.

05:55.950 --> 05:57.270
Tendría que instalar todo el software,

05:57.270 --> 05:58.440
tendría que configurarlos.

05:58.440 --> 05:59.580
Todo eso lleva su tiempo,

05:59.580 --> 06:02.222
y por eso no es muy rápido en medidas de elasticidad para

06:02.222 --> 06:04.980
que podamos escalar y satisfacer esa demanda.

06:04.980 --> 06:07.860
Si tienes un modelo de negocio de crecimiento muy lento, no pasa nada.

06:07.860 --> 06:10.200
Pero si estás tratando con algo que es de alta velocidad

06:10.200 --> 06:12.171
o cualquiera de estas plataformas de medios

06:12.171 --> 06:14.370
sociales modernos, y algo que has hecho se ha vuelto

06:14.370 --> 06:16.920
viral, y todo el mundo va a tu sitio web y comienza a inundarte,

06:16.920 --> 06:19.950
si no tienes la capacidad de escalar rápidamente, vas a perder la capacidad

06:19.950 --> 06:22.052
de capturar ese tráfico que viene de ese incidente

06:22.052 --> 06:23.880
viral.

06:23.880 --> 06:25.620
Y por eso quieres poder construir

06:25.620 --> 06:27.360
tu material de forma rápida y elástica,

06:27.360 --> 06:29.700
y eso es lo que nos permite la nube.

06:29.700 --> 06:32.910
Lo cuarto que tenemos se conoce como utilización medida.

06:32.910 --> 06:33.810
Esto nos remite al debate

06:33.810 --> 06:36.510
sobre la elasticidad rápida que acabamos de mantener.

06:36.510 --> 06:38.686
Ahora bien, cuando hablamos de utilización

06:38.686 --> 06:40.170
medida, nos referimos al hecho

06:40.170 --> 06:43.800
de que estamos pagando por un servicio en función de su uso.

06:43.800 --> 06:46.650
Cuando utilizamos un servicio medido, como una base

06:46.650 --> 06:47.730
de datos, pueden cobrarnos

06:47.730 --> 06:49.170
en función del número de usuarios,

06:49.170 --> 06:52.050
conexiones o datos almacenados.

06:52.050 --> 06:53.910
Esencialmente, se nos cobra en

06:53.910 --> 06:56.910
función del uso real del servicio que se consume.

06:56.910 --> 06:59.262
Y lo hacemos por segundos, por

06:59.262 --> 07:03.480
minutos, por horas, por días o incluso por meses.

07:03.480 --> 07:05.211
Por ejemplo, yo uso AWS Lambda

07:05.211 --> 07:08.153
para muchas de mis automatizaciones y funciones

07:08.153 --> 07:11.010
de backend, y me cobran en función de mi uso.

07:11.010 --> 07:13.290
Ahora, por cada millón de solicitudes que hago,

07:13.290 --> 07:14.760
me cobran 20 céntimos.

07:14.760 --> 07:16.200
Y así es una manera muy eficiente para

07:16.200 --> 07:17.880
mí para conseguir mis automatizaciones

07:17.880 --> 07:20.092
hecho porque es una cosa muy, muy bajo costo.

07:20.092 --> 07:22.620
Puedo tener millones y millones de peticiones

07:22.620 --> 07:24.960
y sólo me costaría un par de dólares, y esa

07:24.960 --> 07:27.090
es la idea de un servicio medido.

07:27.090 --> 07:28.334
A veces se distingue

07:28.334 --> 07:30.120
entre servicio medido

07:30.120 --> 07:33.000
y servicio medido.

07:33.000 --> 07:35.640
Ahora bien, cuando hablamos de servicios medidos o con

07:35.640 --> 07:37.470
contador, en realidad estamos hablando

07:37.470 --> 07:38.700
de lo mismo y es nuestra capacidad

07:38.700 --> 07:41.160
de pagar por algo en función del consumo.

07:41.160 --> 07:42.840
Pero aquí hay una diferencia.

07:42.840 --> 07:44.850
Cuando utilizas un servicio con

07:44.850 --> 07:46.073
contador, pagas por

07:46.073 --> 07:49.380
las cosas en función del uso real que has hecho.

07:49.380 --> 07:50.213
Así que si piensas

07:50.213 --> 07:52.500
en la factura del agua o de la luz de tu casa.

07:52.500 --> 07:53.880
Si este mes has abierto la manguera

07:53.880 --> 07:55.650
y has llenado la piscina, vas a pagar

07:55.650 --> 07:56.730
mucho más por la factura

07:56.730 --> 07:59.670
del agua porque has consumido mucha más agua.

07:59.670 --> 08:02.314
En cambio, cuando se trata de un servicio medido,

08:02.314 --> 08:04.950
es más parecido a un plan de telefonía móvil.

08:04.950 --> 08:08.160
En la mayoría de los lugares, pagas una cuota mensual por una determinada

08:08.160 --> 08:10.740
cantidad de uso de ese móvil, ya sea el número de mensajes

08:10.740 --> 08:14.100
de texto, minutos o datos que puedes consumir.

08:14.100 --> 08:15.390
Y una vez que llegues a ese límite,

08:15.390 --> 08:17.790
te suspenderán el servicio y no te darán más hasta

08:17.790 --> 08:19.440
que vuelvas a pagarles.

08:19.440 --> 08:21.300
Así que cuando pienses en un servicio medido,

08:21.300 --> 08:23.310
piensa en el hecho de que estás pagando por adelantado

08:23.310 --> 08:25.920
una cantidad determinada, y tanto si la utilizas como si no, ya

08:25.920 --> 08:27.660
has pagado por esa cantidad.

08:27.660 --> 08:28.493
Pero cuando se trata de

08:28.493 --> 08:30.420
un servicio con contador, pagas por la cantidad exacta

08:30.420 --> 08:31.253
que consumes.

08:31.253 --> 08:33.480
Y esta es realmente una de las ventajas de usar la nube,

08:33.480 --> 08:35.527
que la mayoría de las cosas se hacen sobre una base

08:35.527 --> 08:37.883
medida en la que sólo pagas por lo que usas.

08:37.883 --> 08:41.160
Lo siguiente de lo que vamos a hablar es de los recursos compartidos.

08:41.160 --> 08:43.740
Ahora, cuando hablamos de recursos compartidos, en realidad

08:43.740 --> 08:46.530
estamos hablando de la capacidad de minimizar nuestros costes

08:46.530 --> 08:48.330
porque podemos poner nuestras máquinas

08:48.330 --> 08:50.220
virtuales en los servidores de otros.

08:50.220 --> 08:51.930
Los servidores que utilizamos

08:51.930 --> 08:54.238
para Amazon, Azure y Google Cloud cuestan

08:54.238 --> 08:56.022
10.000, 20.000 o 30.000 dólares

08:56.022 --> 08:58.980
cada uno por un servidor de buena calidad.

08:58.980 --> 09:00.151
Y así, si necesitas comprar

09:00.151 --> 09:02.640
uno de esos para poder alojar tu blog de WordPress, en realidad

09:02.640 --> 09:04.680
no estás utilizando toda esa capacidad, porque

09:04.680 --> 09:06.420
si sólo tienes un par de cientos de lectores,

09:06.420 --> 09:08.100
no va a utilizar tanta carga.

09:08.100 --> 09:10.020
En lugar de eso, tiene mucho más

09:10.020 --> 09:12.660
sentido coger ese servidor tan caro, dividirlo

09:12.660 --> 09:14.550
en trocitos y distribuirlo en

09:14.550 --> 09:16.158
máquinas virtuales a todo

09:16.158 --> 09:18.450
el que quiera usarlo.

09:18.450 --> 09:20.816
Así que podríamos alojar 50 o 100 blogs de

09:20.816 --> 09:24.480
WordPress en ese único servidor en lugar de alojar sólo uno.

09:24.480 --> 09:26.760
Esa es la idea de utilizar recursos compartidos.

09:26.760 --> 09:28.330
Cuando hablamos de recursos compartidos,

09:28.330 --> 09:30.697
nos referimos a reunir todo el hardware que compone

09:30.697 --> 09:33.150
el centro de datos del proveedor de la nube.

09:33.150 --> 09:35.215
Y de esa manera no está dedicado a un solo individuo,

09:35.215 --> 09:37.987
sino que todos podemos usarlo basándonos en una rápida elasticidad

09:37.987 --> 09:41.220
porque, con suerte, lo que Amazon y Google y Azure están pensando

09:41.220 --> 09:42.690
es que cuando hay periodos altos

09:42.690 --> 09:44.970
de demanda para mi empresa, puede haber periodos

09:44.970 --> 09:48.090
bajos para la tuya y viceversa.

09:48.090 --> 09:50.280
Así, en lugar de tener que dedicar recursos de hardware

09:50.280 --> 09:51.480
a cada una de nuestras empresas,

09:51.480 --> 09:54.009
podemos compartir recursos de forma generalizada.

09:54.009 --> 09:55.500
Y la última característica

09:55.500 --> 09:58.710
de la nube es la posibilidad de sincronizar archivos.

09:58.710 --> 10:01.103
Ahora bien, lo bueno de utilizar un recurso basado

10:01.103 --> 10:02.760
en la nube es que puedes poner algo

10:02.760 --> 10:04.649
en un sitio y luego puede extenderse a

10:04.649 --> 10:07.500
otros lugares en función de cómo lo configures.

10:07.500 --> 10:09.420
Por ejemplo, en mi empresa dependemos

10:09.420 --> 10:11.428
mucho de la sincronización de archivos

10:11.428 --> 10:14.249
porque la mayoría de nuestros empleados trabajan a distancia

10:14.249 --> 10:17.640
en todo el mundo, no sólo en nuestras oficinas.

10:17.640 --> 10:18.473
Así que mientras estoy

10:18.473 --> 10:20.100
sentado aquí en mi oficina grabando esto ahora

10:20.100 --> 10:22.830
mismo, necesito una manera de darle este archivo a mi diseñador gráfico

10:22.830 --> 10:24.690
para que pueda crear todas las cosas diferentes que

10:24.690 --> 10:27.060
estás viendo en la pantalla mientras estoy hablando.

10:27.060 --> 10:28.260
Y luego irá a enviarlo

10:28.260 --> 10:31.320
a otro país donde se encuentra mi editor de vídeo.

10:31.320 --> 10:33.060
Y cuando terminen, lo enviarán a mis

10:33.060 --> 10:34.410
oficinas, donde uno de mis empleados

10:34.410 --> 10:36.870
hará los controles de calidad, y luego lo enviaremos

10:36.870 --> 10:39.300
a otro país, que lo subirá al sitio final, donde lo

10:39.300 --> 10:41.040
verán ustedes.

10:41.040 --> 10:43.779
Y así, este vídeo ha viajado probablemente a cuatro o

10:43.779 --> 10:46.680
cinco lugares diferentes para poder ser ese producto acabado

10:46.680 --> 10:49.470
que estás viendo ahora mismo en la pantalla.

10:49.470 --> 10:50.303
Esta es la idea de la

10:50.303 --> 10:52.950
sincronización de archivos, porque cuando grabo esto, lo estoy

10:52.950 --> 10:55.129
grabando en un servidor de archivos basado en la nube,

10:55.129 --> 10:57.780
todos en mi equipo pueden acceder a ese archivo porque tenemos

10:57.780 --> 11:00.360
esa copia sincronizada en todos sus dispositivos y en todos

11:00.360 --> 11:03.030
nuestros servidores alrededor del mundo para que puedan acceder

11:03.030 --> 11:05.430
a él y hacer lo que necesiten.

11:05.430 --> 11:06.630
Y mientras lo hacen, no

11:06.630 --> 11:08.190
se queda solo en su ordenador,

11:08.190 --> 11:11.070
sino que se sincroniza en todos nuestros servidores en

11:11.070 --> 11:13.710
la nube, de modo que todo lo demás que tiene que ocurrir

11:13.710 --> 11:15.510
entre la grabación y la publicación,

11:15.510 --> 11:16.920
y luego el visionado, puede

11:16.920 --> 11:19.080
ocurrir en todos esos servidores de forma

11:19.080 --> 11:20.730
muy racionalizada.

11:20.730 --> 11:22.200
Y esa es una de las grandes ventajas

11:22.200 --> 11:24.420
de la nube desde el punto de vista empresarial:

11:24.420 --> 11:26.970
no tienes un servidor en tu oficina.

11:26.970 --> 11:28.201
Ahora está en la nube,

11:28.201 --> 11:31.650
en un centro de datos protegido, de alta disponibilidad,

11:31.650 --> 11:32.980
escalable y elástico

11:32.980 --> 11:34.617
para responder a periodos

11:34.617 --> 11:37.740
de mayor o menor demanda.

11:37.740 --> 11:39.015
Sólo tenemos que pagar por lo

11:39.015 --> 11:41.177
que usamos y podemos compartir recursos con otras

11:41.177 --> 11:42.537
personas que quizá ni conozcamos

11:42.537 --> 11:45.480
porque todos estamos sentados en el mismo servidor físico.

11:45.480 --> 11:46.820
Y estas son todas las cosas de las que

11:46.820 --> 11:49.110
hablamos cuando empezamos a hablar de las características

11:49.110 --> 11:50.970
de la nube y de por qué se ha producido esta gran migración

11:50.970 --> 11:53.740
a la nube por parte de muchas empresas de todo el mundo