شراء خادم أم استئجاره أم استخدام السحابة؟ اتخذوا القرار لكل تطبيق على حدة

أربعة نماذج يجب تمييزها بوضوح في العروض

شراء خادم يعني أولاً امتلاك جهاز. قد يوجد في غرفة معداتك أو في مركز بيانات برسوم استضافة مكانية. وتبقى الكهرباء وقطع الغيار ودورة الحياة بأكملها بحاجة إلى تنظيم. قد يناسب الشراء أحمالاً مستقرة طويلة الأجل، لكنه يجمّد رأس المال ويتطلب توقعات واقعية للسعة والعمر المفيد.

في الخادم المخصص المستأجر، يوفّر المزوّد الجهاز الفعلي. يحدد العقد سرعة استبدال القطع المعطلة والدعم المتاح وما إذا كان نظام التشغيل مُداراً. أما الخادم الافتراضي فيشارك منصة فعلية مع أنظمة أخرى. يجب أن تناسب ضمانات أدائه وحدود باقته التطبيق.

قد تشير السحابة إلى هذه الآلات الافتراضية، لكنها تشمل أيضاً قواعد بيانات مُدارة وتخزين كائنات وخدمات موجهة للتطبيقات. لذلك يتجاوز الفرق الدفعة الشهرية إلى الأعمال التقنية التي تؤديها بنفسك وتلك التي تتولاها الخدمة فعلاً. لا يجيب وصف تسويقي مثل «مُدار» عن ذلك دون وصف خدمة محدد.

ستة أسئلة قبل أول مقارنة للأسعار

• كيف يبدو الحمل؟ الاستخدام الداخلي المستقر والذروات الموسمية والمشاريع المؤقتة تحتاج إلى احتياطيات مختلفة.
• أين تتولد البيانات الكبيرة؟ إذا عولج الفيديو يومياً في المكتب، فإن مسار الوصول إلى الحوسبة مهم بقدر قدرة الحوسبة نفسها.
• ما الذي يجب أن يستمر عند انقطاع الإنترنت؟ اكتب مسارات العمل المحلية الأساسية تحديداً.
• من يشغّل النظام؟ التوافر وترتيبات البدلاء والخبرة جزء من القرار.
• ما مقدار الانقطاع وفقدان البيانات المقبول؟ يحدد ذلك النسخ الاحتياطي والاستعادة.
• كيف يمكن إخراج البيانات والتطبيق لاحقاً؟ يجب أن يتكامل التصدير والصيغ والهويات وإعادة البناء.

وثّق الإجابات لكل تطبيق. غالباً ما تختلف متطلبات خدمة الملفات ونظام إدارة الأعمال والبوابة العامة. وقد يؤدي نقل الثلاثة للسبب نفسه إلى إغفال اعتماد محلي أو دفع تكلفة مرونة لا تستخدمها خدمة مستقرة.

مصفوفة قرار تتضمن اعتراضات حقيقية

امنح المعايير أوزاناً بعد إكمال ورقة المتطلبات فقط. إذا وجب استمرار آلة تصنيع عند انقطاع خط الإنترنت، فهذا قيد حاسم لا مجرد درجة منخفضة في ترتيب عام. يمكن الموازنة بين الجهد والتكلفة وقابلية التكيف ضمن الخيارات المتبقية. لا ينبغي أن يخفي ترتيب رياضي عدم الملاءمة.

ثلاثة تطبيقات وثلاثة قرارات محتملة

المثال الأول: مكتب تصميم يتعامل مع ملفات مشاريع كبيرة داخل موقع واحد تقريباً. يكشف الاختبار أن نقل البيانات إلى خدمات بعيدة يستغرق أكبر وقت. قد تلائم الحالة خدمة ملفات محلية مع نسخة خارج الموقع يمكن استعادتها بصورة مستقلة. يتطلب ذلك غرفة مناسبة وصيانة وخطة استبدال. سيتغير القرار إذا أصبح الفريق يعمل أساساً من مواقع موزعة.

المثال الثاني: بوابة حجز عامة تواجه ذروات غير منتظمة ولديها فريق تقني داخلي صغير. يمكن لمنصة تطبيقات مُدارة مع قاعدة بيانات تولي مهام، شريطة تصميم البرنامج لها. يجب فحص تكلفة الحجز وتصدير البيانات وحدود الخدمة. خادم افتراضي ثابت الحجم يعمل طوال اليوم يُعد سحابياً أيضاً، لكنه لا يستفيد تلقائياً من هذه الفرصة.

