kiss my frogs
Contribuer
Twitter Facebook LinkedIn RSS
[ Rechercher ]
Accueil Contribuer TwitterTwitter FacebookFacebook LinkedInLinkedIn RSSRSS

Quand une startup en rachète une autre ! C’est l’aventure vécue par 2 startups bien connues dans le domaine du monitoring. Découvrez les visions croisées de leurs CTOs : Emmanuel Gueidan pour Logmatic acquis récemment par Datadog et Alexis Lê-Quôc. Comment les décideurs techniques vivent-ils cette étape charnière dans la vie d’une startup ? Quels ont été leurs critères de décision respectifs ? A quels challenges ont-ils dû faire face et à quoi ressemble leur quotidien aujourd’hui ? Quels enjeux pour Emmanuel redevenu employé, comment ont-ils réussi à articuler leurs solutions au sein d’un même produit ? Quels impacts sur les technos et les équipes ? Tout ça c’est dans #souslecapot !

Par choix, les anglicismes, termes techniques et raccourcis de vocabulaire sont laissés tels quels – incontournables dans n’importe quelle discussion technique un peu réaliste 🙂

Emmanuel, qui es-tu ?

Emmanuel : Je suis un ingénieur de 34 ans, depuis toujours dans l’édition de logiciel, un dev. J’ai commencé ma carrière chez Dassault Systèmes puis je me suis orienté vers des startups. Un beau jour – c’était il y a 6 ans – j’ai eu envie de lancer ma propre entreprise, Logmatic, qui a été un franc succès et qui m’a amené ici chez Datadog puisqu’ils nous ont rachetés. Au départ, notre startup s’appelait Focusmatic et faisait de l’analyse de réseaux sociaux. On a pivoté vers Logmatic quand on a réalisé que le business n’était pas autant au rendez-vous qu’on l’espérait.

En quoi consistait votre solution Logmatic  ?

Emmanuel : C’est un outil SaaS qui a pour vocation d’aider toutes les entreprises informatisées de comprendre ce que font les applications qu’elles développent. C’est un outil d’analyse de logs : ces bons vieux logs qui trainent dans des fichiers, on peut les consolider et les visualiser dans un navigateur, placer des alertes dessus, faire des rendus graphiques, bref des usages analytiques.

Focusmatic était centré sur Twitter : c’est 140 caractères attachés à une date. Et un log…c’est autour de 200 caractères attachés à une date : on s’est dit que de l’un à l’autre il ne devait pas y avoir tant de différences…

Du démarrage de Logmatic jusqu’à votre rachat, comment ça s’est passé ?

Emmanuel : On était 3 co-fondateurs (Amirhossein Malekzadeh, Renaud Boutet et moi-même), vite rejoints par un premier employé – qui est toujours là ! On est monté à une vingtaine de personnes dont 7 pour l’équipe technique.

Comment êtes-vous passés de Focusmatic à Logmatic ?

Emmanuel : Pour faire fonctionner Focusmatic on avait développé un système distribué qui tournait sur 25 serveurs et on avait souvent besoin de consolider et analyser leurs logs. C’est sur ce besoin interne qu’on a trouvé un marché. Focusmatic était centré sur Twitter : c’est 140 caractères attachés à une date. Et un log…c’est autour de 200 caractères attachés à une date : on s’est dit que de l’un à l’autre il ne devait pas y avoir tant de différences… On a adapté tout ça dans un MVP et on l’a vendu avant même d’avoir le nom Logmatic ! Ce premier jet avec Focusmatic nous a permis d’avoir une expérience d’entrepreneurs et ça nous a bien aidés pour la suite.

On est passé d’une équipe d’une vingtaine de personnes à une société de 400 personnes !

Et de Logmatic vers Datadog : quelle est l’histoire ? Comment vous ont-ils connus ?

Emmanuel : Le premier contact que j’ai eu avec Datadog c’est quand ils sont devenus clients de Logmatic. C’est une histoire assez classique. On ne s’est jamais sentis en concurrence même si on vit dans le même espace puisque Datadog fournit une offre de monitoring d’infrastructure, des métriques, des alertes sur des environnements cloud ou non.

