French Tech - Interview d'Emile Vauge, créateur de Traefik

Pour terminer cette année 2020, je vous propose un nouveau format pour ce blog, je vais interviewer ponctuellement des personnes qui composent le paysage de la French Tech !

Pour ce premier billet, j’ai eu l’occasion d’échanger avec Emile Vauge, le papa de Traefik et de Containous, qui s’appelle depuis peu Traefik Labs.

L’occasion de faire une rétrospective sur Traefik qui a soufflé dernièrement sa cinquième bougie.

Afin de ne pas "dénaturer" le contenu de cet échange, cet article ne sera pas disponible en anglais.

L’interview

Quelle a été l’étincelle de départ qui a créé Traefik proxy, quelle est la vision globale que tu avais pour la "raison d’être" de cette solution ? Si tu devais définir Traefik de manière simple, comment le définirais-tu ?

"Automatisation", pourquoi ? Parce que c’est parti de là en fait : il y a cinq ans, je travaillais sur la mise en place d’une plateforme de microservices et à cette époque, les microservices, c’était un concept nouveau, et il n’y avait pas beaucoup d’outillage. Certes il y avait la vague Docker qui commençait, Mesos, etc., mais Kubernetes n’était pas encore né et l’écosystème n’avait pas la fondation CNCF comme structure.

Donc je devais réfléchir sur cette plateforme de microservice qui devait être capable de déployer plusieurs milliers de microservices, et en l’occurrence, je devais être capable d’exposer une bonne partie de ces microservices sur Internet. Quand on commence à devoir jouer avec plusieurs milliers de microservices, autant dire que c’est impossible de faire ça manuellement, et qu’il faut tout automatiser, y compris la configuration des reverse proxys. À l’époque, je travaillais avec Mesos, et j’ai fait mes premiers essais avec les reverse proxys qui existaient à l’époque : Nginx, HA Proxy que j’ai couplé à Consul Template. Au final, on se retrouvait avec une usine à gaz, qui reposait sur plusieurs briques pour avoir un reverse proxy dynamique, et je me suis clairement dit que l’existant ne permettait pas de construire une solution satisfaisante. J’aurais adoré avoir un reverse proxy qui s’intègre directement sur cette plateforme et qui se reconfigure automatiquement.

Les mois suivants, tout ceci a maturé dans mon esprit, en me demandant comment créer un reverse proxy from scratch et qu’on puisse modifier sa configuration sans le redémarrer. Ce qui n’est pas simple. La plupart des reverse proxys redémarrent leur process quand ils changent leur configuration. Je voulais éviter ce point, parce que ce reverse proxy devait être déployé dans Docker qui monitore un process en particulier.

Au bout de quelques mois, j’avais un premier prototype qui marchait et que j’ai opensourcé sur Github et appelé Traefik. Je l’ai publié sur hackernews et il en a fait la front page. Quand on fait la front page de ce site, ça change la donne, et réellement du jour au lendemain, c’est devenu un projet avec plein d’étoiles et une communauté s’est créée en quelques semaines. C’était complètement inattendu, parce que c’était clairement un side project que je faisais pour moi à la base. Je me disais que ça plairait à quelques personnes parce que le concept était sympa, mais je n’ai jamais imaginé que ça deviendrait ce que c’est aujourd’hui.

Je me suis rapidement décidé à quitter mon boulot et à créer une société pour être à 100 % dessus.

Traefik a soufflé sa cinquième bougie dernièrement, de ton point de vue, comment une petite entreprise française a pu s’imposer comme un acteur majeur dans le domaine de l’Ingress controller/Reverse proxy?

C’est la magie de l’open source. En fait qu’on soit français, kenyan, chinois, on s’en fiche. Ce qui compte, ce n’est pas là d’où ça vient, c’est la communauté qui s’est créée et qui a directement été internationale. Il aurait été créé dans n’importe quel pays, ça aurait produit le même résultat. Une fois qu’on a amorcé une communauté, ça donne la possibilité de lever des fonds auprès d’investisseurs et du coup d’accélérer le projet, d’avoir une équipe, et de faire grossir la communauté encore plus vite. Lever des fonds en France, sur l’open source, il y a 10 ans, c’était presque impossible, néanmoins, Traefik en est l’exemple, aujourd’hui, on peut lever des fonds en Europe sur un projet communautaire.

