Jeremy Burton, PDG d’Observe – Série d’entretiens

Jeremy Burton, PDG d’Observe, est un dirigeant chevronné du logiciel d’entreprise avec plus de 20 ans d’expérience dans des entreprises technologiques majeures, notamment Dell Technologies (DELL ), EMC, Oracle (ORCL ) et VERITAS. Il a dirigé des équipes mondiales dans le développement de produits, le marketing et les fusions et acquisitions stratégiques, en créant et en développant des entreprises dans le stockage, la sécurité et le SaaS. Burton a également co-fondé le Oracle Technology Network, qui est passé à des millions de membres dans le monde, et siège actuellement au conseil d’administration de Snowflake et en tant que conseiller de l’équipe de Formule 1 de McLaren.

Observe, basé à San Mateo, en Californie, est une plate-forme d’observabilité SaaS de nouvelle génération qui aide les équipes SRE, DevOps et d’ingénierie à enquêter et à optimiser les systèmes distribués modernes. Conçu sur l’infrastructure de données de Snowflake, il unifie les journaux, les métriques et les traces dans un seul ensemble de données enrichi de contexte, permettant aux équipes d’accélérer la réponse aux incidents, d’identifier les causes profondes et d’améliorer la fiabilité dans des environnements cloud complexes.

Vous avez occupé des postes de direction chez des géants mondiaux comme Dell, EMC et Oracle, et maintenant vous dirigez une startup avec Observe. Qu’est-ce qui vous a motivé à quitter la stabilité et la taille pour prendre le risque de construire quelque chose à partir de zéro ?

J’ai eu la chance de travailler pour des dirigeants incroyables, notamment Larry Ellison et Michael Dell. J’ai travaillé avec eux 20 ou 30 ans après leur arrivée, mais ce qui les rend remarquables, c’est qu’ils étaient là depuis le début. Ils ont pris les premières décisions de produit, établi les voies de marché et créé une culture pour le succès à long terme. Mon rôle était de fournir des améliorations incrémentales sur les décennies de travail acharné qu’ils avaient déjà effectué. Finalement, j’en suis arrivé à un point de ma carrière où je voulais prouver à moi-même que je pouvais également construire une entreprise, prendre un produit à la mise sur le marché, établir un mouvement de vente et créer une culture qui pourrait prospérer à long terme.

Observe se positionne comme une nouvelle catégorie dans l’observabilité, en intégrant les journaux, l’analyse et la surveillance dans une plate-forme unifiée. Comment voyez-vous cette approche redéfinir l’espace par rapport aux acteurs établis comme Splunk et Datadog (DDOG ) ?

Le grand problème auquel sont confrontés les outils hérités est qu’ils n’ont pas été conçus pour l’échelle. Dans les conversations avec les clients, nous avons vu à plusieurs reprises que Splunk et Datadog deviennent prohibitifs en termes de coûts à mesure que le volume de télémétrie augmente, et que c’est fondamentalement un problème lié à la manière dont les outils hérités ont été conçus.

Observe se différencie en ce que notre plate-forme est construite sur une architecture de lac de données à flux utilisant des formats ouverts comme Apache Iceberg. Cela signifie que nous pouvons découpler le calcul de la mémoire, mettre à l’échelle de manière élastique et fournir une observabilité à une fraction du coût des systèmes traditionnels. Les concurrents comme Splunk s’appuient toujours sur des architectures monolithiques qui nécessitent une planification de la capacité de pointe – et même les outils plus récents comme Datadog nécessitent un tiering de données, une réhydratation et une réindexation pour maintenir les coûts sous contrôle.

Nous nous concentrons également sur une expérience d’observabilité unifiée. Les journaux, les métriques, les traces et les événements vivent tous dans un même endroit, avec un langage de requête unique et un graphique de connaissances qui mappe automatiquement les relations entre les services, les utilisateurs et les incidents. Ce contexte est ce qui rend la résolution des problèmes plus rapide. En revanche, Splunk et Datadog ont des back-ends distincts pour les journaux, les métriques et les traces, ce qui conduit à des analyses plus lentes.

Enfin, nous avons investi massivement dans la dépannage basé sur l’IA. Notre O11y AI SRE peut prendre des entrées de langage naturel, générer des hypothèses et guider les ingénieurs dans la résolution des incidents, et non seulement les alerter. Et il est conçu pour utiliser notre graphique de connaissances, qui fournit le contexte nécessaire pour une résolution précise des problèmes. C’est un pas de plus que la détection d’anomalies ou l’alerte que la plupart des concurrents offrent aujourd’hui.

