WEBVTT

00:00.090 --> 00:00.923
Instrutor: Hoje em

00:00.923 --> 00:02.880
dia, a computação em nuvem pode ser encontrada

00:02.880 --> 00:05.580
em todos os lugares, e isso se deve ao fato de que há muitas vantagens

00:05.580 --> 00:07.290
em usar a computação em nuvem.

00:07.290 --> 00:09.510
E é nisso que vamos nos concentrar nesta lição, quando

00:09.510 --> 00:10.343
começarmos a falar

00:10.343 --> 00:12.930
sobre as diferentes características da nuvem.

00:12.930 --> 00:15.160
Quando falamos de computação em nuvem, há

00:15.160 --> 00:17.670
vários benefícios ou características que vemos

00:17.670 --> 00:19.680
quando optamos por usar a nuvem.

00:19.680 --> 00:23.460
Isso inclui alta disponibilidade, escalabilidade, elasticidade, utilização

00:23.460 --> 00:24.750
medida, recursos compartilhados

00:24.750 --> 00:27.540
e sincronização de arquivos.

00:27.540 --> 00:29.040
Vamos dar uma olhada nelas.

00:29.040 --> 00:31.350
Primeiro, temos alta disponibilidade.

00:31.350 --> 00:32.749
Agora, a alta disponibilidade

00:32.749 --> 00:34.410
refere-se ao fato de que os serviços

00:34.410 --> 00:37.800
sofrem pouquíssimo tempo de inatividade quando se usa a nuvem.

00:37.800 --> 00:39.690
Isso ocorre porque a maioria dos serviços criados

00:39.690 --> 00:41.670
na nuvem é desenvolvida para ser altamente confiável

00:41.670 --> 00:43.200
e muito tolerante a falhas.

00:43.200 --> 00:45.900
Isso significa que podemos garantir um alto nível de disponibilidade.

00:45.900 --> 00:47.610
Agora, quando se trata de disponibilidade,

00:47.610 --> 00:50.160
geralmente medimos isso em termos de uma porcentagem

00:50.160 --> 00:53.760
do tempo de atividade em relação ao tempo de inatividade.

00:53.760 --> 00:55.920
Assim, por exemplo, o padrão ouro dentro

00:55.920 --> 00:58.860
das redes é conhecido como cinco noves.

00:58.860 --> 01:02.970
Cinco noves significa 99. 999% de tempo de atividade ou disponibilidade,

01:02.970 --> 01:06.390
conforme experimentado por seus usuários finais.

01:06.390 --> 01:09.030
Isso significa que só podemos ter cerca de cinco minutos

01:09.030 --> 01:11.980
e 15 segundos de tempo de inatividade a cada ano.

01:11.980 --> 01:15.090
Isso mesmo, apenas cinco minutos e 15

01:15.090 --> 01:18.570
segundos em todos os 365 dias de um ano.

01:18.570 --> 01:20.400
Agora, para fazer isso, é preciso ter

01:20.400 --> 01:23.430
sistemas altamente confiáveis e altamente disponíveis.

01:23.430 --> 01:25.330
Portanto, se você tiver um site, na

01:25.330 --> 01:29.123
verdade terá pelo menos dois servidores da Web para hospedá-lo.

01:29.123 --> 01:30.300
Portanto, se um cair, o outro

01:30.300 --> 01:32.160
ainda estará carregando a carga, o que significa

01:32.160 --> 01:35.730
que o usuário final não sofrerá nenhum tempo de inatividade.

01:35.730 --> 01:36.690
É disso que estamos falando

01:36.690 --> 01:38.640
quando falamos de alta disponibilidade.

01:38.640 --> 01:42.210
Por exemplo, com meu próprio site, diontraining. com, temos de fato uma configuração

01:42.210 --> 01:44.760
altamente disponível que foi criada

01:44.760 --> 01:47.280
usando serviços de nuvem.

