PlanetScale CEO på Cloud-Prem og Climbing the Engineering Ladder

Sam Lambert er administrerende direktør for PlanetScale, en MySQL-kompatibel serverløs databaseudbyder. Før han kom til PlanetScale (dengang som chief product officer), var han VP of engineering hos GitHub.

I dette interview diskuterer Lambert en række emner relateret til cloud-native software-leveringsmodeller, herunder hvordan god serverløs ser ud, hvem der skal køre Kubernetes og fremkomsten af ​​"cloud-prem" - en implementeringsmodel, der kombinerer styrkerne fra på -prem-software og SaaS-tilbud. Han deler også sin erfaring med at blive en ikke-grundlægger administrerende direktør og sine råd om, hvornår og hvordan man kan flytte fra ingeniør til ledelse.

---

FREMTID: Du har beskrevet, hvad PlanetScale laver - i det mindste dets ikke rene SaaS-tilbud - "cloud-prem" computing. Hvordan definerer du det begreb?

SAM LAMBERT: Cloud-prem er en ny model - grundlæggende cloud-native løsning til on-prem. Traditionelt har virksomheder måttet enten have en on-prem løsning eller en cloud løsning, og skrævende begge dele er traditionelt meget vanskeligt. Hos GitHub havde vi denne spænding med at køre github.com og også sælge GitHub Enterprise som en on-prem løsning. Med cloud-produktet skulle vi kunne presse og levere løbende. At skære en udgivelse baseret på det var en virkelig vanskelig opgave, og at bygge arkitekturer for begge betød, at vi ikke leverede den lokale løsning så godt, som vi kunne have gjort; det var bare meget besværligt at gøre. 

Da vi kom til PlanetScale, besluttede vi, at vi ville være cloud-only, men det kan du selvfølgelig ikke bare gøre med et databaseprodukt eller et produkt, der har strenge overholdelseskrav. Så med cloud-prem implementerer vi i det væsentlige dataplanet for vores produkt i en VPC administreret af brugeren, hvor de bruger vores kontrolplan til at orkestrere det, og vi administrerer det. Det i bund og grund føles som om du bare bruger et almindeligt cloud-baseret SaaS-produkt, men dataene ligger på din konto. Dit sikkerhedsteam kan auditere det, og de føler sikkerheden og tilliden ved at have det inden for grænserne af deres infrastruktur, uden ulemperne ved selv at skulle patche, frigive og administrere on-prem software.

Der er en anden ekstra fordel, som er, at hvis du er en stor kunde med en fantastisk forhandlet pris med Amazon, for eksempel, kan du stadig betale denne sats og beholde dit forpligtede forbrug hos Amazon inde på din konto.

Hvilken slags pushback får du? Der er nogle diehard SaaS og on-prem butikker derude ...

Vi kan give dig ren SaaS, hvor vi hoster dataene inde på vores konto, og det har folk det helt fint med. Den virkelige pushback er, hvis folk bare vil have on-prem. Men cloud-prem-modellen begynder virkelig at give genlyd. Vi har fået regulerede virksomheder til at bruge produktet, fordi de ser den dobbelte fordel ved at holde dataene lokalt, så sikkerhed eller compliance er tilfreds, men heller ikke skal administrere det. 

Dette er grunden til, at denne model er så enestående fantastisk og et rigtigt øjeblik i tiden: Fordi den kommer uden om problemet med ikke virksomheder, der ikke ønsker at lave on-prem - og det er en gammel, død model, dybest set - men stadig for det meste opfylder kravene at on-prem ville.

Men ja, du møder stadig modstand nogle gange. Der er nogle virksomheder, der bare ikke vil stole på SaaS-software, men skyen er hurtigt ved at gøre op med det. Ligesom du ikke bestemmer hvornår eller hvordan Amazon opdaterer S3 og gør S3 bedre, det sker bare. Det handler om at opbygge tillid hos en masse kunder om, at du er den bedste virksomhed til at klare et bestemt job for dem, og hjælpe dem med at blive mere fortrolige med det. 

