PDG de PlanetScale sur Cloud-Prem et gravir les échelons de l'ingénierie

Sam Lambert est PDG de PlanèteÉchelle, un fournisseur de bases de données sans serveur compatible MySQL. Avant de rejoindre PlanetScale (alors en tant que directeur produit), il était vice-président de l'ingénierie chez GitHub.

Dans cette interview, Lambert aborde un certain nombre de sujets liés aux modèles de fourniture de logiciels cloud natifs, notamment à quoi ressemble un bon système sans serveur, qui doit exécuter Kubernetes et l'émergence du « cloud-prem » — un modèle de déploiement qui combine les atouts de sur -offres logicielles et SaaS prem. Il partage également son expérience de PDG non fondateur et ses conseils sur le moment et la manière de passer de l'ingénierie à la gestion.

---

FUTUR : Vous avez décrit ce que fait PlanetScale – du moins son offre non purement SaaS – l'informatique « cloud-prem ». Comment définissez-vous ce terme ?

SAM LAMBERT : Cloud-prem est un nouveau modèle – la solution cloud native pour le sur site, en gros. Traditionnellement, les entreprises devaient soit avoir un sur site solution ou un nuage solution, et chevaucher les deux est traditionnellement très difficile. Chez GitHub, nous avions cette tension liée à la gestion de github.com et à la vente de GitHub Enterprise en tant que solution sur site. Avec le produit cloud, nous devions être en mesure de pousser et de livrer en continu. Supprimer une version basée sur cela était une tâche vraiment difficile, et construire des architectures pour les deux signifiait que nous ne fournissions pas la solution sur site aussi bien que nous aurions pu le faire ; c'était juste très difficile à faire. 

Lorsque nous sommes arrivés à PlanetScale, nous avons décidé que nous voulions être uniquement dans le cloud, mais, bien sûr, vous ne pouvez pas le faire uniquement avec un produit de base de données ou un produit qui a des exigences de conformité strictes. Ainsi, avec cloud-prem, nous déployons essentiellement le plan de données de notre produit dans un VPC géré par l'utilisateur, où il utilise notre plan de contrôle pour l'orchestrer et nous le gérons. Il s'agit essentiellement vous avez l'impression d'utiliser simplement un produit SaaS classique basé sur le cloud, mais les données résident dans votre compte. Votre équipe de sécurité peut l'auditer, et elle ressent la sécurité et la confiance de l'avoir dans les limites de son infrastructure, sans les inconvénients de devoir mettre à jour, publier et gérer elle-même les logiciels sur site.

Il y a un autre avantage supplémentaire : si vous êtes un gros client avec un tarif négocié intéressant avec Amazon, par exemple, vous pouvez toujours payer ce tarif et conserver vos dépenses engagées avec Amazon dans votre compte.

Quel genre de refus obtenez-vous ? Il existe des boutiques SaaS et sur site irréductibles…

Nous pouvons vous proposer un SaaS pur, dans lequel nous hébergeons les données dans notre compte, et les gens sont tout à fait d'accord avec cela. Le vrai problème, c'est si les gens veulent juste du sur site. Mais le modèle cloud-prem commence vraiment à trouver un écho. Certaines entreprises réglementées utilisent le produit parce qu'elles voient le double avantage de conserver les données localement afin de garantir la sécurité ou la conformité, mais aussi de ne pas avoir à les gérer. 

C'est pourquoi ce modèle est si unique et génial et représente un véritable moment dans le temps : parce qu'il résout le problème du fait que les entreprises ne veulent pas faire sur site - et il s'agit d'un modèle ancien et mort, fondamentalement - mais qu'elles répondent toujours principalement aux exigences. ce serait le cas sur site.

Mais oui, on rencontre encore parfois de la résistance. Certaines entreprises ne font tout simplement pas confiance aux logiciels SaaS, mais le cloud est en train de supprimer rapidement cela. Par exemple, vous ne décidez pas quand ni comment Amazon met à jour S3 et améliore S3, cela se produit simplement. Il s'agit d'établir auprès d'un grand nombre de clients la confiance que vous êtes la meilleure entreprise pour gérer un travail particulier à leur place, et de les aider à se sentir plus à l'aise avec cela. 

Vous ne pouvez pas créer la meilleure expérience de développement lorsque vous expédiez des logiciels sur site. Vous ne pouvez pas continuellement vous améliorer. Vous ne pouvez pas gérer la qualité, la disponibilité, le temps de fonctionnement : tout cela fait partie de l'expérience.

