Elle fait partie du cercle très fermé des « licornes », ces start-ups valorisées à plus de un milliard de dollars. BlaBlaCar, qui a popularisé le concept du covoiturage en France, est également devenue récemment un concessionnaire automobile nouvelle génération. Derrière cette réussite à la française, il y a également une solide infrastructure informatique, dont la particularité est d’avoir récemment migré tous ses services de production en conteneurs. Nicolas Blanc, directeur de l’architecture, nous livre son retour d’expérience sur cette migration, pour laquelle l’équipe backend a préféré Rocket à Docker.

Pourquoi avoir fait le choix des conteneurs pour la production ?

Notre objectif était d’arriver à industrialiser réellement le hardware. Nous avions déjà réalisé une première étape en essayant de déterminer le plus grand dénominateur commun en termes de hardware pour nos services, mais il fallait pousser cette logique d’industrialisation. Si on ne veut pas multiplier les profils de serveurs, que doit-on faire? On travaillait manuellement avec des recettes Chef pour installer de l’Elasticsearch, du Redis etc… mais les limites étaient vite atteintes, notamment en termes d’isolation. Conclusion, pour continuer dans cette logique, il fallait faire de la machine virtuelle. Nous avons regardé ce qui se faisait en termes de VMs, mais nous n’avons pas été convaincus par les performances. Nous avons donc fait le tour du marché, et commencer à regarder comment faisaient les autres sociétés. Particulièrement séduit par les communiqués de Google sur ses containers, et Borg, nous avons commencé à nous intéresser aux containers : si eux le faisaient, alors pourquoi pas nous ?

Nicolas Blanc lors du TIAD en 2015

Pourquoi choisir Rocket plutôt que Docker ?

A ce moment le marché parlait surtout de Docker, mais en creusant nous avons vite identifié des défauts majeurs pour la mise en production. Nous utilisions alors CoreOS, et l’idée des containers nous a semblé compromise, on ne se voyait pas mettre du Docker en production. CoreOS a alors lancé Rocket (rkt), qui semblait corriger tous les défauts de Docker en production. Mais en contrepartie, Rocket n’embarquait pas tous les avantages de Docker, notamment la facilité de développement. Il était cependant plus facile d’écrire les outils manquants dans Rocket, et d’avoir une partie production solide, que de partir sur Docker et d’essayer de corriger ses défauts de production. Et donc nous avons choisi Rocket pour répondre à cette logique d’industrialisation du parc et optimiser l’usage des machines.

Qui a initié le projet? Les développeurs ou la production ?

C’est clairement un projet qui a été initié par l’équipe backend, dans une logique d’optimisation du hardware sans aller dans le Cloud. Pour nous, le Cloud était rédhibitoire en termes de coûts, vu les compétences d’exploitation hardware que nous avions dans l’équipe. Si nous n’avions pas eu ces compétences dans l’équipe, peut-être serions nous allés vers le Cloud. Comme le projet était poussé par la production, nous avons choisi Rocket. Si le choix avait reposé sur l’équipe de développement, le choix se serait certainement porté sur Docker : Rocket ne proposait aucun outil pour les développeurs.

Comment ce choix a-t-il été reçu par les développeurs ?

Ca été bien perçu, les développeurs étaient motivés par le passage aux containers. Mais il y a eu pas mal de difficultés dans l’adoption et la montée en compétence sur la technologie en elle-même. On ne voulait pas faire de la VM déguisée, et donc cela suppose une courbe d’apprentissage importante. Aujourd’hui encore, toute l’équipe n’est pas complètement au niveau.

Est-ce que ça a changé les méthodes de travail ?

On travaillait déjà dans un optique DevOps avec Chef pour gérer nos recettes. Par contre, c’est toujours la production qui gère les logiciels en production : ici, un développeur ne peut pas décider de remplacer Apache par du Nginx. Nous gérons la configuration des logiciels en production, les développeurs gèrent leur code. La séparation des pouvoirs entre les deux est restée forte.

Avez-vous envisagé une transition par le cloud privé et la virtualisation ?

Oui, et la question est toujours ouverte aujourd’hui. Nous nous sommes posé la question en interne : pourquoi ne pas virtualiser overhead ? Nous avons une partie virtualisation, avec des clusters VMware, parce qu’il y a certains côtés pratiques, mais ça reste coûteux. Maintenant qu’on est en containers, la seule difficulté étant d’installer l’OS, VM ou machine physique, ça ne change plus rien. Donc on se repose régulièrement la question. On n’envisage pas le Cloud privé, c’est contre productif, mais le Cloud public propose peut-être un compromis de performances et de tarifs qui nous conviendra, et donc de ne plus gérer physiquement les serveurs. Même si aujourd’hui, nous n’avons plus à nous déplacer dans les datacenters, il reste une partie d’administration dont nous dispenserait le Cloud public. La proposition de tarif est encore très loin de ce qu’on a en administrant nos machines, mais il y a d’autres choses qui nous faciliteraient la vie dans le Cloud public. Si on devait changer rapidement, sans changer de système d’orchestration, il n’y a que Google (avec Kubernetes) qui pourrait répondre à nos besoins. En tous cas, on surveille régulièrement l’évolution de l’offre de Cloud public.

Aujourd’hui c’est la performance qui reste le driver ?

Oui, la performance est vraiment un critère indispensable. Sans le niveau de performances que nous avons aujourd’hui, certaines bases de données ne tournent pas. Donc on ne peut pas les migrer dans le Cloud (Sur Amazon RDS pour la partie MariaDB par exemple).

Combien de temps a pris la migration ? Quelles difficultés ont été rencontrées ?

