Redéfinissez le Statut (Distro)Quo

Cet article est le premier d'une série de trois articles consacrés à la fourniture de logiciels libres - le passé récent, le point d'inflexion du présent et l'avenir. Nous nous pencherons sur les fondements qui ont créé et défini les distributions des systèmes d'exploitation UNIX et Linux, sur les défis posés par ces distributions traditionnelles, sur le moment de changement qui nous attend et sur l'approche de Chainguard pour définir notre avenir dans le domaine de l'open source.

La première partie se concentre sur la façon dont le statu (distro)quo actuel est apparu et sur certaines de ses implications.

Histoire du monde Linux

En plus de 30 ans d'histoire, les distributions Linux (distros) ont atteint une omniprésence remarquable, alimentant tout, des ordinateurs portables personnels et des serveurs aux environnements complexes en nuage et aux systèmes embarqués. Les différentes saveurs et variétés de distributions Linux témoignent de l'immense popularité de l'open source et des nombreux cas d'utilisation qu'il a permis de résoudre, les principaux acteurs publiant chacun des distributions avec leurs propres caractéristiques et philosophies.

Suivant les traces des systèmes UNIX, les distributions Linux ont adopté la pratique établie consistant à prendre périodiquement des instantanés du noyau et de l'espace utilisateur, à tester rigoureusement, à renforcer, à documenter, à publier, à prendre en charge et, finalement, à retirer chaque version. Pendant des décennies, des piliers comme SUSE, Debian, Red Hat et Ubuntu ont suivi un modèle de production de versions nommées et numérotées.

Pendant plus de trois décennies, les versions d'UNIX et de Linux ont été livrées "lorsqu'elles étaient prêtes". Reconnaissant les cycles de publication asynchrones et imprévisibles de sa distribution mère, Debian, Canonical a introduit un modèle de publication programmée pour Ubuntu. Depuis 2004, Ubuntu est publié de manière fiable sur la branche "devel" de Debian tous les ans, en avril et en octobre. Cela contraste avec l'approche "quand c'est prêt" de Red Hat et de Debian, et donne un certain sens de la prévoyance aux utilisateurs et aux organisations qui dépendent d'Ubuntu. Ce cycle de publication cohérent a aidé les utilisateurs à mieux planifier l'adoption de leur technologie et le déploiement de leur infrastructure, mais le cycle de vie et la maintenance des distributions traditionnelles ont suscité des inquiétudes à plus long terme.

Les logiciels, figés dans le temps

Chaque version résume l'état de l'écosystème des logiciels libres à ce moment précis, avec des milliers de logiciels regroupés dans une distribution générale donnée. Imaginez que chacune de ces versions est un noyau de glace, qui conserve un enregistrement historique des conditions atmosphériques, sauf que dans ce cas, ce sont les logiciels qui sont en grande partie "figés" dans le temps.