Les développeurs peuvent avoir des opinions assez arrêtées sur les bases de données qu'ils utilisent. Comment le modèle de déploiement cloud-prem s'intègre-t-il à l'expérience des développeurs ?

C'est plutôt comme si le modèle de déploiement éliminait les bloqueurs. Vous ne pouvez pas créer la meilleure expérience de développement lorsque vous expédiez des logiciels sur site. Vous ne pouvez pas continuellement vous améliorer. Vous ne pouvez pas gérer la qualité, la disponibilité, le temps de fonctionnement : tout cela fait partie de l'expérience. Si vous ne gérez pas le service vous-même, il est très difficile de créer un niveau d'expérience aussi élevé. 

Bien entendu, un obstacle majeur au SaaS uniquement est la nécessité pour certains utilisateurs de garder les données sous leur contrôle. L’évolutivité pourrait constituer un obstacle majeur au déploiement sur site. Le modèle cloud-prem ressemble donc davantage à un mécanisme permettant de se débarrasser de ces bloqueurs et d’offrir à chacun le meilleur des deux mondes.

Quel est le rôle de Kubernetes dans votre modèle de déploiement ? Et selon vous, quel devrait être le rôle global de Kubernetes pour quelque chose comme un déploiement cloud-prem ?

Kubernetes nous permet de déployer dans les environnements clients de manière très standardisée, et il ressemble au cluster Kubernetes que nous gérons en interne. Sur le plan architectural, nous nous basons également sur Vitess, qui fonctionne sur Kubernetes et a été développé sur Borg, le prédécesseur de Kubernetes chez Google. Donc, nativement, c'est très auto-guérissant. Si vous perdez des pods ou des infrastructures, cela se répare tout seul ; les basculements ne sont pas quelque chose que vous devez considérer manuellement.

Dans notre modèle, les utilisateurs n'ont pas besoin d'exécuter les clusters Kubernetes que nous déployons. Nous n'appliquons pas le modèle de déploiement sur un cluster Kubernetes existant, comme le font certains fournisseurs sur site pour essayer de faciliter les choses. Honnêtement, je me demande si c'est plus facile.

La plupart des gens n’ont pas besoin d’exécuter Kubernetes. C'est un excellent backend pour les fournisseurs d'infrastructures, mais Je ne pense pas que ce soit nécessairement le bon mécanisme de déploiement pour la plupart des entreprises. Je pense que beaucoup de gens ont emprunté cette voie et n’y ont trouvé que peu ou pas d’intérêt.

Si vous avez téléchargé un fichier sur Dropbox et qu'ils vous ont demandé : « Sur combien de serveurs souhaitez-vous que nous le conservions afin qu'il reste hautement disponible ? » Vous diriez : "N'est-ce pas ce que je paie you pour?"

Y a-t-il un niveau d’échelle où cela commence à avoir un sens, à votre avis ? Ou un cas d'utilisation particulier, comme diriger une équipe de plateforme interne ?

Si vous faites ce que nous faisons, c'est-à-dire que vous souhaitez simplifier l'infrastructure et disposer de quelque chose de flexible comme Kubernetes, alors c'est génial. Mais ce niveau de flexibilité est si illimité que si vous créez simplement, par exemple, une entreprise de commerce électronique qui essaie d'héberger un site Web, vous n'avez pas besoin de Kubernetes dans le backend pour le faire. 

C'est très largement adopté, et je pense que beaucoup de gens essaient de créer ces plates-formes internes et voient Kubernetes comme un moyen d'avoir une infrastructure interne simple. Ce n'est tout simplement pas le cas ; cela ne va pas assez loin dans l'expérience de l'utilisateur final. Les gens devraient utiliser le cloud pour quoi il est meilleur pour, et laisser les nuages ​​et les gens comme nous exécuter Kubernetes comme un moyen de simplifier ce qui we faire. 

Mais il y a sûrement un moment où une organisation a une empreinte suffisamment importante pour justifier l’exécution de quelque chose comme Kubernetes en interne, n’est-ce pas ? Comme vous le faisiez sur GitHub ?