Ces dernières années, l’expansion du capital risque en Europe a permis d’élargir les domaines d’investissement, et l’open source en fait partie. C’est tous ces points qui ont permis la création d’une société basée sur Traefik en France.

Traefik Labs met énormément en avant sa communauté, au travers des "Traefik Ambassadors", avec une communauté grandissante de jour en jour est-ce une activité que vous souhaitez conserver ? Si oui, comment comptez-vous la faire évoluer pour s’adapter à son grossissement ?

L’objectif initial de la communauté des "Ambassadors", c’est de réunir les contributeurs sur les projets, quelque soit la contribution : code, documentation, blogpost, vidéo, webinar, peu importe. C’est donc de réunir les contributeurs les plus actifs dans un même groupe afin de tisser une relation particulière avec eux qui soit dans les deux sens : on les forme, on les inclut dans des discussions sur la roadmap, en bref, l’idée est de créer une émulation dans la communauté.

Il est clair qu’aujourd’hui le succès est au rendez-vous, le groupe des "Ambassadors" grossit très rapidement, et on a conscience qu’une taille trop importante diminuerait l’intérêt de ce groupe. On souhaite vraiment que cela reste qualitatif, et pas forcément réunir le plus de personnes possibles, ce qui n’aurait pas de sens.

Traefik Labs vise l’international, et les équipes sont d’ailleurs partout dans le monde, combien de personnes travaillent aujourd’hui pour Traefik Labs ? Quel ratio d’employé français VS le reste du monde avez-vous ? Comment gérez-vous la barrière de la langue et le décalage horaire ?

Ce sont des chiffres qui bougent régulièrement, mais nous sommes environ une quarantaine de personnes dans sept pays. En effet, nous sommes un peu plus concentrés en France, distribués dans plusieurs villes : Toulouse, Bordeaux, Lyon, Paris.

Nous avons des gens aussi bien au Brésil, aux US, en Afrique du Sud, en Pologne, en Allemagne, etc.

Le plus gros décalage horaire, c’est entre l’Europe et la côte ouest des États-Unis, neuf heures, ce n’est pas si facile à gérer. Quand on finit notre journée en France, c’est le début de la journée pour eux.

Traefik Labs s’est bâti sur un projet open source international et donc multitimezone, multipays, multilangues et multiculturels. Comment fait-on pour gérer cette distribution des équipes ?

On utilise beaucoup la communication asynchrone : Slack, Notion, GitHub, etc. En effet si tout passe par l’oral, une grande partie de l’équipe n’accède pas aux informations. C’est aussi accepter pour certains d’entre nous de travailler ponctuellement en décalé, en essayant d’être flexible, sans abuser bien sûr. Personnellement, je travaille décalé en fin de journée plutôt que tôt le matin, cela me permet de travailler plus facilement avec l’équipe des États-Unis.

On échange uniquement en anglais, rien n’est en français. Même les réunions où il n’y a que des Français peuvent être en anglais, cela permet de partager les comptes rendus ou les enregistrements éventuels directement avec le reste de l’équipe.

Aujourd’hui, nous sommes de fait en full remote (NDLR À cause du confinement), mais nous avons des bureaux à Lyon. On avait des bureaux à Toulouse et San Francisco, que l’on a plus en ce moment à cause du CoVid. En général, quand on a plusieurs personnes dans une même ville, on prend un bureau, pour que les gens puissent travailler ensemble s’ils le souhaitent. Sinon nous essayons de nous voir régulièrement dans l’année, au moins deux ou trois fois : soit on fait des moments où se retrouve tous et on va au ski ou autre chose, soit on se retrouve à des conférences.

Hors CoVid, une boite full remote ne peut pas survivre sans que les gens ne se voient en vrai de temps en temps, c’est impossible. Il faut que les gens prennent le temps de se connaître, fassent la fête ensemble, aillent au restaurant, etc. Et il est important que ces moments soient purement récréatifs et tournés vers l’équipe, sans travail. En ce moment, c’est compliqué pour ça, mais en temps normal c’est ce qu’on essaie de faire.

Traefik Labs, c’est aussi Yaegi, un interpréteur Go, pourquoi avoir créé cet interpréteur alors que d’autres solutions existent déjà, n’y a-t-il pas un risque de créé des divergences sur ce langage jeune qu’est le GoLang ?