Du kan ikke opbygge den bedste udvikleroplevelse, når du sender on-prem software. Du kan ikke konstant forbedre dig. Du kan ikke administrere kvalitet, tilgængelighed, oppetid - alle disse ting er en del af oplevelsen.

Udviklere kan være ret meningsfulde om de databaser, de bruger. Hvordan taler cloud-prem-implementeringsmodellen til udvikleroplevelsen?

Det er mere som om implementeringsmodellen fjerner blokeringerne. Du kan ikke opbygge den bedste udvikleroplevelse, når du sender on-prem software. Du kan ikke konstant forbedre dig. Du kan ikke administrere kvalitet, tilgængelighed, oppetid – alle disse ting er en del af oplevelsen. Hvis du ikke selv administrerer tjenesten, er det meget svært at skabe et så højt oplevelsesniveau. 

En stor blokering for SaaS-only er selvfølgelig behovet for nogle brugere for at holde data under deres kontrol. En stor blokering for on-prem kan være skalerbarhed. Og derfor er cloud-prem-modellen mere som en mekanisme til at slippe af med disse blokere og give alle det bedste fra begge verdener.

Hvad er Kubernetes rolle i din implementeringsmodel? Og hvad synes du burde være Kubernetes' rolle generelt for noget som en cloud-prem-implementering?

Kubernetes giver os mulighed for at implementere i kundemiljøer på en meget standardiseret måde, og den ser ud som den Kubernetes-klynge, vi kører internt. Arkitektonisk er vi også baseret på Vitess, som kører på Kubernetes og er udviklet på Borg, forgængeren til Kubernetes hos Google. Så indfødt er det meget selvhelbredende. Hvis du mister pods eller du mister infrastruktur, helbreder det sig selv stort set; failovers er ikke noget, du skal overveje manuelt.

I vores model behøver brugerne ikke at køre de Kubernetes-klynger, som vi implementerer. Vi laver ikke modellen med implementering på en eksisterende Kubernetes-klynge, som nogle lokale leverandører gør som en måde at forsøge at gøre det nemmere. Jeg er skeptisk, om det er nemmere, ærligt talt.

De fleste mennesker behøver ikke at køre Kubernetes. Det er en fantastisk backend for infrastrukturudbydere, men Jeg tror ikke, at det nødvendigvis er den rigtige implementeringsmekanisme for de fleste virksomheder. Jeg tror, ​​at mange mennesker er gået den vej og fundet ringe eller ingen værdi af at gøre det.

Hvis du uploadede en fil til Dropbox, og de spurgte dig: "Hvor mange servere vil du have, at vi holder denne på, så den forbliver høj tilgængelig?" Du ville være sådan, "Er det ikke det, jeg betaler dig til?"

Er der et skalaniveau, hvor det efter din mening begynder at give mening? Eller en bestemt use case, som at drive et internt platformsteam?

Hvis du laver det, vi gør, hvor du vil forenkle infrastrukturen og have noget, der er fleksibelt som Kubernetes, så er det fantastisk. Men det fleksibilitetsniveau er så åbent, at hvis du bare bygger for eksempel en e-handelsvirksomhed, der forsøger at hoste et websted, behøver du ikke Kubernetes i backend for at gøre det. 

Det er meget udbredt, og jeg tror, ​​at mange mennesker forsøger at bygge disse interne platforme, og de ser Kubernetes som en måde at have enkel intern infrastruktur på. Det er bare ikke tilfældet; det går ikke langt nok med slutbrugeroplevelsen. Folk burde bruge skyen til hvad Det er bedst til, og lade skyerne og folk som os køre Kubernetes som en måde at forenkle det we gør. 

Men der er sikkert et punkt, hvor en organisation har et stort nok fodaftryk til at retfærdiggøre at drive noget som Kubernetes internt, ikke? Som du gjorde på GitHub?

