Au milieu de toutes les annonces d'AWS re:Invent la semaine dernière - modernisation du mainframe, mises à jour de la base de données, Graviton 3 basé sur ARM, etc. - l'une n'a peut être pas attiré toutes les attentions : Amazon Linux 2022. Si dans sa keynote le CEO d'AWS Adam Selipsky n'en n'a pas fait mention, le vice-président d'AWS Compute Services Deepak Singh s'est quand même fendu d'un tweet sur le sujet. Mais c'est probablement approprié car Amazon Linux 2022 est le genre de « gros morceau » dont les attentes en termes de stabilité, de sécurité et de performances sont grandes, ce que la version bêta n'est peut être pas en mesure de proposer encore. Ce lancement est donc à prendre pour ce qu'il est, autant pour ce qu'il n'est pas. Pour la première fois, Amazon Linux 2022 n'est par exemple pas basé sur le code Red Hat Enterprise Linux (RHEL). Pas plus que sur CentOS, le clone de longue date de RHEL qui a fait des vagues fin 2020. Au lieu de cela, Amazon Linux 2022 est basé sur un projet porté par la communauté Fedora.

Vous pensez que ce n'est pas grave ? Vous devriez peut-être demander aux autres grands fournisseurs de cloud ce qu'ils ont l'intention de faire maintenant que Red Hat a annoncé la fin de vie de CentOS 8 à la fin 2020. Vous voulez vendre des services CentOS au gouvernement américain ? Cette distribution n'est plus conforme à FedRAMP. Le choix devient donc simple : passez à RHEL ou à un autre système d'exploitation pris en charge ou ne pas contracter avec lui. Aie. Qu'elle soit prémonitoire ou simplement opportune, le focus d'AWS sur Fedora pourrait bien rapporter d'importants bénéfices. Mais pour les entreprises qui se demandent ce qu'elles peuvent faire avec CentOS sur la touche, on pourra peut-être prendre la peine de rappeler que les logiciels libres ne sont souvent pas gratuits.

Le logiciel le plus exploité de l'histoire de l'informatique

Il est logique que chaque fournisseur cloud s'appuie sur CentOS. Après tout, tout le monde le fait. Il n'y a qu'à jeter un œil au système d'exploitation sous-jacent des plus grands éditeurs de SaaS pour trouver trace de ces distributions. En se penchant sur les pratiques de consulting d'IBM, on découvre la façon dont le fournisseur a demandé pendant des années à ses clients de « juste utiliser CentOS ». Les cas d'usage sont variés : sites web d'enseignes européennes de mode, Facebook, l'infrastructure télécom chinoise... Tous fonctionnent sur CentOS et il ne s'agit pas d'instances de test et de développement.

« C'est le logiciel le plus exploité de l'histoire de l'informatique. Nos 10 principaux utilisateurs de CentOS ont plus de 50 000 instances, et ils sont le who's who du Fortune 100. Ils savent ce qu'ils font. Ce ne sont pas des développeurs exécutant dev/test. Ce ne sont pas de petites entreprises », a expliqué un dirigeant d'un grand fournisseur cloud lors d'un échange avec un développeur CentOS. Pourquoi ? Parce que ce système a longtemps été considéré comme sûr. Bien sûr, Red Hat a essayé de prévenir ses clients qu'exécuter la distribution en production pouvait présenter certains risques. Mais la réalité est que ces derniers ont été poussés pendant des années par cet éditeur à se tourner vers RHEL et que ce produit était sûr. Dans ces conditions, pourquoi ne serait-il donc pas aussi rassurant d'utiliser CentOS ? Mais la donne a fini par changer. Après l'annonce de CentOS Stream quelques années après l'acquisition de CentOS par Red Hat, l'éditeur a rendu CentOS moins sûr. Soudain, cette distro est passée de « clone RHEL de confiance » à une sorte de « code bêta bizarre de RHEL». 

Red Hat en deus ex machina ?

