اختيار خدمة الحوسبة المناسبة

يوفر Azure خدمات حوسبة متعددة — صُمم كل منها لنوع مختلف من أحمال العمل ومستوى التحكم ونموذج التشغيل. ويؤدي اختيار خدمة الحوسبة الخاطئة إلى تعقيد غير ضروري (عند اختيار مستوى منخفض جدًا) أو تحكم غير كافٍ (عند اختيار مستوى تجريدي جدًا). والسؤال الأساسي هو: ما مقدار البنية الأساسية الأساسية التي تحتاجون إلى إدارتها؟ يستعرض هذا الدرس خيارات الحوسبة الرئيسية والمعايير التي تساعدكم على اختيار الخيار المناسب لكل سيناريو.

تمنحكم Azure Virtual Machines تحكمًا كاملًا في نظام التشغيل وبيئة التشغيل ومكدس التطبيقات. استخدموا أجهزة VM عندما تحتاجون إلى: تشغيل تطبيقات قديمة تتطلب إصدارًا محددًا من نظام التشغيل أو إعدادًا معينًا للنواة، أو تنفيذ ترحيل الرفع والنقل لحمل عمل محلي دون تعديله، أو تثبيت برامج مخصصة على مستوى النظام، أو استخدام حوسبة مستمرة تعمل على مدار الساعة طوال أيام الأسبوع بتكوين ثابت ويمكن التنبؤ به. والمقابل هو أعلى عبء تشغيلي — إذ تقع على عاتقكم مسؤولية تصحيح نظام التشغيل وتعزيزه أمنيًا ومراقبة طبقة نظام التشغيل.

تُعد Virtual Machine Scale Sets الخيار المناسب عندما تحتاجون إلى أجهزة VM، وتحتاجون في الوقت نفسه إلى التوسّع تلقائيًا استنادًا إلى الطلب. فإذا كان حمل العمل الخاص بكم عديم الحالة (مثل خوادم الويب وخلفيات API وعمال المعالجة الدفعية)، ويعمل بالطريقة نفسها على كل مثيل، ويشهد طلبًا متغيرًا، فإن VMSS هو الخيار الطبيعي. فهو يجمع بين التحكم على مستوى جهاز VM والتوسّع الأفقي التلقائي. وعند الاختيار بين جهاز VM مستقل وVMSS، يكون العامل الحاسم عادةً هو ما إذا كان حمل العمل يحتاج إلى التوسّع بما يتجاوز مثيلًا واحدًا.

إن Azure App Service عبارة عن نظام PaaS لاستضافة تطبيقات الويب وواجهات REST API والواجهات الخلفية للأجهزة المحمولة. تنشرون التعليمات البرمجية الخاصة بكم (بلغة Node.js أو Python أو Java أو .NET أو PHP أو Ruby أو في حاوية)، ويتولى Azure إدارة بيئة التشغيل ونظام التشغيل والتصحيحات وموازنة التحميل والتوسّع. استخدموا App Service عندما تريدون طرح التعليمات البرمجية بسرعة من دون إدارة البنية الأساسية، وعندما يتبع تطبيقكم الأنماط القياسية لتطبيقات الويب، وعندما لا تحتاجون إلى تخصيص على مستوى نظام التشغيل. ويُعد App Service من أكثر خدمات Azure شيوعًا بفضل توازنه بين القوة والبساطة.

تتيح لكم Azure Container Instances (ACI) تشغيل حاوية Docker في السحابة من دون إدارة أي بنية أساسية — فلا أجهزة VM ولا منسّق. وتُعد ACI مثالية لـ أحمال عمل الحاويات قصيرة الأجل وعند الطلب، مثل مهام المعالجة الدفعية المجدولة ومهام مسارات CI/CD ونصوص معالجة البيانات وبيئات التطوير. تبدأ الحاويات خلال ثوانٍ، وتدفعون مقابل كل ثانية من وحدة المعالجة المركزية والذاكرة المستهلكتين. ولا توفر ACI ميزات مثل اكتشاف الخدمات أو عمليات النشر التدريجية أو إعادة التشغيل المستندة إلى الحالة الصحية التي يوفرها Kubernetes — فهي بيئة لتنفيذ حاوية واحدة أو مجموعة حاويات.

إن Azure Kubernetes Service (AKS) بيئة Kubernetes مُدارة لتنسيق التطبيقات المعبأة في حاويات على نطاق واسع. استخدموا AKS عندما تكون لديكم خدمات مصغرة متعددة تحتاج إلى اكتشاف الخدمات وعمليات النشر التدريجية والإصلاح التلقائي والتوسّع المتقدم. ويدير AKS مستوى التحكم في Kubernetes (خادم API وetcd والمجدول) باعتباره مكوّن PaaS مجانيًا، بينما تديرون أنتم أجهزة VM الخاصة بالعُقد العاملة. ويُعد AKS الخيار الأكثر تطلبًا من الناحية التشغيلية بين خيارات الحاويات، لكنه يوفر أكبر قدر من القوة والمرونة لبنى الخدمات المصغرة الإنتاجية.

