WEBVTT

00:00.090 --> 00:00.923
المدرب: في هذه الأيام،

00:00.923 --> 00:02.880
يمكن العثور على الحوسبة السحابية في كل

00:02.880 --> 00:05.580
مكان، وذلك بسبب وجود العديد من الفوائد الرائعة لاستخدام

00:05.580 --> 00:07.290
الحوسبة السحابية.

00:07.290 --> 00:09.510
وهذا ما سنركز عليه في هذا الدرس عندما

00:09.510 --> 00:10.343
نبدأ بالحديث

00:10.343 --> 00:12.930
عن الخصائص المختلفة للسحابة.

00:12.930 --> 00:15.160
عندما نتحدث عن الحوسبة السحابية، هناك

00:15.160 --> 00:17.670
عدد قليل من الفوائد أو الخصائص التي نراها

00:17.670 --> 00:19.680
عندما نختار استخدام السحابة.

00:19.680 --> 00:23.460
وتشمل هذه الميزات التوفر العالي وقابلية التوسع والمرونة

00:23.460 --> 00:24.750
والاستخدام المحدود

00:24.750 --> 00:27.540
والموارد المشتركة ومزامنة الملفات.

00:27.540 --> 00:29.040
دعونا نلقي نظرة على هذه.

00:29.040 --> 00:31.350
أولاً، لدينا نسبة توافر عالية.

00:31.350 --> 00:32.749
الآن، يشير التوفر العالي

00:32.749 --> 00:34.410
إلى حقيقة أن الخدمات تواجه

00:34.410 --> 00:37.800
فترة توقف قليلة جدًا عند استخدام السحابة.

00:37.800 --> 00:39.690
وذلك لأن معظم الخدمات المبنية على

00:39.690 --> 00:41.670
السحابة مصممة لتكون موثوقة للغاية

00:41.670 --> 00:43.200
ومتسامحة مع الأخطاء.

00:43.200 --> 00:45.900
وهذا يعني أنه يمكننا ضمان مستوى عال من التوافر.

00:45.900 --> 00:47.610
الآن، عندما يتعلق الأمر بالتوفر،

00:47.610 --> 00:50.160
فإننا عادةً ما نقيس ذلك من حيث النسبة المئوية لمقدار

00:50.160 --> 00:53.760
وقت التشغيل الموجود مقابل مقدار وقت التوقف عن العمل.

00:53.760 --> 00:55.920
على سبيل المثال، يُعرف المعيار

00:55.920 --> 00:58.860
الذهبي داخل الشبكات بالتسعات الخمس.

00:58.860 --> 01:02.970
خمس تسعات تعني 99 نسبة تشغيل أو توفر تصل إلى 999%

01:02.970 --> 01:06.390
حسب تجربة المستخدمين النهائيين لديك.

01:06.390 --> 01:09.030
وهذا يعني أنه لا يمكننا الحصول إلا على حوالي

01:09.030 --> 01:11.980
خمس دقائق و15 ثانية من التوقف كل عام.

01:11.980 --> 01:15.090
هذا صحيح، خمس دقائق و15 ثانية

01:15.090 --> 01:18.570
فقط على مدار 365 يومًا في السنة.

01:18.570 --> 01:20.400
الآن للقيام بذلك، هذا يعني أنه يجب

01:20.400 --> 01:23.430
أن يكون لديك أنظمة موثوقة للغاية ومتوفرة بشكل كبير.

01:23.430 --> 01:25.330
لذلك، إذا كان لديك موقع ويب واحد،

01:25.330 --> 01:28.290
فسيكون لديك في الواقع خادمان على الأقل يستضيفان ذلك

01:28.290 --> 01:29.123
الموقع.

01:29.123 --> 01:30.300
لذا، إذا تعطل أحدهما،

01:30.300 --> 01:32.160
فإن الآخر لا يزال يحمل العبء، وهذا

01:32.160 --> 01:35.730
يعني أن المستخدم النهائي لا يواجه أي توقف عن العمل.

01:35.730 --> 01:36.690
هذا ما نتحدث عنه

01:36.690 --> 01:38.640
عندما نتحدث عن التوفر العالي.