01:47.280 --> 01:50.070
Portanto, dependendo de onde você está vindo no mundo, você acessará

01:50.070 --> 01:51.060
um de nossos vários servidores

01:51.060 --> 01:53.160
localizados em todo o mundo que esteja mais próximo

01:53.160 --> 01:55.680
de você para obter uma experiência melhor.

01:55.680 --> 01:57.627
Agora, se o seu servidor estiver inativo por algum motivo,

01:57.627 --> 02:00.300
você será automaticamente redirecionado para outro que esteja um pouco

02:00.300 --> 02:02.490
mais longe de você, mas que ainda esteja ativo.

02:02.490 --> 02:04.980
Dessa forma, você ainda obtém o serviço que está procurando,

02:04.980 --> 02:08.460
e essa é uma maneira de garantir alta disponibilidade.

02:08.460 --> 02:10.590
A segunda característica da nuvem sobre a qual falaremos

02:10.590 --> 02:12.480
é conhecida como escalabilidade.

02:12.480 --> 02:15.150
Agora, quando falamos de escalabilidade, estamos

02:15.150 --> 02:17.370
falando do fato de que podemos aumentar o

02:17.370 --> 02:19.080
número de pessoas ou o número de

02:19.080 --> 02:23.220
coisas em nosso sistema em uma taxa linear ou menos que uma taxa linear.

02:23.220 --> 02:24.053
Agora, o que quero

02:24.053 --> 02:26.850
dizer com isso é que digamos que eu tenha 100 usuários usando

02:26.850 --> 02:28.620
meu sistema, e ele custa US$ 10.

02:28.620 --> 02:31.282
Bem, se eu colocar 200 usuários no meu sistema,

02:31.282 --> 02:35.010
ele deverá custar US$ 20 ou menos, e isso seria uma escala linear.

02:35.010 --> 02:37.860
Agora, se eu passasse de 100 para 200 usuários e o

02:37.860 --> 02:40.500
preço fosse de US$ 10 para US$ 100, isso seria

02:40.500 --> 02:42.240
uma escala exponencial, e não

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

02:43.380 --> 02:45.180
Portanto, ao desenvolvermos nossos sistemas

02:45.180 --> 02:47.070
de nuvem, estamos sempre buscando a escalabilidade,

02:47.070 --> 02:49.860
o que significa que, mesmo que tenhamos apenas 10 usuários hoje, amanhã

02:49.860 --> 02:51.090
poderemos ter 100.

02:51.090 --> 02:52.590
No dia seguinte, temos 1.000, no

02:52.590 --> 02:55.260
dia seguinte, podemos ter 10.000, e assim por diante.

02:55.260 --> 02:56.093
Se olharmos para

02:56.093 --> 02:58.800
algumas das grandes empresas, como Facebook, Google,

02:58.800 --> 03:02.160
LinkedIn e UNI, elas têm milhões de usuários finais que acessam

03:02.160 --> 03:04.710
suas plataformas todos os dias e são capazes de aumentar

03:04.710 --> 03:07.422
a escala com base na escalabilidade dos serviços em

03:07.422 --> 03:09.510
nuvem, porque não preciso comprar outro

03:09.510 --> 03:10.710
servidor de US$ 10.000

03:10.710 --> 03:12.990
para colocar em meu data center local, porque,

03:12.990 --> 03:14.490
em vez disso, posso simplesmente

03:14.490 --> 03:16.650
usar o da Amazon e usar uma parte de sua capacidade

03:16.650 --> 03:19.560
conforme necessário.

03:19.560 --> 03:20.970
Agora, quando se trata de escalabilidade,

03:20.970 --> 03:22.650
há duas maneiras de escalar.

03:22.650 --> 03:25.560
Uma delas é aumentar a escala, o que é conhecido como escala vertical.

03:25.560 --> 03:27.090
Isso ocorre ao adicionar mais recursos

03:27.090 --> 03:29.010
a um determinado servidor ou nó.