إن Azure Functions خيار حوسبة يستند إلى الأحداث وبدون خادم، حيث تكتبون دوالًا فردية تُنفّذ استجابةً للمشغلات — مثل طلبات HTTP أو جداول المؤقت أو الرسائل الواردة إلى قائمة انتظار أو الأحداث الصادرة من خدمات Azure الأخرى. وتدفعون مقابل كل عملية تنفيذ (أول مليون عملية تنفيذ شهريًا مجانية)، كما تتوسع المنصة تلقائيًا من صفر إلى آلاف العمليات المتزامنة. استخدموا Functions في الأتمتة المستندة إلى الأحداث وخطافات الويب ومسارات تحويل البيانات وأي حمل عمل قصير الأجل بطبيعته ويعتمد على المشغلات.

استخدموا شجرة القرار المبسطة التالية: هل تحتاجون إلى تحكم كامل في نظام التشغيل؟ → VM أو VMSS. هل لديكم حمل عمل معبأ في حاويات وعلى نطاق واسع؟ → AKS. هل لديكم حاوية واحدة قصيرة الأجل؟ → ACI. هل لديكم تطبيق ويب أو واجهة API من دون إدارة نظام التشغيل؟ → App Service. هل لديكم تعليمات برمجية قصيرة المدة ومستندة إلى الأحداث؟ → Azure Functions. وكلما انتقلتم إلى أسفل هذه القائمة، قلّت البنية الأساسية التي تديرونها وزادت سرعة النشر — لكن قلّ أيضًا مستوى التحكم الذي تملكونه في بيئة التنفيذ. اختاروا أعلى مستوى من التجريد يلبي متطلباتكم.

غالبًا ما تستخدم البنى المعمارية في العالم الحقيقي خيارات حوسبة متعددة معًا. فعلى سبيل المثال، قد تستخدم شركة ما App Service لتطبيق الويب الموجّه إلى العملاء، وAzure Functions لمعالجة الطلبات المستندة إلى الأحداث، وAKS لمنصة الخدمات المصغرة الداخلية، وأجهزة VM لنظام ERP قديم لا يمكن إعادة تصميمه. وتعمل أدوات الإدارة الموحدة في Azure — البوابة وCLI وقوالب ARM وAzure Monitor — بشكل متسق عبر جميع خدمات الحوسبة، مما يجعل إدارة البنى متعددة الحوسبة ممكنة من مستوى تحكم واحد.

تختلف التكلفة اختلافًا كبيرًا بين خيارات الحوسبة. الأجهزة الافتراضية — تُحاسَبون بالساعة وفق حجم الجهاز الافتراضي، حتى عندما يكون خاملًا (ما لم تتم إزالته من التخصيص). App Service — تُحاسَبون بالساعة وفق SKU لخطة App Service، ولكن يمكن لتطبيقات متعددة مشاركة الخطة نفسها دون تكلفة إضافية. ACI — تُحاسَبون لكل ثانية من استخدام وحدة المعالجة المركزية والذاكرة الفعلي، من دون تكلفة على الخمول. Azure Functions (Consumption Plan) — تُحاسَبون حسب عدد مرات التنفيذ وكل ثانية من وقت التنفيذ، مع مستوى مجاني سخي جدًا. بالنسبة إلى أحمال العمل المتقطعة، تكون الخيارات serverless تقريبًا دائمًا الأكثر كفاءة من حيث التكلفة؛ أما بالنسبة إلى أحمال العمل المستقرة التي تعمل باستمرار، فقد تكون الأجهزة الافتراضية المحجوزة أو خطط App Service أقل تكلفة.

تقدم خدمات الحوسبة المختلفة ضمانات مختلفة لاتفاقية مستوى الخدمة: جهاز افتراضي واحد (Premium SSD): ‏99.9%. جهاز افتراضي في Availability Set: ‏99.95%. جهاز افتراضي موزع عبر Availability Zones: ‏99.99%. App Service (المستوى Standard وما فوقه): ‏99.95%. Azure Functions (Consumption Plan): ‏99.95%. AKS: توافر بنسبة 99.95% لخادم API (مع المستوى المدفوع). تُحسَب اتفاقية مستوى الخدمة المركبة لبنية متعددة المكونات بضرب اتفاقيات مستوى الخدمة الفردية؛ فمثلًا، يؤدي ربط App Service (بنسبة 99.95%) بـ Azure SQL (بنسبة 99.99%) إلى اتفاقية مستوى خدمة مركبة تبلغ تقريبًا 99.94%.

اختبروا مدى فهمكم لمفاهيم Microsoft Azure Fundamentals (AZ-900) الواردة في هذا الدرس.

تعلمتم في هذا الدرس أن: Azure توفر خيارات حوسبة متعددة — VMs وVMSS وApp Service وACI وAKS وFunctions — وكل خيار منها يناسب أنواعًا مختلفة من أحمال العمل ومتطلبات التحكم، والقاعدة العامة هي اختيار أعلى مستوى من التجريد يفي بمتطلباتكم لتقليل العبء التشغيلي، والبنى الفعلية غالبًا ما تجمع بين خدمات حوسبة متعددة تُنسَّق من خلال طبقة الإدارة الموحدة في Azure. بعد ذلك، سنبدأ باستكشاف خدمات التخزين في Azure، بدءًا من Storage Accounts.