CEO PlanetScale na Cloud-Prem i wspinanie się po drabinie inżynierskiej

Sam Lambert jest dyrektorem generalnym PlanetSkala, zgodny z MySQL dostawca bezserwerowej bazy danych. Przed dołączeniem do PlanetScale (wtedy jako Chief Product Officer) był wiceprezesem ds. inżynierii w GitHub.

W tym wywiadzie Lambert omawia szereg tematów związanych z natywnymi modelami dostarczania oprogramowania w chmurze, w tym jak wygląda dobry bezserwerowy, kto powinien obsługiwać Kubernetes oraz pojawienie się „cloud-prem” — modelu wdrażania, który łączy w sobie mocne strony -prem oprogramowanie i oferty SaaS. Dzieli się również swoimi doświadczeniami z bycia dyrektorem generalnym non-founderem oraz radami, kiedy i jak przejść od inżynierii do zarządzania.

---

PRZYSZŁOŚĆ: Opisałeś, co robi PlanetScale — przynajmniej nie oferuje czystej SaaS — przetwarzanie w chmurze. Jak definiujesz ten termin?

SAM JAGNIĘCY: Chmura premium to nowy model — w zasadzie natywne rozwiązanie w chmurze dla lokalizacji lokalnej. Tradycyjnie firmy musiały albo mieć lokalnie rozwiązanie lub chmura rozwiązanie, a połączenie obu tych rozwiązań jest tradycyjnie bardzo trudne. W GitHub mieliśmy napięcie związane z prowadzeniem github.com, a także sprzedażą GitHub Enterprise jako rozwiązania lokalnego. Dzięki produktowi w chmurze musieliśmy być w stanie stale naciskać i dostarczać. Wycięcie wydania na tej podstawie było naprawdę trudnym zadaniem, a budowanie architektur dla obu oznaczało, że nie dostarczaliśmy rozwiązania lokalnego tak dobrze, jak mogliśmy to zrobić; było to po prostu bardzo żmudne. 

Kiedy weszliśmy do PlanetScale, zdecydowaliśmy, że chcemy działać tylko w chmurze, ale oczywiście nie można tego zrobić po prostu z produktem bazodanowym lub produktem, który ma ścisłe wymagania dotyczące zgodności. Tak więc, dzięki cloud-prem, zasadniczo wdrażamy płaszczyznę danych naszego produktu w VPC zarządzane przez użytkownika, gdzie używają naszej płaszczyzny sterowania do jej orkiestracji, a my nią zarządzamy. To zasadniczo wydaje się, że używasz zwykłego produktu SaaS opartego na chmurze, ale dane znajdują się na Twoim koncie. Twój zespół ds. bezpieczeństwa może to skontrolować, a oni czują bezpieczeństwo i zaufanie wynikające z posiadania go w granicach swojej infrastruktury, bez wady związanej z koniecznością samodzielnego łatania, wydawania i zarządzania oprogramowaniem lokalnym.

Jest jeszcze jedna dodatkowa korzyść, na przykład jeśli jesteś dużym klientem ze świetną wynegocjowaną stawką z Amazon, możesz nadal płacić tę stawkę i zachować swoje zaangażowanie w Amazon na swoim koncie.

Jakiego rodzaju odpychanie otrzymujesz? Istnieje kilka zagorzałych sklepów SaaS i sklepów stacjonarnych…

Możemy zapewnić Ci czysty SaaS, w którym przechowujemy dane na naszym koncie, a ludzie są z tym całkowicie w porządku. Prawdziwym odwetem jest to, że ludzie chcą tylko na miejscu. Ale model cloud-prem naprawdę zaczyna rezonować. Mamy regulowane firmy korzystające z produktu, ponieważ widzą podwójną korzyść z przechowywania danych lokalnie, dzięki czemu bezpieczeństwo lub zgodność są szczęśliwe, ale także nie muszą nimi zarządzać. 

To dlatego ten model jest tak wyjątkowo niesamowity i stanowi prawdziwy moment w czasie: ponieważ rozwiązuje problem, że nie firmy nie chcą działać lokalnie – i jest to w zasadzie stary, martwy model – ale nadal w większości spełniający wymagania że na miejscu.

Ale tak, wciąż czasami napotykasz opór. Jest kilka firm, które po prostu nie ufają oprogramowaniu SaaS, ale chmura szybko to likwiduje. Na przykład nie musisz decydować, kiedy i jak Amazon aktualizuje S3 i ulepsza S3, po prostu się dzieje. Wszystko sprowadza się do budowania zaufania wielu klientów, że jesteś najlepszą firmą do zarządzania konkretnym stanowiskiem dla nich i pomagania im bardziej się z tym czuć. 