Hvis du har mange værter at administrere - og vi taler om tusindvis af maskiner, hvilket ikke er mange virksomheder - og du vil have infrastruktur, der er en lille smule mere selvhelbredende eller kan udnytte en stor flåde af maskiner, hjælper det dig med at fleksibiliteten til at håndtere disse ting. 

Jeg tror, ​​at spørgsmålet for enhver virksomhed, uanset det tekniske valg, bør være: Er dette differentieret for vores kunder? Er der en slutbrugerhistorie eller et krav, der bliver bedre af, at vi kører og administrerer denne infrastruktur? Og hvis svaret er ingen, så skal du slet ikke gøre det med nogen teknologi.

Som, dybest set kan ingen nu retfærdiggøre at køre deres egen Git-hosting. Det er bare vanvittigt ikke at bruge det latterligt lave beløb for at få GitHub eller GitLab til at gøre det for dig. Det er et afgjort argument; der er ingen fordel ved at gøre det selv. Efterhånden som serverløs og bare teknologi generelt bliver bedre, bevæger den linje sig overalt for alle. Du kommer bare ikke til at bygge et internt databaseteam eller et operationsteam, der er bedre end hos tjenesteudbydere som os selv. 

Og selvom du gjorde det, hvordan ville brugerne vide det? Hvad ville det gøre for din brugerbase? Meget lidt - 99.9 procent af tiden er de ligeglade med din tekniske stak. Enhver virksomhed bør stort set bare gøre ting, der flytter nålen for deres egne brugere og udnytte så meget administreret infrastruktur, som de overhovedet kan.

Sikkerhed er et problem med brugeroplevelsen, og det er meget grundlæggende. Det er svært at være sikker, hvis du gør det svært for dine brugere at gøre det rigtige.

Hvordan ser du, at bekymringer om sikkerhed og databeskyttelse udvikler sig, især for SaaS-udbydere?

Alle bekymrer sig om sikkerhed. Det er noget, vi skal tage ekstremt alvorligt som en virksomhed, der hoster folks data. En tendens jeg ser er det virksomheder går efter deres overholdelsescertificeringer langt hurtigere, end de plejede. Nu skal du få SOC 2 certificering stort set med det samme, ellers kan du ikke spille. (Hvis du vil have lidt at læse, skrev Fly.io en blogindlæg om SOC 2 det er værd at undersøge.)

Og generelt er virksomheder meget opsatte på visse egenskaber, som nu er bordspil, såsom godkendelse med enkelt sign-on, revisionslogning og korrekte tilbagekaldelige adgangstokens.

For eksempel, hvis du nu ved et uheld tjekker dine databaselegitimationsoplysninger ind i et offentligt GitHub-lager, tilbagekalder vi dem straks, så folk ikke kan få adgang til din database. Det er den slags ting, der plejede at ske - folk ville skubbe deres AWS-legitimationsoplysninger ind i et open source-lager, og så bliver deres konto pludselig brugt til Bitcoin-minedrift, og de har løbet op med titusindvis af dollars i regninger, eller deres data er derude på internettet

I sidste ende er mit varme bud, at sikkerhed er et problem med brugeroplevelsen, og det er meget grundlæggende. Det er svært at være sikker, hvis du gør det svært for dine brugere at gøre det rigtige. Hvis du laver sikkerhed som ikke-standard, og noget som folk skal tænke over og konfigurere, er der større sandsynlighed for, at de laver fejl. Så du kan for eksempel ikke oprette forbindelse til PlanetScale på en ikke-krypteret måde - du kan ikke. Folk vil have det ellers, fordi de vil være dovne, eller de vil gøre tingene på bestemte måder. Vi gør det bare ikke muligt. Resultatet er, at ingen kan rode og sende deres data i almindelig tekst over internettet. Det er igen en del af brugeroplevelsen. 

For hver [skyudbydertjeneste] - og der er hundredvis på Amazon - er der fem hotte unge startups, der konkurrerer mod den. Og det bliver meget svært at bekymre sig om så mange brugere og bruge cases og holde det skalere.

Du nævnte serverløs før. Hvad er din arbejdsdefinition af serverløs?