Les logs sont un peu plus orientés troubleshooting mais les deux sont très naturels et complémentaires. On est alignés sur l’ADN aussi : à notre échelle on était petits avec une grosse croissance et Datadog était plus gros mais avec une forte croissance également. La manière de réfléchir aux problèmes (toujours plus de demandes et de clients) et l’approche produit étaient les mêmes.

Datadog propose aussi une offre d’APM (Application Performance Monitoring). Sur un appel à un service web on obtient un découpage du temps passé pour chaque élément du pipeline de traitement : les fameux flame graphs qui font tant rêver.

Comment Logmatic continue-t-il à vivre au sein de l’entité Datadog ?

Emmanuel : La vision Datadog c’est d’avoir un seul outil regroupant les 3 piliers du monitoring : log, infra, APM. On travaille à valoriser l’acquis Logmatic, on a déjà plusieurs clients en beta et beaucoup de belles choses à venir. On réutilise du code mais pas tout et on partage nos expériences respectives : nous sur les logs et eux sur d’autres sujets sur lesquels ils ont plus d’expérience que nous.

Dans le processus de rachat, ce qui est dur c’est le lien à l’équipe : comment vont-ils le vivre ?

Comment s’est passée cette proposition de rachat ? C’est le graal ! Toutes les startups rêvent de se faire racheter ?

Emmanuel : Les propositions de rachat c’est assez flatteur mais c’est quelque chose auquel tout entrepreneur a déjà réfléchi ou même a déjà vécu : on accepte rarement la première proposition qu’on nous fait. Ce n’est finalement pas si exotique que cela et cela fait partie de la vie de la startup.

Par contre, c’est très prenant en temps et énergie donc il ne faut pas se lancer dedans par curiosité mais bien si on est prêt à aller jusqu’au bout.. Ce n’est pas le genre de décision qu’on prend facilement parce que ça va bien au-delà de soi, ça impacte le travail de beaucoup de personnes et c’est tout ça qu’on essaie de prendre en compte. C’est très particulier et très intéressant à vivre !

 

Qu’est ce qui est le plus compliqué à vivre quand on est racheté ?

Emmanuel : Il y a différentes étapes. Dans le processus de rachat, ce qui est dur c’est le lien à l’équipe : comment vont-ils le vivre ? Ça prend pas mal de temps de cerveau, ainsi que de discussions par la suite une fois que c’est annoncé : c’est un moment délicat. Ensuite, une fois le rachat fait, le plus dur à vivre c’est le changement d’échelle qui est très important et très brutal : on passe d’une équipe d’une vingtaine de personnes à une société de 400 personnes. Quelque part même si on est dans un inconfort permanent quand on entreprend, c’est celui qu’on a choisi et qu’on s’est créé : on connait tout sur le bout des doigts et du jour au lendemain on se retrouve dans l’inconnu. C’est pas comme quand on décide de changer de  boulot, on réfléchit 6 mois, on a 3 mois de préavis…là les choses s’emballent un peu plus que cela.

Comme on a envie de bien faire, on se met la pression et on travaille très dur : c’est un mix d’excitation et de découverte de l’inconnu qui est grisant mais pas facile.

Un autre changement important pour le CTO : dans ta startup tu étais décideur et là tu te retrouves avec un management au-dessus de toi ? Comment le vis-tu ?

Emmanuel : Pas trop mal (rires). Datadog est aussi une startup. On est dans le même monde : avoir une personne qui décide pour tout le monde ne permet pas de croître rapidement donc on a beaucoup de latitude.

Ce qu’on nous demande c’est apporter ce côté entrepreneurial, cette énergie et cette autonomie à l’entreprise. Alexis me fait confiance pour le développement de ce nouveau produit et pour contribuer au bon développement des équipes de R&D de Datadog. De plus cela nous a également enlevé certains problèmes : celui du financement par-exemple. Déjà avec Logmatic, je n’étais pas seul à décider et j’avais des comptes à rendre : mes associés, mes investisseurs. Maintenant j’ai une équipe beaucoup plus grosse, des collègues au quatre coins du monde, ce sont autant de responsabilités en plus.

Quels sont tes prochains challenges  ?

Emmanuel : On a un gros travail produit pour affiner au maximum l’offre et satisfaire la base de clients. Etre capable de faire grossir l’équipe rapidement tout en étant percutant dans ce qu’on livre et avec une problématique de scalabilité très importante.