Nie możesz stworzyć najlepszego środowiska programisty, gdy dostarczasz oprogramowanie lokalne. Nie możesz ciągle się doskonalić. Nie możesz zarządzać jakością, dostępnością, czasem pracy bez przestojów — wszystkie te rzeczy są częścią doświadczenia.

Deweloperzy mogą być dość zdeterminowani co do baz danych, z których korzystają. W jaki sposób model wdrażania w chmurze ma wpływ na środowisko programistów?

To bardziej tak, jakby model wdrażania usuwał blokery. Nie możesz stworzyć najlepszego środowiska programisty, gdy dostarczasz oprogramowanie lokalne. Nie możesz ciągle się doskonalić. Nie możesz zarządzać jakością, dostępnością, czasem pracy bez przestojów — wszystkie te rzeczy są częścią doświadczenia. Jeśli sam nie zarządzasz usługą, bardzo trudno jest stworzyć tak wysoki poziom doświadczenia. 

Główną blokadą tylko dla SaaS jest oczywiście potrzeba kontrolowania danych przez niektórych użytkowników. Główną blokadą lokalnego blokowania może być skalowalność. Tak więc model cloud-prem jest bardziej mechanizmem, który pozwala pozbyć się tych blokerów i dać wszystkim to, co najlepsze z obu światów.

Jaka jest rola Kubernetes w Twoim modelu wdrażania? A jak myślisz, jaka powinna być ogólna rola Kubernetes w przypadku wdrożenia typu cloud-prem?

Kubernetes umożliwia nam wdrażanie w środowiskach klientów w bardzo ustandaryzowany sposób i wygląda tak samo jak klaster Kubernetes, który prowadzimy wewnętrznie. Architektonicznie bazujemy również na Vitess, który działa na Kubernetes i został opracowany na Borg, poprzedniku Kubernetes w Google. Tak więc, natywnie, jest bardzo samoleczący. Jeśli zgubisz kapsuły lub stracisz infrastrukturę, to samo się leczy; przełączanie awaryjne nie jest czymś, co trzeba brać pod uwagę ręcznie.

W naszym modelu użytkownicy nie muszą uruchamiać wdrożonych przez nas klastrów Kubernetes. Nie robimy modelu wdrażania w istniejącym klastrze Kubernetes, co niektórzy dostawcy lokalni robią, aby to ułatwić. Szczerze mówiąc, sceptycznie podchodzę do sprawy, czy jest to łatwiejsze.

Większość ludzi nie musi uruchamiać Kubernetes. To świetny backend dla dostawców infrastruktury, ale Nie sądzę, że jest to właściwy mechanizm wdrażania dla większości firm. Myślę, że wiele osób podążyło tą drogą i nie znalazło w tym żadnej wartości.

Jeśli przesłałeś plik do Dropbox, a oni zapytali Cię: „Na ilu serwerach chcesz, abyśmy to zachowali, aby zachować wysoką dostępność?” Powiesz: „Czy to nie jest to, za co płacę?” ty dla?"

Czy według Ciebie istnieje taki poziom skali, na którym zaczyna to mieć sens? A może konkretny przypadek użycia, na przykład prowadzenie wewnętrznego zespołu platformy?

Jeśli robisz to, co my, gdzie chcesz uprościć infrastrukturę i mieć coś, co jest elastyczne, jak Kubernetes, to świetnie. Ale ten poziom elastyczności jest tak otwarty, że jeśli budujesz, powiedzmy, firmę e-commerce, która próbuje hostować witrynę, nie potrzebujesz Kubernetes w zapleczu, aby to robić. 

Jest to bardzo szeroko stosowane i myślę, że wiele osób próbuje budować te wewnętrzne platformy i postrzegają Kubernetes jako sposób na posiadanie prostej wewnętrznej infrastruktury. Po prostu tak nie jest; nie idzie wystarczająco daleko z wrażeniami użytkownika końcowego. Ludzie powinni używać chmury do czego jest najlepsze dla i pozwalając chmurom i ludziom takim jak my uruchomić Kubernetes jako sposób na uproszczenie tego, co we zrobić. 

Ale z pewnością jest punkt, w którym organizacja ma wystarczająco duży ślad, aby uzasadnić wewnętrzne prowadzenie czegoś takiego jak Kubernetes, prawda? Tak jak robiłeś na GitHub?