01:38.640 --> 01:42.210
على سبيل المثال، مع موقع الويب الخاص بي، diontraining. com، لدينا بالفعل إعداد

01:42.210 --> 01:44.760
متاح للغاية تم إنشاؤه باستخدام

01:44.760 --> 01:47.280
الخدمات السحابية.

01:47.280 --> 01:50.070
لذلك، اعتمادًا على المكان الذي أتيت منه في العالم،

01:50.070 --> 01:51.060
ستصل إلى أحد خوادمنا

01:51.060 --> 01:53.160
المتعددة الموجودة حول العالم الأقرب

01:53.160 --> 01:55.680
إليك للحصول على تجربة أفضل.

01:55.680 --> 01:57.627
الآن، إذا كان الخادم الخاص بك معطلاً لسبب

01:57.627 --> 02:00.300
ما، فسيتم إعادة توجيهك تلقائيًا إلى خادم آخر بعيد عنك

02:00.300 --> 02:02.490
قليلاً، لكنه لا يزال قيد التشغيل.

02:02.490 --> 02:04.980
وبهذه الطريقة، ستظل تحصل على الخدمة

02:04.980 --> 02:08.460
التي تبحث عنها، وهذه طريقة لضمان التوفر العالي.

02:08.460 --> 02:10.590
السمة الثانية للسحابة التي سنتحدث

02:10.590 --> 02:12.480
عنها تُعرف بقابلية التوسع.

02:12.480 --> 02:15.150
الآن، عندما نتحدث عن قابلية التوسع،

02:15.150 --> 02:17.370
فهذا يعني أنه يمكننا زيادة

02:17.370 --> 02:19.080
عدد الأشخاص أو عدد الأشياء

02:19.080 --> 02:23.220
في نظامنا بمعدل خطي أو أقل من معدل خطي.

02:23.220 --> 02:24.053
الآن، ما أعنيه

02:24.053 --> 02:26.850
بذلك هو أنه لنفترض أن لدي 100 مستخدم يستخدمون نظامي،

02:26.850 --> 02:28.620
ويكلفني ذلك 10 دولارات.

02:28.620 --> 02:31.282
حسنًا، إذا وضعت 200 مستخدم على نظامي، فمن المفترض

02:31.282 --> 02:35.010
أن يكلفني ذلك 20 دولارًا أو أقل، وسيكون ذلك مقياسًا خطيًا.

02:35.010 --> 02:37.860
الآن، إذا انتقلت من 100 مستخدم إلى 200 مستخدم

02:37.860 --> 02:40.500
وارتفع السعر من 10 دولارات إلى 100 دولار،

02:40.500 --> 02:42.240
فسيكون ذلك مقياسًا أسيًا، ونحن

02:42.240 --> 02:43.380
لا نريد ذلك.

02:43.380 --> 02:45.180
لذلك، بينما نقوم ببناء أنظمتنا السحابية،

02:45.180 --> 02:47.070
فإننا نبحث دائمًا عن قابلية التوسع، وهذا

02:47.070 --> 02:49.860
يعني أنه حتى لو كان لدينا 10 مستخدمين فقط اليوم، فقد يكون لدينا

02:49.860 --> 02:51.090
100 غدًا.

02:51.090 --> 02:52.590
وفي اليوم التالي، لدينا 1000،

02:52.590 --> 02:55.260
وفي اليوم التالي، قد يكون لدينا 10000، وهكذا.

02:55.260 --> 02:56.093
إذا نظرت إلى بعض

02:56.093 --> 02:58.800
الشركات الكبرى مثل Facebook وGoogle وLinkedIn

02:58.800 --> 03:02.160
وUNI، فستجد أن لديهم الملايين من المستخدمين النهائيين

03:02.160 --> 03:04.710
الذين يصلون إلى منصاتهم كل يوم وهم قادرون على

03:04.710 --> 03:07.422
التوسع بناءً على قابلية التوسع السحابي الخدمات،

03:07.422 --> 03:09.510
لأنني لست مضطرًا للذهاب وشراء خادم

03:09.510 --> 03:10.710
آخر بقيمة 10000 دولار

