بازاندیشی در نسخههای پشتیبانی بلندمدت
به طور سنتی نسخههای سیستمعامل با پشتیبانی بلندمدت ستون فقرات استقرارهای سازمانی بودهاند. این مدلی است که توسط IBM، Oracle، Microsoft، Suse و Red Hat استفاده میشود و از ابتدای ارائه پشتیبانی چندین دهه پیش، تفکر رایج در مورد سیستمعاملها بوده است.
در گذشته رایج بوده که هم سرورها و هم نسخههای سیستمعامل دسکتاپ از این مدل پیروی کنند، اما در فضای Linux به ویژه، دیدیم که محصولات کمتر رسمی آزادند که با نسخههای سریعتر، بدون پشتیبانی یا صرفاً بدون ساختار آزمایش کنند. در فضای محصول اصلی، openSuse، Fedora و Ubuntu همه پیشنهادهای پشتیبانی کوتاهمدت یا پیشنهادهای انتشار سریع ارائه دادند. به جای چرخههای انتشار به واحد سال و چرخههای پشتیبانی نزدیک به یک دهه، چرخههای انتشار را به ماهها و پشتیبانی را به فقط چند ماه یا چند سال کاهش دادند.
در فضای دسکتاپ، دریافت ویژگیها و برنامههای جدیدتر زودتر، به جای تمرکز اصلی بر ثبات که در سرورها رایج بود، اغلب منطقی بود و مزیت افزودهای آورد که فناوریها یا رویکردهای جدید میتوانستند بر محصولات با چرخه انتشار سریعتر آزمایش شوند قبل از اینکه در محصولات سرور پشتیبانی بلندمدت ادغام شوند. Fedora، به عنوان مثال، یک محیط اثبات برای فناوریهایی است که پس از اثبات خود، وارد نسخههای Red Hat Enterprise Linux خواهند شد. با استفاده از Fedora، کاربران نهایی ویژگیها را زودتر دریافت میکنند، زودتر در مورد فناوریهای RHEL یاد میگیرند و Red Hat محصولات را در مقیاس بزرگ قبل از استقرار در سرورهای حیاتی آزمایش میکند.
در طول زمان ثبات نسخههای کوتاهمدت به طور چشمگیری بهبود یافته و این سیستمها به طور فزایندهای به عنوان گزینههای قابل دوام برای سیستمهای سرور دیده میشوند. این سیستمها پیشرفتها، ویژگیها و ارتقاهای جدیدتری را زودتر دریافت میکنند که اغلب مفید تلقی میشود.
یک مزیت بزرگ هر سیستمعاملی اکوسیستم پشتیبانی آن است، از جمله بستهها و کتابخانههایی که به عنوان بخشی از سیستمعامل پایه پشتیبانی و ارائه میشوند. با نسخههای بلندمدت، اغلب میبینیم که بستههای حیاتی در طول عمر نسخه به طور چشمگیری قدیمی میشوند که میتواند در موارد شدید باعث مشکلاتی در عملکرد، سازگاری و حتی امنیت شود. این به وضوح کاربران سیستمعاملهای نسخه بلندمدت را مجبور میکند بین ادامه زندگی با محدودیتهای اجزای قدیمیتر یا ادغام اجزای جدید خودشان که اغلب ارزش اساسی محصول نسخه بلندمدت را میشکند، انتخاب کنند.
زیرا هدف یک نسخه بلندمدت داشتن ثبات و آزمایش یکپارچهسازی است، جایگزینی اجزا در محصول برای «کار اطراف» محدودیتهای یک LTS به این معنی است که آن اجزا به شیوه LTS رفتار نمیشوند و آزمایش یکپارچهسازی از طرف فروشنده احتمالاً دیگر اتفاق نمیافتد، یا اگر بیفتد، نه به همان درجه. در واقع، آنچه اتفاق میافتد این است که این یک محصول نسخه کوتاهمدت خودساخته میشود، اما با اجزای اصلی قدیمی و نظارت کمتر.
در واقع، در اکثر جنبهها، انجام این کار بدتر از رفتن مستقیم به یک محصول نسخه کوتاهمدت است. استفاده از یک محصول نسخه کوتاهمدت یا انتشار سریع به فروشنده اجازه میدهد آزمایش و یکپارچهسازی فرضشده را با فقط یک چرخه انتشار و پشتیبانی سریعتر حفظ کند، به طوری که ارزش کلی مفهوم نسخه بلندمدت حفظ شود و با تمام اجزای سیستمعامل، نه فقط چند تا، بهروز شود. این امکان استانداردسازی بیشتر، آزمایش صنعتی و دانش مشترک و یکپارچهسازی بیشتر از مدل LTS جزئی را فراهم میکند.
شاید زمان آن رسیده باشد که ارزش پشتیبانی بلندمدت برای سیستمعاملها را بازاندیشی کنیم. به نظر میرسد برای مدت طولانی، ارزش این رویکرد صرفاً فرض و پیروی شد، و مطمئناً مزایایی داشت و دارد؛ اما دنیای سیستمعامل از زمانی که این رویکرد اول معرفی شد تغییر کرده است. نیاز به بهروزرسانیها افزایش یافته در حالی که نرخ تغییر چیزهایی مثل هستهها و کتابخانهها به طور چشمگیری کاهش یافته. سرورهای قدرتمندتر سازگاری را بالاتر در پشته منتقل کردهاند و به جای اینکه نرمافزار برای یک سیستمعامل نوشته شود، اغلب برای نسخه خاصی از یک زبان یا زمان اجرا یا لایه انتزاع دیگری نوشته میشود.
چرخههای انتشار کوتاهتر به معنی این است که سیستمها ویژگیها را، از بالا به پایین، بیشتر دریافت میکنند. بهروزرسانیها بین نسخههای «اصلی» کوچکتر و کمتر تأثیرگذار هستند. تغییرات از بهروزرسانیها افزایشیتر هستند و یک منحنی یادگیری و تطابق ارگانیکتر ارائه میدهند. و مهمتر از همه نیاز به جایگزینی اجزای سیستم که با دقت آزمایش و با نسخههای ارائهشده توسط شخص ثالث یکپارچه شدهاند، به طور موثر ناشناخته میشود.
ثبات برای فروشندگان نرمافزار ارزشی برای نسخههای بلندمدت باقی میماند و باعث میشود برای مدت طولانی نیاز به استفاده از نسخههای بلندمدت وجود داشته باشد. اما برای مدیر سیستم، ارزش این رویکرد به نظر میرسد در حال کاهش باشد و شخصاً احساس میکنم در سالهای اخیر یک نقطه شکست پیدا کرده. به نظر میرسید انتظار و عادی بود که دو یا سه سال منتظر بهروزرسانی بستهها باشیم، اما امروز این احساس غیرضروری دست و پاگیر میدهد. به طور فزایندهای رایج به نظر میرسد که اجزای سطح بالاتر با الزام اجزای پایهای جدیدتر ساخته میشوند؛ انتظار اینکه سیستمعاملها یا بهروزتر باشند یا اینکه بخشهایی از سیستمعامل جداگانه از بقیه بهروز شوند.
اتکای سنگین به فناوریهای کانتینرسازی ممکن است این روند را به برخی روشها معکوس کند، اما به روشهایی که همیشه ارزش نسخههای بلندمدت را کاهش میدهند. کانتینرسازی نیاز به قابلیتهای گسترده در سیستمعامل پایه را کاهش میدهد و بهروزرسانی مکررتر را برای پشتیبانی بهبودیافته هسته، سیستم فایل، درایور و کانتینر آسانتر و موثرتر میکند در حالی که کتابخانهها و سایر وابستگیها را در کانتینرها باقی میگذارد و به برنامههایی که به وابستگیهای پشتیبانی بلندمدت نیاز دارند اجازه میدهد به این روش رفع شوند و برنامههایی که میتوانند از اجزای جدیدتر بهرهمند شوند به آن شکل مورد توجه قرار گیرند.
البته مجازیسازی در کاهش ارزش مدلهای پشتیبانی بلندمدت نقش داشته با ایجاد بازیابی سریع و تکثیر سیستمها بیاهمیت. ثباتی که نسخههای پشتیبانی بلندمدت را برای رفع آن نیاز داشتیم، تا حدی توسط لایه مجازیسازی رفع میشود؛ انتزاع سختافزار ثبات درایور را به روشهای بسیار مهم بهبود میدهد. به همین ترتیب، مدلهای پشتیبانی سبک DevOps نیاز به پشتیبانی بلندمدت را کاهش میدهند و اکوسیستمهای سرور را چابکتر و منعطفتر میکنند. روندها در پارادایمهای مدیریت سیستم تمایل دارند به نفع سیستمعاملهای مدرنتر باشند.
زمان نشان خواهد داد که آیا روندها در جهتی که در حال حرکت هستند ادامه مییابند. برای خودم، سال گذشته یکی از روشنگرانه بوده که دیدهام بارهایم را از یک دهه حمایت سرسختانه از محصولات با پشتیبانی بسیار بلندمدت به محصولات با انتشار سریع منتقل کنم و باید بگویم، از این تغییر بسیار خوشحالم.
آگهی
