WEBVTT

00:00.090 --> 00:00.923
Eğitmen: Bugünlerde

00:00.923 --> 00:02.880
bulut bilişim her yerde karşımıza çıkıyor

00:02.880 --> 00:05.580
ve bunun nedeni de bulut bilişim kullanmanın pek çok

00:05.580 --> 00:07.290
büyük faydası olması.

00:07.290 --> 00:09.510
Bulutun farklı özellikleri hakkında konuşmaya

00:09.510 --> 00:10.343
başlarken bu derste

00:10.343 --> 00:12.930
odaklanacağımız konu da bu olacak.

00:12.930 --> 00:15.160
Bulut bilişim hakkında konuştuğumuzda,

00:15.160 --> 00:17.670
bulutu kullanmayı seçtiğimizde gördüğümüz bir

00:17.670 --> 00:19.680
avuç fayda veya özellik vardır.

00:19.680 --> 00:23.460
Bunlar arasında yüksek kullanılabilirlik, ölçeklenebilirlik, esneklik,

00:23.460 --> 00:24.750
ölçülü kullanım, paylaşılan

00:24.750 --> 00:27.540
kaynaklar ve dosya senkronizasyonu yer alır.

00:27.540 --> 00:29.040
Bunlara bir göz atalım.

00:29.040 --> 00:31.350
İlk olarak, yüksek kullanılabilirliğe sahibiz.

00:31.350 --> 00:32.749
Şimdi, yüksek kullanılabilirlik,

00:32.749 --> 00:34.410
bulutu kullanırken hizmetlerin

00:34.410 --> 00:37.800
çok az kesinti yaşaması anlamına gelir.

00:37.800 --> 00:39.690
Bunun nedeni, bulut üzerinde inşa edilen hizmetlerin

00:39.690 --> 00:41.670
çoğunun son derece güvenilir ve hataya karşı çok toleranslı

00:41.670 --> 00:43.200
olacak şekilde inşa edilmiş olmasıdır.

00:43.200 --> 00:45.900
Bu, yüksek düzeyde kullanılabilirlik sağlayabileceğimiz anlamına gelir.

00:45.900 --> 00:47.610
Şimdi, kullanılabilirlik söz konusu

00:47.610 --> 00:50.160
olduğunda, bunu genellikle ne kadar kesinti süresine

00:50.160 --> 00:53.760
karşılık ne kadar çalışma süresi olduğu yüzdesi cinsinden ölçeriz.

00:53.760 --> 00:55.920
Örneğin, ağların içindeki altın

00:55.920 --> 00:58.860
standart beş dokuz olarak bilinir.

00:58.860 --> 01:02.970
Beş dokuz, 99 demek. 999 çalışma süresi veya son kullanıcılarınız

01:02.970 --> 01:06.390
tarafından deneyimlenen kullanılabilirlik.

01:06.390 --> 01:09.030
Bu da her yıl sadece beş dakika 15 saniye kesinti

01:09.030 --> 01:11.980
yaşayabileceğimiz anlamına geliyor.

01:11.980 --> 01:15.090
Bu doğru, bir yıldaki 365 günün tamamında

01:15.090 --> 01:18.570
sadece beş dakika ve 15 saniye.

01:18.570 --> 01:20.400
Şimdi bunu yapmak için, yüksek düzeyde kullanılabilir

01:20.400 --> 01:23.430
olan son derece güvenilir sistemlere sahip olmanız gerektiği anlamına geliyor.

01:23.430 --> 01:25.330
Yani bir web siteniz varsa, aslında

01:25.330 --> 01:29.123
bunu barındıran en az iki web sunucunuz olacaktır.

01:29.123 --> 01:30.300
Yani biri devre dışı kalırsa

01:30.300 --> 01:32.160
diğeri yükü taşımaya devam eder ve bu da

01:32.160 --> 01:35.730
son kullanıcının herhangi bir kesinti yaşamayacağı anlamına gelir.

01:35.730 --> 01:36.690
Yüksek kullanılabilirlikten

01:36.690 --> 01:38.640
bahsederken de bundan bahsediyoruz.

01:38.640 --> 01:42.210
Örneğin, kendi web sitem olan diontraining ile. com olarak, bulut hizmetleri kullanılarak

01:42.210 --> 01:44.760
oluşturulmuş çok yüksek kullanılabilirliğe

01:44.760 --> 01:47.280
sahip bir kurulumumuz var.