03:10.710 --> 03:12.990
لوضعه في مركز البيانات المحلي الخاص بي،

03:12.990 --> 03:14.490
لأنه بدلاً من ذلك يمكنني فقط

03:14.490 --> 03:16.650
استخدام Amazon واستخدام جزء من قدراتهم

03:16.650 --> 03:19.560
عندما أحتاج إليها.

03:19.560 --> 03:20.970
الآن، عندما يتعلق الأمر بقابلية التوسع،

03:20.970 --> 03:22.650
هناك طريقتان يمكنك من خلالهما التوسع.

03:22.650 --> 03:25.560
أحدهما هو الارتقاء، وهو ما يُعرف بالمقياس الرأسي.

03:25.560 --> 03:27.090
وذلك عن طريق إضافة المزيد من

03:27.090 --> 03:29.010
الموارد إلى خادم أو عقدة معينة.

03:29.010 --> 03:31.020
على سبيل المثال، إذا كنت تستخدم خادمًا سحابيًا

03:31.020 --> 03:32.970
يحتوي على وحدتي CPU ظاهريتين، فيمكنك في الواقع

03:32.970 --> 03:35.730
زيادة ذلك إلى أربع وحدات معالجة مركزية افتراضية.

03:35.730 --> 03:37.170
هذه هي فكرة التوسع.

03:37.170 --> 03:38.610
أنت تضيف المزيد من الموارد، سواء كان ذلك المزيد

03:38.610 --> 03:41.040
من المعالجات، أو المزيد من ذاكرة الوصول العشوائي، أو المزيد من السعة التخزينية،

03:41.040 --> 03:43.110
أو المزيد من النطاق الترددي، أو أشياء من هذا القبيل.

03:43.110 --> 03:45.120
الآن، من ناحية أخرى، يمكنك أيضًا تغيير الحجم،

03:45.120 --> 03:47.100
وهو ما يُعرف باسم القياس الأفقي.

03:47.100 --> 03:49.440
هذا هو المكان الذي لا تزال تستخدم فيه أجهزة أصغر،

03:49.440 --> 03:50.280
ولكنك تستخدم المزيد

03:50.280 --> 03:53.400
منها كلها تعمل جنبًا إلى جنب خلف موازن التحميل.

03:53.400 --> 03:55.080
لذلك بدلاً من أن يكون لديك خادم واحد يتعامل

03:55.080 --> 03:57.316
مع كل الأحمال الخاصة بك ويتوسع لأعلى عن طريق زيادة

03:57.316 --> 04:00.180
وحدات المعالجة المركزية (CPUs) وزيادة الذاكرة، يمكنك بدلاً

04:00.180 --> 04:02.520
من ذلك التوسع والانتقال من خادم واحد إلى خادمين أو خادمين

04:02.520 --> 04:05.970
إلى أربعة، أو من أربعة إلى ثمانية، وأنت يمكنك الاستمرار في التحرك نحو الخارج،

04:05.970 --> 04:07.170
عن طريق إضافة خوادم إضافية

04:07.170 --> 04:09.840
خلف موازن التحميل الخاص بك والذي يمكنك بعد ذلك التعامل مع

04:09.840 --> 04:11.940
حركة المرور الإضافية.

04:11.940 --> 04:13.710
والآن، يقودنا هذا إلى المنطقة الثالثة،

04:13.710 --> 04:15.864
والتي تُعرف بالمرونة السريعة.

04:15.864 --> 04:18.960
الآن، عندما نتحدث عن المرونة السريعة، فإننا نتحدث

04:18.960 --> 04:20.160
عن حقيقة أنه يمكننا

04:20.160 --> 04:22.731
زيادة حجمها أو تقليصها بسرعة كبيرة.

04:22.731 --> 04:25.454
يتم ذلك الآن لأننا نستخدم الأتمتة والتنسيق

04:25.454 --> 04:28.110
مع الكثير من الأجهزة الافتراضية على هذه

04:28.110 --> 04:29.970
الخوادم الفعلية المملوكة لشركة

04:29.970 --> 04:32.220
Amazon وGoogle وMicrosoft وغيرها

04:32.220 --> 04:35.040
من الشركات التي تسمح لنا باستخدام أجزاء أو