Si vous avez beaucoup d'hôtes à gérer (et nous parlons de milliers de machines, ce qui ne représente pas beaucoup d'entreprises) et que vous souhaitez une infrastructure un peu plus auto-réparatrice ou capable d'exploiter un grand parc de machines, cela vous aide à avoir la flexibilité nécessaire pour gérer ces choses. 

Je pense que la question que doit se poser chaque entreprise, quel que soit le choix technique, devrait être : Est-ce que cela différencie nos clients ? Y a-t-il une histoire ou une exigence de l'utilisateur final qui est améliorée par notre gestion et notre gestion de cette infrastructure ? Et si la réponse est aucune, alors vous ne devriez pas du tout le faire avec n'importe quelle technologie.

Par exemple, personne ne peut désormais justifier de gérer son propre hébergement Git. C'est tout simplement fou de ne pas dépenser une somme d'argent ridiculement faible pour que GitHub ou GitLab le fasse à votre place. C'est un argument réglé ; il n'y a aucun avantage à le faire soi-même. À mesure que la technologie sans serveur et juste, en général, s'améliore, cette ligne se déplace partout pour tout le monde. Vous n’allez tout simplement pas constituer une équipe interne de base de données ou une équipe opérationnelle meilleure que celle des fournisseurs de services comme nous. 

Et même si c’était le cas, comment les utilisateurs le sauraient-ils ? Qu'est-ce que cela ferait pour votre base d'utilisateurs ? Très peu : 99.9 % du temps, ils ne se soucient pas de votre pile technologique. Chaque entreprise devrait simplement faire des choses qui font bouger les choses pour ses propres utilisateurs et exploiter autant d'infrastructures gérées que possible.

La sécurité est un problème d’expérience utilisateur et elle est très fondamentale. Il est difficile d'être en sécurité si vous empêchez vos utilisateurs de faire ce qu'il faut.

Comment voyez-vous évoluer les préoccupations en matière de sécurité et de confidentialité des données, en particulier pour les fournisseurs SaaS ?

