CEO di PlanetScale su Cloud-Prem e Climbing the Engineering Ladder

Sam Lambert è CEO di PianetaScala, un provider di database serverless compatibile con MySQL. Prima di entrare in PlanetScale (allora come chief product officer), è stato vicepresidente dell'ingegneria presso GitHub.

In questa intervista, Lambert discute una serie di argomenti relativi ai modelli di distribuzione del software nativi cloud, tra cui che aspetto ha un buon serverless, chi dovrebbe eseguire Kubernetes e l'emergere di "cloud-prem", un modello di distribuzione che combina i punti di forza di on -prem software e offerte SaaS. Condivide anche la sua esperienza come CEO non fondatore e i suoi consigli su quando e come passare dall'ingegneria alla gestione.

---

FUTURO: hai descritto ciò che PlanetScale sta facendo, almeno non è un'offerta SaaS pura, l'elaborazione "cloud-prem". Come definisci quel termine?

SAM LAMBERT: Prem cloud è un nuovo modello: sostanzialmente la soluzione nativa del cloud per l'on-premise. Tradizionalmente, le aziende hanno dovuto avere un in loco soluzione o a nuvola soluzione, e stare a cavallo di entrambe è tradizionalmente molto difficile. In GitHub, abbiamo avuto questa tensione nell'esecuzione di github.com e anche nella vendita di GitHub Enterprise come soluzione in loco. Con il prodotto cloud, dovevamo essere in grado di spingere e fornire continuamente. Tagliare una versione basata su quello è stato un compito davvero difficile e la creazione di architetture per entrambi significava che non stavamo fornendo la soluzione in loco come avremmo potuto fare; era solo molto arduo da fare. 

Quando siamo arrivati ​​a PlanetScale, abbiamo deciso che volevamo essere solo cloud, ma, ovviamente, non puoi farlo semplicemente con un prodotto database o un prodotto che ha severi requisiti di conformità. Quindi, con cloud-prem, distribuiamo essenzialmente il piano dati del nostro prodotto in a VPC gestito dall'utente, dove usa il nostro piano di controllo per orchestrarlo e noi lo gestiamo. In sostanza sembra di utilizzare solo un normale prodotto SaaS basato su cloud, ma i dati risiedono all'interno del tuo account. Il tuo team di sicurezza può verificarlo e sente la sicurezza e la fiducia di averlo entro i limiti della propria infrastruttura, senza gli svantaggi di dover applicare patch, rilasciare e gestire da soli il software in loco.

C'è un altro vantaggio aggiuntivo, ovvero se sei un grande cliente con un'ottima tariffa negoziata con Amazon, ad esempio, puoi pagare ancora quella tariffa e mantenere la spesa impegnata con Amazon all'interno del tuo account.

Che tipo di respingi ricevi? Ci sono alcuni irriducibili SaaS e negozi on-premise là fuori...

Possiamo offrirti un SaaS puro, in cui ospitiamo i dati all'interno del nostro account e le persone stanno benissimo con questo. Il vero respingimento è se le persone vogliono solo in loco. Ma il modello cloud-prem sta davvero iniziando a risuonare. Abbiamo società regolamentate che utilizzano il prodotto perché vedono il doppio vantaggio di conservare i dati a livello locale in modo che la sicurezza o la conformità siano soddisfatte, ma anche di non doverlo gestire. 

Questo è il motivo per cui questo modello è così unico e straordinario e un momento reale nel tempo: perché risolve il problema delle aziende che non vogliono lavorare in locale - ed essendo un modello vecchio e morto, in pratica - ma che soddisfano per lo più i requisiti che in sede lo farebbe.

Ma sì, a volte incontri ancora resistenza. Ci sono alcune aziende che semplicemente non si fideranno del software SaaS, ma il cloud lo sta rapidamente eliminando. Ad esempio, non puoi decidere quando o come Amazon aggiorna S3 e migliora S3, succede e basta. Si tratta di creare fiducia con molti clienti sul fatto che tu sia l'azienda migliore per gestire un lavoro particolare per loro e aiutarli a sentirsi più a loro agio con quello. 