Jeśli masz do zarządzania wiele hostów — a mówimy o tysiącach maszyn, a to nie jest wiele firm — i potrzebujesz infrastruktury, która jest trochę bardziej samonaprawiająca się lub może wykorzystać dużą flotę maszyn, to pomoże ci to mieć elastyczność w obsłudze tych rzeczy. 

Myślę, że pytanie dla każdej firmy, bez względu na wybór techniczny, powinno brzmieć: Czy to się wyróżnia dla naszych klientów? Czy istnieje historia lub wymóg użytkownika końcowego, który został przez nas ulepszony dzięki zarządzaniu tą infrastrukturą i zarządzaniu nią? A jeśli odpowiedź brzmi Nie, to w ogóle nie powinieneś tego robić z żadną technologią.

Na przykład w zasadzie nikt teraz nie może uzasadnić prowadzenia własnego hostingu Git. To po prostu szaleństwo, aby nie wydawać śmiesznie małej ilości pieniędzy, aby GitHub lub GitLab zrobili to za Ciebie. To ustalony argument; nie ma żadnych zalet robienia tego samemu. Ponieważ serwer bezserwerowy i tylko technologia ogólnie staje się coraz lepsza, ta linia porusza się wszędzie i dla wszystkich. Po prostu nie zbudujesz wewnętrznego zespołu bazodanowego lub zespołu operacyjnego, który byłby lepszy niż u dostawców usług takich jak my. 

A nawet jeśli tak, to skąd użytkownicy o tym wiedzą? Co by to zrobił dla Twojej bazy użytkowników? Bardzo mało — w 99.9 procent przypadków nie dbają o twój stack technologiczny. Każda firma powinna po prostu robić rzeczy, które poruszają igłę dla własnych użytkowników i wykorzystywać jak najwięcej zarządzanej infrastruktury.

Bezpieczeństwo to problem związany z doświadczeniem użytkownika i jest bardzo fundamentalny. Trudno jest być bezpiecznym, jeśli utrudniasz użytkownikom robienie właściwych rzeczy.

Jak widzisz ewoluujące obawy dotyczące bezpieczeństwa i prywatności danych, szczególnie w przypadku dostawców SaaS?

Każdy dba o bezpieczeństwo. To coś, co musimy traktować bardzo poważnie jako firma, która przechowuje dane ludzi. Jednym z trendów, który widzę, jest to firmy dążą do uzyskania certyfikatów zgodności znacznie wcześniej niż kiedyś. Teraz musisz dostać Certyfikat SOC 2 prawie natychmiast, inaczej nie będziesz w stanie grać. (Jeśli chcesz trochę poczytać, Fly.io napisał: wpis na blogu na temat SOC 2 warto się tym zająć.)

Ogólnie rzecz biorąc, firmy są bardzo zainteresowane pewnymi możliwościami, które są teraz stawkami w tabeli, takimi jak uwierzytelnianie jednokrotnego logowania, rejestrowanie audytu i odpowiednie odwołalne tokeny dostępu.

Na przykład teraz, jeśli przypadkowo sprawdzisz poświadczenia bazy danych w publicznym repozytorium GitHub, natychmiast je unieważnimy, aby ludzie nie mogli uzyskać dostępu do Twojej bazy danych. To coś, co kiedyś się zdarzało — ludzie wpychali swoje dane uwierzytelniające AWS do repozytorium open source, a potem ich konto nagle jest wykorzystywane do wydobywania bitcoinów i mają dziesiątki tysięcy dolarów na rachunkach, albo ich dane są tam w internecie

Ostatecznie, moim gorącym zdaniem jest to, że bezpieczeństwo jest problemem związanym z doświadczeniem użytkownika i jest bardzo fundamentalne. Trudno jest być bezpiecznym, jeśli utrudniasz użytkownikom robienie właściwych rzeczy. Jeśli ustawisz zabezpieczenia, które nie są domyślne i są czymś, o czym ludzie muszą myśleć i konfigurować, jest bardziej prawdopodobne, że popełnią błędy. Na przykład nie możesz połączyć się z PlanetScale w sposób niezaszyfrowany — ty nie może. Ludzie chcą inaczej, ponieważ chcą być leniwi lub chcą robić rzeczy w określony sposób. Po prostu tego nie umożliwiamy. W rezultacie nikt nie może zepsuć i wysłać swoich danych w postaci zwykłego tekstu przez Internet. To znowu jest częścią doświadczenia użytkownika. 

Na każdą [usługę dostawcy chmury] — a jest ich setki na Amazon — konkuruje z nią pięć gorących młodych startupów. Bardzo trudno będzie dbać o tak wielu użytkowników i przypadki użycia oraz utrzymywać to skalowanie.

