WEBVTT

00:00.090 --> 00:00.923
Instruktor: W dzisiejszych

00:00.923 --> 00:02.880
czasach chmurę obliczeniową można znaleźć wszędzie,

00:02.880 --> 00:05.580
a to naprawdę dlatego, że korzystanie z niej przynosi tak wiele wspaniałych

00:05.580 --> 00:07.290
korzyści.

00:07.290 --> 00:09.510
I właśnie na tym skupimy się w tej lekcji,

00:09.510 --> 00:10.343
gdy zaczniemy

00:10.343 --> 00:12.930
mówić o różnych cechach chmury.

00:12.930 --> 00:15.160
Kiedy mówimy o chmurze obliczeniowej, istnieje

00:15.160 --> 00:17.670
kilka korzyści lub cech, które widzimy, gdy decydujemy

00:17.670 --> 00:19.680
się na korzystanie z chmury.

00:19.680 --> 00:23.460
Obejmują one wysoką dostępność, skalowalność, elastyczność, mierzone

00:23.460 --> 00:24.750
wykorzystanie, współdzielone

00:24.750 --> 00:27.540
zasoby i synchronizację plików.

00:27.540 --> 00:29.040
Przyjrzyjmy się im.

00:29.040 --> 00:31.350
Po pierwsze, mamy wysoką dostępność.

00:31.350 --> 00:32.749
Teraz wysoka dostępność odnosi

00:32.749 --> 00:34.410
się do faktu, że usługi doświadczają

00:34.410 --> 00:37.800
bardzo niewielkich przestojów podczas korzystania z chmury.

00:37.800 --> 00:39.690
Wynika to z faktu, że większość usług

00:39.690 --> 00:41.670
tworzonych w chmurze jest wysoce niezawodna

00:41.670 --> 00:43.200
i odporna na błędy.

00:43.200 --> 00:45.900
Oznacza to, że możemy zapewnić wysoki poziom dostępności.

00:45.900 --> 00:47.610
Jeśli chodzi o dostępność,

00:47.610 --> 00:50.160
zwykle mierzymy ją w procentach czasu

00:50.160 --> 00:53.760
sprawności w stosunku do czasu przestoju.

00:53.760 --> 00:55.920
Na przykład, złotym standardem

00:55.920 --> 00:58.860
w sieciach jest pięć dziewiątek.

00:58.860 --> 01:02.970
Pięć dziewiątek oznacza 99. 999% czasu sprawności lub dostępności

01:02.970 --> 01:06.390
doświadczanej przez użytkowników końcowych.

01:06.390 --> 01:09.030
Oznacza to, że każdego roku możemy mieć tylko

01:09.030 --> 01:11.980
około pięciu minut i 15 sekund przestoju.

01:11.980 --> 01:15.090
Zgadza się, tylko pięć minut i 15

01:15.090 --> 01:18.570
sekund przez całe 365 dni w roku.

01:18.570 --> 01:20.400
Aby to zrobić, trzeba dysponować

01:20.400 --> 01:23.430
wysoce niezawodnymi i dostępnymi systemami.

01:23.430 --> 01:25.330
Jeśli więc masz jedną witrynę, będziesz

01:25.330 --> 01:29.123
mieć co najmniej dwa serwery internetowe, które ją hostują.

01:29.123 --> 01:30.300
Jeśli więc jeden z nich ulegnie

01:30.300 --> 01:32.160
awarii, drugi nadal przenosi obciążenie,

01:32.160 --> 01:35.730
co oznacza, że użytkownik końcowy nie doświadcza żadnych przestojów.

01:35.730 --> 01:36.690
O tym właśnie mówimy,

01:36.690 --> 01:38.640
gdy mówimy o wysokiej dostępności.

01:38.640 --> 01:42.210
Na przykład na mojej własnej stronie internetowej, diontraining. com, w rzeczywistości mamy bardzo

01:42.210 --> 01:44.760
wysoce dostępną konfigurację, która została

01:44.760 --> 01:47.280
stworzona przy użyciu usług w chmurze.

01:47.280 --> 01:50.070
Tak więc, w zależności od tego, skąd pochodzisz na świecie, dotrzesz

01:50.070 --> 01:51.060
do jednego z naszych wielu