01:47.280 --> 01:50.070
Dolayısıyla, dünyanın neresinden geldiğinize bağlı olarak, daha

01:50.070 --> 01:51.060
iyi bir deneyim elde etmek

01:51.060 --> 01:53.160
için dünyanın dört bir yanında bulunan birden fazla

01:53.160 --> 01:55.680
sunucumuzdan size en yakın olanına ulaşacaksınız.

01:55.680 --> 01:57.627
Şimdi, eğer sunucunuz herhangi bir nedenle çalışmıyorsa,

01:57.627 --> 02:00.300
otomatik olarak sizden biraz daha uzakta olan başka bir sunucuya yönlendirilirsiniz,

02:00.300 --> 02:02.490
ancak sunucu hala çalışır durumdadır.

02:02.490 --> 02:04.980
Bu şekilde, aradığınız hizmeti almaya devam edersiniz

02:04.980 --> 02:08.460
ve bu da yüksek kullanılabilirliği sağlamanın bir yoludur.

02:08.460 --> 02:10.590
Bulutun bahsedeceğimiz ikinci özelliği

02:10.590 --> 02:12.480
ölçeklenebilirlik olarak bilinir.

02:12.480 --> 02:15.150
Şimdi, ölçeklenebilirlikten bahsettiğimizde, bu,

02:15.150 --> 02:17.370
sistemimizdeki insan sayısını veya nesne

02:17.370 --> 02:19.080
sayısını doğrusal bir oranda veya

02:19.080 --> 02:23.220
doğrusal bir orandan daha az artırabileceğimiz gerçeğinden bahsediyor.

02:23.220 --> 02:24.053
Bununla kastettiğim

02:24.053 --> 02:26.850
şey, diyelim ki sistemimi kullanan 100 kullanıcım var ve

02:26.850 --> 02:28.620
bu bana 10 dolara mal oluyor.

02:28.620 --> 02:31.282
Sistemime 200 kullanıcı koyarsam, bana 20

02:31.282 --> 02:35.010
dolar veya daha azına mal olur ve bu doğrusal bir ölçek olur.

02:35.010 --> 02:37.860
Şimdi, 100 kullanıcıdan 200 kullanıcıya çıkarsam

02:37.860 --> 02:40.500
ve fiyat 10 dolardan 100 dolara çıkarsa, bu

02:40.500 --> 02:43.380
üstel bir ölçek olur ve bunu istemeyiz.

02:43.380 --> 02:45.180
Dolayısıyla bulut sistemlerimizi oluştururken

02:45.180 --> 02:47.070
her zaman ölçeklenebilirlik arıyoruz ve bu da bugün

02:47.070 --> 02:49.860
sadece 10 kullanıcımız olsa bile yarın 100 kullanıcımız olabileceği

02:49.860 --> 02:51.090
anlamına geliyor.

02:51.090 --> 02:52.590
Ondan sonraki gün 1.000, ondan

02:52.590 --> 02:55.260
sonraki gün 10.000 ve bu şekilde devam edebilir.

02:55.260 --> 02:56.093
Facebook, Google,

02:56.093 --> 02:58.800
LinkedIn ve UNI gibi bazı büyük şirketlere bakarsanız,

02:58.800 --> 03:02.160
her gün platformlarına erişen milyonlarca son kullanıcıya sahip

03:02.160 --> 03:04.710
olduklarını ve bulut hizmetlerinin ölçeklenebilirliğine

03:04.710 --> 03:07.422
dayalı olarak ölçeklenebildiklerini görürsünüz, çünkü

03:07.422 --> 03:10.710
gidip yerel veri merkezime koymak için 10.000 dolarlık bir sunucu

03:10.710 --> 03:14.490
daha satın almam gerekmiyor, bunun yerine Amazon'unkini kullanabilir ve

03:14.490 --> 03:16.650
ihtiyacım olduğunda kapasitelerinin bir

03:16.650 --> 03:19.560
kısmını kullanabilirim.

03:19.560 --> 03:20.970
Şimdi, ölçeklenebilirlik söz konusu olduğunda,

03:20.970 --> 03:22.650
ölçeklendirmenin iki yolu vardır.

03:22.650 --> 03:25.560
Birincisi, dikey ölçek olarak bilinen yukarı doğru ölçeklendirmedir.

03:25.560 --> 03:27.090
Bu, belirli bir sunucuya veya düğüme

