"قابل للتوسع" من أكثر الكلمات استخدامًا بإفراط في تسويق البنية التحتية، وغالبًا ما تُستخدم لتعني ببساطة "يعمل على بنية سحابية" — وهذا ليس الشيء نفسه. قابلية التوسع هي القدرة على استيعاب حمل أكبر بإضافة موارد أكثر، وما إذا كان ذلك ممكنًا فعليًا، وبأي سلاسة، يعتمد على كيفية بناء التطبيق نفسه أكثر بكثير من المنصة التي يصادف أنه يعمل عليها.
ماذا تعني "قابلية التوسع" فعليًا
يكون نظام ما قابلاً للتوسع إن استطاع استيعاب حمل متزايد — مستخدمون أكثر، طلبات أكثر، بيانات أكثر — بإضافة موارد، دون الحاجة لإعادة تصميم جوهرية للقيام بذلك. هذه خاصية محددة وقابلة للاختبار، لا صفة تسويقية: تطبيق لا يستطيع العمل إلا كنسخة واحدة، مهما كبرت تلك النسخة، وصل إلى سقف قابلية التوسع حتى لو كان يعمل على بنية سحابية بموارد يمكن تجهيزها نظريًا بلا حدود.
التجهيز التلقائي مقابل تطبيق مبني لاستخدامه
توفر المنصات السحابية آلية قابلية التوسع — القدرة على تجهيز سعة حوسبة أو تخزين أو شبكة إضافية، غالبًا تلقائيًا استجابة للحمل. ما لا توفره تلقائيًا هو تطبيق مبني فعليًا للاستفادة من تلك الآلية. توجيه تطبيق تقليدي بنسخة واحدة إلى منصة سحابية لا يجعله قابلاً للتوسع أفقيًا؛ بل يشغّل النسخة الواحدة نفسها على بنية سحابية بدلاً من خادم تقليدي، بنفس السقف الأساسي بمجرد وصول تلك النسخة الواحدة إلى حدها الأقصى. تتطلب قابلية التوسع الأفقي الحقيقية أن يستطيع التطبيق نفسه العمل كنسخ متعددة منسّقة خلف موازن حمل — راجع الاستضافة السحابية مقابل الاستضافة التقليدية لمعرفة كيف يختلف التوسع الرأسي عن الأفقي فعليًا.
الحدود التي لا تزيلها قابلية التوسع
حتى تطبيق مصمَّم جيدًا فعليًا وقابل للتوسع أفقيًا له حدود لا تحلها إضافة نسخ أكثر. قاعدة البيانات مثال شائع: إضافة خوادم تطبيق أكثر لا تساعد إن كانت جميعها ما زالت توجّه طلباتها عبر قاعدة بيانات واحدة هي نفسها عنق الزجاجة — توسيع قاعدة البيانات مشكلة معمارية منفصلة بذاتها (نسخ قراءة، تجزئة، تجميع اتصالات) لا تحلها "السحابة" تلقائيًا لمجرد أن خوادم التطبيق أمامها تستطيع التوسع بحرية. الاعتماديات الخارجية — واجهة برمجية خارجية بحدود معدل خاصة بها، معالج دفع، مورد مشترك تعتمد عليه أجزاء أخرى من النظام — تفرض حدودًا لا تزيلها أي كمية من سعة الحوسبة الإضافية على جانبك. قابلية التوسع على طبقة الحوسبة ضرورية لكنها غير كافية لنظام يتعامل مع حمل عشوائي؛ يجب أن تدعم كل طبقة من النظام التوسع فعليًا، لا الطبقة الأسهل لإضافة نسخ إليها فقط. تحديد أي طبقة من نظام محدد هي السقف الفعلي — خوادم التطبيق، قاعدة البيانات، اعتمادية خارجية — قبل الاستثمار في بنية التوسع هو ما يحوّل "نحتاج للتوسع" من هدف غامض إلى مهمة هندسية محددة وقابلة للتنفيذ، بدلاً من بند ميزانية مفتوح بلا نقطة نهاية واضحة يستمر بالنمو دون أن يحل القيد الفعلي أبدًا.
لماذا تتوسع التطبيقات عديمة الحالة بسهولة أكبر
تطبيق عديم الحالة — حيث يُعالَج كل طلب بشكل مستقل، دون الاعتماد على بيانات مخزّنة في ذاكرة تلك النسخة المحددة من الخادم أو قرصها المحلي بين الطلبات — يمكن إضافة نسخ جديدة إليه أو إزالتها بحرية، لأن أي نسخة تستطيع معالجة أي طلب. تطبيق ذو حالة، حيث يحتفظ خادم بشيء يعتمد عليه طلب لاحق (جلسة مخزّنة في ذاكرة محلية، ملف مكتوب على قرص محلي لا تخزين مشترك)، لا يمكن توسيعه بهذه البساطة: يجب أن يصل الطلب إلى النسخة المحددة التي تحمل حالته، أو يجب نقل تلك الحالة إلى مكان مشترك — قاعدة بيانات، ذاكرة مؤقتة موزّعة، تخزين كائنات مشترك — قبل أن يعمل التوسع الأفقي بنظافة فعليًا. هذا أحد أكثر الأسباب شيوعًا لعدم "توسع" تطبيق قائم على السحابة كما كان متوقعًا: بُني على افتراض خادم واحد دائم، ويجب إزالة ذلك الافتراض قبل أن يصبح التوسع الأفقي ممكنًا فعليًا لا متاحًا نظريًا فقط.
علامات أن تطبيقًا ليس قابلاً للتوسع فعليًا بعد
عدد قليل من العلامات الملموسة تدل على أن تطبيقًا ليس جاهزًا فعليًا للتوسع الأفقي، بغض النظر عن المنصة التي يعمل عليها: تتعطل جلسات المستخدمين أو تسجّل خروجهم بشكل غير متوقع حين تُوزَّع الحركة عبر أكثر من نسخة واحدة؛ الملفات المرفوعة أو التقارير المولَّدة لا يمكن الوصول إليها إلا من النسخة المحددة التي أنشأتها؛ أو يعتمد التطبيق على مهام خلفية مجدولة ستعمل مكررة، وتسبب مشاكل، إن شغّلتها أكثر من نسخة في وقت واحد. تدل أي من هذه على أن حالة ما تُحفَظ في مكان غير مشترك بين النسخ، ويجب معالجة ذلك معماريًا قبل أن تساعد إضافة نسخ أكثر فعليًا بدلاً من التسبب في أعطال جديدة.
سيناريو: عرض ومضي سريع يعمل فعليًا
يطلق متجر تجزئة عرض "ومضي" يتوقع له جلب أضعاف الذروة العادية للحركة لبضع ساعات. بُني التطبيق عديم الحالة منذ البداية — تعيش الجلسات في ذاكرة مؤقتة مشتركة لا على خوادم فردية، وتعيش صور المنتجات المرفوعة في تخزين كائنات مشترك لا على قرص محلي لأي نسخة، ولا توجد مهام مجدولة خاصة بخادم بعينه قد تتكرر إن شغّلتها أكثر من نسخة. بفضل ذلك، يستطيع التوسع التلقائي للمنصة السحابية إضافة نسخ تطبيق خلف موازن الحمل مع تصاعد الحركة، وتستطيع أي من تلك النسخ معالجة أي طلب وارد بشكل صحيح، لأن لا واحدة منها تحمل حالة لا تصل إليها الأخريات.
قاعدة البيانات أمام كل تلك النسخ خُطِّط لها بشكل منفصل: تتولى نسخ القراءة طفرة حركة تصفح المنتجات، بينما يذهب الحجم الأصغر من عمليات الكتابة الفعلية (تقديم طلب، خصم من المخزون) إلى قاعدة البيانات الرئيسية، بحجم يناسب ذلك الحمل المحدد والأقل حجمًا لا حركة القراءة الكاملة. حين ينتهي العرض وتعود الحركة إلى خط الأساس، تتقلص نسخ التطبيق الإضافية تلقائيًا، وتكون تكلفة الطفرة مؤقتة فعليًا. لم ينجح شيء من هذا لأن المنصة "سحابية" — نجح لأن التطبيق وقاعدة البيانات كليهما صُمِّما عمدًا، مسبقًا، لهذا النوع المحدد من الحمل المتغير. نفس عرض الومضي السريع على تطبيق ذي حالة بنسخة واحدة على نفس المنصة السحابية كان سيصطدم بسقف سعة تلك النسخة الواحدة، بغض النظر عن كمية البنية التحتية الإضافية المتاحة نظريًا للتجهيز.
نهج عملي لقابلية التوسع
بالنسبة لمعظم الشركات النامية، نقطة البداية العملية ليست البناء لمقياس نظري لا نهائي منذ اليوم الأول — بل فهم أين يقع السقف الفعلي للبنية الحالية، ومعالجة ذلك تحديدًا حين يقترب النمو منه، بدلاً من الإفراط في الهندسة لمقياس قد لا يصل أبدًا. غالبًا ما تُخدَم شركة بنمو ثابت ويمكن التنبؤ به بشكل أفضل بتحديد حجم بنية تقليدية بشكل مناسب ومراجعة السؤال دوريًا من اعتماد بنية سحابية أصلية قبل الأوان؛ نشاط بطلب مرن وغير متوقع فعليًا هو الحالة التي بُنيت من أجلها قابلية التوسع السحابية. توفر الاستضافة السحابية من ANYSRV الآلية الأساسية في كلتا الحالتين — ما يحدد ما إذا كانت تُستخدم فعليًا هو كيفية بناء التطبيق فوقها. تقييم ذلك بصدق قبل الالتزام بميزانية انتقال سحابي، بدلاً من افتراض أن المنصة وحدها ستوفر قابلية التوسع، هو ما يفصل انتقالاً يُجدي فعليًا عن انتقال ينقل السقف المعماري نفسه فقط إلى بنية أغلى.
