Compte tenu de la guerre que se livrent les grands acteurs intervenant sur les containers, Docker bien sûr, mais aussi Google, Microsoft et quelques autres, l’industrie a besoin d’un standard susceptible de mettre tout le monde d’accord. Sans que cela soit encore une certitude, OCI (Open Container Initiative) pourrait jouer ce rôle. C’est en tout cas une très importante brique qui vient s’établir dans le paysage des containers et qui doit beaucoup à Docker.

L’initiative OCI a succédé à l’ « Open Container Project » en 2015, lui-même lancé à l’initiative de Docker, qui sait mieux que tout le monde qu’une technologie aussi structurante que les containers ne peut espérer perdurer, si elle ne s’appuie pas sur une base standardisée universelle. C’est la règle.

Le forum OCI propose d’ores et déjà une première mouture de sa norme, la 1.0 avec deux composants clés : les formats d’images et les spécifications du « runtime », pour l’exécution. C’est un début, sachant qu’il manque encore beaucoup d’éléments, dont certains essentiels comme la distribution des containers ou la méthode pour solliciter une image, hébergée dans un annuaire.

L’un des points forts d’OCI, est sans doute, le consensus qui semble se dessiner autour de son initiative, la plupart des acteurs qui comptent dans ce domaine étant représentés dans le forum : Docker bien sûr, la cheville ouvrière du projet, Dell, Cloud Foundry, Core OS, Google, IBM, Huawei, Intel, Mesosphere, Microsoft, Oracle, Red Hat, VM Ware, etc. Souvent des concurrents de Docker. C’est en tout cas une marque de bonne santé.

L’initiative OCI regroupe aujourd’hui une quarantaine de participants, parmi lesquels les acteurs les plus prestigieux du domaine. Toute la question est de savoir si ce petit monde sera capable de se comprendre et de ne pas chercher à personnaliser le standard à leurs couleurs. Il ne faudrait pas qu’elle se retrouve dans la même situation qu’OpenStack pour le Cloud ou même Unix et Linux
Des objectifs ambitieux

Le forum OCI souhaite faire ce qui n’a pas été fait avec la virtualisation. Créer un cadre dans lequel pourront s’insérer différentes formes de containers, qu’elles viennent de Docker ou d’un autre horizon. Cela veut dire qu’au-delà du runtime et du paramétrage des images containers, il faudra régler de manière commune des aspects sécuritaires, d’administration d’images, surtout hétérogènes.

Ce n’est évidemment pas gagné et on voit mal Google ou Microsoft, pour ne pas les citer, abandonner le leadership d’une opération à une petite compagnie de 250 personnes, qui certes a lancé le mouvement, mais ne représente (pas encore) grand-chose sur l’échiquier industriel de l’informatique moderne. De sorte qu’il faudra être très prudent et ne pas considérer que la présence des Red Hat, IBM, Google et les autres dans OCI, comme une preuve d’acception et de …soumission.

On a déjà vu par le passé des forums du même type, censés unifier les bonnes volontés, n’être en fait qu’une arène où se sont (violemment) affrontés des intérêts divergents et finalement inconciliables des participants.

On ne voit pas pourquoi il en serait différemment avec OCI.

Docker a déjà construit une offre très complète, qui sert de cadre aux différentes briques qui vont constituer le nouvel écosystème. Pour ce qui est des couches de base, runtime et image container (containerd et runc), sont les deux premiers constituants de l’offre OCI 1.0.
La pyramide actuelle

Il faut bien avoir conscience que les spécifications d’OCI, dans leur version courante, sont surtout l’aboutissement de trois ans d’efforts, effectués chez Docker, depuis le premier « commit » de libcontainer en 2014 et surtout sa donation en juin 2015, du format de base container et du runtime runC, qui allaient devenir les éléments fondateurs de la norme 1.0 OCI actuelle.

Pour Docker, ce sont les premiers éléments d’un « ordre futur », rien moins que les TCP/IP et HTTP des containers. L’ambition est évidente.

Pour bien comprendre l’importance stratégique d’OCI 1.0, il faut cependant extrapoler sur les futurs chantiers, ceux qui seront menés par les partenaires et anticiper sur la manière dont ils s’inscriront dans l’échafaudage OCI. Raisonnement qu’il faudra faire au cas par cas, en fonction de la boîte à outils existante ou à venir de l’entreprise.

Prenons l’exemple de Kubernetes, qui est sans doute le plus emblématique des « partenaires » et celui sur lequel les DSI se posent le plus de questions.

Kubernetes de Google est une solution d’orchestration des containers, qui se présente comme LE concurrent de Swarm, l’offre maison de Docker.

Depuis quelques mois, Google a multiplié les annonces le concernant : un CRI (Container Runtime Interface), pour supporter à la fois Docker et son alternative RKT chez CoreOS, mais aussi une version dérivée de CRI, dite CRI-O qui établit un lien entre Kubernetes et tous les runtime compatibles OCI. En gros, Google prend en charge n’importe quel « runtime «  à condition qu’il soit compatible OCI, mais aussi des hyperviseurs à base de conteneurs tel que runv qui supporte certaines versions de KVM et QEMU, ainsi que Xen.

Dans cet esprit d’ouverture et d’intégration, on peut dès lors très bien imaginer ce que sera le futur écosystème standardisé par OCI, qui s’établira sur des services de bas niveau Docker essentiellement : runtime et image container, mais avec au-dessus une très importante panoplie de solutions qui toucheront à tous les domaines, sécurité avec des services de scan, distribution, performances, contrôle de contenus, administration des applications, etc.

L’une des interrogations sera de savoir si l’on pourra faire confiance à un seul fournisseur au-dessus de Docker ou si l’on pourra imaginer des architectures multi-fournisseurs, avec le « best of breed » des solutions du marché.

Malgré les annonces des promoteurs OCI, l’expérience, là encore, nous incite à penser que c’est plutôt la première alternative qui sera choisie. Histoire de ne pas cumuler les obstacles.