ملاحظة: كنتُ قد بحثتُ عن ترجمةٍ مناسبةٍ لعبارة (Serverless) وقد وجدتُ العديد من الترجمات المقترحة: “اللاّخوادم”، “التخلّي عن الخوادم”، بدون خادم، “الحوسبة الغير مرتكزة على خوادم”، وغيرها؛ لكنّي رأيتُ أن أترجمها إلى عبارة “دون خادم”.

ملخّص التدوينة: الحوسبة دون خادم (Serverless Computing) والتطبيقات دون خادم (Serverless Applications) وما هو دون خادم، أعتبرهُ لاعبًا خرافيًّا أنيقًا، فمتى كانت لديك فكرة لمنتجٍ ما أو خدمة أو تطبيق، وتريد أن تصل بها إلى السوق بأسرعِ وأخصرِ وقتٍ ممكن؛ فأنصحك بأن تجرّب ثم تتشرّب الحوسبة دون خادم والتطبيقات دون خادم.

مبدئيًا، الحوسبة دون خادم تتيحُ لك بناء وتشغيل التطبيقات والخدمات دون الحاجة إلى التفكير بالخوادم؛ وليس -في الحقيقة- دون الحاجة إلى خادم. التطبيقات دون خادم لا تتطلّب منك تجهيز (Provision) أو توسّع (Scale) أو إدارة (Manage) أيًّا من الخوادم. يُمكنك استخدامهما لبناء أيّ نوعٍ من التطبيقات أو خدمات الناحية الخلفيّة (Backend Service). ستلاحظ -عزيزي القارئ- أنّ كل ما يتطلّب تشغيل وتوسّع ووفرةٍ عالية (High Availability)، ستلاحظ أنّه قد أزيح عن كاهلك.

هذا الأمر -عزيزي القارئ- ثوريٌّ بامتياز؛ فلا حاجة لأن تدفع لقاء خادمٍ خامل (Idle)، ولا أن تقلق بشأن التحديثات الأمنيّة لهذا الخادم أو تقلق بشأن توفّره من عدمه. أنت -عزيزي القارئ- ستدفع -في هذا السياق- لقاء تنفيذ الدالّة البرمجيّة وحسب.

بناء تطبيقاتٍ دون خادم يعني أن يركّز المطوّرون على المنتج الأساسي بدلاً من أن يقلقوا تجاه إدارة وتشغيل الخوادم أو بيئات التشغيل (Runtimes) سواءً كانت هذه الخوادم سحابيّة أو محليّة (On-Premises). إزاحة هذه الضغوط سيمنحُ المطوّرين وقتًا مزيدًا وطاقةً، يُمكن الاستفادة منهما في تطوير منتجاتٍ رائعةٍ وموثوقةٍ (Reliable) تتوسّع متى تطلّب الأمر.

“لامدا (Lambda)” -مثلاً- وهي إحدى خدمات أمازون (AWS) وما يشبهها مثل “دوالّ قوقل (Google Functions)” و”دوالّ أزُور (Azure Functions)”، تتيح لك تنفيذ الشفرة البرمجيّة (Code) دون الحاجة إلى تجهيز أو إدارة الخوادم ذات العلاقة؛ إذ تدفع لقاء وقت الحوسبة (Compute Time) الذي تستهلكه، ليس ثمّة تكاليف للشفرة البرمجيّة الخاملة التي لا تعمل. كلّ ما عليك القيام به أن ترفع شفرتك البرمجيّة إلى هذه الخدمات وما يشبهها ثمّ ستقوم الأخيرة بما هو مطلوب لتشغيل وتوسّع شفرتك البرمجيّة بوفرةٍ عالية.

لنعُد -عزيزي القارئ- إلى فترةٍ سابقة قليلاً، كنتَ حتّى تقوم بتشغيل أيّ تطبيق على الويب -مثلاً-، كنتَ تطلب خادمًا ملموسًا (Physical) مُسبقًا، وكنتَ تعطي معلوماتٍ تفصيليّةً حول كل مكوّنات الخادم، وترمي بتخمينٍ تظنّ أنّه متعمّق فتجد أنّه يؤدي إلى خسائرَ فادحةٍ تأتي -عادةً- إمّا على هيئة شراء خوادم أكثر ممّا يجب، أو -والأسوأ من ذلك- أن تكتشف أنّ الخوادم التي قمت بشرائها لا تستطيع تحمّل الضغط، هما أمران -عزيزي القارئ- أحلاهما مُرّ. كان النّاس -غالبًا- يتحمّلون التكلفة المرتفعة ويشترون خوادمًا بعتادٍ (Hardware) مُذهل. شراء هذه الخوادم القويّة كان يسمّى “التوسّع بشكلٍ عموديّ (Scale Up/Vertical Scaling)”.

(صورة: توضيح لآليّة التوسّع بشكلٍ عموديّ).

بعض الشركات -بعد فترةٍ من الزمن- وجدت حلاًّ وسطًا: “التوسّع بشكلٍ أفقي (Scale Out/Horizontal Scaling)”. هذا يعني إضافة مجموعة من العتاد منخفض التكلفة جنبًا إلى جنب ومن ثمّ توزيع ضغط الحوسبة (Computing Load) بين هذا العتاد؛ كنتيجةً لذلك، ظهرت آلاتٌ ذات قوّة وكُلفة منخفضة بدلاً من آلاتٍ قويّة ومُكلفة. بشكلٍ عام، يعتبر التوسّع بشكلٍ أفقي -نوعًا ما- أسهل وأقلّ كلفةً من التوسّع بشكلٍ عمودي. توسّع -عزيزي القارئ- حسب الاحتياج، توسّع بشكلٍ لا نهائي متى أردت.