En résumé : nous sommes rentables, nous sommes unifiés et nous sommes ouverts. Ces trois qualités sont ce que les clients nous disent nous distinguer des acteurs établis comme Splunk et des nouveaux acteurs comme Datadog.

Avoir supervisé des opérations de plusieurs milliards de dollars et maintenant diriger une startup, quels sont les enseignements sur l’efficacité, l’agilité ou l’innovation des grandes entreprises qui sont transposables – et quels sont ceux qui ne le sont pas ?

C’est contre-intuitif, mais les grandes entreprises réussies font un petit nombre de choses très bien, et elles comprennent chaque détail. Celles qui échouent font trop de choses, et tout se dégrade en médiocrité.

Dans une startup, vous vous concentrez sur une chose à la fois et vous vous obsédez sur chaque détail. Il n’y a pas suffisamment de financement pour faire plus que cela. En conséquence, ce qui rend les startups si intenses, c’est que vous pouvez littéralement faire faillite si vous ne résolvez pas les choses suffisamment rapidement. Vous devez donc prendre des décisions plus rapidement, publier plus rapidement, échouer plus rapidement et apprendre plus rapidement. Et vous devez faire tout cela avec moins de personnes.

Néanmoins, l’aspect le plus libérateur d’une startup est que vous n’avez pas de produit établi, de modèle commercial ou de voie de marché établie. Cela signifie que vous avez la liberté de faire de nouvelles hypothèses sur toutes ces choses. Ce n’est pas le cas dans une grande entreprise. Par exemple, vous ne pouvez pas casser le modèle commercial avec un nouveau produit disruptif. Même si techniquement vous pourriez le construire, le directeur financier et Wall Street ne vous laisseront pas maximiser son potentiel. C’est pourquoi les startups gagnent souvent, même si en théorie elles n’auraient pas dû avoir de chance.

Vous avez également été membre du conseil d’administration de Snowflake pendant près d’une décennie. Qu’est-ce que vous avez appris du parcours de Snowflake qui éclaire votre stratégie chez Observe ?

Snowflake a attaqué un problème ancien avec une nouvelle architecture. Ils ont construit leur technologie sur une idée simple mais puissante et ont perturbé un marché massif encombré par des fournisseurs hérités. Il y a quelques leçons ici : jouer dans des marchés massifs, et vous pouvez construire une entreprise massive. De plus, vous devez avoir une approche radicalement différente de celle des acteurs établis pour que le client puisse voir des avantages énormes à passer à votre solution.

Le marché de l’observabilité que nous attaquons est massif, 30 milliards de dollars et en croissance. Nous avons résolu le problème de l’observabilité d’une manière très unique : en utilisant une fondation de lac de données, un calcul élastique et des formats ouverts. Cela promet de donner aux clients une amélioration d’un ordre de grandeur à la fois en termes de rapidité de dépannage et de coût global.

Vous avez été profondément impliqué dans le développement de produits, le marketing et les fusions et acquisitions à grande échelle. Comment cette expérience influence-t-elle la façon dont vous priorisez les stratégies de croissance chez Observe ?

Dans les premiers jours d’une startup, c’est assez simple, vous construisez un excellent produit et vous essayez de le vendre. C’est la stratégie de croissance. Cela dit, ma carrière est très biaisée vers le logiciel d’entreprise et la résolution de problèmes complexes pour les grandes entreprises, il n’est donc pas surprenant que Observe se concentre carrément sur cela !

Sur la base de mon expérience, je pense que pour construire une grande entreprise d’observabilité, vous devez résoudre le problème pour les plus grandes entreprises du monde. Cela signifie gérer des pétaoctets de données, des milliers d’utilisateurs et des milliers d’applications. Il y a de nombreuses entreprises d’observabilité, mais très peu peuvent gagner dans cet environnement, je m’assure donc qu’Observe puisse le faire.

L’observabilité est devenue critique à mesure que les applications distribuées modernes deviennent plus complexes. Quels sont les plus grands défis et opportunités pour les entreprises au cours des 3 à 5 prochaines années ?

Le plus grand défi aujourd’hui est l’échelle. Les charges de travail Kubernetes, les microservices et maintenant les charges de travail d’IA produisent des volumes de données qui submergent les outils traditionnels. La fiabilité de ces outils plonge à mesure que le coût explose, et ce n’est simplement pas soutenable ; une nouvelle architecture est nécessaire.