Den måde jeg beskriver det på er, at gode serverløse produkter kun skal eksponere det, du absolut skal kontrollere for at få tingene gjort. Hvis du uploadede en fil til Dropbox, og de spurgte dig: "Hvor mange servere vil du have, at vi holder denne på, så den forbliver høj tilgængelig?" Du ville være sådan, "Er det ikke det, jeg betaler dig til?" Er det løftet om skyen? Skyen skal være meget mere end blot at tilføje vCPU'er og hukommelse, men i skyen. 

Serverless siger: "Hvad er værdienheden for bruger? Hvad gør bruger ønsker at gøre?” Og det tvinger dem ikke til mere end det. Så for mig er det en optimistisk bevægelse, der går mod enkelhed og bedre produktdesign. 

Hvordan vil du vurdere forholdet mellem din virksomhed og cloud-udbydere lige nu? Er "frenemies" en retfærdig beskrivelse?

Det er interessant, fordi vi konkurrerer på nogle måder, men vi bringer også meget mere brug til deres platform. For kunder, der kører vores administrerede, cloud-prem-version, arbejder vi med Amazon-repræsentanter, så folk ikke går for at gå til Google; de bliver på Amazon, og de bruger vores software. Så repræsentanterne får stadig masser af forbrug, vi får vores bud på hele den aftale, og det er fantastisk. Jeg tror, ​​de langsomt vil bevæge sig baglæns og få virksomheder som os til at være slutbrugeroplevelsen. Og i sidste ende vinder de stadig, fordi de stadig sælger servere med større og større mængder. 

Men vi er i denne interessante mellemfase, hvor de ikke kun er store kasseforhandlere. De konkurrerer stadig med os med visse produkter, men det bliver meget sværere, fordi der nu for hver af deres tjenester – og der er hundredvis på Amazon – er fem hotte unge startups, der konkurrerer imod det. Og det bliver meget svært at bekymre sig om så mange brugere og bruge cases og holde det skalere.

Hvis du er typen leder, der ikke prøver at klatre op ad stigen hele tiden - men bare får gjort det, du siger, du vil gøre, og du er kollegial, mens du gør det, og du hjælper folk med at vinde, og du presser folk frem - du bliver bare naturligt bragt ind i større rum.

Uafhængigt: Du var ikke administrerende direktør for PlanetScale til at begynde med. Hvordan opstod dit skifte fra CPO til CEO?

Da jeg kom til, gjorde virksomheden tingene lidt anderledes. Vi lavede hostet Vitess, som er det gamle produkt, vi havde. Jeg besluttede, at jeg ville bygge et fantastisk databaseprodukt, der havde Vitess i sin kerne, hvor Vitess var den underliggende motor, men ikke var det endelige produkt. Så vi smed på en måde det gamle produkt væk og byggede dette nye, og det blev meget vellykket. Og så hyrede jeg en masse folk fra mit tidligere firma, GitHub, og folk, som jeg kendte godt. 

På det tidspunkt var en stor del af virksomheden og kulturen mennesker, der var kommet for at arbejde sammen med mig - for at arbejde sammen igen - så et dobbelt skift af kulturen og produktet kom ind gennem det, jeg ville lave. Den sidste logiske ting var at tilpasse alt under den vision. Derfor blev jeg administrerende direktør.

Det var en simpel overgang, der blev gjort og støvet meget, meget hurtigt. Jeg mener, vores grundlæggere er fantastiske. De startede denne virksomhed, de byggede virksomheden, og så afleverede de den, ligesom mange stiftere gør. Nogle virksomheder burde have gjort det før.

Du rykkede også ret hurtigt op ad stigen hos GitHub, fra DBA til VP of engineering. Hvad er dit råd til at gøre den slags overgange med succes, og også til at beslutte, om et skift til ledelse er det rigtige?

Først og fremmest, hvis du er i en virksomhed, der kræver at blive leder for at have indflydelse, så er du i den forkerte virksomhed. Jeg tror, ​​at mange mennesker forlader en individuel bidragyderrolle for at gå hen og være manager bare for at blive i rummet, hvilket er forfærdeligt. 