01:51.060 --> 01:53.160
serwerów zlokalizowanych na całym świecie, który

01:53.160 --> 01:55.680
jest najbliżej ciebie, aby uzyskać lepsze wrażenia.

01:55.680 --> 01:57.627
Jeśli Twój serwer z jakiegoś powodu przestanie działać,

01:57.627 --> 02:00.300
zostaniesz automatycznie przekierowany na inny, który znajduje

02:00.300 --> 02:02.490
się nieco dalej od Ciebie, ale nadal działa.

02:02.490 --> 02:04.980
W ten sposób nadal otrzymujesz usługę, której

02:04.980 --> 02:08.460
szukasz, i jest to sposób na zapewnienie wysokiej dostępności.

02:08.460 --> 02:10.590
Drugą cechą chmury, o której będziemy

02:10.590 --> 02:12.480
mówić, jest skalowalność.

02:12.480 --> 02:15.150
Kiedy mówimy o skalowalności, chodzi

02:15.150 --> 02:17.370
o to, że możemy zwiększać liczbę

02:17.370 --> 02:19.080
osób lub liczbę rzeczy w naszym

02:19.080 --> 02:23.220
systemie w tempie liniowym lub mniej niż liniowym.

02:23.220 --> 02:24.053
Chcę przez to powiedzieć,

02:24.053 --> 02:26.850
że mam 100 użytkowników korzystających z mojego systemu, który

02:26.850 --> 02:28.620
kosztuje mnie 10 dolarów.

02:28.620 --> 02:31.282
Cóż, jeśli dodam 200 użytkowników do mojego systemu,

02:31.282 --> 02:35.010
powinno mnie to kosztować 20 USD lub mniej, a to byłaby skala liniowa.

02:35.010 --> 02:37.860
Teraz, gdybym przeszedł od 100 do 200 użytkowników,

02:37.860 --> 02:40.500
a cena wzrosłaby z 10 do 100 dolarów, byłaby

02:40.500 --> 02:42.240
to skala wykładnicza, a tego

02:42.240 --> 02:43.380
nie chcemy.

02:43.380 --> 02:45.180
Budując nasze systemy chmurowe, zawsze

02:45.180 --> 02:47.070
szukamy skalowalności, a to oznacza,

02:47.070 --> 02:49.860
że nawet jeśli dziś mamy tylko 10 użytkowników, jutro możemy

02:49.860 --> 02:51.090
mieć ich 100.

02:51.090 --> 02:52.590
Dzień później mamy 1000,

02:52.590 --> 02:55.260
dzień później możemy mieć 10 000 itd.

02:55.260 --> 02:56.093
Jeśli spojrzeć na

02:56.093 --> 02:58.800
niektóre z dużych firm, takich jak Facebook, Google,

02:58.800 --> 03:02.160
LinkedIn i UNI, mają one miliony użytkowników końcowych, którzy uzyskują

03:02.160 --> 03:04.710
dostęp do ich platform każdego dnia i są w stanie skalować

03:04.710 --> 03:07.422
się w oparciu o skalowalność usług w chmurze, ponieważ

03:07.422 --> 03:09.510
nie muszę iść i kupować kolejnego serwera

03:09.510 --> 03:10.710
o wartości 10 000 USD, aby

03:10.710 --> 03:14.490
umieścić go w moim lokalnym centrum danych, ponieważ zamiast tego mogę po prostu

03:14.490 --> 03:16.650
użyć Amazon i wykorzystać część ich możliwości,

03:16.650 --> 03:19.560
gdy tego potrzebuję.

03:19.560 --> 03:20.970
Jeśli chodzi o skalowalność,

03:20.970 --> 03:22.650
istnieją dwa sposoby skalowania.

03:22.650 --> 03:25.560
Jednym z nich jest skalowanie w górę, znane jako skalowanie pionowe.

03:25.560 --> 03:27.090
Polega to na dodaniu większej ilości

03:27.090 --> 03:29.010
zasobów do określonego serwera lub węzła.

03:29.010 --> 03:31.020
Na przykład, jeśli korzystasz z serwera opartego

03:31.020 --> 03:32.970
na chmurze, który ma dwa wirtualne procesory,

03:32.970 --> 03:35.730
możesz zwiększyć ich liczbę do czterech.