03:29.010 --> 03:31.020
Por exemplo, se você estiver usando um servidor

03:31.020 --> 03:32.970
baseado em nuvem que tenha duas CPUs virtuais,

03:32.970 --> 03:35.730
poderá aumentar esse número para quatro CPUs virtuais.

03:35.730 --> 03:37.170
Essa é a ideia de aumentar a escala.

03:37.170 --> 03:38.610
Você está adicionando mais recursos,

03:38.610 --> 03:41.040
sejam eles mais processadores, mais RAM, mais armazenamento,

03:41.040 --> 03:43.110
mais largura de banda ou coisas do gênero.

03:43.110 --> 03:45.120
Agora, por outro lado, você também pode reduzir a escala,

03:45.120 --> 03:47.100
o que é conhecido como escala horizontal.

03:47.100 --> 03:49.440
Nesse caso, você ainda usa máquinas menores, mas

03:49.440 --> 03:50.280
usa mais delas, todas

03:50.280 --> 03:53.400
trabalhando em conjunto por trás de um balanceador de carga.

03:53.400 --> 03:55.080
Portanto, em vez de ter um servidor que

03:55.080 --> 03:57.316
esteja lidando com toda a sua carga e escalando para

03:57.316 --> 04:00.180
cima aumentando as CPUs e a memória, você pode escalar para fora

04:00.180 --> 04:02.520
e ir de um servidor para dois servidores ou de dois servidores

04:02.520 --> 04:05.970
para quatro, ou de quatro para oito, e pode continuar se movendo para fora, adicionando

04:05.970 --> 04:07.170
servidores adicionais por

04:07.170 --> 04:09.840
trás do balanceador de carga com os quais você pode lidar com

04:09.840 --> 04:11.940
tráfego adicional.

04:11.940 --> 04:13.710
Agora, isso nos leva à terceira área,

04:13.710 --> 04:15.864
conhecida como elasticidade rápida.

04:15.864 --> 04:18.960
Agora, quando falamos de elasticidade rápida, estamos falando

04:18.960 --> 04:20.160
do fato de que podemos aumentar

04:20.160 --> 04:22.731
ou diminuir a escala muito rapidamente.

04:22.731 --> 04:25.454
Isso é feito porque usamos automação e orquestração

04:25.454 --> 04:28.110
com muitas máquinas virtuais nesses servidores

04:28.110 --> 04:29.970
físicos pertencentes à Amazon,

04:29.970 --> 04:32.220
ao Google, à Microsoft e a outras empresas

04:32.220 --> 04:35.040
que nos permitem usar partes ou todos os seus serviços

04:35.040 --> 04:38.104
conforme necessário, sob demanda.

04:38.104 --> 04:41.040
E isso nos dá essa rápida elasticidade.

04:41.040 --> 04:43.200
Quando ouvir o termo elasticidade rápida

04:43.200 --> 04:46.290
ou elasticidade em geral, pense nele como o fato de o sistema

04:46.290 --> 04:48.785
ser capaz de lidar com mudanças na demanda em

04:48.785 --> 04:50.370
tempo real.

04:50.370 --> 04:51.410
Então, vamos voltar ao exemplo

04:51.410 --> 04:54.780
do uso de meu website em diontraining. com.

04:54.780 --> 04:56.490
Se agora eu acessar meu site e tiver

04:56.490 --> 04:58.770
1.000 alunos conectados, e daqui a cinco minutos

04:58.770 --> 05:00.330
eu acessar e tiver 10.000 alunos

05:00.330 --> 05:02.520
conectados, meus sistemas serão projetados

05:02.520 --> 05:03.774
para ativar recursos adicionais

05:03.774 --> 05:07.230
de nuvem e transferir parte da carga desses novos usuários para esses

05:07.230 --> 05:10.230
serviços adicionais.

05:10.230 --> 05:12.810
Essa é a ideia de elasticidade rápida.

