إعادة التفكير في إصدارات الدعم طويل الأمد

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

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

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

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

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

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

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

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

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

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

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

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

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