03:27.090 --> 03:29.010
daha fazla kaynak eklemektir.

03:29.010 --> 03:31.020
Örneğin, iki sanal CPU'ya sahip bulut tabanlı

03:31.020 --> 03:32.970
bir sunucu kullanıyorsanız, bunu aslında

03:32.970 --> 03:35.730
dört sanal CPU'ya çıkarabilirsiniz.

03:35.730 --> 03:37.170
Bu, ölçek büyütme fikridir.

03:37.170 --> 03:38.610
Daha fazla işlemci, daha fazla RAM, daha

03:38.610 --> 03:41.040
fazla depolama alanı, daha fazla bant genişliği veya bunun gibi

03:41.040 --> 03:43.110
şeyler olsun, daha fazla kaynak ekliyorsunuz.

03:43.110 --> 03:45.120
Öte yandan, yatay ölçeklendirme olarak bilinen dışarı

03:45.120 --> 03:47.100
doğru ölçeklendirme de yapabilirsiniz.

03:47.100 --> 03:49.440
Bu, hala daha küçük makineler kullandığınız, ancak bir

03:49.440 --> 03:50.280
yük dengeleyicinin

03:50.280 --> 03:53.400
arkasında birlikte çalışan daha fazla makine kullandığınız yerdir.

03:53.400 --> 03:55.080
Dolayısıyla, tüm yükünüzü yöneten tek

03:55.080 --> 03:57.316
bir sunucuya sahip olmak ve CPU'ları ve belleği artırarak

03:57.316 --> 04:00.180
yukarı doğru ölçeklendirmek yerine, bunun yerine ölçeklendirebilir

04:00.180 --> 04:02.520
ve bir sunucudan iki sunucuya veya iki sunucudan dörde

04:02.520 --> 04:05.970
veya dörtten sekize geçebilir ve yük dengeleyicinizin arkasına daha sonra

04:05.970 --> 04:07.170
ek trafikle başa çıkabileceğiniz

04:07.170 --> 04:11.940
ek sunucular ekleyerek dışarı doğru ilerlemeye devam edebilirsiniz.

04:11.940 --> 04:13.710
Şimdi, bu bizi hızlı esneklik olarak

04:13.710 --> 04:15.864
bilinen üçüncü alanımıza getiriyor.

04:15.864 --> 04:18.960
Şimdi, hızlı esneklikten bahsettiğimizde, çok hızlı bir şekilde

04:18.960 --> 04:20.160
ölçek büyütebileceğimiz

04:20.160 --> 04:22.731
veya küçültebileceğimiz gerçeğinden bahsediyoruz.

04:22.731 --> 04:25.454
Şimdi bunu yapıyoruz çünkü Amazon, Google, Microsoft

04:25.454 --> 04:28.110
ve diğer şirketlere ait olan bu fiziksel sunuculardaki

04:28.110 --> 04:29.970
çok sayıda sanal makineyle otomasyon

04:29.970 --> 04:32.220
ve orkestrasyon kullanıyoruz ve bu da hizmetlerinin

04:32.220 --> 04:35.040
bir kısmını veya tamamını talep üzerine kullanmamıza

04:35.040 --> 04:38.104
olanak tanıyor.

04:38.104 --> 04:41.040
Bu da bize hızlı bir esneklik sağlıyor.

04:41.040 --> 04:43.200
Hızlı esneklik veya genel olarak esneklik

04:43.200 --> 04:46.290
terimini duyduğunuzda, bunu sistemin talepteki değişiklikleri

04:46.290 --> 04:48.785
gerçek zamanlı olarak ele alma yeteneği olarak

04:48.785 --> 04:50.370
düşünün.

04:50.370 --> 04:51.410
Şimdi diontraining adresindeki

04:51.410 --> 04:54.780
web sitemi kullanma örneğine geri dönelim. com.

04:54.780 --> 04:56.490
Şu anda web sitemi kontrol ettiğimde

04:56.490 --> 04:58.770
1.000 öğrenci giriş yapmışsa ve beş dakika

04:58.770 --> 05:00.330
sonra kontrol ettiğimde 10.000

05:00.330 --> 05:02.520
öğrenci giriş yapmışsa, sistemlerim ek bulut

05:02.520 --> 05:03.774
kaynaklarını çalıştırmak

05:03.774 --> 05:07.230
ve bu yeni kullanıcılardan gelen yükün bir kısmını bu ek hizmetlere