Tout le monde se soucie de la sécurité. C'est quelque chose que nous devons prendre extrêmement au sérieux en tant qu'entreprise qui héberge des données personnelles. Une tendance que je vois est que les entreprises demandent leurs certifications de conformité bien plus tôt qu’avant. Maintenant tu dois obtenir Certification SOC 2 presque immédiatement, sinon vous ne pourrez pas jouer. (Si vous voulez un bon bout de lecture, Fly.io a écrit un article de blog sur SOC 2 cela vaut la peine d'être étudié.)

Et, en général, les entreprises sont très friandes de certaines fonctionnalités qui sont désormais un enjeu de table, telles que l'authentification par authentification unique, la journalisation d'audit et les jetons d'accès révocables appropriés.

Par exemple, désormais, si vous vérifiez accidentellement les informations d'identification de votre base de données dans un référentiel GitHub public, nous les révoquons immédiatement afin que personne ne puisse accéder à votre base de données. C'est le genre de chose qui se produisait autrefois : les gens transféraient leurs informations d'identification AWS dans un référentiel open source, puis leur compte était soudainement utilisé pour le minage de Bitcoin et ils avaient accumulé des dizaines de milliers de dollars en factures, ou leurs données étaient perdues. là-bas sur Internet

En fin de compte, ce que je pense est que la sécurité est un problème d’expérience utilisateur et qu’elle est très fondamentale. Il est difficile d'être en sécurité si vous empêchez vos utilisateurs de faire ce qu'il faut. Si vous faites en sorte que la sécurité ne soit pas une sécurité par défaut et que les utilisateurs doivent y réfléchir et la configurer, ils sont plus susceptibles de commettre des erreurs. Ainsi, par exemple, vous ne pouvez pas vous connecter à PlanetScale de manière non cryptée : vous ne peut pas. Les gens veulent qu’il en soit autrement parce qu’ils veulent être paresseux ou parce qu’ils veulent faire les choses d’une certaine manière. Nous ne le rendons tout simplement pas possible. Le résultat est que personne ne peut se tromper et envoyer ses données en texte brut sur Internet. Encore une fois, cela fait partie de l’expérience utilisateur. 

Pour chaque [service de fournisseur de cloud] – et il y en a des centaines sur Amazon – cinq jeunes startups en vogue lui font concurrence. Et il va devenir très difficile de s'occuper d'autant d'utilisateurs et de cas d'utilisation et de continuer à évoluer.

Vous avez déjà parlé du sans serveur. Quelle est votre définition pratique du sans serveur ?

La façon dont je le décris est que les bons produits sans serveur ne devraient exposer que ce que vous absolument besoin de contrôler pour faire avancer les choses. Si vous avez téléchargé un fichier sur Dropbox et qu'ils vous ont demandé : « Sur combien de serveurs souhaitez-vous que nous le conservions afin qu'il reste hautement disponible ? » Vous diriez : "N'est-ce pas ce que je paie you pour?" Est-ce la promesse du cloud ? Le cloud devrait être bien plus que simplement ajouter des processeurs virtuels et de la mémoire, mais dans le cloud. 

Serverless dit : « Quelle est l'unité de valeur du utilisateur? Que fait le utilisateur vouloir faire?" Et cela ne les oblige pas à faire autre chose. Donc, pour moi, c'est un mouvement optimiste qui va vers la simplicité et une meilleure conception de produits. 

Comment évalueriez-vous actuellement la relation entre votre entreprise et les fournisseurs de cloud ? Le terme « ennemis » est-il une description juste ?

C'est intéressant, car nous sommes en concurrence d'une certaine manière, mais nous apportons également beaucoup plus d'utilisation à leur plateforme. Pour les clients exécutant notre version cloud-prem gérée, nous travaillons avec les représentants d'Amazon afin que les gens ne partent pas pour aller chez Google ; ils restent sur Amazon et utilisent notre logiciel. Donc, les commerciaux consomment toujours beaucoup, nous comprenons toute cette affaire, et c'est génial. Je pense qu'ils vont lentement reculer et que des entreprises comme nous seront l'expérience de l'utilisateur final. Et en fin de compte, ils gagnent toujours, car ils vendent toujours des serveurs à des volumes de plus en plus importants. 

Mais nous sommes dans cette phase intermédiaire intéressante, où ils ne sont pas seulement des détaillants à grande surface. Ils nous concurrencent toujours avec certains produits, mais cela devient de plus en plus difficile car, désormais, pour chacun de leurs services – et il y en a des centaines sur Amazon – il y a cinq jeunes startups en vogue qui leur font concurrence. Et il va devenir très difficile de s'occuper d'autant d'utilisateurs et de cas d'utilisation et de continuer à évoluer.

Si vous êtes le genre de manager qui n'essaie pas de gravir les échelons tout le temps, mais qui se contente de faire ce que vous dites que vous allez faire, et que vous êtes collégial pendant que vous le faites, et que vous aidez les gens à gagner et que vous poussez les gens avancent – ​​vous êtes naturellement amené dans des pièces plus grandes.

Sans rapport : vous n'étiez pas le PDG de PlanetScale pour commencer. Comment s’est déroulée votre transition de CPO à CEO ?

Lorsque j’ai rejoint l’entreprise, l’entreprise faisait les choses un peu différemment. Nous faisions du Vitess hébergé, qui est l'ancien produit que nous avions. J'ai décidé que je voulais créer un produit de base de données étonnant qui avait Vitess en son cœur, où Vitess était le moteur sous-jacent, mais n'était pas le produit final. Nous avons donc en quelque sorte jeté l’ancien produit et construit ce nouveau produit, qui a connu un grand succès. Et puis j'ai embauché beaucoup de personnes de mon ancienne entreprise, GitHub, et des gens que je connaissais bien. 

À ce moment-là, une grande partie de l’entreprise et de la culture était composée de gens venus travailler avec moi – pour travailler à nouveau ensemble – donc un double changement de culture et de produit s’est produit à travers ce que je voulais faire. La dernière chose logique était de tout aligner sur cette vision. C'est pourquoi je suis devenu PDG.

C’était une transition simple qui a été réalisée et dépoussiérée très, très rapidement. Je veux dire, nos fondateurs sont formidables. Ils ont lancé cette entreprise, ils l’ont bâtie, puis ils l’ont transmise comme le font beaucoup de fondateurs. Certaines entreprises auraient dû procéder ainsi plus tôt.

Vous avez également gravi les échelons chez GitHub assez rapidement, de DBA à vice-président de l'ingénierie. Quels sont vos conseils pour réussir ce type de transition, mais aussi pour décider si une transition vers le management est la bonne ?

Tout d'abord, si vous travaillez dans une entreprise qui nécessite de devenir manager pour avoir une quelconque influence, alors vous n'êtes pas dans la bonne entreprise. Je pense que beaucoup de gens quittent leur rôle de contributeur individuel pour devenir manager simplement pour rester dans la salle, ce qui est terrible. 

Mon conseil est de devenez manager si vous vous souciez profondément des gens et des résultats que des personnes formidables peuvent obtenir. Vous pouvez aller trop loin dans l'autre sens, où vous n'êtes qu'un gestionnaire de personnel et ne vous souciez pas tellement du travail. Je pense qu’en fin de compte, vous voulez voir de grandes choses se construire, et vous le faites grâce à une culture formidable et à l’autonomisation des gens. Donc, si vous vous souciez de ces choses et pouvez les construire, devenez manager.

Je me souciais vraiment de ces choses. J'ai rejoint GitHub en tant qu'ingénieur, j'y ai eu un impact et j'ai adoré. Et je savais que pour évoluer, pour continuer à faire de l'ingénierie de qualité, nous avions besoin d'une excellente gestion. Je voulais construire une culture performante avec de grands ingénieurs. J’ai donc commencé à faire ça et nous avons eu beaucoup de changements. L'entreprise s'est développée, mais j'ai simplement travaillé de manière très constante avec des gens dont je savais qu'ils faisaient de bonnes choses, et j'ai grandi à partir de là. 

On vous demande toujours d’en faire plus. Si vous êtes le genre de manager qui n'essaie pas de gravir les échelons tout le temps, mais qui se contente de faire ce que vous dites que vous allez faire, et que vous êtes collégial pendant que vous le faites, et que vous aidez les gens à gagner et que vous poussez les gens avancent – ​​vous êtes naturellement amené dans des pièces plus grandes. Cela s'est produit sur une période de temps. Et puis finalement, oui, je dirigeais une grande équipe là-bas en tant que vice-président parce que je faisais toujours exactement ce qui était nécessaire pour l'entreprise, je m'y tenais, je travaillais dur et je responsabilisais les gens. 

Et ce dont je suis le plus fier, c'est le nombre de personnes qui sont passées de GitHub à PlanetScale parce qu'elles le savaient. Vous savez ce que je veux dire? Ils ne l'ont pas fait avons à. C'était, pour moi, un signe que j'avais montré que je pouvais constamment faire ce que j'avais dit que j'allais faire en tant que leader. Les gens sont venus pour ça.

Soit dit en passant : très souvent, les dirigeants ruinent les entreprises. Nous avons écrit un manifeste de gestion cela explique ce que nous pensons de ce rôle.

Si vous ne pouvez pas accepter l'idée que vos erreurs vont nuire à la carrière des gens et que les gens dépendent vraiment de vous, alors [la gestion n'est] pas pour vous. 