Entre la prise de décision et le passage en production il s’est écoulé un an. La principale difficulté a concerné les outils : beaucoup des outils dont nous avions besoin pour l’exploitation n’existaient pas. Donc on les a construit et nous les avons proposé en open source (Dgr pour la partie build de l’image ACI, Green Garden ggn pour l’exploitation de la ferme de serveurs…) tous ces outils ont dus être écrits. D’ailleurs, ceux qui savent comment on fonctionnait en termes d’industrialisation avec Chef, retrouveront certains patterns en commun. Nous n’avons pas tout jeté, ce sont des nouveaux outils technologiquement, mais en termes de process nous avons réutilisé une partie de l’existant. L’outillage a vraiment demandé beaucoup de travail. Après, se posent de nouvelles questions. Comment faire les tests pour construire les ACI ? Il n’y a pas d’outil de test, rien n’est intégré… il a fallu repenser toute la chaîne de développement. Cela a représenté 6 mois de développement pour la base, avec peu de personnes impliquées, et 6 mois pour embarquer tout le reste de l’équipe et faire en sorte que tout le monde s’approprie les outils. Pendant que les outils continuaient d’être développés, il fallait faire monter l’équipe en compétence sur ces outils.

Comment vous avez géré cette montée en compétences ? Par des formations ?

Cela s’est fait au sein de l’équipe : ceux qui avaient fait expliquaient aux autres, nous n’avons pas eu le temps de faire autrement. Cela a généré des moments difficiles, ce n’est pas simple de devoir développer un outil très rapidement, former les autres en même temps, et puis tout le monde n’est pas nécessairement prêt à changer ses habitudes de travail pour sauter dans l’inconnu, tout en devant respecter des délais de livraison très serrés. Donc, ça n’a pas été simple, mais aujourd’hui personne ne regrette ce choix.

Quels ont été les bénéfices de cette migration ?

Le premier bénéfice, c’est la réutilisation des conteneurs. A l’époque, même avec des recettes génériques (comme Chef), quand on arrivait sur de nouveaux serveurs, il y avait nécessairement de nouvelles choses à écrire. Aujourd’hui, il n’y pas à réinstaller de serveur, il n’y a rien à réécrire, on monte un nouveau cluster, on précise la configuration et on déploie. Trois minutes après avoir fini la configuration, c’est en production. Si on utilise des images existantes (par exemple sur des cluster MariaDB), c’est vraiment très très rapide. C’est un gain que l’on constate quotidiennement dès qu’il faut monter un nouveau backend.

Est-ce que vous avez gagné également en temps d’ajouts de nouveaux services? 

Nous avons plus de services qu’avant et nous pouvons en lancer de plus en plus, mais il y a encore une marge d’amélioration. Pour construire les conteneurs, il y a encore beaucoup de choses qui dépendent de nous, l’équipe backend. Il faut encore continuer à industrialiser pour que les développeurs soient plus autonomes sur les déploiements. C’est en cours, je pense que d’ici 6 mois on pourra effectivement dire qu’on a amélioré le time to market. Mais c’est encore compliqué de lâcher la main sur certains sujets !

Qu’est-ce que ça a changé au niveau des méthodes de travail et de l’organisation ?

Ce n’est pas tant le passage au conteneur qui a changé quelque chose, que la manière dont est arrivés au conteneur. Les tensions que nous avons rencontrées durant cette migration ont forcé toute l’équipe à une forme de communication et d’agilité nouvelle. Quand il faut aller vite, faire les changements, adapter tout, et qu’on est 25 dans l’équipe, alors il faut changer d’organisation.

Où en êtes vous de votre projet d’automatisation avec Kubernetes ?

C’est en production depuis 3 mois sur un certain nombre d’éléments, nous avançons petit à petit. Cette brique va nous permettre justement d’améliorer le time to market. Aujourd’hui un des inconvénients de notre mode de fonctionnement est l’obligation d’être root pour déployer un nouveau service. Du coup, ça pose problème quand on refuse le droit root aux développeurs pour des raisons de sécurité. Kubernetes va nous permettre de donner de l’indépendance aux développeurs, de façon à ce qu’ils puissent déployer tous les services qu’ils souhaitent quand ils le veulent. C’est notre objectif, que chacun puisse lancer un conteneur, tout en fixant des limites aux services lancés de façon automatisée.

Pour conclure, nous sommes contents d’avoir fait cette migration. Si c’était à refaire, je ne le referai pas nécessairement de la même manière, dans les mêmes circonstances. Là, ça c’est fait en mode “tout ou rien” : on a commandé les serveurs pour tous les exploiter en conteneurs. Si c’était à refaire, je garderai une partie des serveurs dans l’ancien datacenter, je laisserai aux outils le temps de mûrir, et à l’équipe de monter en compétence. Là, ça c’est fait trop vite, même si au final ça a soudé les gens, il y a eu des moments très difficiles. On est passé à deux doigts de voir l’équipe exploser. Les délais étaient trop courts au vu de la maturité des outils. Il est vrai que si Docker avait répondu à nos exigences de production, la migration aurait été beaucoup plus rapide. Là, avec des outils encore très jeunes, il faut vraiment avoir une équipe solide pour se lancer dans cette aventure. C’est un pari sur l’avenir : encore aujourd’hui, nous n’avons pas couvert l’ensemble de ce que nous faisions avant en automatisation, notamment sur les tests. Mais si demain, nous avons besoin de doubler le nombre de serveurs, on le fera très sereinement.

Pour approfondir le sujet, ci-dessous le talk de Simon Lallemand, BlaBlaCar, lors du TIAD 2016