04:35.040 --> 04:38.104
جميع خدماتها حسب الحاجة عند الطلب .

04:38.104 --> 04:41.040
وهذا يعطينا تلك المرونة السريعة.

04:41.040 --> 04:43.200
عندما تسمع مصطلح المرونة السريعة

04:43.200 --> 04:46.290
أو المرونة بشكل عام، فكر في الأمر على أنه حقيقة قدرة

04:46.290 --> 04:48.785
النظام على التعامل مع التغيرات في الطلب

04:48.785 --> 04:50.370
في الوقت الفعلي.

04:50.370 --> 04:51.410
لذلك دعونا نعود إلى مثال استخدام

04:51.410 --> 04:54.780
موقع الويب الخاص بي في diontraining. com.

04:54.780 --> 04:56.490
إذا قمت الآن بفحص موقع الويب الخاص

04:56.490 --> 04:58.770
بي، وقام 1000 طالب بتسجيل الدخول، وقمت بتسجيل

04:58.770 --> 05:00.330
الدخول بعد خمس دقائق من الآن،

05:00.330 --> 05:02.520
وكان هناك 10000 طالب قاموا بتسجيل الدخول،

05:02.520 --> 05:03.774
فإن أنظمتي مصممة لتشغيل

05:03.774 --> 05:07.230
موارد سحابية إضافية ودفع بعض هذا العبء من تلك الموارد المستخدمين

05:07.230 --> 05:10.230
الجدد على تلك الخدمات الإضافية.

05:10.230 --> 05:12.810
هذه هي فكرة المرونة السريعة.

05:12.810 --> 05:14.580
بشكل عام، عندما تعمل في السحابة،

05:14.580 --> 05:16.470
إذا قمت بتصميم أنظمتك بشكل صحيح،

05:16.470 --> 05:18.949
فستكون لديك القدرة على التمتع بالمرونة

05:18.949 --> 05:21.150
والتوسع بسرعة كبيرة، وبعد ذلك بالمثل،

05:21.150 --> 05:23.520
عندما يختفي الطلب، يمكنك التخلص بسرعة

05:23.520 --> 05:24.750
من تلك الخوادم الإضافية

05:24.750 --> 05:27.120
وإعادتها إلى الأسفل.

05:27.120 --> 05:28.680
والسبب وراء رغبتك في القيام بذلك

05:28.680 --> 05:31.166
هو أن كل تلك الخوادم الإضافية ستكلفك المزيد من المال،

05:31.166 --> 05:33.390
وإذا لم يكن لديك عدد كافٍ من المستخدمين للحصول

05:33.390 --> 05:34.500
عليها، فلن ترغب في الدفع

05:34.500 --> 05:36.510
مقابل ذلك، لذا ستقوم بتحريرها وإعادتها إلى

05:36.510 --> 05:37.410
مزود الخدمة الخاص بك

05:37.410 --> 05:40.140
حتى يتمكنوا بعد ذلك من تأجير هذه الخدمة لشخص آخر.

05:40.140 --> 05:42.750
بدلاً من ذلك، إذا كنت تقوم بإنشاء نموذج محلي،

05:42.750 --> 05:45.000
فلنفترض أن لدي 1000 طالب اليوم.

05:45.000 --> 05:48.150
حسنًا، بالنسبة لـ 1000 طالب، قد أحتاج إلى ثلاثة خوادم ويب.

05:48.150 --> 05:49.830
ولكن إذا ذهبت إلى 10000 طالب،

05:49.830 --> 05:51.956
فسوف أحتاج إلى 15 خادم ويب آخر.

05:51.956 --> 05:55.080
حسنًا، للقيام بذلك، يجب أن أشتري 15 خادمًا إضافيًا.

05:55.080 --> 05:55.950
لا بد لي من الرف لهم.

05:55.950 --> 05:57.270
يجب أن أقوم بتثبيت كافة البرامج،

05:57.270 --> 05:58.440
ويجب أن أقوم بتكوينها.

05:58.440 --> 05:59.580
كل هذا يستغرق وقتًا،

05:59.580 --> 06:02.222
وبالتالي فإن مقاييس المرونة ليست سريعة جدًا