05:12.810 --> 05:14.580
Em geral, quando se trabalha na nuvem,

05:14.580 --> 05:16.470
se você projetou seus sistemas corretamente,

05:16.470 --> 05:18.949
tem a capacidade de ter elasticidade e aumentar a escala

05:18.949 --> 05:21.150
muito rapidamente e, da mesma forma, quando a

05:21.150 --> 05:23.520
demanda diminui, você pode se livrar rapidamente

05:23.520 --> 05:24.750
desses servidores extras

05:24.750 --> 05:27.120
e reduzi-los novamente.

05:27.120 --> 05:28.680
E o motivo pelo qual você quer fazer isso

05:28.680 --> 05:31.166
é porque todos esses servidores extras custarão mais dinheiro

05:31.166 --> 05:33.390
e, se você não tiver usuários suficientes para tê-los,

05:33.390 --> 05:34.500
não vai querer pagar por isso,

05:34.500 --> 05:36.510
então você os liberará e os devolverá ao seu provedor

05:36.510 --> 05:37.410
de serviços para que ele

05:37.410 --> 05:40.140
possa alugar esse serviço para outra pessoa.

05:40.140 --> 05:42.750
Em vez disso, se você estiver usando um modelo no local,

05:42.750 --> 05:45.000
digamos que eu tenha 1.000 alunos hoje.

05:45.000 --> 05:48.150
Bem, para 1.000 alunos, talvez eu precise de três servidores da Web.

05:48.150 --> 05:49.830
Mas se eu passar a ter 10.000 alunos,

05:49.830 --> 05:51.956
precisarei de mais 15 servidores da Web.

05:51.956 --> 05:55.080
Bem, para fazer isso, eu teria que comprar mais 15 servidores.

05:55.080 --> 05:55.950
Eu teria que colocá-los em uma prateleira.

05:55.950 --> 05:57.270
Eu teria que instalar todos os softwares,

05:57.270 --> 05:58.440
teria que configurá-los.

05:58.440 --> 05:59.580
Tudo isso leva tempo e, portanto,

05:59.580 --> 06:02.222
não é muito rápido em termos de medidas de elasticidade para que

06:02.222 --> 06:04.980
possamos aumentar a escala para atender a essa demanda.

06:04.980 --> 06:07.860
Se você tiver um modelo de negócios de crescimento muito lento, tudo bem.

06:07.860 --> 06:10.200
Mas se você estiver lidando com algo de alta velocidade

06:10.200 --> 06:12.171
ou com qualquer uma dessas plataformas modernas

06:12.171 --> 06:14.370
de mídia social, e algo que você fez se tornou viral,

06:14.370 --> 06:16.920
e todos vão para o seu site e começam a inundá-lo, se você não

06:16.920 --> 06:19.950
tiver a capacidade de aumentar a escala rapidamente, perderá a capacidade

06:19.950 --> 06:22.052
de capturar o tráfego proveniente desse incidente

06:22.052 --> 06:23.880
viral.

06:23.880 --> 06:25.620
Portanto, você quer ser capaz de criar

06:25.620 --> 06:27.360
seu material de forma rápida e elástica,

06:27.360 --> 06:29.700
e é isso que a nuvem nos permite fazer.

06:29.700 --> 06:32.910
A quarta coisa que temos é conhecida como utilização medida.

06:32.910 --> 06:33.810
Isso remete à nossa discussão

06:33.810 --> 06:36.510
sobre elasticidade rápida que acabamos de fazer.

06:36.510 --> 06:38.686
Agora, quando estamos falando de utilização

06:38.686 --> 06:40.170
medida, estamos falando do fato

06:40.170 --> 06:43.800
de que estamos pagando por um serviço com base no pagamento por uso.

06:43.800 --> 06:46.650
Portanto, quando usamos um serviço medido, como um banco de dados,

06:46.650 --> 06:47.730
eles podem nos cobrar com

06:47.730 --> 06:49.170
base no número de usuários, no número