Wspomniałeś wcześniej o bezserwerowym. Jaka jest twoja robocza definicja bezserwerowego?

Opisuję to tak, że dobre produkty bezserwerowe powinny eksponować tylko to, co Ty absolutnie Potrzebujesz kontroli, aby załatwić sprawy. Jeśli przesłałeś plik do Dropbox, a oni zapytali Cię: „Na ilu serwerach chcesz, abyśmy to zachowali, aby zachować wysoką dostępność?” Powiesz: „Czy to nie jest to, za co płacę?” ty dla?" Czy to obietnica chmury? Chmura powinna być czymś więcej niż tylko dodawaniem procesorów wirtualnych i pamięci, ale w chmurze. 

Serverless mówi: „Jaka jest jednostka wartości dla użytkownik? Co oznacza użytkownik chcę zrobić?" I nie zmusza ich to do niczego więcej. Dla mnie jest to więc optymistyczny ruch, który zmierza w kierunku prostoty i lepszego projektowania produktów. 

Jak oceniasz obecnie relacje między Twoją firmą a dostawcami chmury? Czy „wrogowie” to uczciwy opis?

To interesujące, ponieważ w pewnym sensie konkurujemy, ale także znacznie częściej wykorzystujemy ich platformę. W przypadku klientów korzystających z naszej zarządzanej wersji chmurowej współpracujemy z przedstawicielami Amazon, aby ludzie nie odchodzili do Google; pozostają na Amazon i korzystają z naszego oprogramowania. Tak więc handlowcy wciąż mają dużo konsumpcji, dostajemy nasze ujęcie i to jest świetne. Myślę, że powoli będą się cofać i sprawić, by firmy takie jak my stały się doświadczeniem użytkownika końcowego. I ostatecznie wciąż wygrywają, ponieważ wciąż sprzedają serwery w coraz większych ilościach. 

Ale jesteśmy w tej interesującej fazie środkowej, w której nie są to tylko duże sklepy detaliczne. Nadal konkurują z nami niektórymi produktami, ale jest to coraz trudniejsze, ponieważ teraz o każdą z ich usług – a na Amazon są setki – konkuruje z nią pięć gorących młodych startupów. Bardzo trudno będzie dbać o tak wielu użytkowników i przypadki użycia oraz utrzymywać to skalowanie.

Jeśli jesteś typem menedżera, który nie próbuje cały czas wspinać się po szczeblach drabiny — ale po prostu robi to, co mówisz, że zamierzasz zrobić, i jesteś kolegialny, kiedy to robisz, i pomagasz ludziom wygrywać, i naciskasz ludzie do przodu — po prostu naturalnie trafiasz do większych pomieszczeń.

Niepowiązane: na początku nie byłeś dyrektorem generalnym PlanetScale. Jak doszło do przejścia z CPO na CEO?

Kiedy dołączyłem, firma działała trochę inaczej. Robiliśmy hosted Vitess, który jest starym produktem, który mieliśmy. Zdecydowałem, że chcę zbudować niesamowity produkt bazodanowy, którego sercem byłby Vitess, gdzie Vitess był podstawowym silnikiem, ale nie był produktem końcowym. Wyrzuciliśmy więc stary produkt i zbudowaliśmy nowy, który odniósł duży sukces. A potem zatrudniłem wielu ludzi z mojej poprzedniej firmy, GitHub, i ludzi, których dobrze znałem. 

W tamtym momencie dużą część firmy i kultury stanowili ludzie, którzy przybyli ze mną do pracy — aby znów razem pracować — więc podwójna zmiana kultury i produktu pojawiła się dzięki temu, co chciałem zrobić. Ostatnią logiczną rzeczą było dostosowanie wszystkiego do tej wizji. Dlatego zostałem CEO.

To było proste przejście, które zostało wykonane i odkurzone bardzo, bardzo szybko. To znaczy nasi założyciele są wspaniali. Założyli tę firmę, zbudowali firmę, a potem przekazali ją, jak wielu założycieli. Niektóre firmy powinny zrobić to wcześniej.

Dość szybko awansowałeś również po drabinie w GitHub, od DBA do wiceprezesa ds. inżynierii. Jaka jest twoja rada, aby pomyślnie przeprowadzić tego typu zmiany, a także zdecydować, czy przejście do zarządzania jest właściwe?