Déjà, il n’y a pas d’autres interpréteurs Go qui existent, il y a des interpréteurs écrits en Go, mais de base, le Go est compilé, et il n’y a pas d’autre interpréteur de go écrit en go.

C’est parti du fait que sur Traefik, on a pensé assez tôt qu’une des fonctionnalités les plus intéressantes serait la possibilité d’écrire des plug-ins, des extensions de Traefik complètement personnalisées. Pourquoi ? Parce que beaucoup de sociétés peuvent par exemple avoir besoin de modifier la façon dont les requêtes sont traitées dans Traefik.

Ensuite, il y avait plusieurs possibilités. Go propose un mécanisme de plug-ins basé sur des librairies dynamiques, et initialement, nous étions partis là-dessus. Le souci est qu’ils n’ont jamais complètement terminé cette fonctionnalité : elle ne fonctionne pas sous Windows, et elle est très contraignante, pour pouvoir utiliser une librairie dynamique, il faut d’abord la compiler en utilisant rigoureusement la même chaîne de compilation (OS, processeurs, code, etc.). Au niveau de l’expérience utilisateur, ce n’était pas possible, et nos premiers essais n’étaient pas concluants. C’était de loin notre solution préférée, mais nous n’avons pas pu l’utiliser.

Ensuite, il y a des plug-ins de type GRPC, sous forme de process à côté de Traefik, ces deux process communiquant en GRPC. C’est le mécanisme utilisé par HashiCorp par exemple dans plusieurs de leurs produits. Le souci c’est que sur Traefik, nous aimions bien le fait qu’il n’y ait qu’un seul process, s’il y a deux process, c’est plus complexe à gérer, plus propices aux instabilités. En plus, au niveau performance, c’était un vrai problème, dans le cas de plug-ins modifiants interagissant avec le pipeline du proxy. C’était une solution simple, mais pas envisageable au niveau performance.

La troisième possibilité qu’on ait exploré, c’était de créer un interpréteur en Go. On s’est d’abord dit que c’était un énorme boulot bien sûr, mais on a ensuite pensé que cet effort pourrait avoir un impact communautaire important. Comme pour le JS, où les interpréteurs ont explosé ces dernières années, au point qu’aujourd’hui, on écrit même du code backend en JS.

On s’est donc ditqu'il avait une opportunité qui profiterait à toute la communauté. Faire des plug-ins en Go, c’est une idée séduisante et le fait qu’ils soient interprétables aussi c’est plus flexible.

C’est parti de là, il n’y avait aucune solution évidente. L’idée était donc de remplir un vide technique qui correspondait à un de nos besoins.

Aujourd’hui, les plug-ins nécessitent d’avoir Traefik Pilot et doivent être sur un repository GitHub public. Est-ce que c’est quelque chose qui est amené à évoluer à l’avenir, je sais que certains préféreraient mettre leur code source sur GitLab par exemple, ou qui préféreraient, surtout en entreprise, avoir des plug-ins privés.

Bien sûr, c’est un sujet qui a été très rapidement mis sur la table, on savait que ça poserait problème à certains. Il y a beaucoup de raisons pour lesquelles nous sommes partis dans cette direction :

• On voulait que l’open source soit mis en avant, que les plug-ins soient communautaires, ce qui entraîne une meilleure qualité et transparence.
• Le fait que tout soit centralisé dans un hub unique, en l’occurrence Pilot, permet d’améliorer l’expérience utilisateur. C’est beaucoup plus simple, tout est standardisé, au même endroit.
• Enfin, cette centralisation permet d’améliorer la sécurité des plug-ins, avec la possibilité d’avoir des checks automatisés, de blacklister un plug-in posant problème, etc.

Néanmoins, il y a de vrais besoins d’entreprises qui ne peuvent pas opensourcer leur code. Nous sommes en train d’y réfléchir, et des solutions seront proposées très bientôt sur ce sujet.

En bref, l’idée était de mettre l’open source et l’expérience utilisateur au centre de cette première itération de Pilot. Mais des évolutions vont être apportées pour satisfaire le plus grand nombre.

Remerciements

Je remercie une fois de plus Emile Vauge d’avoir pris le temps de répondre à mes questions et d’en apprendre un peu plus sur cette pépite de la French Tech.

Je remercie aussi Patricia Dugan, community manager de Traefik Labs d’avoir permis cette rencontre et de toujours répondre à mes questions concernant Traefik Labs/Containous.