06:49.170 --> 06:52.050
de conexões ou no número de dados armazenados.

06:52.050 --> 06:53.910
Essencialmente, estamos sendo cobrados

06:53.910 --> 06:56.910
com base no uso real do serviço que está sendo consumido.

06:56.910 --> 06:59.262
E fazemos isso por segundo,

06:59.262 --> 07:03.480
por minuto, por hora, por dia ou até mesmo por mês.

07:03.480 --> 07:05.211
Por exemplo, eu uso o AWS Lambda

07:05.211 --> 07:08.153
para muitas das minhas automações e funções de back-end,

07:08.153 --> 07:11.010
e eles cobram com base no meu uso.

07:11.010 --> 07:13.290
Agora, para cada um milhão de solicitações que eu fizer,

07:13.290 --> 07:14.760
eles me cobram 20 centavos.

07:14.760 --> 07:16.200
Portanto, essa é uma maneira

07:16.200 --> 07:17.880
muito eficiente de realizar minhas

07:17.880 --> 07:20.092
automações, pois o custo é muito baixo.

07:20.092 --> 07:22.620
Posso ter milhões e milhões de solicitações

07:22.620 --> 07:24.960
e isso me custaria apenas alguns dólares,

07:24.960 --> 07:27.090
e essa é a ideia de um serviço medido.

07:27.090 --> 07:28.334
Agora, outra coisa que

07:28.334 --> 07:30.120
você verá é que, às vezes, há uma distinção

07:30.120 --> 07:33.000
entre serviço medido e serviço medido.

07:33.000 --> 07:35.640
Agora, quando falamos de serviços medidos ou mensurados,

07:35.640 --> 07:37.470
estamos realmente falando da mesma coisa,

07:37.470 --> 07:38.700
que é a nossa capacidade de

07:38.700 --> 07:41.160
pagar por algo com base no consumo.

07:41.160 --> 07:42.840
Mas há uma diferença aqui.

07:42.840 --> 07:44.850
Quando você usa um serviço medido,

07:44.850 --> 07:46.073
está pagando por

07:46.073 --> 07:49.380
coisas com base no uso real do que fez.

07:49.380 --> 07:50.213
Portanto, se você pensar

07:50.213 --> 07:52.500
na conta de água ou de energia elétrica de sua casa.

07:52.500 --> 07:53.880
Se você ligou a mangueira

07:53.880 --> 07:55.650
de água e encheu a piscina este mês,

07:55.650 --> 07:56.730
pagará muito mais pela

07:56.730 --> 07:59.670
conta de água porque usou muito mais água.

07:59.670 --> 08:02.314
Por outro lado, quando você lida com um serviço medido, isso

08:02.314 --> 08:04.950
é mais parecido com o seu plano de telefone celular.

08:04.950 --> 08:08.160
Na maioria dos lugares, você paga uma taxa mensal por uma determinada

08:08.160 --> 08:10.740
quantidade de uso do celular, seja o número de mensagens

08:10.740 --> 08:14.100
de texto, minutos ou dados que pode consumir.

08:14.100 --> 08:15.390
E quando você atingir esse limite,

08:15.390 --> 08:17.790
eles interromperão o serviço e não fornecerão mais nada

08:17.790 --> 08:19.440
até que você pague novamente.

08:19.440 --> 08:21.300
Portanto, quando pensar em um serviço medido, pense

08:21.300 --> 08:23.310
no fato de que você está pagando antecipadamente por

08:23.310 --> 08:25.920
uma determinada quantidade e, independentemente de usá-la ou não,

08:25.920 --> 08:27.660
você já pagou por essa quantidade.

08:27.660 --> 08:28.493
Mas quando se trata de um

08:28.493 --> 08:30.420
serviço com medidor, você paga pela quantidade exata

08:30.420 --> 08:31.253
que está usando.

08:31.253 --> 08:33.480
E essa é realmente uma das vantagens de usar a nuvem,