05:07.230 --> 05:10.230
aktarmak üzere tasarlanmıştır.

05:10.230 --> 05:12.810
Hızlı esneklik fikri budur.

05:12.810 --> 05:14.580
Genel olarak, bulutta çalışırken, sistemlerinizi

05:14.580 --> 05:16.470
doğru tasarladıysanız, hızlı bir şekilde

05:16.470 --> 05:18.949
esnekliğe sahip olma ve çok hızlı ölçeklendirme yeteneğine

05:18.949 --> 05:21.150
sahip olursunuz ve benzer şekilde, talep azaldığında,

05:21.150 --> 05:27.120
bu ekstra sunuculardan hızlı bir şekilde kurtulabilir ve onları geri indirebilirsiniz.

05:27.120 --> 05:28.680
Bunu yapmak istemenizin nedeni, tüm bu ekstra

05:28.680 --> 05:31.166
sunucuların size daha fazla paraya mal olacak olması ve bunlara

05:31.166 --> 05:33.390
sahip olmak için yeterli kullanıcınız yoksa, bunun için

05:33.390 --> 05:34.500
ödeme yapmak istememenizdir,

05:34.500 --> 05:36.510
bu nedenle bunları serbest bırakacak, hizmet sağlayıcınıza

05:36.510 --> 05:37.410
geri vereceksiniz, böylece

05:37.410 --> 05:40.140
bu hizmeti başka birine kiralayabilirler.

05:40.140 --> 05:42.750
Bunun yerine, yerleşik bir model yapıyorsanız,

05:42.750 --> 05:45.000
diyelim ki bugün 1.000 öğrencim vardı.

05:45.000 --> 05:48.150
1.000 öğrenci için üç web sunucusuna ihtiyacım olabilir.

05:48.150 --> 05:49.830
Ama 10.000 öğrenciye ulaşırsam,

05:49.830 --> 05:51.956
15 web sunucusuna daha ihtiyacım olacak.

05:51.956 --> 05:55.080
Bunu yapmak için 15 sunucu daha satın almam gerekecek.

05:55.080 --> 05:55.950
Onları rafa kaldırmam gerekecek.

05:55.950 --> 05:57.270
Tüm yazılımları yüklemem, yapılandırmam

05:57.270 --> 05:58.440
gerekecekti.

05:58.440 --> 05:59.580
Tüm bunlar zaman alıyor

05:59.580 --> 06:02.222
ve bu nedenle bu talebi karşılamak için ölçek büyütebilmemiz

06:02.222 --> 06:04.980
esneklik ölçütlerinde çok hızlı değil.

06:04.980 --> 06:07.860
Eğer çok yavaş büyüyen bir iş modeliniz varsa, sorun değil.

06:07.860 --> 06:10.200
Ancak yüksek hızlı bir şeyle veya bu modern sosyal

06:10.200 --> 06:12.171
medya platformlarından herhangi biriyle

06:12.171 --> 06:14.370
uğraşıyorsanız ve yaptığınız bir şey viral olduysa

06:14.370 --> 06:16.920
ve herkes web sitenize gidip size akın etmeye başladıysa,

06:16.920 --> 06:19.950
hızlı bir şekilde ölçeklendirme yeteneğiniz yoksa, bu viral olaydan

06:19.950 --> 06:23.880
gelen trafiği yakalama yeteneğini kaçıracaksınız.

06:23.880 --> 06:25.620
Bu nedenle, ürünlerinizi hızlı ve

06:25.620 --> 06:27.360
esnek bir şekilde oluşturabilmek

06:27.360 --> 06:29.700
istiyorsunuz ve bulut da bize bunu sağlıyor.

06:29.700 --> 06:32.910
Sahip olduğumuz dördüncü şey ölçülü kullanım olarak bilinir.

06:32.910 --> 06:33.810
Şimdi bu, az önce yaptığımız

06:33.810 --> 06:36.510
hızlı esneklik tartışmasına geri dönüyor.

06:36.510 --> 06:38.686
Şimdi, ölçülü kullanımdan bahsederken,

06:38.686 --> 06:40.170
kullanım başına ödeme esasına

06:40.170 --> 06:43.800
göre bir hizmet için ödeme yaptığımız gerçeğinden bahsediyoruz.

06:43.800 --> 06:46.650
Dolayısıyla, veritabanı gibi ölçülü bir hizmet kullandığımızda,

06:46.650 --> 06:47.730
kullanıcı sayısına veya