Non puoi creare la migliore esperienza per sviluppatori quando spedisci software in locale. Non puoi migliorare continuamente. Non puoi gestire la qualità, la disponibilità, i tempi di attività: tutte queste cose fanno parte dell'esperienza.

Gli sviluppatori possono essere piuttosto supponenti sui database che utilizzano. In che modo il modello di distribuzione cloud-prem parla dell'esperienza degli sviluppatori?

È più come se il modello di distribuzione eliminasse i blocchi. Non puoi creare la migliore esperienza per sviluppatori quando spedisci software in locale. Non puoi migliorare continuamente. Non puoi gestire la qualità, la disponibilità, i tempi di attività: tutte queste cose fanno parte dell'esperienza. Se non gestisci tu stesso il servizio, è molto difficile creare un livello di esperienza così elevato. 

Uno dei principali ostacoli per il solo SaaS, ovviamente, è la necessità per alcuni utenti di mantenere i dati sotto il loro controllo. Uno dei principali ostacoli per l'on-premise potrebbe essere la scalabilità. E quindi il modello cloud-prem è più simile a un meccanismo per sbarazzarsi di questi blocchi e offrire a tutti il ​​meglio di entrambi i mondi.

Qual è il ruolo di Kubernetes nel tuo modello di distribuzione? E quale pensi dovrebbe essere il ruolo di Kubernetes in generale per qualcosa come un'implementazione cloud-prem?

Kubernetes ci consente di eseguire il deployment negli ambienti dei clienti in modo molto standardizzato e ha lo stesso aspetto del cluster Kubernetes che eseguiamo internamente. Dal punto di vista architettonico, ci basiamo anche su Vitess, che gira su Kubernetes ed è stato sviluppato su Borg, il predecessore di Kubernetes in Google. Quindi, nativamente, è molto autorigenerante. Se perdi i pod o perdi l'infrastruttura, si cura praticamente da solo; i failover non sono qualcosa che devi considerare manualmente.

Nel nostro modello, gli utenti non devono eseguire i cluster Kubernetes che distribuiamo. Non eseguiamo il modello di distribuzione su un cluster Kubernetes esistente, cosa che fanno alcuni fornitori in loco per cercare di semplificare le cose. Sono scettico se sia più facile, onestamente.

La maggior parte delle persone non ha bisogno di eseguire Kubernetes. È un ottimo back-end per i fornitori di infrastrutture, ma Non credo che sia necessariamente il giusto meccanismo di implementazione per la maggior parte delle aziende. Penso che molte persone abbiano intrapreso quella strada e abbiano trovato poco o nessun valore nel farlo.

Se hai caricato un file su Dropbox e ti hanno chiesto: "Quanti server vorresti che lo manteniamo in modo che rimanga altamente disponibile?" Saresti tipo, “Non è quello che sto pagando Tu per?"

C'è un livello di scala in cui inizia ad avere senso, secondo te? O un caso d'uso particolare, come l'esecuzione di un team interno della piattaforma?

Se stai facendo quello che facciamo noi, dove vuoi semplificare l'infrastruttura e avere qualcosa che sia flessibile come Kubernetes, allora è fantastico. Ma quel livello di flessibilità è così aperto che se stai solo costruendo, diciamo, una società di e-commerce che sta cercando di ospitare un sito Web, non hai bisogno di Kubernetes nel back-end per farlo. 

È ampiamente adottato e penso che molte persone provino a costruire queste piattaforme interne e vedono Kubernetes come un modo per avere una semplice infrastruttura interna. Non è solo il caso; non va abbastanza lontano con l'esperienza dell'utente finale. Le persone dovrebbero usare il cloud per cosa è meglio per, e lasciare che le nuvole e le persone come noi gestiscano Kubernetes come un modo per semplificare cosa we fare. 

Ma sicuramente c'è un punto in cui un'organizzazione ha un'impronta abbastanza grande da giustificare l'esecuzione interna di qualcosa come Kubernetes, giusto? Come stavi facendo su GitHub?

