Cet article fait partie de notre guide: Conteneurs et automatisation : la voie royale vers DevOps

Conteneurs : Red Hat milite pour un standard pour éviter la fragmentation

Lars Herrmann, l’expert conteneur chez Red Hat, explique au MagIT comment l’éditeur s’implique dans les communautés Docker, Kubernetes et Appc pour contribuer, à terme, à faire émerger un standard.

Aujourd’hui, la plupart des éditeurs d’OS Linux ont agrafé à leur catalogue une version de leur précieux OS, taillé sur mesure pour le monde des conteneurs applicatifs. Red Hat, en premier lieu, avec son projet Atomic Host (qui utilise Kubernetes comme moteur d’orchestration et Docker comme moteur de conteneurs), mais également Ubuntu avec Snappy Ubuntu Core.

Sans compter aussi sur les pure-players comme CoreOS, dont le projet commercial Tectonic vient grossir les rangs des technologies présentes sur le marché.

Résultat, si la technologie d’applications en conteneurs n’est certes pas nouvelle – les conteneurs existaient déjà avec Solaris et Sun - l’engouement pour ce modèle d’architecture applicatif tend à trouver sa place alors que le Cloud et les environnements hétérogènes habillent de plus en plus les SI des entreprises.

Seulement voilà : avec ce contexte est née une certaine confusion. Des technologies émergent avec deux formats concurrents (Docker et Appc), sans aucun véritable standard ouvert. De quoi donner le tournis aux responsables informatiques et aux développeurs.

Si aujourd’hui le format de conteneur Docker, supporté par l’essentiel des acteurs de l’IT,  est devenu le standard de fait, un autre format a fait son apparition : Appc. Ce format soutenu par VMware, Red Hat et CoreOS est un concurrent direct du format Docker. CoreOS en a fait d’ailleurs le socle de son OS Tectonic, via le format rkt – en fait une implémentation (la première) d’Appc.

Appc, trop restrictif ?

Dans ce climat, en proie à une certaine incertitude, Red Hat a fait le choix de jouer la carte du grand écart. Grand écart ? Comprendre, prendre part à tous les débats, s’impliquer auprès des communautés, en « upstream », pour au final favoriser une forme de convergence, de standard, et l’adoption de l’approche par conteneurs par les entreprises.

C’est ce qu’a tenu à préciser Lars Herrmann (en illustration), expert en conteneurisation chez Red Hat, qui a fait le point sur la stratégie du groupe avec la rédaction du MagIT, sur les engagements de la firme au chapeau rouge dans les projets Appc, Docker et Kubernetes – l’éditeur est le 2e contributeur de ces deux derniers projets.

« Notre participation vise à rassembler les communautés afin d’éviter la fragmentation et d’accélérer l’innovation. Tous les projets Open Source ne sont pas destinés à devenir des solutions pour les entreprises. Appc par exemple ; même si certains aspects liés à la sécurité de la spécification sont intéressants, nous pensons que cela est trop restrictif pour soutenir un écosystème de conteneurs pour entreprises », précise-t-il.

Ajoutant : « Si  nos travaux auprès des communautés ne débouchent pas toujours sur des produits Red Hat, encourager le compatibilité et coordonner les standards entre plusieurs projets contribue à donner naissance à une architecture complète, moderne, fiable et sécurisée. »

Limiter les risques de fragmentation

En clair, il s’agit aussi de limiter les possibilités de fragmentation d’un écosystème, alors que sans standard réel, chacun peut jouer sa partition, même avec les défauts et les qualités des technologies.

« La fragmentation est toujours une crainte dans le monde de l’Open Source, au moins jusqu’à ce que des standards ouverts et communs soient acceptés par projets et communautés. C’est en partie pour cela que nous nous sommes engagés auprès des projets Appc et Docker – nous avons déjà participé à la standardisation, avant le chaos des OS Linux, et nous souhaitons pouvoir aujourd’hui aider en apportant cette connaissance à une spécification ou un standard de conteneur alors que la technologie progresse. Les standards, s'ils osnt bien appliqués, contribuent à limiter les risques de fragmentation », soutient-il.

Certes. Mais comment parvenir à standardiser et éviter la fragmentation si l’une des technologies clés – Docker – est dans le giron d’une unique entreprise et non dans celui d’une fondation indépendante, comme pour OpenStack par exemple ?

De l’avis de Lars Herrmann, la création d’une fondation n’est pas forcément une nécessité. « La fragmentation intervient lorsque des technologies ou des standards distincts ne trouvent pas de consensus dans la communauté ».

Tout en reconnaissant qu’un projet soutenu par une unique société n’est pas sans risque, il affirme que le projet Docker fédère « un très grand nombre de contributeurs ».

« La diversité de ces contributions, associée à la méritocratie appliquée dans le processus de décision, contribue à ce que le projet Docker continue d’être centré sur l’adoption par les entreprises, et  non pas sur les objectifs restreints d’un ou deux acteurs, réduisant alors les possibilités de fragmentation », conclut-il.

Soyez le premier à commenter

M'envoyer une notification dès qu'un autre membre commente.

Merci de créer un identifiant pour pouvoir poster votre commentaire.

- ANNONCES GOOGLE

Close