WEBVTT 00:00.090 --> 00:00.923 Instructeur: Tegenwoordig 00:00.923 --> 00:02.880 is cloud computing overal te vinden, en dat 00:02.880 --> 00:05.580 komt echt omdat er zoveel grote voordelen zitten aan het gebruik 00:05.580 --> 00:07.290 van cloud computing. 00:07.290 --> 00:09.510 En dat is waar we ons in deze les op gaan richten 00:09.510 --> 00:10.343 als we het gaan hebben 00:10.343 --> 00:12.930 over de verschillende kenmerken van de cloud. 00:12.930 --> 00:15.160 Als we het over cloud computing hebben, zijn er 00:15.160 --> 00:17.670 een handvol voordelen of kenmerken die we zien als we 00:17.670 --> 00:19.680 ervoor kiezen om de cloud te gebruiken. 00:19.680 --> 00:23.460 Deze omvatten hoge beschikbaarheid, schaalbaarheid, elasticiteit, 00:23.460 --> 00:24.750 gemeten gebruik, gedeelde 00:24.750 --> 00:27.540 bronnen en bestandssynchronisatie. 00:27.540 --> 00:29.040 Laten we deze eens bekijken. 00:29.040 --> 00:31.350 Ten eerste hebben we hoge beschikbaarheid. 00:31.350 --> 00:32.749 Hoge beschikbaarheid verwijst 00:32.749 --> 00:34.410 naar het feit dat services zeer weinig 00:34.410 --> 00:37.800 downtime ondervinden wanneer je de cloud gebruikt. 00:37.800 --> 00:39.690 Dit komt omdat de meeste diensten die 00:39.690 --> 00:41.670 in de cloud worden gebouwd, zeer betrouwbaar 00:41.670 --> 00:43.200 en fouttolerant zijn. 00:43.200 --> 00:45.900 Dit betekent dat we een hoge mate van beschikbaarheid kunnen garanderen. 00:45.900 --> 00:47.610 Nu, als het gaat om beschikbaarheid, 00:47.610 --> 00:50.160 meten we dit meestal in termen van een percentage 00:50.160 --> 00:53.760 van hoeveel uptime er is versus hoeveel downtime. 00:53.760 --> 00:55.920 Zo staat de gouden standaard binnen 00:55.920 --> 00:58.860 netwerken bekend als vijf negens. 00:58.860 --> 01:02.970 Vijf negens betekent 99. 999% uptime of beschikbaarheid 01:02.970 --> 01:06.390 zoals ervaren door uw eindgebruikers. 01:06.390 --> 01:09.030 Dit betekent dat we elk jaar slechts ongeveer vijf 01:09.030 --> 01:11.980 minuten en 15 seconden downtime kunnen hebben. 01:11.980 --> 01:15.090 Dat klopt, slechts vijf minuten en 15 seconden 01:15.090 --> 01:18.570 over de hele 365 dagen in een jaar. 01:18.570 --> 01:20.400 Om dat te kunnen doen, moet je beschikken 01:20.400 --> 01:23.430 over zeer betrouwbare systemen die zeer beschikbaar zijn. 01:23.430 --> 01:25.330 Dus als je één website hebt, heb 01:25.330 --> 01:28.290 je in feite minstens twee webservers die deze 01:28.290 --> 01:29.123 hosten. 01:29.123 --> 01:30.300 Dus als er één uitvalt, 01:30.300 --> 01:32.160 draagt de andere nog steeds de belasting 01:32.160 --> 01:35.730 en dat betekent dat de eindgebruiker geen downtime ervaart. 01:35.730 --> 01:36.690 Dat is waar we het over hebben 01:36.690 --> 01:38.640 als we het over hoge beschikbaarheid hebben. 01:38.640 --> 01:42.210 Bijvoorbeeld met mijn eigen website, diontraining. com hebben we eigenlijk een zeer 01:42.210 --> 01:44.760 hoog beschikbare opstelling die is gemaakt 01:44.760 --> 01:47.280 met behulp van cloudservices. 01:47.280 --> 01:50.070 Dus afhankelijk van waar je vandaan komt in de wereld, bereik 01:50.070 --> 01:51.060 je een van onze meerdere 01:51.060 --> 01:53.160 servers in de wereld die het dichtst bij jou 01:53.160 --> 01:55.680 in de buurt staat voor een betere ervaring. 01:55.680 --> 01:57.627 Als je server om de een of andere reden down is, 01:57.627 --> 02:00.300 word je automatisch omgeleid naar een andere server die iets verder 02:00.300 --> 02:02.490 bij je vandaan ligt, maar nog steeds up is. 02:02.490 --> 02:04.980 Op die manier krijg je nog steeds de service die je 02:04.980 --> 02:08.460 zoekt en dat is een manier om hoge beschikbaarheid te garanderen. 02:08.460 --> 02:10.590 Het tweede kenmerk van de cloud waar we het over gaan 02:10.590 --> 02:12.480 hebben staat bekend als schaalbaarheid. 02:12.480 --> 02:15.150 Als we het nu hebben over schaalbaarheid, dan 02:15.150 --> 02:17.370 hebben we het over het feit dat we het aantal 02:17.370 --> 02:19.080 mensen of het aantal dingen in 02:19.080 --> 02:23.220 ons systeem lineair of minder dan lineair kunnen verhogen. 02:23.220 --> 02:24.053 Wat ik daarmee bedoel 02:24.053 --> 02:26.850 is dat ik 100 gebruikers heb die mijn systeem gebruiken 02:26.850 --> 02:28.620 en dat het me $10 kost. 02:28.620 --> 02:31.282 Nou, als ik 200 gebruikers op mijn systeem zet, zou het 02:31.282 --> 02:35.010 me $20 of minder moeten kosten, en dat zou een lineaire schaal zijn. 02:35.010 --> 02:37.860 Als ik nu van 100 naar 200 gebruikers ga en de prijs 02:37.860 --> 02:40.500 gaat van $10 naar $100, dan zou dat een exponentiële 02:40.500 --> 02:43.380 schaal zijn en dat willen we niet. 02:43.380 --> 02:45.180 Dus terwijl we onze cloudsystemen uitbouwen, 02:45.180 --> 02:47.070 zijn we altijd op zoek naar schaalbaarheid, en dat 02:47.070 --> 02:49.860 betekent dat zelfs als we vandaag maar 10 gebruikers hebben, we er morgen 02:49.860 --> 02:51.090 misschien wel 100 hebben. 02:51.090 --> 02:52.590 De dag daarna hebben we er 1000, 02:52.590 --> 02:55.260 de dag daarna misschien 10.000, enzovoort. 02:55.260 --> 02:56.093 Als je kijkt naar 02:56.093 --> 02:58.800 een aantal grote bedrijven zoals Facebook en Google 02:58.800 --> 03:02.160 en LinkedIn en UNI, dan hebben zij miljoenen eindgebruikers die elke 03:02.160 --> 03:04.710 dag toegang hebben tot hun platformen en zij zijn in 03:04.710 --> 03:07.422 staat om op te schalen op basis van de schaalbaarheid 03:07.422 --> 03:09.510 van cloudservices, want ik hoef niet nog 03:09.510 --> 03:10.710 een server van $10.000 te 03:10.710 --> 03:12.990 kopen voor in mijn lokale datacenter, want in 03:12.990 --> 03:14.490 plaats daarvan kan ik gewoon die 03:14.490 --> 03:16.650 van Amazon gebruiken en een deel van hun capaciteit 03:16.650 --> 03:19.560 gebruiken als ik dat nodig heb. 03:19.560 --> 03:20.970 Wat schaalbaarheid betreft, zijn 03:20.970 --> 03:22.650 er twee manieren om te schalen. 03:22.650 --> 03:25.560 Eén daarvan is om op te schalen, wat bekend staat als verticale schaal. 03:25.560 --> 03:27.090 Dit gebeurt door meer bronnen toe 03:27.090 --> 03:29.010 te voegen aan een bepaalde server of node. 03:29.010 --> 03:31.020 Als je bijvoorbeeld een cloud-gebaseerde 03:31.020 --> 03:32.970 server gebruikt die twee virtuele CPU's 03:32.970 --> 03:35.730 heeft, kun je dat verhogen naar vier virtuele CPU's. 03:35.730 --> 03:37.170 Dit is het idee van schaalvergroting. 03:37.170 --> 03:38.610 Je voegt meer bronnen toe, of 03:38.610 --> 03:41.040 dat nu meer processors, meer RAM, meer opslag, meer 03:41.040 --> 03:43.110 bandbreedte of dat soort dingen zijn. 03:43.110 --> 03:45.120 Aan de andere kant kun je ook naar buiten schalen, 03:45.120 --> 03:47.100 wat bekend staat als horizontaal schalen. 03:47.100 --> 03:49.440 Hierbij gebruik je nog steeds kleinere machines, 03:49.440 --> 03:50.280 maar je gebruikt er 03:50.280 --> 03:53.400 meer die allemaal samenwerken achter een loadbalancer. 03:53.400 --> 03:55.080 Dus in plaats van één server te hebben die 03:55.080 --> 03:57.316 al je belasting afhandelt en naar boven te schalen 03:57.316 --> 04:00.180 door de CPU's en het geheugen te vergroten, kun je in plaats daarvan 04:00.180 --> 04:02.520 naar buiten schalen en van één server naar twee servers 04:02.520 --> 04:05.970 gaan, of van twee servers naar vier, of van vier naar acht, en je kunt naar buiten 04:05.970 --> 04:07.170 blijven schalen door extra 04:07.170 --> 04:09.840 servers toe te voegen achter je loadbalancer waarmee je dan 04:09.840 --> 04:11.940 extra verkeer kunt afhandelen. 04:11.940 --> 04:13.710 Dit brengt ons bij ons derde gebied, 04:13.710 --> 04:15.864 dat bekend staat als snelle elasticiteit. 04:15.864 --> 04:18.960 Als we het nu hebben over snelle elasticiteit, dan hebben 04:18.960 --> 04:20.160 we het over het feit dat 04:20.160 --> 04:22.731 we heel snel kunnen op- of afschalen. 04:22.731 --> 04:25.454 Dit wordt gedaan omdat we gebruik maken van automatisering 04:25.454 --> 04:28.110 en orkestratie met veel virtuele machines op deze 04:28.110 --> 04:29.970 fysieke servers die eigendom zijn 04:29.970 --> 04:32.220 van Amazon, Google, Microsoft en andere 04:32.220 --> 04:35.040 bedrijven die ons in staat stellen om delen of al hun 04:35.040 --> 04:38.104 diensten op aanvraag te gebruiken. 04:38.104 --> 04:41.040 En dit geeft ons die snelle elasticiteit. 04:41.040 --> 04:43.200 Als je de term snelle elasticiteit of elasticiteit 04:43.200 --> 04:46.290 in het algemeen hoort, denk dan aan het vermogen van het systeem 04:46.290 --> 04:48.785 om veranderingen in de vraag in realtime op te 04:48.785 --> 04:50.370 vangen. 04:50.370 --> 04:51.410 Laten we teruggaan naar het 04:51.410 --> 04:54.780 voorbeeld van mijn website diontraining. com. 04:54.780 --> 04:56.490 Als ik nu op mijn website kijk en er 04:56.490 --> 04:58.770 zijn 1000 studenten ingelogd, en ik kijk over 04:58.770 --> 05:00.330 vijf minuten en er zijn 10.000 05:00.330 --> 05:02.520 studenten ingelogd, dan zijn mijn systemen 05:02.520 --> 05:03.774 ontworpen om extra cloudresources 05:03.774 --> 05:07.230 op te starten en een deel van de belasting van die nieuwe gebruikers 05:07.230 --> 05:10.230 naar die extra services te duwen. 05:10.230 --> 05:12.810 Dat is het idee van snelle elasticiteit. 05:12.810 --> 05:14.580 Als je in de cloud werkt, heb je over 05:14.580 --> 05:16.470 het algemeen, als je je systemen goed 05:16.470 --> 05:18.949 hebt ontworpen, de mogelijkheid om snel elasticiteit 05:18.949 --> 05:21.150 te hebben en heel snel op te schalen, en op dezelfde 05:21.150 --> 05:24.750 manier, als de vraag wegvalt, kun je snel die extra servers wegdoen en 05:24.750 --> 05:27.120 ze weer terugbrengen. 05:27.120 --> 05:28.680 En de reden waarom je dat zou willen doen 05:28.680 --> 05:31.166 is omdat al die extra servers je meer geld gaan kosten, en 05:31.166 --> 05:33.390 als je niet genoeg gebruikers hebt om ze te hebben, 05:33.390 --> 05:34.500 wil je daar niet voor betalen, 05:34.500 --> 05:37.410 dus ga je ze vrijgeven en teruggeven aan je serviceprovider zodat 05:37.410 --> 05:40.140 zij die service aan iemand anders kunnen verhuren. 05:40.140 --> 05:42.750 In plaats daarvan, als je een on premise model gebruikt, 05:42.750 --> 05:45.000 stel dat ik vandaag 1000 studenten had. 05:45.000 --> 05:48.150 Nou, voor 1.000 studenten heb ik misschien drie webservers nodig. 05:48.150 --> 05:49.830 Maar als ik naar 10.000 studenten 05:49.830 --> 05:51.956 ga, heb ik nog eens 15 webservers nodig. 05:51.956 --> 05:55.080 Om dat te doen, zou ik 15 extra servers moeten kopen. 05:55.080 --> 05:55.950 Ik zou ze moeten rekken. 05:55.950 --> 05:57.270 Ik zou alle software moeten installeren, 05:57.270 --> 05:58.440 ik zou ze moeten configureren. 05:58.440 --> 05:59.580 Dat kost allemaal tijd, 05:59.580 --> 06:02.222 en dus is het niet erg snel in elasticiteitsmaatregelen 06:02.222 --> 06:04.980 voor ons om op te schalen om aan die vraag te voldoen. 06:04.980 --> 06:07.860 Als je een heel langzaam groeiend bedrijfsmodel hebt, is dat prima. 06:07.860 --> 06:10.200 Maar als je te maken hebt met iets dat een hoge snelheid 06:10.200 --> 06:12.171 heeft of een van deze moderne sociale mediaplatforms, 06:12.171 --> 06:14.370 en iets wat je hebt gedaan is viraal gegaan en iedereen 06:14.370 --> 06:16.920 gaat naar je website en begint je te overspoelen, als je niet 06:16.920 --> 06:19.050 de mogelijkheid hebt om snel op te schalen, zul je 06:19.050 --> 06:19.950 de mogelijkheid missen 06:19.950 --> 06:22.052 om het verkeer vast te leggen dat afkomstig is van 06:22.052 --> 06:23.880 dat viraal incident. 06:23.880 --> 06:25.620 En dus wil je in staat zijn om je spullen 06:25.620 --> 06:27.360 te bouwen op een snelle elastische manier, 06:27.360 --> 06:29.700 en dat is waar de cloud ons toe in staat stelt. 06:29.700 --> 06:32.910 Het vierde ding dat we hebben staat bekend als gedoseerd gebruik. 06:32.910 --> 06:33.810 Dit gaat terug naar 06:33.810 --> 06:36.510 de discussie over snelle elasticiteit die we net hadden. 06:36.510 --> 06:38.686 Als we het nu hebben over gedoseerd gebruik, 06:38.686 --> 06:40.170 dan hebben we het over het feit 06:40.170 --> 06:43.800 dat we betalen voor een dienst op basis van betalen per gebruik. 06:43.800 --> 06:46.650 Dus als we een gedoseerde service gebruiken, zoals een database, kunnen ze 06:46.650 --> 06:47.730 ons kosten in rekening brengen 06:47.730 --> 06:49.170 op basis van het aantal gebruikers of het 06:49.170 --> 06:52.050 aantal verbindingen, of het aantal gegevens dat wordt opgeslagen. 06:52.050 --> 06:53.910 In wezen worden we afgerekend op basis van 06:53.910 --> 06:56.910 het werkelijke gebruik van de service die wordt verbruikt. 06:56.910 --> 06:59.262 En dat doen we op secondebasis, minuutbasis, 06:59.262 --> 07:03.480 uurbasis, dagbasis of zelfs maandbasis. 07:03.480 --> 07:05.211 Ik gebruik bijvoorbeeld AWS Lambda 07:05.211 --> 07:08.153 voor veel van mijn back-end automatiseringen en functies, 07:08.153 --> 07:11.010 en ze rekenen me op basis van mijn gebruik. 07:11.010 --> 07:13.290 Voor elke miljoen aanvragen die ik doe, brengen 07:13.290 --> 07:14.760 ze me nu 20 cent in rekening. 07:14.760 --> 07:16.200 En dus is het voor mij een heel efficiënte 07:16.200 --> 07:17.880 manier om mijn automatiseringen te 07:17.880 --> 07:20.092 doen, omdat het heel weinig kost. 07:20.092 --> 07:22.620 Ik kan miljoenen en miljoenen aanvragen hebben 07:22.620 --> 07:24.960 en het zou me maar een paar dollar kosten, en dat 07:24.960 --> 07:27.090 is het idee van een bemeterde dienst. 07:27.090 --> 07:28.334 Wat je ook zult zien is 07:28.334 --> 07:30.120 dat er soms onderscheid wordt 07:30.120 --> 07:33.000 gemaakt tussen gemeten en gemeten diensten. 07:33.000 --> 07:35.640 Als we het hebben over gemeten diensten, hebben 07:35.640 --> 07:37.470 we het eigenlijk over hetzelfde en 07:37.470 --> 07:38.700 dat is ons vermogen om voor 07:38.700 --> 07:41.160 iets te betalen op basis van verbruik. 07:41.160 --> 07:42.840 Maar er is hier een verschil. 07:42.840 --> 07:44.850 Als je een service met meter gebruikt, 07:44.850 --> 07:46.073 betaal je voor dingen op 07:46.073 --> 07:49.380 basis van het werkelijke gebruik van wat je hebt gedaan. 07:49.380 --> 07:50.213 Dus als je denkt aan je 07:50.213 --> 07:52.500 waterrekening of je elektriciteitsrekening thuis. 07:52.500 --> 07:53.880 Als je deze maand je waterslang 07:53.880 --> 07:55.650 hebt aangezet en je zwembad hebt gevuld, 07:55.650 --> 07:56.730 ga je veel meer betalen voor 07:56.730 --> 07:59.670 je waterrekening omdat je veel meer water hebt gebruikt. 07:59.670 --> 08:02.314 Omgekeerd, als je te maken hebt met een gemeten service, 08:02.314 --> 08:04.950 lijkt dit meer op je mobiele telefoonabonnement. 08:04.950 --> 08:08.160 Op de meeste plaatsen betaal je een maandelijks bedrag voor een bepaalde 08:08.160 --> 08:10.740 hoeveelheid gebruik van die mobiele telefoon, of dat 08:10.740 --> 08:14.100 nu het aantal sms'jes, minuten of data is die je mag verbruiken. 08:14.100 --> 08:15.390 En als je die limiet hebt bereikt, 08:15.390 --> 08:17.790 stoppen ze je service en geven ze je niets meer tot 08:17.790 --> 08:19.440 je opnieuw betaalt. 08:19.440 --> 08:21.300 Dus als je denkt aan een gemeten dienst, denk 08:21.300 --> 08:23.310 dan aan het feit dat je vooraf betaalt voor een bepaalde 08:23.310 --> 08:25.920 hoeveelheid en of je er nu gebruik van maakt of niet, je hebt al 08:25.920 --> 08:27.660 betaald voor die hoeveelheid. 08:27.660 --> 08:28.493 Maar als je te maken hebt 08:28.493 --> 08:30.420 met service op meter, betaal je voor de exacte hoeveelheid 08:30.420 --> 08:31.253 die je gebruikt. 08:31.253 --> 08:33.480 En dit is echt een van de voordelen van het gebruik van de cloud, 08:33.480 --> 08:35.527 is dat de meeste dingen worden gedaan op een gedoseerde 08:35.527 --> 08:37.883 basis waarbij je alleen betaalt voor wat je gebruikt. 08:37.883 --> 08:41.160 Het volgende waar we het over gaan hebben is gedeelde bronnen. 08:41.160 --> 08:43.740 Als we het nu hebben over gedeelde bronnen, hebben we het 08:43.740 --> 08:46.530 echt over de mogelijkheid om onze kosten te minimaliseren omdat 08:46.530 --> 08:48.330 we onze virtuele machines op de servers 08:48.330 --> 08:50.220 van iemand anders kunnen zetten. 08:50.220 --> 08:51.930 Als je kijkt naar de servers die we 08:51.930 --> 08:54.238 gebruiken voor Amazon, Azure en Google Cloud, 08:54.238 --> 08:56.022 die dingen kosten 10, 20, 30.000 dollar 08:56.022 --> 08:58.980 per stuk voor een server van goede kwaliteit. 08:58.980 --> 09:00.151 En dus als je er zo eentje moet 09:00.151 --> 09:02.640 kopen om je WordPress blog te hosten, gebruik je niet 09:02.640 --> 09:04.680 echt al die capaciteit, want als je maar een paar 09:04.680 --> 09:06.420 honderd lezers hebt, zal het niet zoveel 09:06.420 --> 09:08.100 belasting gebruiken. 09:08.100 --> 09:10.020 In plaats daarvan is het veel logischer 09:10.020 --> 09:12.660 om die ene echt dure server te nemen, hem in kleine 09:12.660 --> 09:14.550 stukjes te knippen en hem in virtuele 09:14.550 --> 09:16.158 machines uit te delen aan iedereen 09:16.158 --> 09:18.450 die hem wil gebruiken. 09:18.450 --> 09:20.816 We kunnen dus 50 of 100 WordPress blogs 09:20.816 --> 09:24.480 hosten op die ene server in plaats van slechts één. 09:24.480 --> 09:26.760 Dat is het idee van het gebruik van gedeelde bronnen. 09:26.760 --> 09:28.330 Als we het hebben over gedeelde bronnen, 09:28.330 --> 09:30.697 hebben we het over het samenvoegen van alle hardware 09:30.697 --> 09:33.150 in het datacenter van de cloudaanbieder. 09:33.150 --> 09:35.215 En op die manier is het niet toegewijd aan één 09:35.215 --> 09:37.987 individu, maar kunnen we het allemaal gebruiken op basis van 09:37.987 --> 09:41.220 snelle elasticiteit omdat, hopelijk, wat Amazon en Google en Azure 09:41.220 --> 09:42.690 denken is dat wanneer er hoge periodes 09:42.690 --> 09:44.970 van vraag zijn voor mijn bedrijf, er misschien lage 09:44.970 --> 09:48.090 periodes zijn voor jouw bedrijf en vice versa. 09:48.090 --> 09:50.280 Dus in plaats van dat we voor elk van onze bedrijven specifieke 09:50.280 --> 09:51.480 hardwarebronnen moeten hebben, 09:51.480 --> 09:54.009 kunnen we over de hele linie bronnen delen. 09:54.009 --> 09:55.500 En het laatste kenmerk van de 09:55.500 --> 09:58.710 cloud is de mogelijkheid om bestanden te synchroniseren. 09:58.710 --> 10:01.103 Het mooie van het gebruik van cloudgebaseerde bronnen 10:01.103 --> 10:02.760 is dat je iets op één plek kunt zetten 10:02.760 --> 10:04.649 en dat het zich dan kan verspreiden naar 10:04.649 --> 10:07.500 andere plekken op basis van hoe je het configureert. 10:07.500 --> 10:09.420 In mijn bedrijf vertrouwen we bijvoorbeeld 10:09.420 --> 10:11.428 veel op bestandssynchronisatie omdat de 10:11.428 --> 10:14.249 meeste van onze mensen medewerkers op afstand zijn die over 10:14.249 --> 10:17.640 de hele wereld werken, niet alleen in onze eigen kantoren. 10:17.640 --> 10:18.473 Dus terwijl ik hier nu 10:18.473 --> 10:20.100 in mijn kantoor zit om dit op te nemen, heb 10:20.100 --> 10:22.830 ik een manier nodig om dit bestand aan mijn grafisch ontwerper te 10:22.830 --> 10:24.690 geven, zodat zij alle verschillende dingen 10:24.690 --> 10:27.060 kan maken die je op het scherm ziet terwijl ik praat. 10:27.060 --> 10:28.260 En dan gaat ze het naar een 10:28.260 --> 10:31.320 ander land sturen, waar mijn video-editor zich bevindt. 10:31.320 --> 10:33.060 En als ze klaar zijn, sturen ze het terug naar 10:33.060 --> 10:34.410 mijn kantoor waar een van mijn medewerkers 10:34.410 --> 10:36.870 onze kwaliteitscontroles uitvoert, en dan sturen we het naar 10:36.870 --> 10:38.400 een ander land die het uploadt naar de 10:38.400 --> 10:39.300 uiteindelijke site waar 10:39.300 --> 10:41.040 je het te zien krijgt. 10:41.040 --> 10:43.779 En dus heeft deze ene video waarschijnlijk naar vier 10:43.779 --> 10:46.680 of vijf verschillende plaatsen gereisd om het eindproduct 10:46.680 --> 10:49.470 te worden dat je nu op het scherm ziet. 10:49.470 --> 10:50.303 Dit is het idee van bestandssynchronisatie, 10:50.303 --> 10:52.950 want als ik dit opneem, neem ik het op naar een cloud-gebaseerde 10:52.950 --> 10:55.129 bestandsserver, iedereen in mijn team heeft toegang 10:55.129 --> 10:57.780 tot dat bestand omdat we die gesynchroniseerde kopie op al 10:57.780 --> 11:00.360 hun apparaten hebben en op al onze servers over de hele wereld, 11:00.360 --> 11:05.430 zodat ze er toegang toe hebben en kunnen doen wat ze moeten doen. 11:05.430 --> 11:06.630 En terwijl ze dat doen, staat 11:06.630 --> 11:08.190 het niet alleen op hun computer, 11:08.190 --> 11:11.070 maar wordt het gesynchroniseerd op al onze cloudservers, 11:11.070 --> 11:13.710 zodat alle andere handelingen die moeten gebeuren tussen 11:13.710 --> 11:15.510 het opnemen en publiceren, en vervolgens 11:15.510 --> 11:16.920 het bekijken, op een zeer gestroomlijnde 11:16.920 --> 11:20.730 manier kunnen gebeuren op al die servers. 11:20.730 --> 11:22.200 En dat is een van de grote voordelen 11:22.200 --> 11:24.420 van de cloud vanuit zakelijk oogpunt: je 11:24.420 --> 11:26.970 hebt geen server in je kantoor staan. 11:26.970 --> 11:28.201 Het bevindt zich nu 11:28.201 --> 11:31.650 in de cloud in een datacenter dat beschermd is, dat hoog 11:31.650 --> 11:32.980 beschikbaar is, dat schaalbaar 11:32.980 --> 11:34.617 is en dat elastisch kan reageren 11:34.617 --> 11:37.740 op hogere en lagere eisen. 11:37.740 --> 11:39.015 We hoeven alleen te betalen voor 11:39.015 --> 11:41.177 wat we gebruiken en we kunnen bronnen delen met andere 11:41.177 --> 11:42.537 mensen die we misschien niet eens 11:42.537 --> 11:45.480 kennen omdat we allemaal op dezelfde fysieke server zitten. 11:45.480 --> 11:46.820 En dit zijn allemaal dingen 11:46.820 --> 11:49.110 waar we het over hebben als we het over cloudkenmerken 11:49.110 --> 11:50.970 hebben en waarom veel bedrijven over de 11:50.970 --> 11:53.740 hele wereld naar de cloud zijn overgestapt.