Founder's Guide to Scaling Applications: When to Build, When to Buy and What Breaks

Je suis Julien, cofondateur et CTO d'Algolia. Nous développons un API de recherche pour aider n'importe quel développeur à avoir une très bonne recherche dans leur application. Mais aujourd'hui, je ne parlerai pas de recherche du tout. Je vais discuter de la décision de construire contre acheter et je vais essayer de couvrir quelques erreurs que nous avons faites sur ces décisions. Je pense que je n'ai jamais rencontré une compagnie qui n'a pas fait quelques erreurs à propos de construire contre acheter et la plupart du temps, c'est lié aux coûts à long terme, à l'estimation à long terme de ce que ça signifie pour construire ou acheter une solution. Je vais d'abord vous donner quelques chiffres sur où nous sommes et quand je vous donnerai quelques exemples, je vais essayer d'expliquer où nous étions à cette étape quand nous avons pris la décision parce que l'étape est bien sûr importante dans ces décisions Aujourd'hui, nous sommes une équipe distribuée. Nous avons fondé la compagnie en 2012 à Paris. Nous avons ensuite converti la compagnie aux Etats-Unis. Aujourd'hui, nous sommes environ 350 personnes dans 6 différents bureaux. Nous avons principalement une infrastructure en biométal avec près de 3000 serveurs. distribuée dans plus de 70 centres de données, et nous possédons entre 200 et 300 milliards d'applications par mois. Tout cela n'a pas été construit en un jour, cela nous a pris quelques années, et je vais donner le contexte pour tous les exemples. Bien sûr, derrière ce produit, nous avons une équipe super forte. Aucune d'entre elles ne serait possible sans une très forte équipe d'ingénieurs et de produits. L'un des concepts les plus confus pour moi, c'est que plus votre équipe est meilleure, plus difficile c'est d'adopter une bonne construction contre une mauvaise solution. Je suis sûr que ce sera très incompréhensible. Probablement, vous ne le verrez pas d'abord. nous voyons tous les effets positifs d'avoir un excellent équipe d'ingénieurs. Bien sûr, de bons ingénieurs peuvent construire un produit beaucoup plus vite que d'autres. Bien sûr, cela contribue à avoir un grand impact, un impact clé pour votre entreprise. Mais nous n'en parlons pas assez sur les aspects négatifs d'une très forte équipe d'ingénieurs. Je pense que ce n'est pas quelque chose que nous discutons assez. Tout d'abord, je pense qu'un bon ingénieur peut facilement vous donner 10 bonnes raisons de construire au lieu d'acheter. C'est super facile. Vous ne trouverez jamais suffisamment d'arguments pour acheter. Vous pouvez toujours avoir un problème très spécifique. Vous pouvez toujours trouver des arguments que vous avez besoin d'une solution customisée. Vous devez le construire, à peu près. Et ce que j'ai vu, c'est que la plupart du temps Vous pouvez discuter, vous pouvez lutter, ils vont venir avec un prototype en deux heures, ou le jour après, et ils vont tenter de vous montrer que c'est facile à construire. Et ils vont toujours sous-estimer les coûts à long terme, l'impact à long terme de construction contre achat. Je vais donc essayer de discuter avec quelques exemples concrets et quelques erreurs concretes. Certaines étaient positives, avec de bons effets, et certaines ont été négatives pour nous, et nous devons les changer. Je vais donc les couvrir pour vous donner un peu d'inspiration sur quand nous avons construit et quand nous avons décidé d'acheter. La première grande décision que nous avons prise, c'était au début de l'entreprise, nous étions seulement deux, nous n'avions même pas de fonds, nous n'avions pas de salariés, donc au début de l'entreprise, nous avons décidé d'utiliser l'infrastructure en métaux et non de l'infrastructure cloud, VMs. qui était complètement fou à ce moment et beaucoup de gens nous ont mal compris quand nous avons pris cette décision. C'était bien sûr risqué et c'était un gros bet. La raison pour laquelle nous avons pris cette décision est à cause de notre bet sur le marché. Nous travaillions dans ce domaine pendant plus de dix ans avant de créer l'entreprise. Nous étions convaincus que les gens voulaient avoir une bonne performance. Les gens investissaient beaucoup de temps pour avoir une bonne performance, mais ils n'arrivaient pas à des résultats suffisants. Notre initiale était que la performance pouvait faire une grande différence. Nous voulions avoir un facteur 10 sur la performance, ce qui signifie qu'il fallait être fou de la performance sur tous les aspects différents. Bien sûr, nous devons construire un logiciel qui est vraiment différent en termes de performance, mais l'hardware, même le réseau, joue un rôle important dans la performance. Les search engines sont très intensifs en termes de CPU, SSD, mémoire, donc nous avons dû choisir une machine très spécifique, un hardware très spécifique, afin d'assurer la meilleure performance du marché. Aucun d'entre eux n'était disponible sur l'infrastructure cloud à ce moment-là. C'est pour cela que nous avons pris cette décision fou d'utiliser BareMetal. Et nous devons construire tout de suite. Nous distribuons les données grâce au facteur 3, afin d'assurer une haute disponibilité. Vous pouvez le faire sur CloudProvider avec AvailabilityZone. Vous avez beaucoup de fonctionnalités hors de la boîte pour le faire. Nous devons construire tout de suite dans le software pour avoir une haute disponibilité. Et bien sûr, au début, nous n'avons pas eu le temps de faire ça. La première version du software n'avait aucune disponibilité. C'était un serveur qui fonctionnait sur un seul provideur. C'était, d'une part, un peu risqué, parce qu'une grande erreur de hardware pourrait nous causer beaucoup de problèmes. Mais c'était le moyen le plus simple d'obtenir les réponses que nous avions besoin. Comme nous avons ce grand bet, nous avions besoin d'obtenir des réponses du marché sur ce bet. Est-ce réaliste ? Est-ce que la performance a un impact aussi grand que ce que nous avions prévu ? Ou est-ce difficile de vendre un logiciel basé uniquement sur une grande différence en performance ? Donc, pour imaginer le produit en ce moment, le set de features du produit était super limité. Nous n'avons pas obtenu même 1% des features que nous avons aujourd'hui, mais nous avons eu une grande différence en termes de performance par rapport à tout autre sur le marché. Et la réaction que nous avons reçue était super positive. Pratiquement, elle a confirmé notre bet initial. Cette décision était super risquée. C'était à un moment où ça pourrait avoir fait mal à l'entreprise, comme une grande erreur, une grande erreur hardware pourrait avoir fait mal à nous en termes de confiance. Mais nous étions dans les premiers jours et ça a été positif, nous avons validé notre assumption. Une chose est certaine, même si nous avons décidé d'utiliser l'infrastructure en béton, même si nous avons décidé de faire tout nous-mêmes, nous avons essayé de réduire nos investissements autant que possible. Bien sûr, nous utilisons le leasing et non la co-location, nous n'avons pas acheté le matériel, assemblé la machine, etc. Nous avons pris des fournisseurs pour faire ça pour nous. Comme nous utilisons LeaseWeb, OVH, ces fournisseurs qui nous aident à faire cela. Long story short, aujourd'hui nous avons de l'infrastructure sur le cloud et ça nous a pris du temps pour avoir de la bonne infrastructure, de la bonne hardware, dans le cloud, pour gérer notre API. Aujourd'hui, il y a beaucoup plus de variété d'hardware sur les fournisseurs de cloud que ce qui était le cas en 2012. Donc c'était une bonne décision. C'est le seul exemple positif que je vais partager avec vous. Mais parfois, un buid contre un buy peut être positif. Ce n'est pas seulement à propos de toujours choisir l'un. C'est quelque chose qui peut être votre grande différenciation. Cela peut être votre facteur 10, comme sur performance pour nous. Mais ça peut aussi être une décision négative. Et je vais essayer de couvrir plus de exemples négatifs. Donc j'ai trois plus concrets exemples d'erreurs que nous avons faites. Deuxième décision, très importante décision. Au début de 2014, nous étions en train de lancer ce que nous appelons notre réseau de recherche distribuée. Ceci est l'abilité de distribuer la recherche dans différentes locations GEO sans avoir à payer les clients. Nous avons un API, ils poussent les données, nous distribuons la recherche au monde entier, et puis nous redirigons l'utilisateur au centre de données le plus proche. Chaque client peut décider dans quelle location ils veulent avoir pour contrôler leurs coûts. Nous avons 15, 16 régions mondiales, mais vous ne pouvez pas vouloir utiliser toutes, alors vous pouvez contrôler vos coûts. La distribution géologique est faite par le DNS. Et nous utilisions une solution d'Amazon, AWS, Route 53, qui est leur DNS managé, pour faire ça. Nous avions un grand problème d'abord, le nombre de régions qu'ils soutenaient n'étaient pas les mêmes que nous. Comme nous avions, au moment du lancement, 12 régions, Amazon ne couvrait que 7 d'entre elles. Donc nous n'avions pas pu faire le géorouting pour tous nos clients, toutes nos régions. Deuxième problème, qui était un problème de performance. Quand nous créions une région, comme une entrée spécifique pour un client, cela a pris quelques minutes. C'est-à-dire que dans le flux d'embarquement de nos utilisateurs, cela a pris quelques minutes pour set-up l'account, ce qui a causé une énorme diminution dans le processus. Nous avons donc décidé de chercher toutes les solutions du marché. L'équipe d'ingénieurs était super, super petite à ce moment-là. Nous étions en total quatre ingénieurs qui travaillaient sur le produit, y compris moi, y compris notre VP d'ingénieur, donc quatre en total, donc une équipe très, très petite. La première réaction a été de chercher des produits existants. Au début, il y avait une page Wikipédia listant tous les DNS managés disponibles sur le marché. Nous les avons pris un par un, nous avons contacté tous, nous avons regardé leur offre. Aucun d'entre eux n'a été capable d'adresser notre cas d'utilisation. C'était donc un grand désappointement. Je pense qu'il y avait une liste de 20 différents provideurs. Aucun d'entre eux n'avait une solution qui pouvait suivre notre cas d'utilisation. Ce que nous avons fait, c'était de sélectionner les plus avancés et d'ajouter une discussion de produits avec eux. Peut-être qu'ils n'ont pas la solution sur le marché aujourd'hui, mais peut-être qu'ils l'ont dans leur propre map. Aucun d'entre eux n'a pu nous donner leur propre map ou un ETR de quand ils seront capables d'adresser notre cas d'utilisation. Nous étions donc coincés. Comme je l'ai mentionné, une bonne équipe d'ingénieurs aime les défis. Aucun temps, les ingénieurs ne construisent pas un petit prototype basé sur l'open source et nous avons négocié avec un fournisseur de réseaux pour construire comme un réseau Anycast avec nos 12 régions pour redirecter le trafic à notre constructeur custom, DNS, basé sur l'open source software. Le prototype a été construit en deux jours, un prototype en travail, bien sûr, pas à l'échelle. Mais ensuite, transformer un petit prototype dans un produit, dans la production, pas avec dix API calls, mais avec des millions d'API calls par mois, c'est une autre histoire. Quand nous avons fait ces études et quand nous avons signé le contrat avec le fournisseur Anycast nous avons pris du temps. La raison est que ce fournisseur voulait au minimum trois ans d'engagement sur la solution. Ce qui est énorme pour une petite entreprise comme nous. C'était un grand budget. Et le budget était si grand que nous avons décidé de prendre du temps pour analyser la situation. Par chance, nous avons rencontré quelqu'un à San Francisco qui a lancé une startup sur DNS. Donc, c'était une rencontre complètement random à San Francisco, rencontrant une petite startup, construisant une solution DNS managée. L'occasion d'avoir quelque chose qui correspondait à notre cas d'utilisation était super low. Mais encore, cette petite startup construisait quelque chose dans un domaine où nous avons fait beaucoup d'analyses, donc nous avons eu une discussion super intéressante. et ils nous ont proposé de transformer leur roadmap et d'adresser notre cas d'utilisation en un mois. L'entreprise était très jeune, ils avaient juste fondé il y a quelques mois auparavant cette discussion, c'est-à-dire à un stade super rapide, et bien sûr, c'était risqué pour nous, parce que nous étions un peu plus avancés, c'était clé pour nos produits, donc relier à une très petite entreprise est un peu risqué, mais nous avons décidé de prendre le risque. La grande raison pour laquelle nous avons pris ce risque, c'est parce que l'équipe derrière cette startup a travaillé sur DNS pendant 20 ans. Donc, ils savaient beaucoup sur le domaine, et en fait, ils nous ont fait réaliser que notre solution custom-réalisée manquait d'un peu de choses qui pouvaient nous faire mal. Comme, nous n'avons pas anticipé comme DDoS sur le DNS, ce qui est un grand problème et qui s'est passé beaucoup de temps. Donc, ça pouvait nous faire mal. Nous avons beaucoup de choses que nous n'avions pas anticipées. Nous avons donc décidé d'utiliser ces solutions à la dernière minute, peut-être quelques jours avant de signer un contrat de trois ans avec le fournisseur et de lancer notre propre solution. Et cette histoire ne s'arrête pas au moment où nous avons décidé d'utiliser une startup. Parce que, comme je l'ai mentionné, quand vos ingénieurs se sont inquiétés d'un problème, un problème spécifique, et qu'il n'y a pas de solution dans le marché, ils ont essayé de penser à la différenciation. Comme, oh, nous pouvons faire cette spécifique fonction, ce serait dix fois mieux qu'un autre produit. Ou nous pouvons développer celui-ci, qui est aussi une grande différenciation. Donc, nous avons eu une sorte de longue planète de grandes différenciations sur le DNS, comparé aux produits existants, while we were not experts on DNS, which seems a bit wrong. But I think a good engineering team will always find this and they will come to you and give you a big list of things you could do way better than anyone else, even if they have no strong expertise on this market. My understanding is that Il y a toujours ce fameux mot, nous overestimons toujours ce que nous pouvons faire en un an, et nous sous-estimons ce que nous pouvons faire en 10 ans. Je pense que le gros erreur ici, c'est que l'équipe a complètement overestimé ce qu'elle pouvait faire dans un temps d'année. Mais cette solution SAS nous a donné beaucoup d'apprentissage. Toutes les idées folles que nous avions, en fait, elles les ont développées. Nous avons donc contracté avec eux et ils nous ont donné beaucoup d'avantages de l'apprentissage. La plupart de leurs grandes idées, en fait, ne fonctionnaient pas dans notre cas d'utilisation. Nous aurions mis un énorme effort dans R&D pour les essayer et elles ne fonctionnaient pas. Avec ce produit de SAS, ils ont fait tous les investissements, nous l'avons testé et dans notre cas d'utilisation, ça ne fonctionnait pas. Donc l'investissement n'était pas fou comparé aux résultats. mais nous avons fait le mistake et je pense que l'un des apprentissages clés c'est que trouver le fournisseur est super complexe ce n'est pas seulement aller sur Wikipédia et lister les fournisseurs il s'agit de chercher la startup et peut-être que la startup n'existe pas et la startup existera dans un an donc c'est aussi à propos de penser à propos de la complexité pour changer de solution comme ce commitment de trois ans serait fou Et si aujourd'hui j'étais en position de prendre la décision, je n'irais pas avec un contrat de 3 ans. J'essayerais de trouver des travailleurs autour, peut-être en réduisant le nombre de régions, peut-être 12 était trop, trouver quelque chose où je n'ai pas de 3 ans à garder. 3 ans est trop pour garder dans une situation qui peut potentiellement nous coûter beaucoup d'argent juste pour le maintenir. Nous étions en train de faire de gros erreurs, et par beaucoup de chances, à la dernière minute, nous avons découvert cette entreprise et décidé de prendre le risque. Peut-être que la histoire aurait été très différente si nous avions développé ce DNS, et je pense que ce serait le cas, parce qu'il aurait fallu tout le R&D pour développer quelque chose où nous n'étions pas experts. Une autre décision très similaire, C'était bien plus tard. Nous étions 35 ingénieurs. Nous nous concentrions sur la performance. Bien sûr, le monitoring de notre API, le monitoring de la performance, était clé depuis le début. Et nous utilisions un produit SAS pour monitorer notre infrastructure. Mais nous avons atteint quelques limites dans la solution que nous utilisions. Et ces limites, c'était principalement parce que les solutions que nous utilisions étaient conçues pour monitorer une machine spécifique, alors que notre service est distribué à travers une série de machines, et nous avons besoin de voir un graphique distribué sur quelques machines. Donc, nous avons donc encore discuté avec plusieurs proviseurs, et nous avons eu des discussions sur le roadmap, des discussions sur ce qui pourrait être une bonne implementation pour notre cas d'utilisation. Nous avons discuté pendant un an avec le fournisseur que nous utilisions et il n'y avait toujours pas de délivery sur ce qui pourrait faire un impact pour nous. Pendant que nous discutions avec les fournisseurs, l'équipe d'ingénieurs, un jour, a décidé de construire un prototype. Donc, ils ont construit un prototype interne, basé sur l'open source, en utilisant Collecty, Grafana, Graphite. Et dans un jour, ils ont réussi à avoir quelque chose de mieux que notre solution SAS. Et je pense que, ici, peut-être que l'erreur est de penser que, parce qu'un jour, vous avez quelque chose de mieux que ce que vous avez, c'est super facile d'avoir votre propre solution qui ne coûte pas beaucoup d'argent parce qu'il a été construit en un jour et que vous pouvez l'adapter à vos besoins. Je pense qu'il y a quelques retours dans cette conclusion. Le premier, c'est que c'est un prototype en un jour. C'était déployé sur une seule machine, alors qu'on avait à ce moment-là 200 ou 300 machines. Donc, prendre cette solution et faire son échelle à 300 machines n'est pas une question d'heures. Donc, le premier gros défaut est la limitation. Puis, même si c'était mieux, quand nous regardions ce que nous manquions dans cette solution, la liste était énorme. Nous avions des dizaines, si ce n'était pas des centaines, de fonctionnalités manquantes pour nos besoins. Cela signifie que notre équipe devrait développer toutes ces fonctionnalités pour notre performance. et cela signifie que mon plan d'aventure serait de mettre un peu d'emphasis sur ces métriques qui ne sont pas un changement de jeu pour l'entreprise ce n'est pas quelque chose qui est exposé aux clients c'est quelque chose pour nous pour tracer la performance de notre service et je pense que c'est encore un retour à l'esprit comme penser à court terme, construire quelque chose dans un jour, ce qui est génial, c'est un bon effort d'ingénieur mais ensuite, à long terme, mettre notre investissement dans quelque chose ce qui n'est pas un changement de jeu pour notre entreprise. Je préfère payer pour un service externe plutôt que de prendre mes meilleurs ingénieurs et de les faire travailler sur ce sujet. Et j'ai fait une erreur à ce moment-là, à cause de la histoire précédente sur DNS. J'ai essayé de les convaincre d'utiliser une solution externe. J'ai essayé de discuter avec eux, d'arguer que le coût long terme serait super, super cher et qu'il fallait choisir quelque chose de plus efficace. Je n'ai jamais réussi à les convaincre. C'est presque un argument contre l'autre. Et si vous parlez d'une chose spécifique, ils vont venir avec un autre prototype. C'est une discussion sans fin. Et vous n'allez jamais réussir à les convaincre. Encore une fois, les bons ingénieurs, ils ont 10 différentes façons de vous expliquer que la meilleure solution est de construire et pas acheter. Je pense qu'au moins une chose qui est bonne avec les ingénieurs intelligents, c'est qu'ils apprennent rapidement. et ils ont toujours appris de cette expérience précédente avec DNS. Je n'ai jamais réussi à les convaincre, mais un jour, le chef d'ingénieur a découvert une entreprise, et nous avions exactement le même modèle. Ils ont découvert une entreprise, ont construit une super bonne solution de monitoring, ils ont construit un petit prototype, ils ont convaincu l'équipe, et nous avons utilisé la solution SAS. Mais nous avons cette longue étape intermédiaire avec Open Source développée, et nous avons mis de l'effort sur Open Source. avec des retours, même ce six mois d'investissement en open source a été une perte de temps. Pendant ce moment, nous n'avons jamais mis l'open source en production, nous n'avons jamais eu un impact de business, parce que c'était juste une enquête. En utilisant nos précédents fournisseurs, en essayant de les pousser un peu dans notre direction, même s'ils n'étaient pas capables d'exécuter notre vision de monitoring, aurait été bien mieux que de passer notre temps à construire des prototypes. Donc, encore une fois, une petite équipe, même si c'était 30 personnes, c'est bien plus grand que 4. Mais si vous avez 3-4 personnes dans cette équipe qui se concentrent sur leur temps et sur la construction d'une solution à l'open source, et puis vous vous disputez, et ils passent plus de temps, et c'est inutile. En fait, vous perdez votre R&D sur quelque chose qui n'est pas changeant. Donc ce que j'ai appris dans cette histoire, c'est de ne jamais essayer de les convaincre, Mais défendez-les. Défendez-les sur le coût de développer leur prototype. Défendez-les sur le fait qu'on ne peut pas utiliser notre solution de monitoring existante pendant 6 mois, 2 ans, pendant que nous trouvons une bonne solution sur le marché. Défendez-les sur chaque décision, mais n'essayez pas de les convaincre. Je pense que ça ne va jamais fonctionner. Mon feed-back est que vous ne les convaincerez jamais, mais vous pouvez les challenger et ils verront le problème différemment. Empower-les, mais ne les donnez pas une ordre. Donc pour celui-ci, encore une fois, nous avons pris la décision de construire internement, ce qui était une mauvaise décision. Pendant six mois, nous avons construit ces prototypes, nous avons fait des itérations, j'ai essayé de les convaincre. La décision n'était pas une bonne, et la bonne solution vient six mois plus tard du développeur d'origine, parce qu'ils ont trouvé une bonne entreprise en construisant de bons produits. Et j'ai une autre chose qui est drôle dans cette histoire, L'équipe d'ingénieurs a reconnu qu'ils n'auraient jamais pu développer la solution qu'ils ont découvert. Et je pense que l'apprentissage avec SAS, votre équipe interne ne sera jamais capable de compter avec un produit de SAS. Jamais. C'est inutile. Si la solution est réussie, l'équipe va grandir, et peut-être aujourd'hui ils auront deux ingénieurs, mais dans deux ans ils auront 50, et vous resterez avec un effort limité et seulement deux sous-ingénieurs travaillant dessus. Cette solution était si bonne qu'ils étaient convaincus dans une semaine qu'ils n'arriveraient jamais à construire la même chose. Mais encore une fois, ils ont pris la décision de construire internement. L'exemple dernier que je voulais couvrir est un peu plus complexe. C'est une décision que nous faisons plusieurs fois. Celui-ci concerne notre solution d'analyse. Sur chaque appel d'API de recherche de nos utilisateurs, nous monitorisons tous les appels d'API et leur donnons des statistiques. Nous avons fait cette analyse plusieurs fois. Lorsque nous avons créé le produit, nous avons fait un premier version de l'analyse, 200 lignes de code Ruby, une heure de développement, super bons investissements. Et cette analyse est aussi business-critique, parce que nous l'utilisons pour le billage. Nous comptons le nombre d'appels d'API, et c'est ce que nous utilisons pour le billage. Mais au début de l'entreprise, nous savions que la solution n'était pas scalable, 200 lignes de code, mais c'était parfait. Ce n'était même pas valable de regarder la solution existante du marché, en une heure, elle a été résolvée. Mais nous savions que ce n'était pas quelque chose qui pouvait s'élargir. Quelques mois plus tard, avec la croissance, pas même un an plus tard, nous avons dû redoubler cette partie, qui était expérimentée. Nous savions qu'elle n'était pas capable d'élargir. Et nous avons donné à l'ingénieur, à un ingénieur, l'autonomie pour regarder le problème, mais pas au marché. Ce que nous lui avons donné était une mission de remplacer ces composants qui n'étaient pas en élargissement. Alors ce qu'il a fait, c'est qu'il a pris une meilleure Programming Language. Au lieu de Ruby, il a pris Java, ce qui est meilleur en termes de performance. Au lieu de 200 lignes de code dans un spread, il multiplie le nombre de spreads, ce qui nous donne de l'autonomie. Ce développement était bon dans le sens qu'il était capable d'envoyer 100 fois le chargement de l'application précédente, ce qui nous a donné 2 ans. Pendant 2 ans, nous avons pu utiliser ce software. Mais encore une fois, le software n'était pas scalable. Nous regardons la solution sur le marché, Et encore une fois, une solution similaire. Rien n'était parfaitement bon pour notre problème, et surtout, notre échelle était si grande, nous étions déjà en train de procéder à des millions d'applications, mais le prix était trop élevé pour nous. Nous aurions perdu de l'argent en utilisant un fournisseur d'analyses. Nous avons fait une erreur en ce moment, qui est de dire, ok, ce n'est pas possible pour le prix, voyons une autre solution. Nous avons utilisé à la fin une solution hybride, qui est un mélange d'APIs et de codes custom. Et nous avons utilisé la plateforme GCP pour cela, avec PubSub, Dataflow, et beaucoup de produits différents. Mais cela nous a pris près d'un an pour le développer. Nous avons atteint beaucoup de problèmes, beaucoup de bugs, comme ces API n'ont jamais été utilisées à cette taille, donc nous avons eu beaucoup de problèmes qui n'étaient pas prévus. Mais à ce moment-là, nous avons déjà atteint les limites du programme précédent. L'un de nos meilleurs ingénieurs, pendant près d'un an, a dû faire de son mieux pour maintenir la solution qui s'éloignait plusieurs fois par jour, en passant beaucoup de temps simplement à maintenir une solution, ce qui n'est pas bien. Au final, avec quelques retours, nous devions avoir payé pour une solution très coûteuse d'un an. Nous aurions certainement perdu de l'argent. mais j'aurais gagné le temps d'un de mes meilleurs ingénieurs qui pourrait avoir travaillé sur quelque chose de plus critique que maintenir une solution qui était supposée mourir. Donc c'est un autre erreur, en regardant les coûts peut-être trop tôt et en dépensant un certain nombre d'argent pour une période limitée de temps, ça nous achèterait un certain temps et le temps d'un de nos meilleurs ingénieurs. C'est une grande chose. Nous n'avons jamais trop d'ingénieurs. Je n'ai jamais rencontré quelqu'un qui avait trop d'ingénieurs. Donc à la fin, ces décisions sont critiques pour le business. Ces décisions inventent la roue. C'est une phrase assez commune qu'on entend en ingénierie. Nous faisons toujours des erreurs. Mon feed-back est que c'est super difficile de ne pas faire de erreurs. Nous tous faisons des erreurs et je pense qu'il faut s'en occuper. Et l'une des meilleures façons de s'en occuper, c'est d'accepter qu'on peut remplacer des composants facilement au cours du temps et ne pas penser à construire quelque chose pour le long terme. Le coût de maintenir une solution peut être super, super élevé. Alors, comment ne pas essayer de réinventer la roue ? Je pense que l'une des choses que je suis le plus fier de, c'est probablement que nos ingénieurs ont appris beaucoup. Ces ingénieurs ont appris beaucoup plus vite que moi personnellement dans ma carrière. Parce qu'ils ont vu tous ces erreurs très rapidement, dans un environnement très rapide. Et je suis super fier de ce qu'ils ont fait. Ils sont devenus meilleurs dirigeants, dirigeants d'ingénierie. Donc avoir de très fortes expériences dans votre équipe, des gens qui ont beaucoup d'expériences, qui ont fait des erreurs plusieurs fois, je pense que c'est l'une des meilleures façons d'éviter cela. Ensuite, bien sûr, penser à garder une solution pour la courte durée. J'ai une histoire très drôle à propos de ça. J'ai travaillé dans un grand groupe qui, dans les années 80, a développé un software spécifique pour versionner leur code de source. Ce software était génial. Aujourd'hui, ils l'utilisent toujours. Ce software est 10 fois dix fois pire que n'importe quelle solution du marché. Et ils ont une équipe totale pour le maintenir. Donc, 30 ans plus tard, ils maintiennent leur choix interne et ils ne peuvent pas migrer. Donc, plus tôt vous pouvez bouger de quelque chose que vous construisez à travers une solution extérieure, plus tôt vous pouvez garder votre focus. Et la vitesse d'itération, le focus, je pense, est un élément critique dans n'importe quelle équipe d'ingénieurs. La vitesse d'itération est ce qui fait la différence. et je pense que l'un des seuls bons raisons pour construire à long terme, c'est que vous avez un facteur 10. Facteur 10 sur votre produit, facteur 10 sur n'importe quoi, c'est un bon raison pour construire. Donc c'est tout. Je pense qu'on a une minute pour des questions. Donc, première question, quelles entreprises ne devraient pas construire leur propre infrastructure ? Je pense que pour la plupart des entreprises, c'est une exception de construire votre propre infrastructure. Je pense que 99% des entreprises ne devraient pas construire leur propre infrastructure. Je pense qu'il faut avoir un grand but et qu'il faut qu'il y ait une énorme différence dans votre produit, dans votre entreprise, dans votre business, pour avoir une bonne raison de le construire. Sinon, je ne pense pas. Je pense que si nous avions découvert que le facteur, la performance n'était pas une grande différenciation, nous aurions changé de cloud. Donc je pense que la plupart des entreprises ne devraient pas construire leur infrastructure. Une autre question, comment naviguez-vous la décision MEC contre BAI avec plusieurs grandes vendeurs de données qui ont plus d'offres que jamais? La complexité de l'offre est définitivement un problème Je pense que lorsque vous évaluez toutes les solutions Je n'ai jamais voulu que mon équipe pense en termes de fonctionnalités. Je pense que vous avez le produit avec le set de fonctionnalités comme c'est aujourd'hui, mais si vous l'utilisez et que vous achetez une solution, vous devez projeter votre décision à long terme. Donc, en regardant la planification, en discutant la planification avec le fournisseur quand c'est stratégique, en regardant ce que le produit sera en un an, en deux ans, en discutant leur vision du marché, et si cela peut vous aider, je pense que c'est un très bon moyen de faire la grande différence et de partir de la comparaison des features ou de la complexité de la solution. Et une autre chose, c'est de regarder les coûts d'intégration. Si ça vous prend deux ans pour vous migrer à une solution, alors c'est un problème. Une autre question, que pensez-vous que sont les principaux bénéfices d'InnosBuild sur la solution Vendor ? Je pense qu'il n'y en a qu'un pour moi, qui est le facteur 10. Si vous avez ce facteur 10 sur une zone spécifique qui est importante pour votre entreprise, ça peut être l'UX, la performance, la référence, ça peut être tout. Si vous avez ce facteur 10, et c'est quelque chose que vous pouvez mesurer, Si c'est votre forte différence sur le marché, alors c'est bien de l'acquérir. Si ce n'est pas votre facteur 10, et si c'est plus une fonction de votre produit, alors je pense que ça n'a pas de sens. Si c'est votre seul produit, votre seule différenciation, je vous recommande de construire. Si ce n'est pas le cas, alors achetez-le. Et trouvez un bon fournisseur. Merci.