Repenser les versions à support à long terme

Traditionnellement, les versions de systèmes d’exploitation à support à long terme ont constitué le rempart des déploiements en entreprise. C’est le modèle utilisé par IBM, Oracle, Microsoft, Suse et Red Hat, et c’est la pensée conventionnelle autour des systèmes d’exploitation depuis le début des offres de support, il y a plusieurs décennies.

Il a été courant par le passé que les versions de systèmes d’exploitation, tant pour les serveurs que pour les postes de travail, suivent ce modèle, mais dans l’univers Linux en particulier, nous avons commencé à voir ce schéma bousculé, lorsque des produits moins formels ont été libres d’expérimenter des versions plus rapides, non supportées ou tout simplement non structurées. Dans l’espace des produits principaux, openSuse, Fedora et Ubuntu ont tous proposé des offres à support à court terme ou des offres à publication rapide. Au lieu de cycles de publication se mesurant en années et de cycles de support approchant la décennie, ils ont réduit les cycles de publication à des mois et le support à seulement quelques mois ou quelques années tout au plus.

Dans l’univers des postes de travail, obtenir plus tôt de nouvelles fonctionnalités et applications, au lieu de privilégier avant tout la stabilité comme c’était courant sur les serveurs, avait souvent du sens et apportait l’avantage supplémentaire que de nouvelles technologies ou approches pouvaient être testées sur des produits à cycle de publication plus rapide avant d’être intégrées dans des produits serveurs à support à long terme. Fedora, par exemple, est un terrain d’essai pour des technologies qui, après avoir fait leurs preuves, se fraieront un chemin vers les versions de Red Hat Enterprise Linux. En utilisant Fedora, les utilisateurs finaux obtiennent des fonctionnalités plus tôt, peuvent se familiariser plus tôt avec les technologies de RHEL, et Red Hat peut tester les produits à grande échelle avant de les déployer sur des serveurs critiques.

Au fil du temps, la stabilité des versions à court terme s’est nettement améliorée, et ces systèmes sont de plus en plus perçus comme des options viables pour les systèmes serveurs. Ces systèmes bénéficient plus tôt des améliorations, des fonctionnalités et des mises à niveau les plus récentes, ce qui est souvent considéré comme un avantage.

Un avantage majeur de tout système d’exploitation est son écosystème de support, y compris les paquets et les bibliothèques qui sont pris en charge et fournis dans le cadre du système d’exploitation de base. Avec les versions à long terme, nous observons souvent des paquets critiques vieillir considérablement tout au long de la durée de vie de la version, ce qui peut entraîner des problèmes de performance, de compatibilité et même de sécurité dans les cas extrêmes. Cela contraint manifestement les utilisateurs de systèmes d’exploitation à version à long terme à choisir entre continuer à composer avec les limitations des composants plus anciens ou intégrer eux-mêmes de nouveaux composants, ce qui brise souvent la valeur fondamentale du produit à version à long terme.

Parce que l’objectif d’une version à long terme est d’assurer la stabilité et les tests d’intégration, remplacer des composants au sein du produit pour “contourner” les limitations d’une LTS signifie que ces composants ne sont pas traités selon une logique LTS et que les tests d’intégration de la part du fournisseur n’ont plus lieu, fort probablement, ou, s’ils ont lieu, pas dans la même mesure. En réalité, ce qui se produit, c’est que cela devient un produit à version à court terme assemblé par soi-même, mais avec des composants de base hérités et une supervision moindre.

En réalité, à bien des égards, procéder ainsi est pire que de passer directement à un produit à version à court terme. Utiliser un produit à publication rapide ou à court terme permet au fournisseur de maintenir les tests et l’intégration présumés, simplement avec un cycle de publication et de support plus rapide, de sorte que la valeur générale du concept de version à long terme est préservée, et ce avec l’ensemble des composants du système d’exploitation mis à jour, et non quelques-uns seulement. Cela permet une plus grande standardisation, davantage de tests à l’échelle du secteur ainsi qu’un partage des connaissances et une intégration plus poussés qu’avec un modèle LTS partiel.