03:35.730 --> 03:37.170
To jest właśnie idea skalowania.

03:37.170 --> 03:38.610
Dodajesz więcej zasobów, niezależnie od

03:38.610 --> 03:41.040
tego, czy jest to więcej procesorów, więcej pamięci RAM, więcej pamięci

03:41.040 --> 03:43.110
masowej, więcej przepustowości, czy podobnych rzeczy.

03:43.110 --> 03:45.120
Teraz, z drugiej strony, można również skalować,

03:45.120 --> 03:47.100
co jest znane jako skalowanie poziome.

03:47.100 --> 03:49.440
W tym przypadku nadal używasz mniejszych maszyn,

03:49.440 --> 03:50.280
ale używasz ich więcej,

03:50.280 --> 03:53.400
wszystkie pracują w tandemie za load balancerem.

03:53.400 --> 03:55.080
Zamiast więc mieć jeden serwer obsługujący

03:55.080 --> 03:57.316
całe obciążenie i skalować go w górę poprzez zwiększanie

03:57.316 --> 04:00.180
liczby procesorów i pamięci, można zamiast tego skalować go w górę

04:00.180 --> 04:02.520
i przejść z jednego serwera na dwa serwery lub z dwóch

04:02.520 --> 04:05.970
serwerów na cztery, lub z czterech na osiem, i można nadal przesuwać się w górę,

04:05.970 --> 04:07.170
dodając dodatkowe serwery

04:07.170 --> 04:09.840
za load balancerem, za pomocą których można następnie obsługiwać

04:09.840 --> 04:11.940
dodatkowy ruch.

04:11.940 --> 04:13.710
To prowadzi nas do trzeciego obszaru,

04:13.710 --> 04:15.864
znanego jako szybka elastyczność.

04:15.864 --> 04:18.960
Kiedy mówimy o szybkiej elastyczności, mamy na myśli

04:18.960 --> 04:20.160
fakt, że możemy bardzo

04:20.160 --> 04:22.731
szybko skalować w górę lub w dół.

04:22.731 --> 04:25.454
Dzieje się tak, ponieważ używamy automatyzacji

04:25.454 --> 04:28.110
i orkiestracji z wieloma maszynami wirtualnymi

04:28.110 --> 04:29.970
na tych fizycznych serwerach, które

04:29.970 --> 04:32.220
są własnością Amazon, Google, Microsoft

04:32.220 --> 04:35.040
i innych korporacji, które pozwalają nam korzystać

04:35.040 --> 04:38.104
z części lub wszystkich ich usług na żądanie.

04:38.104 --> 04:41.040
A to daje nam tę szybką elastyczność.

04:41.040 --> 04:43.200
Kiedy słyszysz termin szybka elastyczność

04:43.200 --> 04:46.290
lub ogólnie elastyczność, pomyśl o tym jako o zdolności systemu

04:46.290 --> 04:48.785
do radzenia sobie ze zmianami popytu w czasie

04:48.785 --> 04:50.370
rzeczywistym.

04:50.370 --> 04:51.410
Wróćmy więc do przykładu korzystania

04:51.410 --> 04:54.780
z mojej strony internetowej pod adresem diontraining. com.

04:54.780 --> 04:56.490
Jeśli teraz sprawdzam moją stronę

04:56.490 --> 04:58.770
internetową i mam zalogowanych 1000 studentów,

04:58.770 --> 05:00.330
a za pięć minut sprawdzam i jest zalogowanych

05:00.330 --> 05:02.520
10 000 studentów, moje systemy są zaprojektowane

05:02.520 --> 05:03.774
tak, aby uruchamiać dodatkowe

05:03.774 --> 05:07.230
zasoby w chmurze i przenosić część obciążenia od tych nowych użytkowników

05:07.230 --> 05:10.230
na te dodatkowe usługi.

05:10.230 --> 05:12.810
Na tym polega idea szybkiej elastyczności.

05:12.810 --> 05:14.580
Ogólnie rzecz biorąc, gdy pracujesz w

05:14.580 --> 05:16.470
chmurze, jeśli prawidłowo zaprojektowałeś

05:16.470 --> 05:18.949
swoje systemy, masz możliwość szybkiego uzyskania elastyczności

