ماذا يعني مصطلح "الحوسبة السحابية الأصلية" فعليًا؟

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

Kubernetes ونظام الحاويات البيئي

برز Kubernetes كطبقة التنسيق الأساسية لأحمال العمل السحابية الأصلية، ويُعد فهم دوره أمرًا بالغ الأهمية لفهم تطوير التطبيقات السحابية الأصلية الحديثة. يُجرّد Kubernetes البنية التحتية الأساسية - سواء كانت خوادم فعلية أو أجهزة افتراضية أو عقد مزود خدمة سحابية - ويُقدم واجهة برمجة تطبيقات موحدة لوصف حالة النظام المطلوبة. عندما تُعلن عن رغبتك في تشغيل ثلاث نسخ متماثلة من خدمة ما، يضمن لك Kubernetes تشغيلها باستمرار، حيث يقوم باستبدال النسخ المعطلة، وإعادة جدولة أحمال العمل عند تعطل العُقد، وإدارة توجيه الشبكة لضمان وصول مستخدمي الخدمة إلى نقطة نهاية مستقرة بغض النظر عن مكان تشغيل الحاويات الأساسية.
لقد تطورت بيئة CNCF المحيطة بـ Kubernetes لتصبح نظامًا بيئيًا متكاملًا. توفر شبكات الخدمات مثل Istio وLinkerd اتصالًا آمنًا وقابلًا للمراقبة بين الخدمات دون الحاجة إلى تعديل كود التطبيق. تُمكّن أدوات GitOps مثل Argo CD وFlux من إدارة حالة المجموعة بشكل تصريحي ومُتحكم في إصداراته. يوفر Helm إدارة الحزم لتطبيقات Kubernetes. بينما يوفر Prometheus وGrafana بنية المراقبة. تُشكل هذه الأدوات مجتمعةً منصةً تُتيح لفرق الهندسة إدارة البنية التحتية المعقدة دون الحاجة إلى متخصصين في العمليات.

الحوسبة بلا خوادم والتطور ما بعد الحاويات

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

إدارة الإنفاق السحابي كمنهجية للمنتجات: FinOps

تُنشئ البنى السحابية الأصلية تحديات جديدة في إدارة التكاليف، تعجز عمليات شراء تقنية المعلومات التقليدية عن التعامل معها. فعندما يتم توفير البنية التحتية برمجيًا وفواتيرها بالثانية، تنعكس قرارات الهندسة مباشرةً على النتائج المالية؛ إذ يمكن لطبقة تخزين مؤقت غير مُهيأة بشكل صحيح، أو استعلام قاعدة بيانات غير مُحسَّن، أو مجموعة خوادم خاملة، أن تُضيف آلاف الدولارات إلى الفواتير الشهرية دون أن تُثير أي تنبيه تشغيلي.
برزت منهجية FinOps - وهي ممارسة تهدف إلى إضفاء المساءلة المالية على الإنفاق السحابي - كمنهجية معترف بها في مؤسسات هندسة الحوسبة السحابية الأصلية. يعمل ممارسو FinOps مع فرق الهندسة والمالية والمنتجات لتحقيق شفافية التكاليف، وتخصيص الإنفاق لتحقيق نتائج الأعمال، ووضع أهداف التحسين، وإنشاء حلقات تغذية راجعة تُوضح آثار التكلفة للمهندسين عند اتخاذ قرارات التصميم. عادةً ما تُقلل المؤسسات التي تُطبق ممارسات FinOps من هدر الموارد السحابية بنسبة 20-30% خلال السنة الأولى دون المساس بالقدرات أو الأداء.

هندسة المنصات ومنصة المطورين الداخلية

مع ازدياد تعقيد البنية التحتية السحابية، برزت وظيفة تنظيمية جديدة: هندسة المنصات. تقوم فرق المنصات ببناء وصيانة منصات المطورين الداخلية (IDPs) - وهي بيئات مُنسقة وموحدة تُخفي تعقيدات Kubernetes، وشبكات الخدمات، وأدوات المراقبة، وخطوط أنابيب التكامل المستمر/التسليم المستمر (CI/CD) من خلال واجهات سهلة الاستخدام للمطورين. وبدلاً من توقع أن يصبح كل مهندس خبيرًا في Kubernetes، تُنشئ فرق هندسة المنصات "مسارات ذهبية" - وهي عبارة عن سير عمل مُعد مسبقًا ومُحدد مسبقًا يُمكّن مطوري التطبيقات من نشر خدماتهم ومراقبتها وإدارتها دون الحاجة إلى معرفة متعمقة بالبنية التحتية.