المثال الثالث: تطبيق داخلي يعمل باستقرار وبطلب مفهوم جيداً. لا تريد الشركة تشغيل غرفة خوادم، لكنها تتعامل مع مزوّد لنظام التشغيل والتطبيق. قد يضبط الجهدَ خادمٌ مخصص مستأجر أو افتراضي بضمانات مناسبة. وتبقى الاستعادة الفعلية واتصال الموظفين ونطاق استبدال العتاد تعاقدياً بحاجة إلى فحص.

من يتولى التحديثات والنسخ الاحتياطي والاستعادة؟

في EC2، تسند AWS إلى العميل، ضمن أمور أخرى، نظام التشغيل الضيف والتطبيق المثبت. يشغّل المزوّد البنية الأساسية. ويختلف التقسيم في خدمات أخرى. طبّق المبدأ على كل عرض واطلب تسمية المسؤول في كل طبقة. AWS: نموذج المسؤولية المشتركة ↗

تسمّي ورقة تشغيل جيدة دوراً مسؤولاً عن العتاد ونظام التشغيل وقاعدة البيانات والتطبيق ووصول المستخدمين والنسخ الاحتياطي. وتشمل البدلاء وأزمنة الاستجابة وإجراءات التغيير. تجنب عبارة «ربما يتولاها المضيف». وإلا فلن تظهر الفجوة إلا عند الحاجة إلى استعادة قاعدة بيانات، حين يكون كل طرف مسؤولاً عن جزء فقط.

يصف RTO المدة المستهدفة للاستعادة؛ ويصف RPO فقدان البيانات المقبول زمنياً. تُشتق الأهداف من العمل. لذلك تميز وثائق AWS بين توافر مكونات منفردة واستعادة تطبيق كامل بعد عطل كبير. AWS: تخطيط التعافي من الكوارث ↗

للمرونة قيمة، وللالتزامات نتائج

لا تحتاج بيئة اختبار يمكن إيقافها بسرعة إلى حساب شراء مماثل لقاعدة بيانات تعمل سنوات. تصف AWS نماذج تسعير مختلفة للأحمال المتغيرة والاستخدام القصير والالتزامات الأطول. قد يخفض الالتزام التكلفة، لكن فقط إذا تحقق الاستخدام المتعهد به فعلاً. لا يغني الخصم عن توقع الطلب. AWS: مواءمة التسعير مع الحمل ↗

اطلب لكل خيار حساباً يستخدم أحجام البيانات ومدد التشغيل والاحتفاظ ومهام الدعم نفسها. واحسب أيضاً شهراً بطلب أعلى ونهاية العقد. يجب أن تشمل الأنظمة المملوكة استبدال العتاد؛ والخدمات الخارجية التصدير والنقل وإعادة البناء. قد يبدو سعر البداية المنخفض مختلفاً على المدة الكاملة.

أثبت قابلية النقل باختبار تصدير صغير

زر التنزيل لا يثبت إمكان الانتقال. صدّر في اختبار مجموعة بيانات تمثيلية مع الإعدادات المطلوبة، واستوردها إلى بيئة هدف مستقلة. افحص بقاء العلاقات والصلاحيات والمرفقات والطوابع الزمنية. ويشمل ذلك للتطبيق مخطط قاعدة البيانات والخدمات اللازمة وربط حسابات المستخدمين.

قِس المدة أيضاً. يستغرق تصدير افتراضي بحجم 2 TB عبر اتصال متاح فعلياً بسرعة 100 Mbit/s نحو 44.4 ساعة للنقل وحده، باستخدام وحدات عشرية. وتُضاف التحضيرات والفحوص والانقطاعات. قد يُقبل ذلك لنقل أرشيف، لا لاستعادة سريعة. لذا تحتاج قابلية التصدير وقابلية الاستعادة إلى اختبارين منفصلين.

اتخذ القرار بتجربة أولية محدودة

اختر تطبيقاً تمثيلياً واختبر الخيار المفضل في ظروف واقعية. تحتاج التجربة معايير قابلة للقياس مسبقاً: زمن الاستجابة لعدد مستخدمين متفق عليه، ونسخة احتياطية كاملة، واستعادة ضمن الهدف، وتقرير تكلفة شهري مفهوم. وحدد مسار الرجوع قبل نقل بيانات الإنتاج.

بعد الاختبار، سجّل القرار في وثيقة قصيرة: النموذج المختار والمسؤوليات المقبولة وافتراضات التكلفة والقيود المقبولة والمراجعة التالية. أفضل بنية هي التي يستطيع الفريق تشغيلها بموثوقية وتغييرها لاحقاً. وقد تختلف حسب التطبيق ما دامت الانتقالات والمسؤوليات واضحة.