Se hai molti host da gestire - e stiamo parlando di migliaia di macchine, che non sono molte aziende - e desideri un'infrastruttura un po' più autoriparante o in grado di sfruttare un ampio parco macchine, ti aiuta ad avere la flessibilità per gestire queste cose. 

Penso che la domanda per ogni azienda, indipendentemente dalla scelta tecnica, dovrebbe essere: Questo è diverso per i nostri clienti? C'è una storia o un requisito dell'utente finale che è migliorato da noi che gestiamo e gestiamo questa infrastruttura? E se la risposta è no, quindi non dovresti farlo con nessuna tecnologia.

Ad esempio, praticamente nessuno ora può giustificare l'esecuzione del proprio hosting Git. È semplicemente pazzesco non spendere una quantità di denaro ridicolmente bassa per far sì che GitHub o GitLab lo facciano per te. È un argomento stabilito; non c'è alcun vantaggio nel farlo da soli. Man mano che la tecnologia serverless e solo tecnologica, in generale, migliora, quella linea si sta spostando ovunque per tutti. Semplicemente non creerai un team di database interno o un team operativo migliore rispetto a fornitori di servizi come noi. 

E anche se lo facessi, come lo saprebbero gli utenti? Cosa farebbe per la tua base di utenti? Molto poco: il 99.9% delle volte non si preoccupano del tuo stack tecnologico. Ogni azienda dovrebbe praticamente fare cose che spostino l'ago per i propri utenti e sfruttare quanta più infrastruttura gestita possibile.

La sicurezza è un problema di esperienza dell'utente ed è molto fondamentale. È difficile essere sicuri se rendi difficile per i tuoi utenti fare la cosa giusta.

Come vede l'evoluzione dei problemi di sicurezza e privacy dei dati, in particolare per i provider SaaS?

