Переосмысление релизов с долгосрочной поддержкой

Традиционно релизы операционных систем с долгосрочной поддержкой являлись опорой корпоративных развёртываний. Именно такую модель используют IBM, Oracle, Microsoft, Suse и Red Hat, и она является общепринятой концепцией в области операционных систем с момента появления коммерческих предложений по поддержке многие десятилетия назад.

В прошлом как серверные, так и настольные операционные системы следовали этой модели, однако в экосистеме Linux мы начали наблюдать её пересмотр, когда менее формальные продукты получили свободу экспериментировать с более частыми, неподдерживаемыми или просто неструктурированными релизами. В основном продуктовом пространстве openSuse, Fedora и Ubuntu предложили релизы с краткосрочной поддержкой или быстрые релизы. Вместо циклов выпуска, измеряемых годами, и циклов поддержки, приближающихся к десяти годам, они сократили циклы до месяцев, а поддержку — до нескольких месяцев или максимум нескольких лет.

В области настольных систем получение новых функций и приложений раньше, вместо того чтобы сосредотачиваться исключительно на стабильности, как это было принято для серверов, часто имело смысл и давало дополнительное преимущество: новые технологии или подходы можно было тестировать на продуктах с более коротким циклом выпуска перед их интеграцией в серверные продукты с долгосрочной поддержкой. Fedora, например, служит полигоном для технологий, которые, доказав свою состоятельность, войдут в состав Red Hat Enterprise Linux. Используя Fedora, конечные пользователи получают функции раньше, знакомятся с технологиями RHEL заблаговременно, а Red Hat получает возможность протестировать продукты в масштабе перед развёртыванием на критически важных серверах.

Со временем стабильность краткосрочных релизов существенно улучшилась, и всё больше эти системы рассматриваются как жизнеспособные варианты для серверных систем. Такие системы быстрее получают новые улучшения, функции и обновления, что нередко считается преимуществом.

Важным преимуществом любой операционной системы является её экосистема поддержки, включая пакеты и библиотеки, которые поддерживаются и поставляются в составе базовой операционной системы. При долгосрочных релизах мы нередко наблюдаем значительное устаревание критически важных пакетов на протяжении жизненного цикла релиза, что может порождать проблемы с производительностью, совместимостью и даже безопасностью в крайних случаях. Это, очевидно, вынуждает пользователей долгосрочных релизов выбирать между смирением с ограничениями устаревших компонентов или самостоятельной интеграцией новых компонентов, что зачастую нивелирует фундаментальную ценность продукта с долгосрочной поддержкой.

Поскольку цель долгосрочного релиза — стабильность и интеграционное тестирование, замена компонентов продукта для «обхода» ограничений LTS означает, что с этими компонентами больше не обращаются в духе LTS, и интеграционное тестирование от вендора, по всей видимости, больше не проводится или проводится в меньшей степени. По сути, в результате получается самостоятельно собранный продукт с коротким циклом поддержки, но с устаревшими базовыми компонентами и меньшим контролем качества.

В действительности в большинстве аспектов это хуже, чем переход непосредственно на продукт с коротким циклом поддержки. Использование краткосрочного или быстрого релиза позволяет вендору сохранить предполагаемое тестирование и интеграцию, пусть и с более коротким циклом выпуска и поддержки, так что общая ценность концепции долгосрочного релиза сохраняется — и для всех компонентов операционной системы, а не только для нескольких. Это обеспечивает большую стандартизацию, отраслевое тестирование, обмен знаниями и интеграцию, чем при частичной LTS-модели.

Возможно, пришло время переосмыслить ценность долгосрочной поддержки для операционных систем. Слишком долго, по всей видимости, ценность этого подхода просто принималась как данность и применялась без сомнений — и, безусловно, у неё есть и были достоинства; однако мир операционных систем изменился с момента введения этого подхода. Потребность в обновлениях возросла, тогда как темп изменений таких вещей, как ядра и библиотеки, резко замедлился. Более мощные серверы подняли уровень совместимости выше по стеку, и вместо того чтобы писать программное обеспечение под ОС, его всё чаще пишут под конкретную версию языка или среды выполнения или другого уровня абстракции.

Более короткие циклы выпуска означают, что системы получают функции сверху донизу чаще. Обновления между «мажорными» релизами меньше и менее значительны. Изменения от обновлений более инкрементальны, обеспечивая более органичную кривую освоения и адаптации. И что наиболее важно, необходимость замены компонентов системы, тщательно протестированных и интегрированных, сторонними версиями становится, по существу, неслыханной.

Стабильность для вендоров программного обеспечения по-прежнему является ценностью долгосрочных релизов и будет вызывать потребность в использовании долгосрочных релизов ещё долгое время. Однако для системного администратора ценность этого подхода, похоже, снижается и, на мой личный взгляд, достигла переломной точки в последние годы. Раньше казалось нормальным и привычным ждать два-три года обновления пакетов, но сегодня это ощущается как излишне обременительное. Всё более распространённым становится то, что компоненты более высокого уровня создаются с требованием более новых базовых компонентов — с расчётом на то, что операционные системы будут либо более актуальными, либо части ОС будут обновляться отдельно от остальных.

Широкое использование технологий контейнеризации может в каком-то смысле обратить этот тренд, но таким образом, что одновременно снижает ценность долгосрочных релизов. Контейнеризация уменьшает требования к базовым возможностям операционной системы, делая более простым и эффективным более частое обновление для улучшения поддержки ядра, файловых систем, драйверов и контейнеров, оставляя при этом библиотеки и другие зависимости внутри контейнеров — что позволяет приложениям, нуждающимся в компонентах с долгосрочной поддержкой, удовлетворять эти потребности именно там, а приложениям, способным выиграть от более новых компонентов, — использовать их.

Разумеется, виртуализация сыграла роль в снижении ценности моделей с долгосрочной поддержкой, сделав быстрое восстановление и дублирование систем тривиальным. Стабильность, которую нам обеспечивали долгосрочные релизы, частично обеспечивает уровень виртуализации; аппаратная абстракция значительно улучшает стабильность драйверов. В том же ключе devops-модели поддержки также снижают потребность в долгосрочной поддержке и делают серверные экосистемы более гибкими и адаптивными. Тенденции в парадигмах системного администрирования всё больше склоняются в пользу более современных операционных систем.

Время покажет, продолжатся ли тенденции в том же направлении. Лично для меня прошедший год стал открывающим глаза: я перевёл собственные рабочие нагрузки с десятилетнего приверженности продуктам с очень долгосрочной поддержкой на продукты с быстрым циклом выпуска, и должен сказать, что очень доволен этим изменением.