Les containers remettent en question l’organisation d’une DSI. C’est ce que pointe Xavier Mesnil, architecte IT chez Zebestof, société spécialisée dans l’achat programmatique de publicité. Zebestof utilise les containers depuis 2013. Il a pris la parole le 23 mars lors de l’événement Cloud Computing organisé à Paris.
Qui est responsable et de quoi ?
« Les containers gomment les lignes entre Dev et Ops et de qui est responsable de quoi, » dit-il. « A cause de la facilité réelle du container, on s’éloigne des serveurs d’application. Ces couches de facilité, il faut les adresser en termes de responsabilités dans les organisations des systèmes d’information, » insiste-t-il.
On observe une disparition de qui est responsable de quoi entre Dev et Ops. « Avec les containers, le problème à la DSI devient qui est responsable de quoi entre le Dev et l’Ops, » prévient-il. Il souligne que les containers gomment les lignes. « Dire que dans le container, le responsable c’est le Dev, et qu’en dehors du container c’est les Ops, c’est naïf. On risque une perte de compétences des Ops, » reprend-il. Il y voit un piège en termes d’organisation.
« Les containers et les micros services vont plus vite que l’organisation des DSI qui doivent s’adapter, » affirme l’architecte. « Avec les containers et les micro services, la DSI change son organisation, » ajoute-t-il. « Nous travaillons avec des équipes plus petites, plus innovantes. »
Les logiciels reflets de la communication entre informaticiens
L’architecte fait alors référence à la loi de Conway. C’est à dire qu’un composant logiciel qui a de multiples auteurs nécessite que ceux-ci communiquent fréquemment entre eux. Dès lors, l’interface logicielle d’un système informatique reflète les limites sociales de l’organisation qui l’a produit.
Zebestof envoie 9 milliards de messages publicitaires par an. Il s’agit de prestations de RTB (Real Time Bidding), du marketing programmatique. « Il faut répondre à des dizaines de milliers de requêtes d’enchères par seconde. Nous recevons 80 000 ‘bid requests’ par seconde en période de pic de trafic, » illustre Xavier Mesnil.
Zebestof s’est lancé en 2013 dans les containers. Il s’agissait du début de cette technologie et la société Docker venait à peine de se créer. Zebestof qui ignorait l’existence de Docker a créé sa propre technologie de container, à partir d’OpenVZ afin d’améliorer la densité de ses applications.
Un même objet de bout en bout
« Le container sert pour le Dev, le test, la production, c’est un environnement répétable, associant le source, le build, les librairies partagées. C’est un tout complètement homogène ‘bit à bit’. Le container évite que la production plante puisque l’application est dans le même écosystème du poste de Dev jusqu’à la Prod, » se félicite-t-il. Il poursuit : « on va plus vite, comme le dit Docker, il s’agit de Build Ship Run, et on peut en monter en charge de manière horizontale. »
Si c’était à refaire aujourd’hui, Xavier Mesnil choisirait Docker pour les serveurs d’application. « Docker c’est de l’application container, mais il y a un problème de persistance des données. Aujourd’hui, nous ferions le choix de Docker pour les serveurs d’application, mais pour les bases de données, je serais plus réservé. Ils devraient régler les problèmes, » pense-t-il.
Pour lui, la virtualisation par container amène des performances supérieures aux machines virtuelles telles que Xen ou KVM qui transportent de l’overhead. Un container est plus agile et plus léger et apporte des performances accrues. Enfin, « la containerisation fonctionne uniquement sur Linux pour l’heure, mais il y a à venir des solutions de Microsoft« , conclut-il.