Si vous êtes un IC cherchant à faire la transition vers la gestion, quelle est la première étape ?

Je pense que vous devez commencer à apprendre à réfléchir de manière sociologique à la dynamique de l'équipe et des personnes qui vous entourent, et à la manière dont vous pouvez influencer la façon dont les gens travaillent en équipe. Devenir un responsable technique, par exemple, comporte bien plus de dynamique sociale que la simple écriture du meilleur code. Vous devez réfléchir aux choses dont nous dépendons, aux personnes dont nous dépendons et à la manière dont nous façonnons notre organisation pour qu'elle reflète le travail que nous allons effectuer - sans avoir à entrer dans les pensées et les sentiments des gens et à les gérer réellement. . Donc, un bon moyen est de essayez de diriger un projet qui comporte beaucoup de travail et de dépendances interfonctionnels, et nécessite que les gens fonctionnent bien ensemble, pour voir si vous avez la capacité d'inspirer les gens à faire leur travail en groupe. 

Si vous y parvenez, vous pourrez alors commencer à acquérir les compétences nécessaires pour bien travailler avec les gens et être leur manager. Parce que c'est un rôle difficile ; c'est un rôle de servitude. Les gens mettent leur carrière entre vos mains, et c'est quelque chose que vous devez prendre très au sérieux. Si vous ne pouvez pas accepter l'idée que vos erreurs vont gâcher la carrière des gens et que les gens dépendent vraiment de vous, alors ce n'est pas pour vous. 

Si vous pensez pouvoir y parvenir et souhaitez aider les gens à devenir de meilleures versions d’eux-mêmes, creusez.

Publié le 2 août 2022