05:18.949 --> 05:21.150
i bardzo szybkiego skalowania, a następnie, gdy

05:21.150 --> 05:23.520
zapotrzebowanie spadnie, możesz szybko pozbyć się

05:23.520 --> 05:24.750
tych dodatkowych serwerów

05:24.750 --> 05:27.120
i obniżyć ich wydajność.

05:27.120 --> 05:28.680
A powodem, dla którego chcesz to zrobić,

05:28.680 --> 05:31.166
jest to, że wszystkie te dodatkowe serwery będą kosztować więcej

05:31.166 --> 05:33.390
pieniędzy, a jeśli nie masz wystarczającej liczby użytkowników,

05:33.390 --> 05:34.500
aby je mieć, nie chcesz za to

05:34.500 --> 05:37.410
płacić, więc zamierzasz je zwolnić, oddać dostawcy usług, aby mógł następnie

05:37.410 --> 05:40.140
wynająć tę usługę komuś innemu.

05:40.140 --> 05:42.750
Zamiast tego, jeśli korzystasz z modelu on premise,

05:42.750 --> 05:45.000
powiedzmy, że mam dziś 1000 studentów.

05:45.000 --> 05:48.150
Cóż, dla 1000 studentów mogę potrzebować trzech serwerów internetowych.

05:48.150 --> 05:49.830
Ale jeśli dojdę do 10 000 studentów, będę potrzebował

05:49.830 --> 05:51.956
kolejnych 15 serwerów internetowych.

05:51.956 --> 05:55.080
Aby to zrobić, musiałbym kupić 15 dodatkowych serwerów.

05:55.080 --> 05:55.950
Musiałbym je ułożyć.

05:55.950 --> 05:57.270
Musiałbym zainstalować całe oprogramowanie,

05:57.270 --> 05:58.440
musiałbym je skonfigurować.

05:58.440 --> 05:59.580
Wszystko to wymaga czasu,

05:59.580 --> 06:02.222
więc nie jest to zbyt szybkie pod względem elastyczności,

06:02.222 --> 06:04.980
abyśmy mogli skalować, aby zaspokoić ten popyt.

06:04.980 --> 06:07.860
Jeśli masz bardzo wolno rozwijający się model biznesowy, to w porządku.

06:07.860 --> 06:10.200
Ale jeśli masz do czynienia z czymś, co ma dużą prędkość lub

06:10.200 --> 06:12.171
którąkolwiek z tych nowoczesnych platform mediów

06:12.171 --> 06:14.370
społecznościowych, a coś, co zrobiłeś, stało się wirusowe,

06:14.370 --> 06:16.920
a wszyscy wchodzą na twoją stronę internetową i zaczynają cię

06:16.920 --> 06:19.950
zalewać, jeśli nie masz możliwości szybkiego skalowania, stracisz możliwość

06:19.950 --> 06:22.052
przechwytywania ruchu pochodzącego z tego wirusowego

06:22.052 --> 06:23.880
incydentu.

06:23.880 --> 06:25.620
Dlatego chcesz mieć możliwość szybkiego

06:25.620 --> 06:27.360
i elastycznego tworzenia swoich

06:27.360 --> 06:29.700
rzeczy, a chmura nam na to pozwala.

06:29.700 --> 06:32.910
Czwarta rzecz, którą mamy, jest znana jako mierzone wykorzystanie.

06:32.910 --> 06:33.810
Teraz wracamy do naszej dyskusji

06:33.810 --> 06:36.510
na temat szybkiej elastyczności, którą właśnie przeprowadziliśmy.

06:36.510 --> 06:38.686
Teraz, kiedy mówimy o mierzonym wykorzystaniu,

06:38.686 --> 06:40.170
mówimy o tym, że płacimy

06:40.170 --> 06:43.800
za usługę na zasadzie płatności za użycie.

06:43.800 --> 06:46.650
Tak więc, gdy korzystamy z usługi pomiarowej, takiej jak baza danych,

06:46.650 --> 06:47.730
może ona naliczać nam opłaty

06:47.730 --> 06:49.170
w oparciu o liczbę użytkowników,

06:49.170 --> 06:52.050
liczbę połączeń lub liczbę przechowywanych danych.

06:52.050 --> 06:53.910
Zasadniczo opłaty są naliczane na