(صورة: توضيح لآليّة التوسّع بشكلٍ أفقيّ).

بعد ذلك، جاءت “البيئة الإفتراضيّة (Virtualization)” أو “الحوسبة التخيّليّة”. “الآلة الإفتراضيّة” هي عبارة عن برمجيّة تحاكي الخوادم العتيقة المُعتمدة على العتاد. قد نطرح سؤالاً هنا: ألا يُمكن لهذه البرمجيّة أن تقوم بأيّ شيء من تلقاء نفسها دون أن تحاكي الخوادم؟ ويبدو أن سبب قيامها بذلك هو أنّ هذا النموذج كان هو الذي يستخدمه الجميع.

“السحابة (Cloud)” أتت لاحقًا، بدأت بما يسمّى “البنية التحتيّة كخدمة (Infrastructure as a Service/IaaS)”. البنية التحتيّة كخدمة (IaaS) تضمّ مراكز بيانات (Data Centers) ضخمة وتجعل بينك وبين العتاد طبقة (Layer)، وتتيح لك استخدام الآلات الإفتراضيّة فقط. لاحظ أنّ قابليّة التوسّع (Scalability) باتت أسهل؛ لأنّه صار بإمكانك أن تجهّز خوادمًا إفتراضيّة دون القلق بشأن العتاد، كما ويُمكنك القيام بذلك فورًا و دون الحاجة إلى تخمين متعمّق. احفظ مالك -عزيزي القارئ-، وتحرّك بسرعة.

أتت “المنصّة كخدمة (Platform as a Service/PaaS)” بعد البنية التحتيّة كخدمة، من أمثلتها Heroku و AWS Elastic Beanstalk، بواسطتها أصبح تجهيز الخوادم مؤتمتًا. إذا استطعت إتقان منصّة مقدّم الخدمة (Vendor)، فسيكون نشر (Deploy) التطبيق وتوسعته أسهل بمراحل، كان هذا أوّل انفصال عن النموذج التاريخيّ للخوادم؛ إذ أنّه ليس عليك أن تفكّر فيها كثيرًا.

“إعداد الحاويات (Containerization)” انتشرت في وقتٍ ما هنا. “ديڤ أوبس (DevOps)” و إعداد الحاويات يعتبران موضوعان متداولان. إذ تعتبر إعداد الحاويات طريقة أكفأ لتجهيز البيئة الإفتراضيّة. إذا كنت تدرك أهميّة الآلات الإفتراضيّة؛ حتمًا ستدرك أهميّة الحاويات (Containers).

بعد كلّ ما مضى، جاءت فكرةُ “دون خادم (Serverless)” والأفكار التي تدور في فلكها بمعماريّةٍ تستبدل الآلات الإفتراضيّة والتي تعمل بشكلٍ مطوّل بقوّةِ حوسبةٍ سريعة الزّوال (Ephemeral) تظهر للوجود بمجرّد طلبها وتختفي مباشرةً بعد استخدامها.

(صورة: تطوّر الحوسبة دون خادم).

قُمتُ -قبل فترةٍ بسيطةٍ- ببناء نقطة نهاية (Endpoint) بمعماريّة دون خادم (Serverless Architecture). كانت هذه النقطة ببساطة تستدعي دالّة “الانضمام إلى القائمة البريديّة (Subscribe)” والتي تقوم بضمّ البريد الإلكترونيّ المُدخل إلى القائمة البريديّة بعد التأكّد من صحّته. يُمكن استدعاء هذه النقطة من خلال رابطٍ يبدو كهذا: subscribe?email=test@yopmail.com. بمجرّد أن يتمّ التحقّق من صحّة البريد الإلكترونيّ يتم استدعاء واجهة برمجة تطبيق (API) Mailchimp لتقوم -بدورها- بإضافة البريد الإلكترونيّ إلى القائمة البريديّة لديها. وجدتُ أنّي لم أكن مضطرًا إلى تجهيز الخادم الذي سيحتضن الشفرة البرمجيّة ولا أن أقوم بتشغيل الخادم دون الاستفادة منه في كلّ وقت. أردتُ فقط أن تصل هذه الميزة إلى السوق بأسرع وقتٍ ممكن، وهذا ما تمّ فعلاً.

(صورة: معماريّة دون خادم لدالّة الانضمام إلى القائمة البريديّة).

الآن، ومع وجود العديد من مقدّمي خدمة الحوسبة دون خادم مثل أمازون (AWS Lambda) ومايكروسوفت (Azure Functions) وقوقل (Google Functions) وحتى الخدمات مفتوحة المصدر مثل (Apache OpenWhisk)؛ لا يجدر بك أن تكتب شفرةً برمجيّة لكلّ مقدّم خدمة، الأولى والأجمل أن تعتمد تجريدًا (Abstraction) أو منصّة تنسجم مع كلّ مقدّمي الخدمة، بحيث تكتبُ في مكانٍ واحد يسمح لك لاحقًا بنشر التغييرات على مقدّم الخدمة الذي خصّصت دون حاجةٍ إلى تخصيصٍ في الشفرة البرمجيّة. هناك الكثير من المنصّات للقيام بذلك، تفضّل بالإطّلاع على Serverless Framework كمثال لها.