06:47.730 --> 06:49.170
bağlantı sayısına ya da depolanan

06:49.170 --> 06:52.050
veri sayısına göre bizi ücretlendirebilirler.

06:52.050 --> 06:53.910
Esasen, tüketilen hizmetin gerçek

06:53.910 --> 06:56.910
kullanımına göre ücretlendiriliyoruz.

06:56.910 --> 06:59.262
Ve bunu saniye bazında, dakika bazında,

06:59.262 --> 07:03.480
saat bazında veya günlük bazda, hatta aylık bazda yapıyoruz.

07:03.480 --> 07:05.211
Örneğin, arka uç otomasyonlarımın

07:05.211 --> 07:08.153
ve işlevlerimin çoğu için AWS Lambda kullanıyorum ve

07:08.153 --> 07:11.010
beni kullanımıma göre ücretlendiriyorlar.

07:11.010 --> 07:13.290
Şimdi yaptığım her bir milyon talep için benden

07:13.290 --> 07:14.760
20 sent alıyorlar.

07:14.760 --> 07:16.200
Bu yüzden otomasyonlarımı

07:16.200 --> 07:17.880
yapmam için çok verimli bir yol

07:17.880 --> 07:20.092
çünkü çok düşük maliyetli bir şey.

07:20.092 --> 07:22.620
Milyonlarca ve milyonlarca talebim olabilir

07:22.620 --> 07:24.960
ve bu bana sadece birkaç dolara mal olur ve

07:24.960 --> 07:27.090
ölçülü bir hizmet fikri de budur.

07:27.090 --> 07:28.334
Şimdi, göreceğiniz diğer

07:28.334 --> 07:30.120
bir şey de bazen ölçülü hizmet ile

07:30.120 --> 07:33.000
ölçülen hizmet arasında bir ayrım göreceksiniz.

07:33.000 --> 07:35.640
Şimdi, ölçülü veya ölçülen hizmetlerden bahsettiğimizde,

07:35.640 --> 07:37.470
aslında aynı şeyden bahsediyoruz ve

07:37.470 --> 07:38.700
bu, tüketim temelinde bir

07:38.700 --> 07:41.160
şey için ödeme yapma yeteneğimizdir.

07:41.160 --> 07:42.840
Ancak burada bir fark var.

07:42.840 --> 07:44.850
Ölçülü bir hizmet kullandığınızda,

07:44.850 --> 07:46.073
yaptığınız gerçek

07:46.073 --> 07:49.380
kullanıma göre ödeme yaparsınız.

07:49.380 --> 07:50.213
Yani evinizdeki su faturanızı

07:50.213 --> 07:52.500
ya da elektrik faturanızı düşünürseniz.

07:52.500 --> 07:53.880
Bu ay su hortumunuzu açtıysanız

07:53.880 --> 07:55.650
ve yüzme havuzunuzu doldurduysanız, çok

07:55.650 --> 07:56.730
daha fazla su kullandığınız

07:56.730 --> 07:59.670
için su faturanız için çok daha fazla ödeme yapacaksınız.

07:59.670 --> 08:02.314
Buna karşılık, ölçülen bir hizmetle anlaştığınızda,

08:02.314 --> 08:04.950
bu daha çok cep telefonu planınıza benzer.

08:04.950 --> 08:08.160
Çoğu yerde, cep telefonunuzu belirli bir miktarda kullanmak

08:08.160 --> 08:10.740
için aylık bir ücret ödersiniz; bu, kullanmanıza

08:10.740 --> 08:13.170
izin verilen kısa mesaj, dakika veya veri sayısı

08:13.170 --> 08:14.100
olabilir.

08:14.100 --> 08:15.390
Ve bu limite ulaştığınızda, hizmetinizi

08:15.390 --> 08:17.790
durdururlar ve siz tekrar ödeme yapana kadar size daha

08:17.790 --> 08:19.440
fazla hizmet vermezler.

08:19.440 --> 08:21.300
Dolayısıyla, ölçülen bir hizmeti düşündüğünüzde,

08:21.300 --> 08:23.310
belirli bir miktar için önceden ödeme yaptığınızı

08:23.310 --> 08:25.920
ve kullansanız da kullanmasanız da bu miktar için zaten ödeme

08:25.920 --> 08:27.660
yapmış olduğunuzu düşünün.

08:27.660 --> 08:28.493
Ancak sayaçlı hizmet söz