06:53.910 --> 06:56.910
podstawie rzeczywistego wykorzystania usługi.

06:56.910 --> 06:59.262
Robimy to w ujęciu sekundowym, minutowym,

06:59.262 --> 07:03.480
godzinowym, dziennym, a nawet miesięcznym.

07:03.480 --> 07:05.211
Na przykład, używam AWS Lambda

07:05.211 --> 07:08.153
do wielu moich automatyzacji i funkcji backendowych,

07:08.153 --> 07:11.010
a oni naliczają mi opłaty w oparciu o moje użycie.

07:11.010 --> 07:13.290
Teraz za każdy milion żądań pobierają

07:13.290 --> 07:14.760
ode mnie 20 centów.

07:14.760 --> 07:16.200
Jest to więc dla mnie bardzo skuteczny

07:16.200 --> 07:17.880
sposób na wykonanie automatyzacji, ponieważ

07:17.880 --> 07:20.092
jest to bardzo, bardzo tania rzecz.

07:20.092 --> 07:22.620
Mogę mieć miliony żądań i będzie mnie to

07:22.620 --> 07:24.960
kosztować tylko kilka dolarów, i taka

07:24.960 --> 07:27.090
jest idea usługi dozowanej.

07:27.090 --> 07:28.334
Inną rzeczą, którą można

07:28.334 --> 07:30.120
zobaczyć, jest czasami rozróżnienie

07:30.120 --> 07:33.000
między usługą mierzoną a usługą mierzoną.

07:33.000 --> 07:35.640
Teraz, kiedy mówimy o usługach mierzonych lub mierzonych,

07:35.640 --> 07:37.470
tak naprawdę mówimy o tym samym i jest

07:37.470 --> 07:38.700
to nasza zdolność do płacenia

07:38.700 --> 07:41.160
za coś na podstawie zużycia.

07:41.160 --> 07:42.840
Jest jednak pewna różnica.

07:42.840 --> 07:44.850
Kiedy korzystasz z usługi odmierzanej,

07:44.850 --> 07:46.073
płacisz za rzeczy w oparciu

07:46.073 --> 07:49.380
o rzeczywiste wykorzystanie tego, co zrobiłeś.

07:49.380 --> 07:50.213
Wystarczy pomyśleć

07:50.213 --> 07:52.500
o rachunku za wodę lub prąd w domu.

07:52.500 --> 07:53.880
Jeśli odkręciłeś wąż z wodą i napełniłeś

07:53.880 --> 07:55.650
basen w tym miesiącu, zapłacisz znacznie

07:55.650 --> 07:56.730
więcej za rachunek za wodę,

07:56.730 --> 07:59.670
ponieważ zużyłeś znacznie więcej wody.

07:59.670 --> 08:02.314
I odwrotnie, gdy masz do czynienia z mierzoną usługą, jest to bardziej

08:02.314 --> 08:04.950
podobne do planu taryfowego telefonu komórkowego.

08:04.950 --> 08:08.160
W większości miejsc użytkownik płaci miesięczną opłatę za określoną ilość korzystania

08:08.160 --> 08:10.740
z telefonu komórkowego, niezależnie od tego, czy jest to liczba

08:10.740 --> 08:14.100
wiadomości tekstowych, minut czy danych, które może wykorzystać.

08:14.100 --> 08:15.390
A gdy osiągniesz ten limit,

08:15.390 --> 08:17.790
zatrzymają twoją usługę i nie dadzą ci więcej, dopóki

08:17.790 --> 08:19.440
nie zapłacisz im ponownie.

08:19.440 --> 08:21.300
Kiedy więc myślisz o mierzonej usłudze,

08:21.300 --> 08:23.310
pomyśl o tym, że płacisz za określoną ilość

08:23.310 --> 08:25.920
z góry i niezależnie od tego, czy z niej korzystasz, czy

08:25.920 --> 08:27.660
nie, już za nią zapłaciłeś.

08:27.660 --> 08:28.493
Ale kiedy masz do czynienia

08:28.493 --> 08:30.420
z usługą odmierzaną, płacisz za dokładną ilość, którą

08:30.420 --> 08:31.253
zużywasz.

08:31.253 --> 08:33.480
I to jest tak naprawdę jedna z zalet korzystania z chmury,