Mit råd er at bliv leder, hvis du bekymrer dig dybt om mennesker og bekymrer dig om de resultater, som fantastiske mennesker kan opnå. Man kan gå for vidt den anden vej, hvor man bare er people manager, og man er ligeglad med arbejdet. Jeg tror, ​​at du i sidste ende ønsker at se store ting blive bygget, og det gør du gennem fantastisk kultur og styrkende mennesker. Så hvis du bekymrer dig om de ting og kan bygge disse ting, så bliv leder.

Jeg brød mig virkelig om de ting. Jeg sluttede mig til GitHub som ingeniør, og jeg havde en indflydelse der, og jeg elskede det. Og jeg vidste, at vi havde brug for god ledelse for at kunne fortsætte med at udføre fantastisk ingeniørarbejde. Jeg ville bygge en højtydende kultur med gode ingeniører. Så jeg begyndte at gøre det, og vi havde mange ændringer. Virksomheden voksede, men jeg arbejdede bare meget konsekvent med mennesker, som jeg vidste, gjorde gode ting, og bare voksede op derfra. 

Du bliver altid bedt om at gøre mere. Hvis du er typen leder, der ikke prøver at klatre op ad stigen hele tiden - men bare får gjort det, du siger, du vil gøre, og du er kollegial, mens du gør det, og du hjælper folk med at vinde, og du presser folk frem - du bliver bare naturligt bragt ind i større rum. Det skete bare over en periode. Og så til sidst, ja, jeg kørte et stort team der som VP, fordi jeg bare altid gjorde præcis, hvad der var nødvendigt for virksomheden og holdt fast i det og arbejdede hårdt og styrkede folk. 

Og det, jeg er mest stolt af, er, hvor mange mennesker der kom fra GitHub til PlanetScale, fordi de vidste det. Du ved hvad jeg mener? Det gjorde de ikke have til. Det var for mig et tegn på, at jeg havde vist, at jeg konsekvent kunne gøre, hvad jeg sagde, jeg ville gøre som leder. Folk kom for det.

Som en sidebemærkning: Meget ofte ødelægger ledere virksomheder. Vi skrev en ledelsesmanifest der fortæller, hvordan vi har det med den rolle.

Hvis du ikke kan håndtere tanken om, at dine fejl vil rode med folks karrierer, og at folk virkelig er afhængige af dig, så er [ledelse] ikke noget for dig. 

Hvis du er en IC, der ønsker at gå over til ledelse, hvad er det første skridt?

Jeg synes, man skal begynde at lære at tænke sociologisk om dynamikken i teamet og de mennesker omkring en, og hvordan man kan påvirke, hvordan folk arbejder sammen som et team. At blive en tech lead, for eksempel, har meget mere social dynamik over sig end blot at skrive den bedste kode. Du er nødt til at tænke på ting, vi er afhængige af, de mennesker, vi er afhængige af, og hvordan vi former vores organisation, så den afspejler det arbejde, vi skal udføre – uden at skulle sætte dig ind i folks tanker og følelser og rent faktisk administrere dem . Så en god måde er at prøve at lede et projekt, der har en masse tværgående arbejde og afhængigheder, og kræver, at folk fungerer godt sammen, for at se, om I har evnen til at inspirere folk til at få deres arbejde gjort som en gruppe. 

Hvis du kan gøre det med succes, så kan du begynde at lære de færdigheder, der skal til for faktisk at arbejde godt med mennesker og være deres leder. For det er en hård rolle; det er en trældomsrolle. Folk lægger deres karriere i dine hænder, og det er noget, du skal tage meget alvorligt. Hvis du ikke kan håndtere tanken om, at dine fejl vil rode med folks karrierer, og at folk virkelig er afhængige af dig, så er det ikke noget for dig. 

Hvis du tror, ​​du kan gøre det og vil hjælpe folk med at blive bedre udgaver af sig selv, så grav ind.

Offentliggjort 2. august 2022