Tutti si preoccupano della sicurezza. È qualcosa che dobbiamo prendere estremamente sul serio come azienda che ospita i dati delle persone. Una tendenza che vedo è quella le aziende stanno cercando le loro certificazioni di conformità molto prima del solito. Ora devi ottenere Certificazione SOC 2 praticamente immediatamente, altrimenti non sarai in grado di giocare. (Se vuoi leggere un po', Fly.io ha scritto a post sul blog su SOC 2 vale la pena esaminarlo.)

E, in generale, le aziende sono molto interessate ad alcune funzionalità che ora sono una posta in gioco, come l'autenticazione single sign-on, la registrazione degli audit e gli appropriati token di accesso revocabili.

Ad esempio, ora, se controlli accidentalmente le credenziali del tuo database in un repository GitHub pubblico, le revochiamo immediatamente in modo che le persone non possano accedere al tuo database. Questo è il genere di cose che succedeva: le persone spingevano le loro credenziali AWS in un repository open source e poi il loro account veniva improvvisamente utilizzato per il mining di Bitcoin e hanno accumulato decine di migliaia di dollari in bollette, oppure i loro dati sono là fuori su internet

In definitiva, la mia opinione positiva è che la sicurezza è un problema di esperienza dell'utente ed è molto fondamentale. È difficile essere sicuri se rendi difficile per i tuoi utenti fare la cosa giusta. Se rendi la sicurezza non predefinita e qualcosa a cui le persone devono pensare e configurare, è più probabile che commettano errori. Quindi, ad esempio, non puoi connetterti a PlanetScale in un modo non crittografato: tu non può. Le persone vogliono diversamente perché vogliono essere pigre o vogliono fare le cose in un certo modo. Semplicemente non lo rendiamo possibile. Il risultato è che nessuno può rovinare e inviare i propri dati in testo normale su Internet. Questo, ancora una volta, fa parte dell'esperienza dell'utente. 

Per ogni [servizio di provider di servizi cloud] - e ce ne sono centinaia su Amazon - ci sono cinque giovani startup calde che competono contro di esso. E diventerà molto difficile occuparsi di così tanti utenti e casi d'uso e mantenerlo scalabile.

Hai menzionato prima il serverless. Qual è la tua definizione di lavoro di serverless?

Il modo in cui lo descrivo è che i buoni prodotti serverless dovrebbero esporre solo ciò che tu assolutamente bisogno di controllare per portare a termine le cose. Se hai caricato un file su Dropbox e ti hanno chiesto: "Quanti server vorresti che lo manteniamo in modo che rimanga altamente disponibile?" Saresti tipo, “Non è quello che sto pagando Tu per?" È questa la promessa del cloud? Il cloud dovrebbe essere molto più della semplice aggiunta di vCPU e memoria, ma nel cloud. 

Serverless dice: "Qual è l'unità di valore per il Utente? Cosa fa il Utente vuoi fare?" E non li obbliga a fare altro. Quindi, per me, è un movimento ottimista che va verso la semplicità e un migliore design del prodotto. 

Come valuteresti il ​​rapporto tra la tua azienda e i fornitori di servizi cloud in questo momento? "Frenemies" è una descrizione corretta?

È interessante, perché in qualche modo competiamo, ma portiamo anche molto più utilizzo alla loro piattaforma. Per i clienti che eseguono la nostra versione gestita e cloud-prem, collaboriamo con i rappresentanti di Amazon in modo che le persone non lascino andare su Google; rimangono su Amazon e usano il nostro software. Quindi le ripetizioni ottengono ancora un sacco di consumo, prendiamo la nostra opinione sull'intero affare ed è fantastico. Penso che lentamente torneranno indietro e che aziende come noi saranno l'esperienza dell'utente finale. E alla fine stanno ancora vincendo, perché stanno ancora vendendo server a volumi sempre maggiori. 

Ma siamo in questa interessante fase intermedia, in cui non si tratta solo di grandi rivenditori. Competono ancora con noi con alcuni prodotti, ma sta diventando molto più difficile perché, ora, per ognuno dei loro servizi - e ce ne sono centinaia su Amazon - ci sono cinque giovani startup calde che competono contro di esso. E diventerà molto difficile occuparsi di così tanti utenti e casi d'uso e mantenerlo scalabile.

Se sei il tipo di manager che non cerca sempre di scalare la scala, ma fa semplicemente quello che dici che farai, e sei collegiale mentre lo fai, aiuti le persone a vincere e spingi le persone in avanti: vieni naturalmente portato in stanze più grandi.

In modo non correlato: all'inizio non eri il CEO di PlanetScale. Come è avvenuto il tuo passaggio da CPO a CEO?

Quando mi sono unito, l'azienda stava facendo le cose in modo leggermente diverso. Stavamo realizzando Vitess in hosting, che è il vecchio prodotto che avevamo. Ho deciso che volevo creare un fantastico prodotto di database che avesse Vitess al centro, in cui Vitess era il motore sottostante, ma non era il prodotto finale. Quindi abbiamo in qualche modo buttato via il vecchio prodotto e costruito questo nuovo, e ha avuto molto successo. E poi ho assunto molte persone della mia precedente azienda, GitHub, e persone che conoscevo bene. 

A quel punto, gran parte dell'azienda e della cultura erano persone che erano venute a lavorare con me, per lavorare di nuovo insieme, quindi un doppio cambiamento della cultura e del prodotto è arrivato attraverso quello che volevo fare. L'ultima cosa logica era allineare tutto sotto quella visione. Ecco perché sono diventato l'amministratore delegato.

È stata una transizione semplice che è stata eseguita e spolverata molto, molto rapidamente. Voglio dire, i nostri fondatori sono fantastici. Hanno fondato questa azienda, l'hanno costruita e poi l'hanno trasferita come fanno molti fondatori. Alcune aziende avrebbero dovuto farlo prima.

Hai anche scalato la scala in GitHub abbastanza rapidamente, da DBA a vicepresidente dell'ingegneria. Qual è il tuo consiglio per effettuare con successo questi tipi di transizioni e anche per decidere se un passaggio alla gestione è quello giusto?

Prima di tutto, se sei in un'azienda che richiede di diventare un manager per avere una qualche influenza, allora sei nell'azienda sbagliata. Penso che molte persone lascino un ruolo di collaboratore individuale per andare a diventare manager solo per rimanere nella stanza, il che è terribile. 

Il mio consiglio è di diventa un manager se tieni profondamente alle persone e ti preoccupi dei risultati che le grandi persone possono ottenere. Puoi andare troppo lontano dall'altra parte, dove sei solo un manager del personale e non ti interessa molto del lavoro. Penso che alla fine tu voglia vedere costruire grandi cose e lo fai attraverso una grande cultura e dando potere alle persone. Quindi, se ti interessano queste cose e puoi costruirle, diventa un manager.

Mi importava davvero di quelle cose. Sono entrato in GitHub come ingegnere, ho avuto un impatto lì e l'ho adorato. E sapevo che per scalare, per continuare a fare grande ingegneria, avevamo bisogno di un'ottima gestione. Volevo costruire una cultura ad alte prestazioni con grandi ingegneri. Così ho iniziato a farlo e abbiamo avuto molti cambiamenti. L'azienda è cresciuta, ma ho lavorato in modo molto coerente con persone che sapevo stavano facendo cose buone, e da lì sono cresciuto. 

Ti viene sempre chiesto di fare di più. Se sei il tipo di manager che non cerca sempre di scalare la scala, ma fa semplicemente quello che dici che farai, e sei collegiale mentre lo fai, aiuti le persone a vincere e spingi le persone in avanti: vieni naturalmente portato in stanze più grandi. È successo solo in un periodo di tempo. E poi alla fine, sì, stavo dirigendo un grande team lì come vicepresidente perché ho sempre fatto esattamente ciò che era necessario per il business e mi sono bloccato e ho lavorato sodo e dato potere alle persone. 

E la cosa di cui sono più orgoglioso è quante persone sono venute da GitHub a PlanetScale perché lo sapevano. Sai cosa intendo? Non l'hanno fatto avere a. Questo era, per me, un segno che avevo dimostrato di poter fare costantemente ciò che dicevo che avrei fatto come leader. La gente è venuta per quello.

Per inciso: molto spesso, i manager rovinano le aziende. Abbiamo scritto un manifesto di gestione che spiega come ci sentiamo riguardo a quel ruolo.

Se non riesci a gestire l'idea che i tuoi errori rovineranno le carriere delle persone e che le persone dipendano davvero da te, allora [la gestione] non fa per te. 

Se sei un IC che cerca di passare alla gestione, qual è il primo passo?

Penso che tu debba iniziare a imparare a pensare in modo sociologico alle dinamiche della squadra e alle persone intorno a te, e come puoi influenzare il modo in cui le persone lavorano insieme come una squadra. Diventare un capo tecnico, ad esempio, ha molte più dinamiche sociali rispetto alla semplice scrittura del codice migliore. Devi pensare alle cose da cui dipendiamo, alle persone da cui dipendiamo e a come stiamo modellando la nostra organizzazione per riflettere il lavoro che faremo, senza dover entrare nei pensieri e nei sentimenti delle persone e gestirle effettivamente . Quindi un buon modo è farlo prova a guidare un progetto che ha molto lavoro e dipendenze interfunzionalie richiede che le persone funzionino bene insieme, per vedere se hai la capacità di ispirare le persone a svolgere il loro lavoro in gruppo. 

Se riesci a farlo con successo, puoi iniziare ad apprendere le competenze necessarie per lavorare davvero bene con le persone ed essere il loro manager. Perché è un ruolo difficile; è un ruolo di servitù. Le persone mettono la loro carriera nelle tue mani, ed è qualcosa che devi prendere molto sul serio. Se non riesci a gestire l'idea che i tuoi errori rovineranno la carriera delle persone e che le persone dipendano davvero da te, allora non fa per te. 

Se pensi di potercela fare e vuoi aiutare le persone a diventare una versione migliore di se stesse, approfondisci.

Inserito il 2 agosto 2022