08:33.480 --> 08:35.527
ponieważ większość rzeczy odbywa się na zasadzie

08:35.527 --> 08:37.883
pomiaru, gdzie płacisz tylko za to, czego używasz.

08:37.883 --> 08:41.160
Następną rzeczą, o której porozmawiamy, są współdzielone zasoby.

08:41.160 --> 08:43.740
Kiedy mówimy o współdzielonych zasobach, tak naprawdę mówimy

08:43.740 --> 08:46.530
o możliwości zminimalizowania naszych kosztów, ponieważ jesteśmy

08:46.530 --> 08:48.330
w stanie umieścić nasze maszyny wirtualne

08:48.330 --> 08:50.220
na cudzych serwerach.

08:50.220 --> 08:51.930
Jeśli spojrzeć na serwery, z

08:51.930 --> 08:54.238
których korzystamy w Amazon, Azure i Google

08:54.238 --> 08:56.022
Cloud, kosztują one 10, 20, 30

08:56.022 --> 08:58.980
000 USD za sztukę za serwer dobrej jakości.

08:58.980 --> 09:00.151
Jeśli więc musisz kupić jeden

09:00.151 --> 09:02.640
z nich, aby móc hostować swój blog WordPress, tak naprawdę nie wykorzystujesz

09:02.640 --> 09:04.680
całej tej pojemności, ponieważ jeśli masz tylko kilkuset

09:04.680 --> 09:06.420
czytelników, nie będzie to wymagało tak dużego

09:06.420 --> 09:08.100
obciążenia.

09:08.100 --> 09:10.020
Zamiast tego o wiele bardziej sensowne

09:10.020 --> 09:12.660
jest wzięcie tego jednego naprawdę drogiego serwera,

09:12.660 --> 09:14.550
pocięcie go na małe kawałki i rozdanie

09:14.550 --> 09:16.158
go w maszynach wirtualnych wszystkim,

09:16.158 --> 09:18.450
którzy chcą z niego korzystać.

09:18.450 --> 09:20.816
Możemy więc hostować 50 lub 100 blogów WordPress

09:20.816 --> 09:24.480
na tym jednym serwerze zamiast hostować tylko jeden.

09:24.480 --> 09:26.760
Na tym polega idea korzystania ze współdzielonych zasobów.

09:26.760 --> 09:28.330
Kiedy mówimy o współdzielonych

09:28.330 --> 09:30.697
zasobach, mamy na myśli zebranie całego sprzętu

09:30.697 --> 09:33.150
w centrum danych dostawcy chmury.

09:33.150 --> 09:35.215
W ten sposób nie jest on dedykowany jednej

09:35.215 --> 09:37.987
osobie, ale wszyscy możemy z niego korzystać w oparciu o

09:37.987 --> 09:41.220
szybką elastyczność, ponieważ, miejmy nadzieję, Amazon, Google

09:41.220 --> 09:42.690
i Azure myślą o tym, że kiedy są

09:42.690 --> 09:44.970
okresy wysokiego popytu dla mojej firmy, mogą

09:44.970 --> 09:48.090
być okresy niskiego popytu dla Twojej firmy i odwrotnie.

09:48.090 --> 09:50.280
Tak więc zamiast mieć dedykowane zasoby sprzętowe

09:50.280 --> 09:51.480
dla każdej z naszych firm, możemy

09:51.480 --> 09:54.009
współdzielić zasoby we wszystkich obszarach.

09:54.009 --> 09:55.500
Ostatnią cechą chmury

09:55.500 --> 09:58.710
jest możliwość synchronizacji plików.

09:58.710 --> 10:01.103
Wspaniałą rzeczą w korzystaniu z zasobów opartych na

10:01.103 --> 10:02.760
chmurze jest to, że można umieścić coś

10:02.760 --> 10:04.649
w jednym miejscu, a następnie rozprzestrzenić

10:04.649 --> 10:07.500
się w innych miejscach w zależności od konfiguracji.

10:07.500 --> 10:09.420
Przykładowo, w mojej firmie często polegamy

10:09.420 --> 10:11.428
na synchronizacji plików, ponieważ większość

10:11.428 --> 10:14.249
naszych pracowników to pracownicy zdalni, którzy pracują

