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

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

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

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



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



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



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

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

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



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

1. , , . , .
   
   
2. ( ). , , . VM, , .
   
   
3. . , .

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

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

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



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



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



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

مشاكل النموذج غير المخدم

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



لهذا السبب.

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

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



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



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

البائع ملزم

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



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



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

أداء

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



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



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



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



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

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

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



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



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



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

تحيا الثورة؟

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