On a plusieurs gros chantiers dont l’orchestration : je veux éviter que les opérations soient un frein à l’équipe. Si on continue à s’orienter vers du micro-service, on a besoin d’industrialiser la sortie de nouveaux services : les mettre en production plus rapidement et de manière plus agile.

Je suis à Paris, j’essaie également de contribuer au bon développement de ce bureau où nous avons aujourd’hui plus de 50 ingénieurs et de grandes ambitions de croissance.

[Alexis arrive !]

Bonjour Alexis, peux-tu nous parler de toi et surtout comment tu es devenu CTO de Datadog ?

Alexis : Ca fait 20 ans que j’habite à New York. J’ai bossé dans de très grosses et aussi de très petites entreprises. Avant Datadog avec mon co-fondateur on faisait tourner une boîte SaaS dans l’éducation. Rien à voir donc mais c’était déjà du SaaS ! C’est là entre 2001 et 2010 qu’on a développé l’idée de Datadog car les outils de monitoring n’étaient pas terribles et mal distribués : les devs avaient zéro visibilité alors que ce sont eux qui font le plus de changements comparés  à l’équipe opérationnelle. Mon parcours est celui d’un software engineer et j’ai aussi fait tourner des équipes opérationnelles. J’ai fait de tout, monter des racks de serveurs dans des datacenters et faire tourner des solutions 24h/24h.  C’est une composante forte de Datadog : cet aspect 24/24 de monitoring et d’alerting.

On répond à un problème d’observabilité et on apporte de la visibilité en temps réel aux équipes qui construisent et gèrent des services en ligne.

Combien êtes-vous chez Datadog ?

Alexis : Nous sommes 560 employés et on ajoute au moins 1 personne par jour. La proportion des profils techniques est autour de 35 à 40%.

Comment avez-vous connu logmatic ?

Alexis : Je pense qu’on les a vus sur un site de news. A ce moment-là on avait déployé un truc en interne basé sur du LogStash et on avait galéré. On a vu que c’était une boite Française et on a voulu essayer. C’est arrivé de manière assez fortuite. On a été leur client pendant un temps, on a vu comment ça marchait et ça nous a donné l’idée de voir s’il y avait qq chose de plus poussé à faire avec eux. On n’était pas encore dans une démarche où l’on voulait se lancer dans le domaine : on les a utilisés comme un client final. C’est comme cela que ça a commencé.

En amont de la transaction on avait validé la compatibilité philosophique entre les équipes.

Peux-tu présenter Datadog ? A quel problème répond votre solution ?

Alexis : On répond à un problème d’observabilité et on apporte de la visibilité en temps réel aux équipes qui construisent et gèrent des services en ligne.

Il y a plusieurs angles : infrastructure (machines, VM, lambdas, containers, …), performance applicative (APM) et une dimension logs via Logmatic. On a besoin de ces 3 aspects pour comprendre correctement ce qui se passe dans une solution et répondre aux questions que nos utilisateurs se posent. Datadog est né en 2010, au moment où a commencé la migration vers le public cloud et où les application cloud-native ont émergé. Fin 2015, de grosses banques américaines qui étaient jusqu’alors complètement opposées au cloud, ont décidé de faire un virage 180° vers le cloud public. C’est un changement fondamental de l’informatique d’entreprise et on les aide à réussir cette migration en donnant à leurs équipes un maximum de visibilité dans ce nouveau monde, pendant et après leur migration..

Votre solution est disponible sur quels cloud ?

Alexis : On supporte tous les clouds providers, et on fonctionne aussi “on-premise”. C’est important pour nous de ne pas être marié à un seul cloud provider : on peut répondre à tous les scénarios.

D’un point de vue techno, sur quoi repose Datadog ?

Alexis : Notre solution est bâtie autour de kafka. Ca n’a rien de surprenant quand on fait du “near real-time Analytics”. On fait beaucoup de Golang depuis 2012 notamment sur tous les traitement de stream processing.  On lit des micro-batches depuis Kafka, traite les messages,  et on dépose les résultats dans kafka pour continuer le traitement en aval. Il y a aussi un historique de code python lié à notre utilisation de numpy et scipy. Python n’est pas idéal pour la gestion de la concurrence, de la mémoire et des performances d’où notre transition vers Go. Pour les traitements batch on utilise spark avec des traitements en scala : on dépose et on pioche dans du cloud storage avec un format parquet : on en a essayé pas mal avant de faire ce choix.