06:02.222 --> 06:04.980
حتى نتمكن من التوسع لتلبية هذا الطلب.

06:04.980 --> 06:07.860
إذا كان لديك نموذج أعمال بطيء النمو للغاية، فلا بأس بذلك.

06:07.860 --> 06:10.200
ولكن إذا كنت تتعامل مع شيء عالي السرعة أو أي

06:10.200 --> 06:12.171
من منصات وسائل التواصل الاجتماعي

06:12.171 --> 06:14.370
الحديثة هذه، وانتشر شيء قمت به، وذهب الجميع

06:14.370 --> 06:16.920
إلى موقع الويب الخاص بك وبدأوا في إغراقك، إذا

06:16.920 --> 06:19.050
لم تكن لديك القدرة لتوسيع النطاق بسرعة،

06:19.050 --> 06:19.950
ستفقد القدرة على

06:19.950 --> 06:22.052
التقاط حركة المرور القادمة من هذا الحادث

06:22.052 --> 06:23.880
الفيروسي.

06:23.880 --> 06:25.620
ولذا فأنت تريد أن تكون قادرًا على بناء

06:25.620 --> 06:27.360
الأشياء الخاصة بك بطريقة مرنة سريعة،

06:27.360 --> 06:29.700
وهذا هو ما تسمح لنا السحابة بالقيام به.

06:29.700 --> 06:32.910
الشيء الرابع الذي لدينا يعرف بالاستخدام المقنن.

06:32.910 --> 06:33.810
والآن يعود هذا إلى

06:33.810 --> 06:36.510
مناقشتنا السريعة حول المرونة التي أجريناها للتو.

06:36.510 --> 06:38.686
الآن، عندما نتحدث عن الاستخدام المقنن،

06:38.686 --> 06:40.170
فإننا نتحدث عن حقيقة أننا

06:40.170 --> 06:43.800
ندفع مقابل الخدمة على أساس الدفع لكل استخدام.

06:43.800 --> 06:46.650
لذا، عندما نستخدم خدمة مقيّدة مثل قاعدة البيانات، فقد

06:46.650 --> 06:47.730
يفرضون علينا رسومًا

06:47.730 --> 06:49.170
بناءً على عدد المستخدمين أو

06:49.170 --> 06:52.050
عدد الاتصالات، أو عدد البيانات التي يتم تخزينها.

06:52.050 --> 06:53.910
بشكل أساسي، يتم تحصيل الرسوم منا بناءً

06:53.910 --> 06:56.910
على الاستخدام الفعلي للخدمة التي يتم استهلاكها.

06:56.910 --> 06:59.262
ونقوم بذلك إما على أساس ثانٍ، أو على أساس

06:59.262 --> 07:03.480
دقيقة، أو على أساس الساعة، أو على أساس يومي، أو حتى على أساس شهري.

07:03.480 --> 07:05.211
على سبيل المثال، أستخدم AWS Lambda

07:05.211 --> 07:08.153
في الكثير من عمليات التشغيل الآلي والوظائف الخلفية الخاصة

07:08.153 --> 07:11.010
بي، وهم يتقاضون رسومًا مني بناءً على استخدامي.

07:11.010 --> 07:13.290
الآن مقابل كل مليون طلب أقدمه، يتقاضون

07:13.290 --> 07:14.760
مني 20 سنتًا.

07:14.760 --> 07:16.200
ولذا فهي طريقة فعالة للغاية بالنسبة

07:16.200 --> 07:17.880
لي لإنجاز عمليات التشغيل الآلي الخاصة

07:17.880 --> 07:20.092
بي لأنها أمر منخفض التكلفة للغاية.

07:20.092 --> 07:22.620
يمكنني الحصول على ملايين وملايين الطلبات

07:22.620 --> 07:24.960
ولن يكلفني ذلك سوى بضعة دولارات، وهذه

07:24.960 --> 07:27.090
هي فكرة الخدمة المقننة.

07:27.090 --> 07:28.334
الآن، الشيء الآخر الذي

07:28.334 --> 07:30.120
ستراه هو أحيانًا أنك سترى تمييزًا

