Avons-nous atteint le point de basculement vers le sans-distribution ?
Cet article est le deuxième d'une série de trois articles consacrés à la distribution de logiciels libres - le passé récent, le point d'inflexion du présent et l'avenir.
Dans le premier article, nous nous sommes penchés sur les fondements qui ont créé et défini les distributions des systèmes d'exploitation UNIX et Linux, ainsi que sur les défis posés par le statu quo des distributions traditionnelles. Si vous n'avez pas eu la chance de le voir, bonne nouvelle : il est toujours là pour vous.
Aujourd'hui, nous allons expliquer pourquoi nous sommes à un point d'inflexion pour changer ce statu quo.
Il existe un cycle vertueux dans la technologie qui repousse les limites de ce qui est construit et de la manière dont il est utilisé. Une nouvelle technologie émerge et capte l'attention du monde entier. Les gens commencent à expérimenter et découvrent de nouvelles applications, des cas d'utilisation et des approches pour maximiser le potentiel de l'innovation. Ces cas d'utilisation génèrent une valeur significative, alimentant la demande pour la prochaine itération de l'innovation, et à son tour, une nouvelle vague d'innovateurs crée la prochaine génération de cas d'utilisation, entraînant de nouvelles avancées.
La conteneurisation est devenue le fondement du développement de logiciels modernes et natifs pour le nuage, prenant en charge de nouveaux cas d'utilisation et de nouvelles approches pour créer des applications résilientes, évolutives et portables. Elle détient également les clés de la prochaine innovation en matière de livraison de logiciels, nécessitant simultanément l'évolution vers des logiciels sécurisés dès la conception et continuellement mis à jour, et servant de moyen pour y parvenir.
Ci-dessous, j'évoquerai certaines des innovations qui ont conduit à notre révolution conteneurisée, ainsi que certaines des caractéristiques du développement de logiciels natifs dans le nuage qui ont conduit à ce point d'inflexion - un point qui a préparé le monde à s'éloigner des distros Linux traditionnelles et à adopter une nouvelle approche de la fourniture de logiciels open source.
L'itération nous a rapprochés de l'ubiquité
De nombreuses innovations ont ouvert la voie à une distribution de logiciels libres plus sûre et plus performante. Dans l'intérêt de votre temps et de mon nombre de mots, j'évoquerai trois étapes particulières. Chaque étape, de Linux Containers (LXC) à Docker et finalement à l'Open Container Initiative (OCI), s'est appuyée sur son prédécesseur, en s'attaquant aux limitations et en ouvrant de nouvelles possibilités.
LXC a jeté les bases en exploitant les capacités du noyau Linux (notamment les cgroups et les espaces de noms) pour créer des environnements légers et isolés. Pour la première fois, les développeurs ont pu empaqueter des applications avec leurs dépendances, offrant ainsi un certain degré de cohérence entre les différents systèmes. Toutefois, la complexité de LXC pour les utilisateurs et l'absence d'un catalogue de distribution d'images normalisé ont entravé son adoption à grande échelle.
Docker a changé la donne en démocratisant la technologie des conteneurs. Il a simplifié le processus de création, d'exécution et de partage des conteneurs, les rendant accessibles à un public plus large. L'interface conviviale de Docker et la création de Docker Hub, un dépôt central d'images de conteneurs, ont favorisé l'émergence d'un écosystème dynamique. Cette facilité d'utilisation a favorisé une adoption rapide, mais a également suscité des inquiétudes quant au verrouillage des fournisseurs et à la nécessité d'une interopérabilité.
Consciente du risque de fragmentation, l'OCI (Open Containers Initiative) est intervenue pour normaliser les formats de conteneurs et les moteurs d'exécution. En définissant des spécifications ouvertes, l'OCI a veillé à ce que les conteneurs puissent être construits et exploités sur différentes plateformes, favorisant ainsi un paysage sain et concurrentiel. Des projets comme runC et containerd, nés de l'OCI, ont fourni une base commune pour les moteurs d'exécution des conteneurs et ont permis une portabilité et une interopérabilité accrues.
Les normes OCI ont également permis à Kubernetes (une autre norme indépendante des fournisseurs) de devenir une plateforme véritablement portable, capable de fonctionner sur un large éventail d'infrastructures et permettant aux organisations d'orchestrer leurs applications de manière cohérente entre les différents fournisseurs de cloud et les environnements sur site. Cette normalisation et les innovations qui y sont associées ont permis de libérer tout le potentiel des conteneurs, ouvrant la voie à leur omniprésence dans le développement des logiciels modernes.
Les logiciels [conteneurisés] sont en train de manger le monde
Les progrès de Linux, la démocratisation rapide des conteneurs grâce à Docker et la normalisation de l'OCI ont tous été dictés par la nécessité, l'évolution des cas d'utilisation des applications natives poussant l'orchestration et la normalisation vers l'avant. Ces caractéristiques des applications natives de l'informatique en nuage montrent également pourquoi une approche généraliste des distros Linux ne permet plus aux développeurs de logiciels de disposer des bases les plus sûres et les plus modernes pour développer leurs produits :
L'architecture orientée microservices : Les applications cloud-natives sont généralement construites comme une collection de petits services indépendants, chaque microservice remplissant une fonction spécifique. Chacun de ces microservices peut être construit, déployé et entretenu de manière indépendante, ce qui offre une flexibilité et une résilience considérables. Chaque microservice étant indépendant, les concepteurs de logiciels n'ont pas besoin de progiciels complets pour faire fonctionner un microservice, se contentant de l'essentiel au sein d'un conteneur.
Des applications économes en ressources et efficaces : Les applications cloud-natives sont conçues pour être efficaces et économes en ressources afin de minimiser les charges sur l'infrastructure. Cette approche dépouillée s'aligne naturellement avec les conteneurs et une stratégie de déploiement éphémère, de nouveaux conteneurs étant déployés en permanence et d'autres charges de travail étant mises à jour avec le dernier code disponible. Cela permet de réduire les risques de sécurité en tirant parti des logiciels les plus récents, plutôt que d'attendre les correctifs des distro et les rétroportages.
Portabilité : Les applications cloud-natives sont conçues pour être portables, avec des performances et une fiabilité constantes, quel que soit l'endroit où l'application est exécutée. Grâce à la standardisation de l'environnement par les conteneurs, les développeurs peuvent dépasser les sempiternels maux de tête du type "ça marchait bien sur ma machine" du passé.
Le cycle vertueux de l'innovation qui conduit à de nouveaux cas d'utilisation et, en fin de compte, à de nouvelles innovations, est évident lorsqu'il s'agit de la conteneurisation et de l'adoption généralisée d'applications "cloud-native". Ce point d'inflexion de l'innovation et des demandes de cas d'utilisation a entraîné un taux incroyable de changement au sein des logiciels open source et souligne à quel point il est essentiel de trouver une nouvelle approche de la fourniture de logiciels open source.
Dans le dernier blog de la série, nous parlerons de la façon dont Chainguard a développé une nouvelle approche sans distorsion, de ses caractéristiques clés et de l'impact qu'elle peut avoir sur les images de conteneurs open source.
Si vous avez trouvé cela utile, n'oubliez pas de consulter notre livre blanc sur ce sujet et la méthode plus large que nous avons adoptée pour résoudre ce problème pour les organisations.
Share this article
Articles connexes
- engineering
Breaking the release monolith: How OutSystems platform engineering restored trust in delivery
Maria Chec, Technical Program Manager, Outsystems, and João Brandão, Release Engineering Director, Outsystems
- engineering
Owning the boundary: Introducing the Chainguard FIPS Provider for OpenSSL 3.4.0
Dimitri John Ledkov, Senior Principal Software Engineer, and Mandy Hubbard, Senior Technical Product Marketing Manager
- engineering
FIPS-ing the Un-FIPS-able: Apache Kafka
Jamon Camisso, Senior Manager, Software Engineering
- engineering
This Shit is Hard: The complexities of fixing Python library security issues at scale
Wesley Wiedenmeier, Senior Software Engineer
- engineering
How I learned to stop worrying and love the latest tag
Adrian Mouat, Staff Developer Relations Engineer
- engineering
The tech leader’s mandate: Use engineering to accelerate sales velocity
Sam Katzen, Staff Product Marketing Manager