10:14.249 --> 10:17.640
na całym świecie, a nie tylko w naszych biurach.

10:17.640 --> 10:18.473
Siedząc teraz w biurze

10:18.473 --> 10:20.100
i nagrywając to, potrzebuję sposobu na

10:20.100 --> 10:22.830
przekazanie tego pliku mojemu projektantowi graficznemu, aby

10:22.830 --> 10:24.690
mógł stworzyć wszystkie różne rzeczy, które

10:24.690 --> 10:27.060
widzisz na ekranie podczas mojej wypowiedzi.

10:27.060 --> 10:28.260
Następnie wyśle go do

10:28.260 --> 10:31.320
innego kraju, gdzie znajduje się mój edytor wideo.

10:31.320 --> 10:33.060
A kiedy skończą, wyślą go z powrotem do mojego

10:33.060 --> 10:34.410
biura, gdzie jeden z moich pracowników

10:34.410 --> 10:36.870
przeprowadzi kontrole jakości, a następnie wyślemy go do innego

10:36.870 --> 10:39.300
kraju, który następnie prześle go na ostateczną stronę, gdzie

10:39.300 --> 10:41.040
będzie można go zobaczyć.

10:41.040 --> 10:43.779
Tak więc to jedno wideo podróżowało prawdopodobnie

10:43.779 --> 10:46.680
do czterech lub pięciu różnych miejsc, aby stać się gotowym

10:46.680 --> 10:49.470
produktem, który widzisz teraz na ekranie.

10:49.470 --> 10:50.303
Jest to idea synchronizacji

10:50.303 --> 10:52.950
plików, ponieważ kiedy to nagrywam, nagrywam to na serwer plików

10:52.950 --> 10:55.129
w chmurze, każdy w moim zespole może uzyskać dostęp

10:55.129 --> 10:57.780
do tego pliku, ponieważ mamy tę zsynchronizowaną kopię na wszystkich

10:57.780 --> 11:00.360
ich urządzeniach i na wszystkich naszych serwerach na całym

11:00.360 --> 11:03.030
świecie, dzięki czemu mogą uzyskać do niego dostęp i robić to,

11:03.030 --> 11:05.430
czego potrzebują.

11:05.430 --> 11:06.630
A gdy to robią, nie siedzą

11:06.630 --> 11:08.190
tylko na swoim komputerze, ale są

11:08.190 --> 11:11.070
synchronizowane na wszystkich naszych serwerach w chmurze,

11:11.070 --> 11:13.710
więc wszystko inne na tej ścieżce, która musi się wydarzyć

11:13.710 --> 11:15.510
między nagrywaniem a publikowaniem,

11:15.510 --> 11:16.920
a następnie oglądaniem, może

11:16.920 --> 11:19.080
odbywać się na wszystkich tych serwerach w bardzo

11:19.080 --> 11:20.730
usprawniony sposób.

11:20.730 --> 11:22.200
Jest to jedna z największych korzyści

11:22.200 --> 11:24.420
płynących z korzystania z chmury z biznesowego punktu

11:24.420 --> 11:26.970
widzenia, ponieważ nie musisz mieć serwera w biurze.

11:26.970 --> 11:28.201
Teraz znajduje się

11:28.201 --> 11:31.650
w chmurze w centrum danych, które jest chronione, wysoce

11:31.650 --> 11:32.980
dostępne, skalowalne

11:32.980 --> 11:34.617
i może elastycznie reagować

11:34.617 --> 11:37.740
na wyższe i niższe wymagania.

11:37.740 --> 11:39.015
Musimy płacić tylko za to, czego

11:39.015 --> 11:41.177
używamy i możemy udostępniać zasoby innym osobom,

11:41.177 --> 11:42.537
których możemy nawet nie znać,

11:42.537 --> 11:45.480
ponieważ wszyscy siedzimy na tym samym serwerze fizycznym.

11:45.480 --> 11:46.820
I to są wszystkie rzeczy, o których

11:46.820 --> 11:49.110
mówimy, kiedy zaczynamy mówić o charakterystyce

11:49.110 --> 11:50.970
chmury i dlaczego nastąpiła tak duża migracja

11:50.970 --> 11:53.740
do chmury przez wiele firm na całym świecie