07:30.120 --> 07:33.000
بين الخدمة المقاسة والخدمة المقاسة.

07:33.000 --> 07:35.640
الآن، عندما نتحدث عن الخدمات المقاسة أو المقاسة،

07:35.640 --> 07:37.470
فإننا نتحدث حقًا عن نفس الشيء وهو

07:37.470 --> 07:38.700
قدرتنا على الدفع مقابل

07:38.700 --> 07:41.160
شيء ما على أساس الاستهلاك.

07:41.160 --> 07:42.840
ولكن هناك فرق هنا.

07:42.840 --> 07:44.850
عندما تستخدم خدمة مقننة، فإنك

07:44.850 --> 07:46.073
تدفع مقابل الأشياء

07:46.073 --> 07:49.380
بناءً على الاستخدام الفعلي لما قمت به.

07:49.380 --> 07:50.213
لذا، إذا فكرت في فاتورة

07:50.213 --> 07:52.500
المياه أو فاتورة الكهرباء في المنزل.

07:52.500 --> 07:53.880
إذا قمت بتشغيل خرطوم المياه الخاص

07:53.880 --> 07:55.650
بك وملأت حمام السباحة الخاص بك هذا الشهر،

07:55.650 --> 07:56.730
فسوف تدفع الكثير مقابل فاتورة

07:56.730 --> 07:59.670
المياه الخاصة بك لأنك استخدمت الكثير من المياه.

07:59.670 --> 08:02.314
الآن على العكس من ذلك، عندما تتعامل مع خدمة مُقاسة،

08:02.314 --> 08:04.950
فهذا يشبه إلى حد كبير خطة هاتفك الخلوي.

08:04.950 --> 08:08.160
في معظم الأماكن، تدفع رسومًا شهرية مقابل قدر معين من استخدام

08:08.160 --> 08:10.740
هذا الهاتف الخلوي، سواء كان ذلك عدد الرسائل النصية

08:10.740 --> 08:14.100
أو الدقائق أو البيانات المسموح لك باستهلاكها.

08:14.100 --> 08:15.390
وبمجرد وصولك إلى هذا

08:15.390 --> 08:17.790
الحد، سيوقفون خدمتك ولن يعطوك المزيد

08:17.790 --> 08:19.440
حتى تدفع لهم مرة أخرى.

08:19.440 --> 08:21.300
لذلك عندما تفكر في خدمة يتم قياسها،

08:21.300 --> 08:23.310
فكر في حقيقة أنك تدفع مقابل مبلغ معين من

08:23.310 --> 08:25.920
الكمية مقدمًا، وسواء كنت تستخدمها أم لا، فقد دفعت

08:25.920 --> 08:27.660
بالفعل مقابل هذا المبلغ.

08:27.660 --> 08:28.493
ولكن عندما تتعامل مع

08:28.493 --> 08:30.420
خدمة مقيّدة، فإنك تدفع مقابل المبلغ المحدد

08:30.420 --> 08:31.253
الذي تستخدمه.

08:31.253 --> 08:33.480
وهذه حقًا إحدى فوائد استخدام السحابة،

08:33.480 --> 08:35.527
وهي أن معظم الأشياء تتم على أساس مقنن

08:35.527 --> 08:37.883
حيث تدفع فقط مقابل ما تستخدمه.

08:37.883 --> 08:41.160
الشيء التالي الذي سنتحدث عنه هو الموارد المشتركة.

08:41.160 --> 08:43.740
الآن، عندما نتحدث عن الموارد المشتركة، فإننا

08:43.740 --> 08:46.530
نتحدث حقًا عن القدرة على تقليل التكلفة لأننا

08:46.530 --> 08:48.330
قادرون على وضع أجهزتنا الافتراضية

08:48.330 --> 08:50.220
على خوادم شخص آخر.

08:50.220 --> 08:51.930
عندما تنظر إلى تلك الخوادم التي نستخدمها

08:51.930 --> 08:54.238
لـ Amazon وAzure وGoogle Cloud، فإن هذه الأشياء

08:54.238 --> 08:56.022
تتراوح قيمتها بين 10 و20 و30 ألف دولار

