بدون خادم: ما هو ولماذا يختلف

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

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

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

نظام التشغيل غير معروف!؟!؟

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

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

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

كم عدد الخوادم التي تحتاجها للتعامل مع حركة المرور الخاصة بك؟

إذا كان بإمكانك الإجابة على هذا السؤال بأي نوع من التخمين حول خوادم X أو أننا بحاجة إلى وحدات معالجة مركزية Y ، فأنت لا تقوم بالتطوير بدون خادم.

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

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

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

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

الخمول عند الصفر

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

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

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

المقايضات بدون خادم

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

استبدل تأمين نظام التشغيل بقفل مزود السحابة

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

حتى الآن ، لا توجد مجموعة متفق عليها من المعايير التي تحدد القيود والضمانات بين مقدمي الخدمات. هذا يعني أنه مشابه لمدى صعوبة نقل التطبيقات من Windows إلى Linux على سبيل المثال في الماضي. ستواجه ذلك الآن عند محاولة نقل تطبيقاتك التي لا تحتوي على خادم من Google's Cloud إلى Amazon.

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

رؤية أقل للأداء والتكاليف

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

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

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

التطبيقات التي تعمل لفترة طويلة ليست هي الحل الأمثل

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

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

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