Pour aggraver les choses, au cours des prochaines années, nous allons voir plus de code écrit, aidé par des outils de codage d’IA, que à tout moment de l’histoire. Ce code ne sera pas parfait, et à un moment donné, il va échouer. Le domaine de la croissance réside dans la question : comment dépanner du code que personne n’a écrit ? Et/ou, tandis que les outils de génération de code peuvent regarder le code et corriger les bogues, peuvent-ils vraiment regarder la façon dont l’application se comporte en production et trouver le code problématique ? C’est une énorme opportunité pour les fournisseurs d’observabilité à l’avenir.

De nombreuses équipes ont du mal avec la prolifération des outils, en utilisant des systèmes distincts pour les journaux, les métriques et les traces. Comment Observe aide-t-il à simplifier cette expérience pour les équipes d’ingénierie et de DevOps dans la pratique ?

Au lieu de jongler avec trois ou quatre outils, Observe donne aux clients une plate-forme unique à utiliser. Les journaux, les métriques, les traces et les alertes d’une entreprise vivent dans le même système et sont liés par un graphique de connaissances. Le graphique de connaissances fournit un contexte qui permet aux utilisateurs de creuser et de pivoter sans heurt sur les journaux, les métriques et les traces pour accélérer la résolution des problèmes. Cela réduit le temps qu’ils ont à passer à passer d’une plate-forme à l’autre, leur permettant de découvrir un problème sans exporter de données ou basculer de contexte.

Pouvez-vous partager un exemple concret de la façon dont Observe a aidé un client à résoudre un problème majeur – quelque chose qui aurait été difficile ou impossible avec les outils d’observabilité traditionnels ?

Capital One utilise Observe pour afficher l’état des parcours client critiques en corrélant et en enrichissant les données de télémétrie avec le contexte commercial pertinent. Ils ingèrent des centaines de téraoctets de télémétrie par jour, y compris des journaux, des métriques, des traces, des dossiers de modification, des journaux de flux VPC et des données de configuration AWS. Observe fournit à Capital One une plate-forme unifiée pour l’observabilité de bout en bout, de sorte que les développeurs et les SRE puissent effectuer une réponse interactive aux incidents et un débogage.

Quel rôle l’apprentissage automatique ou l’IA joue-t-il en arrière-plan chez Observe, et comment aide-t-il les clients à faire surface plus rapidement ou à détecter automatiquement les problèmes ?

L’apprentissage automatique a une histoire mitigée dans l’observabilité, car les environnements d’entreprise sont inhérentement bruyants, et il est très difficile de produire un modèle qui ne résulte pas en milliers d’anomalies. L’IA générative est une technologie très différente et aura un impact beaucoup plus profond.

Nous croyons que l’IA va changer la façon dont les ingénieurs interagissent avec les outils d’observabilité. Tout d’abord, ils pourront parler directement avec leurs données d’observabilité en langage naturel tout en étant assis dans leur IDE, la moitié de nos utilisateurs à l’avenir ne se connecteront peut-être jamais ou n’apprendront jamais Observe ! Deuxièmement, les agents d’IA seront présents pendant les « périodes de paix » pour analyser la télémétrie et rechercher des problèmes potentiels qui pourraient finalement entraîner un incident. Les agents d’IA ne se fatiguent pas ou ne s’ennuient pas et peuvent effectuer un travail que les humains sont simplement incapables de faire. Enfin, pendant les « périodes de guerre », les agents d’IA aideront les ingénieurs et les SRE à déterminer le plan d’action à suivre pour résoudre le problème.

Votre style de leadership inspiré de la Formule 1 met l’accent sur la résilience mentale et l’apprentissage des erreurs. Comment cette perspective a-t-elle façonné votre approche de la construction d’Observe et de la direction de l’équipe à travers les défis et les victoires ?

Le succès en F1 est obtenu en utilisant les données pour guider les décisions futures, à la fois pour le pilote et la voiture. Au moment où une voiture de F1 atteint la fin de la saison, 90 % des pièces ont été remplacées, et elle est 2 secondes plus rapide sur le circuit.

Chez Observe, nous devons avoir la même mentalité pour réussir. Nous publions, nous mesurons, nous écoutons, nous nous adaptions rapidement. Je suppose que 90 % de notre produit est différent aujourd’hui qu’il y a même deux ans. Cette approche exige beaucoup de discipline et beaucoup d’humilité, il n’est pas facile d’entendre de mauvaises nouvelles encore et encore. Pourtant, si vous agissez suffisamment sur de mauvaises nouvelles, elles se transforment progressivement en bonnes nouvelles, et le chiffre d’affaires annuel (ARR) accélère. Ce n’est pas de la magie, c’est de la logique !

Je vous remercie pour cette excellente interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Observe.