Avez-vous une DB métier ?

Alexis : Pour les besoins de type time series (hors logs et APM), on a une API qui va orienter les requêtes selon l’âge de la donnée. Le use case d’observabilité est souvent quasi-temps réel : tu veux voir ce qui se passe maintenant.

Pour ça on a développé de manière indépendante une Time series DB maison qui ressemble à ce qu’avait fait Facebook : Gorilla qui est devenu Beringei depuis. Ca lit depuis kafka, ça stocke en mémoire et les requêtes se font directement depuis la mémoire.

Pour APM c’est un mariage des 2 stacks même si c’est une infrastructure à part : un peu comme les logs et un peu comme les time series. On va trouver entre autres notre time series db, de l’elastic search et du PostgreSQL.

Vous utilisez PostgreSQL, comment réglez-vous le problème de scalabilité d’une base relationnelle en cluster ?

Alexis : Comme tout le monde on “shard” tout. L’avantage c’est que ça plante très rarement. La machine peut être sur les genoux mais ça avance quand même. À la différence  des bases NoSQL distribuées à la Cassandra : si tu as un problème dans le protocole de gossip, il se distribue et tu peux ainsi planter l’ensemble de ton cluster à cause d’une fausse manip. Avec un système plus isolé, on a moins de dommages collatéraux. Pour un service partagé entre tous les clients (“multi-tentant”) c’est essentiel.

En terme d’échelle on est dans un no man’s land entre Google et le reste des boites techniques qui opèrent souvent à une échelle inférieure.

Du coup il y a peu de technologies disponibles qui répondent à nos besoins.

Où se fait l’articulation entre Logmatic et Datadog ? En terme d’archi ?

Alexis : On a des points d’interconnexion qui sont des services. Nous on consomme des services Datadog : ça passe par de l’exposition de services avec gRPC. n évite d’avoir trop d’imbrication bas-niveau.

Quelle est votre stratégie dans le choix des technos ?

Alexis : On essaie d’avoir une de convergence de technos pour uniformiser les savoir-faire et les compétences des équipes. On essaie d’être pragmatiques pour aller le plus vite possible : on ne va pas choisir une techno parce qu’elle est cool ou s’il n’y a que 3 personnes dans le monde qui la maîtrisent.

On fait des choix structurants sur l’inter-connexion par-exemple : utiliser gRPC c’est une manière de forcer une trajectoire technique. On laisse aussi de la liberté aux équipes : n’importe quoi du moment que c’est gRPC. Il ne faut pas que chaque décision soit soumise à un comité centralisé…on est très très loin de cela.

Utilisez-vous les conteneurs tout comme Logmatic ?

Alexis : On supporte les conteneurs & kubernetes depuis le début pour nos clients et on commence à les utiliser pour notre propre solution. C’est là qu’est la tendance du marché et on veut avoir le même vécu que nos clients. Cela s’inscrit aussi dans une stratégie multi-cloud pour que notre implémentation reste facilement portable entre clouds.

A quels défis avez-vous dû faire face suite au rachat de Logmatic ?

Alexis : Ca s’est plutôt bien passé jusque là. En amont de la transaction on avait validé la compatibilité philosophique entre les équipes. Ce qui nous a vraiment attirés dans Logmatic c’est non seulement une approche produit et technique similaire mais aussi une compatibilité de caractères et de personnalité. Dans les 2 cas, ce sont des boîtes créées par des ingénieurs : c’est important. On est dirigé par le produit et non pas par les ventes et c’est ce qui nous rend compatibles.

Quels sont vos enjeux techs et vos prochains challenges chez Datadog ?

Alexis : En terme d’échelle on est dans un no man’s land entre de très gros comme Google et le reste des boites techniques qui opèrent souvent à une échelle bien inférieure à la nôtre.