Les plaintes se sont multipliées, sans pour autant faire basculer les entreprises vers une meilleure alternative. Pendant des années, la communauté CentOS a eu du mal à suivre le rythme de sa popularité. C'est bien d'être populaire, mais moins quand vous n'en tirer aucun bénéfice et que de très grandes entreprises mondiales (banques, opérateurs de télécommunications, etc.) gèrent une grande partie de leurs opérations avec et exigent toutes sortes de modifications du code. Un cocktail idéal en somme pour pousser les développeurs à bout et mettre les entreprises au pied du mur. Il était donc temps d'éviter la surchauffe, et Red Hat est intervenu pour stabiliser la communauté CentOS en embauchant ses principaux contributeurs.

Le but ? Se doter d'une base stable pour des projets communautaires de plus haute volée comme OpenStack et OpenShift ce que n'a pas pu faire Fedora. Bien entendu, Red Hat souhaitait également que les entreprises optant pour la gratuité d'usage comprennent qu'il n'existe pas vraiment de « logiciel libre » au sens pur du terme. Pour rendre le changement moins désagréable pour les développeurs et les petites entreprises, Red Hat a apporté un grand changement à l'édition développeur de RHEL pour la rendre beaucoup plus accessible en la rendant gratuite pour un maximum de 16 serveurs. Un bon moyen pour fournir ainsi aux écoles et autres petites organisations un moyen accessible d'exécuter un Linux testé, certifié et pris en charge.

Des usages cloud intéressants

Rien de tout cela n'aide les fournisseurs de services managés qui doivent faire face aux changements apportés à CentOS. Non pas que ces entreprises ont besoin de Red Hat pour les soutenir car ils exécutent la version sans support depuis des années. Mais la nature même du Linux dont ils dépendent a changé. Drastiquement. C'est une chose d'exécuter un clone d'un Linux pour entreprise dont la qualité du test est éprouvé. C'est une autre chose de faire tourner un logiciel bêta sans aucune garantie de sécurité ou de performance.

Cela commence à ressembler beaucoup au scénario « à manipuler avec précaution » que Red Hat a essayé d'appliquer sans succès à CentOS avant CentOS Stream. C'est devenu soudain un exercice idiot de « dépenser des dollars pour économiser des centimes » étant donné que le système d'exploitation - la base des applications, des bases de données, etc. d'une entreprise - est relativement bon marché par rapport aux dépenses des entreprises pour ses couches IT supérieures. Que faire ? Une réponse « évidente » est de payer Red Hat pour RHEL. Pour ceux qui ne sont pas enclins à le faire, Google a suggéré des alternatives à CentOS et s'est associé à Red Hat pour aider les clients à passer à une version d'OS supportée. Ce que Microsoft propose à ses clients Azure est cependant moins clair. Quand à AWS, ce dernier est déjà passé à Fedora et propose une assistance. Alors oui, ce code sous-jacent est peut-être mieux décrit comme du code alpha, mais les ingénieurs AWS contribueront activement en amont pour l'améliore et le soutenir pleinement.

C'est là que la situation se complique un peu pour les concurrents d'AWS. Personne ne veut vraiment prendre en charge une autre distribution Linux. C'est la raison pour laquelle MongoDB [dont l'auteur Matt Asay est responsable marketing, NDLR] a par exemple opté pour RHEL, Suse et Ubuntu. AWS est le premier à commercialiser son OS Linux. En raison de leur part de marché, ils sont probablement le seul fournisseur suffisamment important pour convaincre les ISV et consorts de prendre en charge leur version de Linux non compatible RHEL. C'est maintenant à Google et Microsoft de trouver comment vivre dans un monde post-CentOS sans la part de marché nécessaire pour les convaincre de prendre en charge leur système d'exploitation. N'oubliez pas que Red Hat a gagné le marché Linux en créant un écosystème autour de son OS certifié. J'entends des rumeurs selon lesquelles ils pourraient se combiner autour d'une offre compatible Suse, mais il est encore trop tôt pour le dire. La seule certitude est que Linux devient à nouveau intéressant. Ce n'est peut-être pas une si bonne chose, car c'est censé constituer un fondement silencieux qui n'attire pas l'attention.