Przede wszystkim jeśli pracujesz w firmie, która wymaga zostania menedżerem, aby mieć jakikolwiek wpływ, to jesteś w złej firmie. Myślę, że wiele osób porzuca rolę indywidualnego współpracownika, aby przejść i zostać menedżerem tylko po to, aby pozostać w pokoju, co jest straszne. 

Moja rada to zostań menedżerem, jeśli zależy ci na ludziach i wynikach, które mogą osiągnąć wspaniali ludzie. Możesz posunąć się za daleko w drugą stronę, gdzie jesteś tylko menedżerem ludzi i nie przejmujesz się zbytnio pracą. Myślę, że ostatecznie chcesz, aby budowane były wspaniałe rzeczy, i robisz to poprzez wspaniałą kulturę i umacnianie ludzi. Jeśli więc zależy ci na tych rzeczach i potrafisz je zbudować, zostań menedżerem.

Bardzo mi na tym zależało. Dołączyłem do GitHub jako inżynier i miałem tam wpływ i bardzo mi się to podobało. Wiedziałem, że w celu skalowania, abyśmy mogli dalej robić świetną inżynierię, potrzebowaliśmy świetnego zarządzania. Chciałem zbudować wysokowydajną kulturę ze świetnymi inżynierami. Więc zacząłem to robić i mieliśmy wiele zmian. Firma rosła, ale ja po prostu bardzo konsekwentnie pracowałem z ludźmi, o których wiedziałem, że robią dobre rzeczy, i właśnie stamtąd wyrosłem. 

Zawsze jesteś proszony o zrobienie więcej. Jeśli jesteś typem menedżera, który nie próbuje cały czas wspinać się po szczeblach drabiny — ale po prostu robi to, co mówisz, że zamierzasz zrobić, i jesteś kolegialny, kiedy to robisz, i pomagasz ludziom wygrywać, i naciskasz ludzie do przodu — po prostu naturalnie trafiasz do większych pomieszczeń. To po prostu wydarzyło się przez pewien czas. I w końcu, tak, prowadziłem tam duży zespół jako wiceprezes, ponieważ zawsze robiłem dokładnie to, co było konieczne dla biznesu, i tkwiłem w nim, ciężko pracowałem i wzmacniałem ludzi. 

A najbardziej dumny jestem z tego, jak wiele osób przeszło z GitHub do PlanetScale, bo o tym wiedzieli. Wiesz co mam na myśli? Nie zrobili mieć do. To był dla mnie znak, że pokazałem, że mogę konsekwentnie robić to, co powiedziałem, że zrobię jako lider. Ludzie po to przyszli.

Na marginesie: bardzo często menedżerowie rujnują firmy. Napisaliśmy manifest zarządzania to określa, jak myślimy o tej roli.

Jeśli nie potrafisz pogodzić się z myślą, że twoje błędy zamieszają się w karierze ludzi i że ludzie naprawdę na tobie polegają, to [zarządzanie] nie jest dla ciebie. 

Jeśli jesteś IC, który chce przejść do zarządzania, jaki jest pierwszy krok?

Myślę, że musisz zacząć się uczyć socjologicznego myślenia o dynamice zespołu i ludzi wokół ciebie oraz o tym, jak możesz wpływać na to, jak ludzie pracują razem jako zespół. Stając się kierownik techniczny, na przykład, ma o wiele większą dynamikę społeczną niż tylko pisanie najlepszego kodu. Musisz pomyśleć o rzeczach, od których zależymy, ludziach, od których zależymy, i o tym, jak kształtujemy naszą organizację, aby odzwierciedlić pracę, którą zamierzamy wykonać — bez konieczności wnikania w myśli i uczucia ludzi i faktycznego zarządzania nimi . Więc dobrym sposobem jest spróbuj poprowadzić projekt, który ma dużo pracy międzyfunkcyjnej i zależnościi wymaga, aby ludzie dobrze ze sobą współpracowali, aby sprawdzić, czy potrafisz zainspirować ludzi do pracy w grupie. 

Jeśli potrafisz to zrobić z sukcesem, możesz zacząć uczyć się umiejętności potrzebnych do pracy z ludźmi i bycia ich menedżerem. Ponieważ to trudna rola; to rola niewoli. Ludzie oddają swoje kariery w twoje ręce i to jest coś, co musisz traktować bardzo poważnie. Jeśli nie potrafisz pogodzić się z myślą, że twoje błędy zamieszają się w karierze ludzi i że ludzie naprawdę na tobie polegają, to nie jest to dla ciebie. 

Jeśli myślisz, że możesz to zrobić i chcesz pomóc ludziom stać się lepszymi wersjami samych siebie, zakop się.

Opublikowano 2 sierpnia 2022 r