Peut-être le moment est-il venu de repenser la valeur du support à long terme pour les systèmes d’exploitation. Pendant trop longtemps, semble-t-il, la valeur de cette approche a simplement été tenue pour acquise et suivie, et elle avait et a certes des mérites ; mais le monde des systèmes d’exploitation a changé depuis que cette approche a été introduite pour la première fois. Le besoin de mises à jour s’est accru, tandis que les rythmes d’évolution d’éléments comme les noyaux et les bibliothèques ont ralenti de façon spectaculaire. Des serveurs plus puissants ont fait remonter la compatibilité plus haut dans la pile, et au lieu d’être écrits pour un système d’exploitation, les logiciels sont souvent écrits pour une version précise d’un langage, d’un environnement d’exécution ou d’une autre couche d’abstraction.

Des cycles de publication plus courts signifient que les systèmes reçoivent des fonctionnalités, de bout en bout, plus fréquemment. Les mises à jour entre les versions “majeures” sont plus réduites et ont moins d’impact. Les changements issus des mises à jour sont plus incrémentaux, offrant une courbe d’apprentissage et d’adaptation plus organique. Et surtout, le besoin de remplacer des composants système soigneusement testés et intégrés par des versions fournies par des tiers devient, en pratique, du jamais-vu.

La stabilité, pour les éditeurs de logiciels, demeure un atout des versions à long terme et fera qu’un besoin d’utiliser des versions à long terme persistera encore longtemps. Mais pour l’administrateur système, la valeur de cette approche semble décroître et, j’en ai personnellement le sentiment, a atteint un point d’inflexion ces dernières années. Il paraissait autrefois attendu et normal d’attendre deux ou trois ans pour que des paquets soient mis à jour, mais aujourd’hui cela semble inutilement contraignant. Il semble de plus en plus courant que des composants de plus haut niveau soient bâtis avec une exigence de composants sous-jacents plus récents ; une attente selon laquelle les systèmes d’exploitation seront soit plus à jour, soit que certaines portions du système d’exploitation seront mises à jour séparément du reste.

Un recours massif aux technologies de conteneurisation pourrait inverser cette tendance à certains égards, mais d’une manière qui réduit dans le même temps, et systématiquement, la valeur des versions à long terme. La conteneurisation réduit le besoin de capacités étendues dans le système d’exploitation de base, ce qui rend plus facile et plus efficace une mise à jour plus fréquente afin d’améliorer la prise en charge du noyau, du système de fichiers, des pilotes et des conteneurs, tout en laissant les bibliothèques et autres dépendances dans les conteneurs, permettant ainsi de répondre de cette manière aux besoins des applications nécessitant des dépendances à support à long terme, et de traiter de cette même façon les applications susceptibles de tirer parti de composants plus récents.

Bien entendu, la virtualisation a joué un rôle dans la réduction de la valeur des modèles de support à long terme en rendant triviales la récupération rapide et la duplication des systèmes. La stabilité pour laquelle nous avons eu besoin des versions à support à long terme est en partie assurée par la couche de virtualisation ; l’abstraction matérielle améliore la stabilité des pilotes de manière très importante. Dans le même esprit, les modèles de support de type devops réduisent eux aussi le besoin de support à long terme et rendent les écosystèmes serveurs plus agiles et plus flexibles. Les tendances dans les paradigmes d’administration système penchent vers des systèmes d’exploitation plus modernes.

L’avenir dira si les tendances se poursuivent dans la direction qu’elles ont prise. Pour ma part, cette dernière année a été riche en révélations et m’a vu déplacer mes propres charges de travail d’une décennie de soutien indéfectible à des produits à très long terme de support vers des produits à publication rapide, et je dois dire que je suis très satisfait de ce changement.