La production d'une distribution Linux robuste comme RHEL, Ubuntu ou Debian nécessite des efforts monumentaux, impliquant des centaines, voire des milliers, d'ingénieurs (dont beaucoup sont employés par la distribution, et beaucoup d'autres travaillent bénévolement au sein de leurs propres communautés open source). Si les utilisateurs apprécient la version initiale, la maintenance et les mises à jour permanentes sont tout aussi cruciales. Les responsables de la maintenance, qu'il s'agisse de bénévoles de la communauté ou d'entités commerciales, fournissent en permanence des mises à jour et des correctifs pour ces paquets pendant une période définie, qui aboutit finalement à la fin de vie de la version (EOL). Ces mises à jour corrigent les bogues, améliorent les performances et la stabilité et, surtout, corrigent les failles de sécurité. Cette maintenance et cette assistance critiques finissent par arriver à leur terme, indépendamment de l'état de préparation de l'utilisateur ou de l'organisation, qui doit alors utiliser un logiciel non pris en charge et faire face à des vulnérabilités ou à des incompatibilités par ses propres moyens.

La réalité de l'obsolescence finale conduit les utilisateurs à porter leur attention non plus sur les correctifs en cours et les améliorations mineures des performances, mais sur les mises à niveau "big bang". Ces mises à niveau majeures sont nécessaires pour accéder à de nouvelles fonctionnalités, à la compatibilité matérielle, aux progrès de l'informatique dématérialisée, aux améliorations des performances et à des mises à jour de sécurité plus complètes, mais elles ont un coût considérable. Les mises à niveau majeures prennent toujours du temps et posent des problèmes, menaçant la stabilité et les performances tout en ralentissant la vitesse globale de l'entreprise. Ainsi, même si les entreprises et les amateurs reconnaissent la nécessité des mises à niveau, il est difficile de trouver quelqu'un d'enthousiaste à cette idée, en particulier dans le cas d'un parc d'infrastructures de grande envergure.

En ce qui concerne les distributions Linux traditionnelles, c'est entre le marteau et l'enclume que se trouvent de nombreux utilisateurs de logiciels libres :

• Ils peuvent compter sur des correctifs incrémentaux tant que la version d'une distribution donnée est maintenue. Cela signifie qu'ils doivent appliquer des correctifs à leur infrastructure vieillissante afin de limiter les risques potentiels en matière de sécurité et de performances, tout en étant incapables de sélectionner et d'appliquer chaque correctif à leur environnement stable ;

• Ou ils peuvent tenter une mise à jour "big bang" à grande échelle qui peut offrir de nouvelles fonctionnalités dans des domaines émergents tels que l'intelligence artificielle et résoudre certains problèmes de sécurité non résolus, mais au prix d'efforts considérables et en introduisant de l'instabilité. De plus, il ne s'agit que d'une solution temporaire, car il faudra recommencer tous les deux ans.

Les compromis de la distribution et les efforts de l'image d'or

Ce compromis perpétuel entraîne une série de problèmes organisationnels. Les équipes de sécurité signalent constamment le nombre élevé de CVE et de vulnérabilités dans les logiciels qui sous-tendent toute une série d'applications et de processus, sans qu'il n'y ait de voie claire pour y remédier. Les équipes d'ingénieurs consacrent d'innombrables heures et ressources de développement à tenter de corriger les vulnérabilités sans entraver les performances et le temps de fonctionnement, tandis que les nouvelles fonctionnalités et les innovations sont soit mises de côté, soit retardées. Jongler avec des priorités contradictoires en matière d'ingénierie et de sécurité conduit finalement à une sorte de compromis au niveau du conseil d'administration, qu'il s'agisse d'assumer plus de risques ou de ralentir l'innovation et, potentiellement, l'expansion des revenus.

Certaines organisations ont tenté de résoudre ces problèmes en interne, avec des équipes dédiées à la curation DIY de progiciels et de distros sur mesure par le biais de programmes d'images en or. Ces efforts bien intentionnés visant à répondre aux attentes en matière de sécurité et de normalisation et à accélérer le travail des développeurs sont souvent victimes des défis posés par les modèles de distribution actuels, qui constituent moins un organisme de normalisation qu'un goulot d'étranglement contourné par l'informatique parallèle. Même avec ces programmes en place, les entreprises peinent à respecter les délais de livraison ou à pénétrer de nouveaux marchés axés sur la conformité parce que les logiciels open source de base sont soit vieillissants, soit vulnérables, soit les deux à la fois.

Il est temps d'adopter une nouvelle approche

Tout cela montre clairement que, malgré son histoire en tant que composante fondamentale de la fourniture de logiciels open source, le modèle de distribution traditionnel est de plus en plus remis en question par les exigences de sécurité et la vitesse toujours croissante de l'informatique moderne. Pour véritablement exploiter le potentiel des technologies "cloud-native", nous devons dépasser les limites de la distribution traditionnelle et explorer de nouveaux paradigmes.

Dans le prochain article de cette série, nous examinerons les forces à l'origine d'un point d'inflexion et ce que cela signifie pour le développement de logiciels modernes.

Si vous avez trouvé cela utile, n'oubliez pas de consulter notre livre blanc et l'approche plus large que nous avons adoptée pour résoudre ce problème pour les organisations.