08:28.493 --> 08:30.420
konusu olduğunda, tam olarak kullandığınız miktar için

08:30.420 --> 08:31.253
ödeme yaparsınız.

08:31.253 --> 08:33.480
Bulut kullanmanın avantajlarından biri de çoğu

08:33.480 --> 08:35.527
şeyin ölçülü olarak yapılması ve yalnızca

08:35.527 --> 08:37.883
kullandığınız kadar ödeme yapmanızdır.

08:37.883 --> 08:41.160
Bir sonraki konuşacağımız konu ise paylaşılan kaynaklar.

08:41.160 --> 08:43.740
Şimdi, paylaşılan kaynaklar hakkında konuştuğumuzda,

08:43.740 --> 08:46.530
sanal makinelerimizi başka birinin sunucularına koyabildiğimiz

08:46.530 --> 08:48.330
için gerçekten maliyetimizi en aza indirme

08:48.330 --> 08:50.220
yeteneğinden bahsediyoruz.

08:50.220 --> 08:51.930
Amazon, Azure ve Google Cloud için

08:51.930 --> 08:54.238
kullandığımız sunuculara baktığınızda, bunların

08:54.238 --> 08:56.022
kaliteli bir sunucu için parça başına

08:56.022 --> 08:58.980
10, 20, 30.000 dolar olduğunu görürsünüz.

08:58.980 --> 09:00.151
WordPress blogunuzu barındırmak

09:00.151 --> 09:02.640
için bunlardan birini satın almanız gerekiyorsa, aslında tüm

09:02.640 --> 09:04.680
kapasiteyi kullanmıyorsunuz demektir, çünkü yalnızca

09:04.680 --> 09:06.420
birkaç yüz okuyucunuz varsa, o kadar fazla

09:06.420 --> 09:08.100
yük kullanmayacaktır.

09:08.100 --> 09:10.020
Bunun yerine, gerçekten pahalı

09:10.020 --> 09:12.660
olan bu sunucuyu alıp küçük parçalara ayırmak

09:12.660 --> 09:14.550
ve sanal makineler halinde kullanmak

09:14.550 --> 09:16.158
isteyen herkese dağıtmak

09:16.158 --> 09:18.450
çok daha mantıklıdır.

09:18.450 --> 09:20.816
Böylece tek bir sunucuda bir tane barındırmak

09:20.816 --> 09:24.480
yerine 50 veya 100 WordPress blogu barındırabiliriz.

09:24.480 --> 09:26.760
Paylaşılan kaynakları kullanma fikri budur.

09:26.760 --> 09:28.330
Paylaşılan kaynaklardan bahsederken,

09:28.330 --> 09:30.697
bulut sağlayıcısının veri merkezini oluşturan tüm donanımın

09:30.697 --> 09:33.150
bir araya getirilmesinden bahsediyoruz.

09:33.150 --> 09:35.215
Ve bu şekilde tek bir kişiye adanmış olmaz,

09:35.215 --> 09:37.987
ancak hepimiz hızlı esnekliğe dayalı olarak kullanabiliriz

09:37.987 --> 09:41.220
çünkü umarım Amazon, Google ve Azure'un düşündüğü şey, benim şirketim

09:41.220 --> 09:42.690
için yüksek talep dönemleri olduğunda,

09:42.690 --> 09:44.970
sizin şirketiniz için düşük dönemler olabilir

09:44.970 --> 09:48.090
ve bunun tersi de geçerlidir.

09:48.090 --> 09:50.280
Böylece her bir şirketimiz için özel donanım kaynaklarına

09:50.280 --> 09:51.480
sahip olmak yerine, kaynakları

09:51.480 --> 09:54.009
yönetim kurulu genelinde paylaşabiliyoruz.

09:54.009 --> 09:55.500
Bulutun son özelliği

09:55.500 --> 09:58.710
ise dosya senkronizasyonu yapabilmesidir.

09:58.710 --> 10:01.103
Bulut tabanlı bir kaynak kullanmanın en güzel yanı,

10:01.103 --> 10:02.760
bir şeyi tek bir yere koyabilmeniz

10:02.760 --> 10:04.649
ve daha sonra onu nasıl yapılandırdığınıza

10:04.649 --> 10:07.500
bağlı olarak başka yerlere yayılabilmesidir.

10:07.500 --> 10:09.420
Örneğin, benim şirketimde dosya senkronizasyonuna