08:56.022 --> 08:58.980
للقطعة الواحدة لخادم عالي الجودة.

08:58.980 --> 09:00.151
وبالتالي، إذا كنت بحاجة إلى

09:00.151 --> 09:02.640
شراء واحدة منها لتتمكن من استضافة مدونة WordPress الخاصة

09:02.640 --> 09:04.680
بك، فأنت لا تستخدم حقًا كل هذه السعة، لأنه إذا

09:04.680 --> 09:06.420
كان لديك بضع مئات من القراء فقط، فلن يستخدم

09:06.420 --> 09:08.100
هذا القدر الكبير من الحمل.

09:08.100 --> 09:10.020
لذا، بدلًا من ذلك، فمن المنطقي أن

09:10.020 --> 09:12.660
نأخذ ذلك الخادم الباهظ الثمن، ونقوم بتقطيعه

09:12.660 --> 09:14.550
إلى أجزاء صغيرة بشكل أساسي، وتوزيعه

09:14.550 --> 09:16.158
على أجهزة افتراضية، إلى أي

09:16.158 --> 09:18.450
شخص آخر يريد استخدامه.

09:18.450 --> 09:20.816
لذلك قد نتمكن من استضافة 50 أو 100 مدونة WordPress

09:20.816 --> 09:24.480
على ذلك الخادم الواحد بدلاً من استضافة واحدة فقط.

09:24.480 --> 09:26.760
هذه هي فكرة استخدام الموارد المشتركة.

09:26.760 --> 09:28.330
عندما نتحدث عن الموارد المشتركة،

09:28.330 --> 09:30.697
فإننا نتحدث عن تجميع جميع الأجهزة معًا لتكوين

09:30.697 --> 09:33.150
مركز بيانات موفر الخدمة السحابية.

09:33.150 --> 09:35.215
وبهذه الطريقة، فهو ليس مخصصًا لفرد

09:35.215 --> 09:37.987
واحد ولكن يمكننا جميعًا استخدامه بناءً على المرونة

09:37.987 --> 09:41.220
السريعة لأنه، كما نأمل، ما تفكر فيه Amazon وGoogle وAzure

09:41.220 --> 09:42.690
هو أنه عندما تكون هناك فترات

09:42.690 --> 09:44.970
طلب عالية لشركتي، قد تكون هناك فترات

09:44.970 --> 09:48.090
منخفضة لشركتك والعكس صحيح.

09:48.090 --> 09:50.280
لذا، فبدلاً من الاضطرار إلى تخصيص موارد الأجهزة

09:50.280 --> 09:51.480
لكل شركة من شركاتنا، يمكننا

09:51.480 --> 09:54.009
مشاركة الموارد في جميع المجالات.

09:54.009 --> 09:55.500
والسمة النهائية للسحابة

09:55.500 --> 09:58.710
هي القدرة على القيام بمزامنة الملفات.

09:58.710 --> 10:01.103
الآن، إن الشيء العظيم في استخدام الموارد المستندة

10:01.103 --> 10:02.760
إلى السحابة هو أنه يمكنك وضع شيء

10:02.760 --> 10:04.649
ما في مكان واحد، ومن ثم يمكن أن ينتشر

10:04.649 --> 10:07.500
إلى أماكن أخرى بناءً على كيفية تكوينه.

10:07.500 --> 10:09.420
على سبيل المثال، في شركتي، نعتمد

10:09.420 --> 10:11.428
على مزامنة الملفات كثيرًا لأن معظم

10:11.428 --> 10:14.249
موظفينا هم في الواقع موظفون عن بعد يعملون في جميع

10:14.249 --> 10:17.640
أنحاء العالم، وليس فقط في مكاتبنا الخاصة.

10:17.640 --> 10:18.473
لذا، بينما أجلس

10:18.473 --> 10:20.100
هنا في مكتبي أسجل هذا الآن، أحتاج

10:20.100 --> 10:22.830
إلى طريقة لتسليم هذا الملف إلى مصمم الجرافيك الخاص بي

10:22.830 --> 10:24.690
حتى يتمكن من إنشاء كل الأشياء المختلفة

