كيف تصل حاويتك من جهازك إلى الإنترنت دون أن تُدير الخوادم بنفسك، ومتى يكون هناك خيار أنسب منها.

التعريف / 01

ما الذي تتولّاه خدمة CaaS فعليًا؟#

تخيّل أنك تريد تشغيل تطبيقك على السحابة، لكنك لا تريد الانشغال بتفاصيل الخوادم ولا ببرمجيات تنسيق معقّدة مثل Kubernetes. هنا بالضبط يأتي دور "الحاويات كخدمة" (CaaS): نموذج سحابي يتكفّل فيه المزوّد بكل ما يخص تشغيل الحاويات وتوزيعها ومراقبتها، ولا يبقى عليك سوى تجهيز صورة حاوية وتحديد متطلباتك.

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

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

الشكل 1 — كلما ابتعدنا عن البنية التحتية الخام (IaaS) واقتربنا من الخدمات الجاهزة (PaaS/FaaS)، تولى المزوّد مسؤولية أكبر من الطبقات. تقف CaaS عند نقطة محددة بدقة: أنت مسؤول عن صورة الحاوية فقط، وكل ما بعدها — من التشغيل الفعلي إلى التوسيع — شأن المنصة.

الأساسيات / 02

لماذا الحاويات أخف من الأجهزة الافتراضية

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

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

الآلية / 03

رحلة الشيفرة من جهازك إلى أول طلب يستقبله تطبيقك

مهما كانت المنصة التي تختارها — AWS Fargate أو Google Cloud Run أو Azure Container Apps — فإن الرحلة تمر بالمراحل ذاتها؛ ما يختلف فعليًا هو من يتولى تنفيذ كل مرحلة منها.

لشكل 3 — كل ما يقع إلى يسار حدود المنصة هو مسؤوليتك: الكود وصورة الحاوية (Image). أما كل ما يقع داخلها — مثل تحديد مكان التشغيل، وفحوصات الحالة (Health Checks)، وإعادة التشغيل، وتوجيه الطلبات — فهو ما تدفع مقابله عند استخدام نموذج «كخدمة» (as a service).

يختلف كل نوع من المنصات بحسب الوحدة التي تصفها وتحدد إعداداتها.
فـ Cloud Run و Fargate يتيحان لك تسليم حاوية واحدة وتحديد إعدادات التزامن (Concurrency).

بينما تكشف Azure Container Apps وخدمات CaaS المبنية على EKS/GKE عن المزيد من مفاهيم Kubernetes — مثل Pods، Services، وقواعد Ingress — مع استمرار المنصة في إدارة طبقة التحكم (Control Plane) نيابةً عنك.

المرونة / 04

كيف “يفكّر” النظام حين يوسّع نفسه تلقائيًا

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

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

المقايضة / 05

ماذا تكسب فعليًا مقابل تخليك عن العنقود

المشهد العام / 06

أبرز الوجهات المتاحة لتشغيل حاوياتك

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

قرار الحكم / 07

متى لا تكون CaaS الخيار الصحيح

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

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

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

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

.