Du coup il y a peu de technologies disponibles qui répondent à nos besoins. Kafka en est une mais en terme de time series, y’a rien qui soit disponible publiquement qui correspondent à notre échelle et pourtant on a essayé plein de trucs ! C’est une partie très intéressante pour nos équipes de dev mais c’est difficile car il faut savoir l’inventer. La corollaire c’est que du fait de la taille de la boite et de la croissance du nombre de clients on se retrouve à devoir tout changer tous les 18/24 mois car c’est difficile de concevoir un système qui devra encaisser une croissance supérieure à x10 tous les 12-24 mois. C’est même discutable de savoir si c’est pertinent de le faire.

Donc on se retrouve en permanence à faire la maintenance de l’existant, continuer à le faire évoluer en même temps que d’inventer l’étape d’après. On doit trouver un équilibre pour que les équipes ne soient pas complètement absorbées par la maintenance ou complètement distraites par la prochaine étape..

La dernière techno que vous avez kiffé ?

Alexis : J’ai des lectures assez éclectiques : un truc qui m’intéresse c’est TLA+ :  une méthode de formalisation du fonctionnement des systèmes à base temporelle. C’est à dire des files d’attente ou tous les process dans lesquels le temps joue un rôle important. La méthode provient de Microsoft Research et plus précisément de Leslie Lamport qui l’a formalisé. Il permet d’avoir des garanties plus mathématiques sur le fonctionnement des systèmes : en particulier les systèmes distribués qui sont notoirement difficiles à concevoir de manière fiable. C’est intéressant car les méthodes formelles ont fait leurs preuves dans l’aviation et pendant très longtemps l’info d’entreprise restait très artisanale. Je pense que c’est en train de changer et la ré-émergence des langages fonctionnels c’est un peu la même logique. TLA+ c’est encore un peu plus ésotérique.

Emmanuel : Le dernier papier que j’ai lu et que j’ai trouvé intéressant vient aussi de chez Microsoft, par l’équipe de Bing, sur BitFunnel : une nouvelle manière d’indexer pour régler les problèmes de très très forte cardinalité. Ils se sont rendus compte que des gens mettaient sur Internet les 15 milliards premiers nombres premiers par exemple et qu’il fallait les indexer. Ça pose des challenges sur les techniques d’indexation full-text et d’aborder ces problématiques là, que je trouve séduisant.

Ca c’est dans un volet théorique et qu’en est-il des technos plus concrètes ?

Alexis : La partie container c’est la prochaine étape et donc kubernetes, sans grande surprise. Ca soulève plein de problèmes nouveaux et intéressants : comment fait-on le networking, la sécurité ? C’est de la plomberie mais de la plomberie importante et on ne la refait pas tous les jours.

Emmanuel : Je parlerais du paradigme du side-car et l’utilisation d’Envoy que je trouve sympa pour faire de l’adressage de service. Un autre truc que j’aimerais essayer c’est  distributedlog de Twitter. Ils essaient de répondre aux problématiques de répartition et de réplication de la donnée. Cela pourrait régler certains problèmes opérationnels qu’on a avec kafka.

Le truc dont vous êtes le plus fier ?

Alexis : On fait pas mal de salons et je suis toujours à la fois surpris et fier d’entendre des clients dire que ce qu’on fait leur rend vraiment service tous les jours. C’est ce qu’on recherche quand on fait une boite SaaS par opposition à la vente de licence où on se revoit 1 an plus tard…

Comment vous imaginez-vous dans 5 ans, dans 10 ans ?

Alexis : Avec plus de cheveux blancs, ça c’est sûr ! La chose dont je suis sûr c’est que les choses que je vais apprendre dans les 5 ans qui viennent sera sans commune mesure avec ce que j’ai appris dans les 7 années qui viennent de passer et si tu m’avais posé la question il y a 5 ans je ne me serais pas imaginé où j’en suis arrivé, notamment en terme de vécu.

Emmanuel : C’est pas comme si j’avais un master plan : je prends les choses comme elles viennent…

Une bonne résolution ?

Emmanuel : Si ma femme lit l’article, il vaut mieux que je dise que je vais rentrer plus tôt le soir et aller moins à New-York (rires) !

De quelle startup souhaiterais-tu soulever le capot pour en connaître l’architecture ?

Emmanuel : Une startup dans la sécurité !

Microsoft respecte votre vie privée. Veuillez consulter notre Déclaration de confidentialité.

Les commentaires sont fermés pour cet article