10:24.690 --> 10:27.060
التي ترونها على الشاشة أثناء حديثي .

10:27.060 --> 10:28.260
ومن ثم ستذهب وترسله

10:28.260 --> 10:31.320
إلى بلد آخر حيث يوجد محرر الفيديو الخاص بي.

10:31.320 --> 10:33.060
وعندما ينتهوا، سوف يرسلونه مرة أخرى

10:33.060 --> 10:34.410
إلى مكاتبي حيث سيقوم أحد الموظفين

10:34.410 --> 10:36.870
التابعين لي بإجراء فحوصات ضمان الجودة لدينا، وبعد ذلك

10:36.870 --> 10:38.400
سنقوم بإرساله إلى بلد آخر سيقوم بعد

10:38.400 --> 10:39.300
ذلك بتحميله إلى الموقع

10:39.300 --> 10:41.040
النهائي حيث ستراه.

10:41.040 --> 10:43.779
ومن ثم فقد انتقل هذا الفيديو إلى أربعة أو خمسة

10:43.779 --> 10:46.680
أماكن مختلفة ليكون قادرًا على أن يكون ذلك المنتج

10:46.680 --> 10:49.470
النهائي الذي ترونه الآن على الشاشة.

10:49.470 --> 10:50.303
هذه هي فكرة مزامنة

10:50.303 --> 10:52.950
الملفات، لأنني عندما أسجل هذا، فأنا أسجله على

10:52.950 --> 10:55.129
خادم ملفات قائم على السحابة، ويمكن لكل

10:55.129 --> 10:57.780
فرد في فريقي الوصول إلى هذا الملف لأن لدينا تلك

10:57.780 --> 11:00.360
النسخة المتزامنة على جميع أجهزتهم وعبر جميع

11:00.360 --> 11:03.030
أجهزتنا خوادم حول العالم حتى يتمكنوا من الوصول

11:03.030 --> 11:05.430
إليها والقيام بما يحتاجون إليه.

11:05.430 --> 11:06.630
وأثناء قيامهم بذلك،

11:06.630 --> 11:08.190
لا يقتصر الأمر على أجهزة الكمبيوتر

11:08.190 --> 11:11.070
الخاصة بهم فحسب، بل تتم مزامنته عبر جميع خوادمنا

11:11.070 --> 11:13.710
السحابية، لذلك يمكن لأي شخص آخر على طول هذا المسار

11:13.710 --> 11:16.920
الذي يجب أن يحدث بين التسجيل والنشر، ثم مشاهدته، أن يحدث

11:16.920 --> 11:20.730
عبر كل تلك الخوادم بطريقة مبسطة للغاية.

11:20.730 --> 11:22.200
وهذه إحدى الفوائد الكبيرة

11:22.200 --> 11:24.420
الحقيقية للقيام بالسحابة من منظور الأعمال،

11:24.420 --> 11:26.970
وهي عدم وجود هذا الخادم في مكتبك.

11:26.970 --> 11:28.201
إنه موجود الآن في السحابة

11:28.201 --> 11:31.650
في مركز بيانات محمي، ومتوفر بدرجة كبيرة، ولديه القدرة على

11:31.650 --> 11:32.980
أن يكون قابلاً للتطوير،

11:32.980 --> 11:34.617
ويمكن أن يكون مرنًا في الاستجابة

11:34.617 --> 11:37.740
لمتطلبات فترات الطلبات الأعلى والأقل.

11:37.740 --> 11:39.015
علينا فقط أن ندفع مقابل

11:39.015 --> 11:41.177
ما نستخدمه ويمكننا مشاركة الموارد مع

11:41.177 --> 11:42.537
أشخاص آخرين قد لا نعرفهم

11:42.537 --> 11:45.480
حتى لأننا جميعًا نجلس على نفس الخادم الفعلي.

11:45.480 --> 11:46.820
وهذه هي كل الأشياء التي

11:46.820 --> 11:49.110
نتحدث عنها عندما نبدأ الحديث عن خصائص السحابة

11:49.110 --> 11:50.970
وسبب هذه الهجرة الكبيرة إلى السحابة

11:50.970 --> 11:53.740
من قبل العديد من الشركات حول العالم