08:33.480 --> 08:35.527
pois a maioria das coisas é feita com base em medidores,

08:35.527 --> 08:37.883
em que você paga apenas pelo que usa.

08:37.883 --> 08:41.160
A próxima coisa sobre a qual falaremos é sobre recursos compartilhados.

08:41.160 --> 08:43.740
Agora, quando falamos de recursos compartilhados, estamos

08:43.740 --> 08:46.530
realmente falando da capacidade de minimizar nosso custo, pois

08:46.530 --> 08:48.330
podemos colocar nossas máquinas virtuais

08:48.330 --> 08:50.220
nos servidores de outra pessoa.

08:50.220 --> 08:51.930
Quando você olha para os servidores

08:51.930 --> 08:54.238
que estamos usando na Amazon, no Azure e no

08:54.238 --> 08:56.022
Google Cloud, eles custam 10, 20,

08:56.022 --> 08:58.980
US$ 30.000 por um servidor de boa qualidade.

08:58.980 --> 09:00.151
Portanto, se você precisar

09:00.151 --> 09:02.640
comprar um desses para hospedar seu blog do WordPress, não

09:02.640 --> 09:04.680
estará realmente usando toda essa capacidade,

09:04.680 --> 09:06.420
pois se você tiver apenas algumas centenas

09:06.420 --> 09:08.100
de leitores, não usará tanta carga.

09:08.100 --> 09:10.020
Portanto, em vez disso, faz muito mais

09:10.020 --> 09:12.660
sentido pegar aquele servidor realmente caro,

09:12.660 --> 09:14.550
dividi-lo em pequenos pedaços e distribuí-lo

09:14.550 --> 09:16.158
em máquinas virtuais para todos

09:16.158 --> 09:18.450
que quiserem usá-lo.

09:18.450 --> 09:20.816
Portanto, talvez possamos hospedar 50 ou 100

09:20.816 --> 09:24.480
blogs WordPress nesse único servidor, em vez de hospedar apenas um.

09:24.480 --> 09:26.760
Essa é a ideia de usar recursos compartilhados.

09:26.760 --> 09:28.330
Quando falamos de recursos compartilhados,

09:28.330 --> 09:30.697
estamos falando de reunir todo o hardware que compõe

09:30.697 --> 09:33.150
o data center do provedor de nuvem.

09:33.150 --> 09:35.215
Dessa forma, ele não é dedicado a um único indivíduo,

09:35.215 --> 09:37.987
mas todos nós podemos usá-lo com base na rápida elasticidade

09:37.987 --> 09:41.220
porque, esperamos, o que a Amazon, o Google e o Azure estão pensando é

09:41.220 --> 09:42.690
que, quando há períodos de alta

09:42.690 --> 09:44.970
demanda para a minha empresa, pode haver períodos

09:44.970 --> 09:48.090
de baixa demanda para a sua empresa e vice-versa.

09:48.090 --> 09:50.280
Assim, em vez de termos que ter recursos de hardware dedicados

09:50.280 --> 09:51.480
a cada uma de nossas empresas,

09:51.480 --> 09:54.009
podemos compartilhar recursos em toda a linha.

09:54.009 --> 09:55.500
E a característica final

09:55.500 --> 09:58.710
da nuvem é a capacidade de sincronização de arquivos.

09:58.710 --> 10:01.103
Agora, o melhor de usar um recurso baseado em nuvem

10:01.103 --> 10:02.760
é que você pode colocar algo em um

10:02.760 --> 10:04.649
lugar e, em seguida, espalhar para outros

10:04.649 --> 10:07.500
lugares com base em como você o configura.

10:07.500 --> 10:09.420
Por exemplo, em minha empresa, dependemos muito

10:09.420 --> 10:11.428
da sincronização de arquivos porque a maioria

10:11.428 --> 10:14.249
de nossos funcionários são, na verdade, funcionários remotos que