10:09.420 --> 10:11.428
çok güveniyoruz çünkü çalışanlarımızın

10:11.428 --> 10:14.249
çoğu aslında sadece kendi ofislerimizde değil, dünyanın

10:14.249 --> 10:17.640
her yerinde çalışan uzaktan çalışanlar.

10:17.640 --> 10:18.473
Şu anda ofisimde

10:18.473 --> 10:20.100
oturmuş bunu kaydederken, ben konuşurken

10:20.100 --> 10:22.830
ekranda gördüğünüz tüm farklı şeyleri oluşturabilmesi

10:22.830 --> 10:24.690
için bu dosyayı grafik tasarımcıma vermenin

10:24.690 --> 10:27.060
bir yoluna ihtiyacım var.

10:27.060 --> 10:28.260
Sonra da gidip video editörümün

10:28.260 --> 10:31.320
bulunduğu başka bir ülkeye gönderecek.

10:31.320 --> 10:33.060
Ve işleri bittiğinde, ofisime geri gönderecekler

10:33.060 --> 10:34.410
ve personelimden biri kalite

10:34.410 --> 10:36.870
güvence kontrollerimizi yapacak ve ardından başka bir

10:36.870 --> 10:39.300
ülkeye göndereceğiz, o da bunu göreceğiniz nihai siteye

10:39.300 --> 10:41.040
yükleyecek.

10:41.040 --> 10:43.779
Dolayısıyla bu video, şu anda ekranda gördüğünüz

10:43.779 --> 10:46.680
bitmiş ürün haline gelebilmek için muhtemelen

10:46.680 --> 10:49.470
dört ya da beş farklı yere gitti.

10:49.470 --> 10:50.303
Bu, dosya senkronizasyonu

10:50.303 --> 10:52.950
fikridir, çünkü bunu kaydettiğimde, bulut tabanlı bir

10:52.950 --> 10:55.129
dosya sunucusuna kaydediyorum, ekibimdeki

10:55.129 --> 10:57.780
herkes bu dosyaya erişebilir çünkü tüm cihazlarında

10:57.780 --> 11:00.360
ve dünyadaki tüm sunucularımızda senkronize edilmiş

11:00.360 --> 11:03.030
bir kopyamız var, böylece ona erişebilir ve ihtiyaç duydukları

11:03.030 --> 11:05.430
şeyi yapabilirler.

11:05.430 --> 11:06.630
Ve bunu yaparken, sadece

11:06.630 --> 11:08.190
kendi bilgisayarlarında durmuyor,

11:08.190 --> 11:11.070
tüm bulut sunucularımızda senkronize ediliyor, böylece

11:11.070 --> 11:13.710
kayıt ve yayınlama arasında gerçekleşmesi gereken

11:13.710 --> 11:15.510
yol boyunca diğer herkes ve sonra onu

11:15.510 --> 11:16.920
izliyorsunuz, tüm bu sunucularda

11:16.920 --> 11:20.730
çok akıcı bir şekilde gerçekleşebilir.

11:20.730 --> 11:22.200
İş perspektifinden bakıldığında

11:22.200 --> 11:24.420
bulut kullanımının en büyük faydalarından biri

11:24.420 --> 11:26.970
de ofisinizde bir sunucu bulundurmamanızdır.

11:26.970 --> 11:28.201
Artık bulutta, korunan,

11:28.201 --> 11:31.650
yüksek erişilebilirliğe sahip, ölçeklenebilir ve daha yüksek

11:31.650 --> 11:32.980
ve daha düşük talep dönemlerine

11:32.980 --> 11:34.617
yanıt vermede elastik olabilen

11:34.617 --> 11:37.740
bir veri merkezinde oturuyor.

11:37.740 --> 11:39.015
Sadece kullandığımız kadarını

11:39.015 --> 11:41.177
ödemek zorundayız ve hepimiz aynı fiziksel sunucuda

11:41.177 --> 11:42.537
oturduğumuz için kaynakları

11:42.537 --> 11:45.480
tanımadığımız diğer insanlarla paylaşabiliyoruz.

11:45.480 --> 11:46.820
Bulut özellikleri hakkında konuşmaya

11:46.820 --> 11:49.110
başladığımızda ve dünya çapında birçok şirket tarafından

11:49.110 --> 11:50.970
buluta neden bu kadar büyük bir göç yaşandığında

11:50.970 --> 11:53.740
bahsettiğimiz şeylerin hepsi bunlardır