النقاط الرئيسية

• منذ عدة سنوات، تلقينا وعودًا بأن الحوسبة بدون خادم ستقود إلى عصر جديد بدون نظام تشغيل محدد لتشغيل التطبيقات. قيل لنا أن هذا الهيكل من شأنه أن يحل العديد من مشاكل قابلية التوسع. في الواقع، كل شيء مختلف.
• في حين أن الكثيرين ينظرون إلى الخدمة بدون خادم على أنها فكرة جديدة، إلا أن جذورها يمكن إرجاعها إلى عام 2006 مع ظهور Zimki PaaS وGoogle App Engine، وكلاهما يستخدم بنية بدون خادم.
• هناك أربعة أسباب وراء توقف الثورة بدون خوادم، بدءًا من الدعم المحدود للغة البرمجة إلى مشكلات الأداء.
• الحوسبة بدون خادم ليست عديمة الفائدة. مُطْلَقاً. ومع ذلك، لا ينبغي اعتبارها بديلاً مباشرًا للخوادم. بالنسبة لبعض التطبيقات، يمكن أن تكون أداة مفيدة.

الخادم ميت، يعيش الخادم!

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

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

من المؤكد أن بعض النماذج التي لا تحتوي على خادم قد تحققت، ولكن ليس كلها. ليس الجميع.

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

ما وعد به أتباع الحوسبة بدون خادم

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

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

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

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

هل هذه حقا فكرة جديدة؟

في الواقع، الفكرة ليست جديدة. إن مفهوم السماح للمستخدمين بالدفع فقط مقابل الوقت الذي يتم فيه تشغيل الكود فعليًا كان موجودًا منذ أن تم تقديمه بواسطة زيمكي باس في عام 2006، وفي نفس الوقت تقريبًا، قدم Google App Engine حلاً مشابهًا جدًا.

في الواقع، ما نسميه الآن النموذج "بدون خادم" هو أقدم من العديد من التقنيات التي تسمى الآن "السحابة الأصلية" التي تقدم نفس الشيء تقريبًا. كما ذكرنا سابقًا، فإن النماذج التي لا تحتوي على خادم هي في الأساس مجرد امتداد لنموذج أعمال SaaS الموجود منذ عقود.

ومن الجدير أيضًا أن ندرك أن بدون خادم ليس بنية FaaS، على الرغم من وجود اتصال بين الاثنين. تعد FaaS في الأساس الجزء الذي يتمحور حول الحوسبة في البنية بدون خادم، ولكنها لا تمثل النظام بأكمله.

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

مشاكل مع النماذج بدون خادم

المشكلة هي أن النماذج التي لا تحتوي على خادم بها... مشاكل. لا تفهموني خطأ: أنا لا أقول إنها سيئة في حد ذاتها أو لا تقدم قيمة كبيرة لبعض الشركات في بعض الظروف. لكن الادعاء الرئيسي "للثورة" - وهو أن البنية بدون خادم ستحل محل البنية التقليدية بسرعة - لم يتحقق أبدًا.

لهذا السبب.

دعم محدود للغات البرمجة

تسمح لك معظم الأنظمة الأساسية التي لا تحتوي على خادم إلا بتشغيل التطبيقات المكتوبة بلغات معينة. وهذا يحد بشكل خطير من مرونة هذه الأنظمة وقدرتها على التكيف.

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

وهذا يقوض إحدى الفوائد الرئيسية للنموذج بدون خادم.

ملزمة البائع

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

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

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

أداء

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

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

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

وهناك نهج آخر يتمثل في ضمان تشغيل البرامج ذات الأهمية الإنتاجية بشكل منتظم لإبقائها متجددة. هذا النهج الثاني، بالطبع، يتناقض بعض الشيء مع الادعاء بأن الأنظمة الأساسية بدون خادم أكثر فعالية من حيث التكلفة لأنك تدفع فقط مقابل الوقت الذي يتم فيه تشغيل برامجك. لقد قدم موفرو الخدمات السحابية طرقًا جديدة للحد من عمليات التشغيل الباردة، ولكن العديد منهم يتطلب "التوسع إلى واحد"، مما يقوض القيمة الأصلية لـ FaaS.

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

لا يمكنك تشغيل التطبيقات بأكملها

أخيرًا، ربما يكون السبب الأكثر أهمية وراء عدم قيام البنى التحتية بدون خادم باستبدال النماذج التقليدية في أي وقت قريب: أنها (عادةً) لا تستطيع تشغيل التطبيقات بأكملها.

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

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

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

تحيا الثورة؟

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

المصدر: www.habr.com