10:14.249 --> 10:17.640
trabalham em todo o mundo, não apenas em nossos próprios escritórios.

10:17.640 --> 10:18.473
Portanto, enquanto estou

10:18.473 --> 10:20.100
sentado aqui no meu escritório gravando isso

10:20.100 --> 10:22.830
agora, preciso de uma maneira de entregar esse arquivo ao meu designer gráfico

10:22.830 --> 10:24.690
para que ele possa criar todas as coisas diferentes

10:24.690 --> 10:27.060
que você está vendo na tela enquanto eu falo.

10:27.060 --> 10:28.260
Depois, ela vai enviar o vídeo

10:28.260 --> 10:31.320
para outro país, onde meu editor de vídeo está localizado.

10:31.320 --> 10:33.060
E, quando terminarem, eles enviarão o material de

10:33.060 --> 10:34.410
volta para o meu escritório, onde um dos

10:34.410 --> 10:36.870
meus funcionários fará as verificações de garantia de qualidade e,

10:36.870 --> 10:38.400
em seguida, enviaremos o material para outro

10:38.400 --> 10:39.300
país, que fará o upload para

10:39.300 --> 10:41.040
o site final, onde você poderá vê-lo.

10:41.040 --> 10:43.779
Portanto, esse vídeo viajou provavelmente por

10:43.779 --> 10:46.680
quatro ou cinco lugares diferentes para chegar ao

10:46.680 --> 10:49.470
produto final que você está vendo agora na tela.

10:49.470 --> 10:50.303
Essa é a ideia de sincronização

10:50.303 --> 10:52.950
de arquivos, porque quando eu gravo isso, estou gravando

10:52.950 --> 10:55.129
em um servidor de arquivos baseado em nuvem, todos

10:55.129 --> 10:57.780
na minha equipe podem acessar esse arquivo porque temos essa

10:57.780 --> 11:00.360
cópia sincronizada em todos os seus dispositivos e em todos

11:00.360 --> 11:03.030
os nossos servidores em todo o mundo para que possam acessá-lo

11:03.030 --> 11:05.430
e fazer o que precisam.

11:05.430 --> 11:06.630
E, enquanto eles fazem isso,

11:06.630 --> 11:08.190
a gravação não fica apenas no computador

11:08.190 --> 11:11.070
deles, mas é sincronizada em todos os nossos servidores em nuvem,

11:11.070 --> 11:13.710
de modo que todo o resto do caminho que precisa ser percorrido

11:13.710 --> 11:15.510
entre a gravação e a publicação, e depois

11:15.510 --> 11:16.920
você a assiste, pode acontecer

11:16.920 --> 11:20.730
em todos esses servidores de maneira muito simplificada.

11:20.730 --> 11:22.200
E esse é um dos grandes benefícios

11:22.200 --> 11:24.420
de usar a nuvem do ponto de vista comercial:

11:24.420 --> 11:26.970
você não tem um servidor no seu escritório.

11:26.970 --> 11:28.201
Agora, ele está na nuvem,

11:28.201 --> 11:31.650
em um data center protegido, altamente disponível, que pode

11:31.650 --> 11:32.980
ser escalonável e elástico

11:32.980 --> 11:34.617
para atender às demandas de

11:34.617 --> 11:37.740
períodos mais altos e mais baixos.

11:37.740 --> 11:39.015
Só temos que pagar pelo que

11:39.015 --> 11:41.177
usamos e podemos compartilhar recursos com outras

11:41.177 --> 11:42.537
pessoas que talvez nem conheçamos,

11:42.537 --> 11:45.480
pois estamos todos no mesmo servidor físico.

11:45.480 --> 11:46.820
E essas são todas as coisas de que

11:46.820 --> 11:49.110
estamos falando quando começamos a falar sobre as características

11:49.110 --> 11:50.970
da nuvem e por que tem havido essa grande migração

11:50.970 --> 11:53.740
para a nuvem por muitas empresas em todo o mundo