Генеральний директор PlanetScale щодо Cloud-Prem і сходження по інженерних сходах

Сем Ламберт є генеральним директором PlanetScale, сумісного з MySQL постачальника безсерверних баз даних. До того, як приєднатися до PlanetScale (тоді він був директором із продуктів), він був віце-президентом із розробки в GitHub.

У цьому інтерв’ю Ламберт обговорює низку тем, пов’язаних із хмарними моделями доставки програмного забезпечення, включно з тим, як виглядає хороша безсерверна система, хто має запускати Kubernetes, а також появу «cloud-prem» — моделі розгортання, яка поєднує в собі сильні сторони на -прем програмне забезпечення та пропозиції SaaS. Він також ділиться своїм досвідом, коли став генеральним директором, який не є засновником, і своїми порадами щодо того, коли і як перейти від інженерної діяльності до управління.

---

МАЙБУТНЄ: Ви описали, що робить PlanetScale — принаймні його пропозиція не в чистому вигляді SaaS — «хмарні» обчислення. Як ви визначаєте цей термін?

СЕМ ЛАМБЕРТ: Cloud-prem це нова модель — хмарне рідне рішення для on-prem. Традиційно компанії повинні були або мати на-прем розчин або a хмара рішення, і подолати обидва традиційно дуже складно. У GitHub у нас була така напруга, пов’язана з запуском github.com і продажем GitHub Enterprise як локального рішення. З хмарним продуктом ми повинні були мати можливість безперервно просувати та доставляти. Розробка випуску на основі цього була справді складним завданням, і створення архітектури для обох означало, що ми не надаємо локальне рішення так добре, як могли б; це було просто дуже важко зробити. 

Коли ми прийшли до PlanetScale, ми вирішили, що хочемо бути лише хмарними, але, звичайно, ви не можете зробити це просто за допомогою продукту бази даних або продукту, який має суворі вимоги до відповідності. Отже, за допомогою cloud-prem ми фактично розгортаємо площину даних нашого продукту в VPC керується користувачем, де вони використовують нашу площину керування, щоб оркеструвати це, а ми ним керуємо. Це по суті таке враження, що ви просто використовуєте звичайний хмарний продукт SaaS, але дані зберігаються у вашому обліковому записі. Ваша команда безпеки може перевірити його, і вони відчувають безпеку та довіру, маючи його в межах своєї інфраструктури, без недоліків, пов’язаних із необхідністю самостійно виправляти, випускати та керувати локальним програмним забезпеченням.

Є ще одна додаткова перевага: наприклад, якщо ви є великим клієнтом і маєте чудову договірну ставку з Amazon, ви все ще платите за такою ставкою та зберігаєте свої зобов’язані витрати на Amazon у своєму обліковому записі.

Яке відштовхування ви отримуєте? Є кілька непохитних SaaS і локальних магазинів…

Ми можемо надати вам чистий SaaS, де ми розміщуємо дані всередині нашого облікового запису, і людей це цілком влаштовує. Справжня відмова полягає в тому, що люди просто хочуть on-prem. Але модель хмарної премії дійсно починає резонувати. У нас є регульовані компанії, які використовують цей продукт, тому що вони бачать подвійну вигоду від зберігання даних локально, щоб забезпечити безпеку чи відповідність, але також не потрібно керувати ними. 

Ось чому ця модель є надзвичайно чудовою та справжньою у часі: тому що вона вирішує проблему, коли компанії не хочуть працювати on-prem — і це, по суті, стара, мертва модель, — але все ще переважно відповідає вимогам що на премії буде.

Але, так, ти все одно іноді зустрічаєш опір. Є деякі компанії, які просто не довіряють програмному забезпеченню SaaS, але хмара швидко позбавляється цього. Мовляв, ви не можете вирішувати, коли або як Amazon оновить S3 і покращить S3, це просто відбувається. Уся справа в тому, щоб зміцнити довіру з багатьма клієнтами, що ви найкраща компанія для виконання конкретної роботи для них, і допомогти їм почуватися зручніше з цим. 

Ви не можете створити найкращий досвід для розробників, коли постачаєте локальне програмне забезпечення. Ви не можете постійно вдосконалюватися. Ви не можете керувати якістю, доступністю, часом безвідмовної роботи — усе це є частиною досвіду.

Розробники можуть бути досить впевненими щодо баз даних, які вони використовують. Як модель розгортання Cloud-Prem впливає на досвід розробників?

Це більше схоже на те, що модель розгортання знімає блокувальники. Ви не можете створити найкращий досвід для розробників, коли постачаєте локальне програмне забезпечення. Ви не можете постійно вдосконалюватися. Ви не можете керувати якістю, доступністю, часом безвідмовної роботи — усе це є частиною досвіду. Якщо ви не керуєте послугою самостійно, дуже важко створити такий високий рівень досвіду. 

Основним блокатором для SaaS-only, звичайно, є потреба деяких користувачів тримати дані під своїм контролем. Головним блокатором для on-prem може бути масштабованість. Таким чином, модель хмарної премії більше схожа на механізм, який дозволяє позбутися цих блокувальників і надати кожному найкраще з обох світів.

Яка роль Kubernetes у вашій моделі розгортання? І якою, на вашу думку, має бути роль Kubernetes загалом для чогось на кшталт хмарного розгортання?

Kubernetes дозволяє нам розгортати в клієнтських середовищах дуже стандартизований спосіб, і він виглядає так само, як кластер Kubernetes, який ми використовуємо всередині. Архітектурно ми також базуємося на Vitess, який працює на Kubernetes і розроблений на Borg, попереднику Kubernetes у Google. Отже, за походженням, це дуже самовідновлюється. Якщо ви втрачаєте стручки або втрачаєте інфраструктуру, вона значною мірою відновлюється; відновлення після збоїв — це не те, що вам потрібно розглядати вручну.

У нашій моделі користувачам не потрібно запускати кластери Kubernetes, які ми розгортаємо. Ми не використовуємо модель розгортання на існуючому кластері Kubernetes, яку роблять деякі локальні постачальники, щоб спростити роботу. Чесно кажучи, я сумніваюся, чи легше це.

Більшості людей не потрібно запускати Kubernetes. Це чудовий сервер для постачальників інфраструктури, але Я не думаю, що це обов’язково правильний механізм розгортання для більшості компаній. Я думаю, що багато людей пішли цим шляхом і не виявили користі від цього мало або взагалі не мали жодної користі.

Якщо ви завантажили файл у Dropbox, і вас запитали: «На скількох серверах ви хочете, щоб ми залишили його, щоб він залишався високодоступним?» Ви б сказали: «Хіба це не те, що я плачу ви для?»

Чи є рівень масштабу, коли це починає мати сенс, на вашу думку? Або конкретний випадок використання, як-от керування внутрішньою командою платформи?

Якщо ви робите те, що робимо ми, де ви хочете спростити інфраструктуру та мати щось таке гнучке, як Kubernetes, тоді це чудово. Але цей рівень гнучкості настільки відкритий, що якщо ви просто створюєте, скажімо, компанію електронної комерції, яка намагається розмістити веб-сайт, вам не потрібен Kubernetes у серверній частині для цього. 

Це дуже широко поширене, і я думаю, що багато людей намагаються створити ці внутрішні платформи, і вони бачать Kubernetes як спосіб мати просту внутрішню інфраструктуру. Це просто не так; це недостатньо залежить від досвіду кінцевого користувача. Люди повинні використовувати хмару для чого це найкраще для, і дозволити хмарам і таким людям, як ми, запускати Kubernetes як спосіб спростити те, we робити. 

Але, звичайно, є момент, коли організація має достатньо великий слід, щоб виправдати внутрішню роботу чогось на зразок Kubernetes, чи не так? Як ви робили в GitHub?

Якщо у вас є багато хостів, якими потрібно керувати — а ми говоримо про тисячі машин, а це не так багато компаній — і вам потрібна інфраструктура, яка має трохи більше самовідновлення або може використовувати великий парк машин, це допоможе вам мати гнучкість для вирішення цих речей. 

Я думаю, що питання для кожної компанії, незалежно від того, який технічний вибір, має бути таким: Чи відрізняє це наших клієнтів? Чи існує історія або вимога кінцевого користувача, яка покращується завдяки запуску та управлінню цією інфраструктурою? І якщо відповідь є немає, то ви взагалі не повинні робити це за допомогою будь-якої техніки.

Мовляв, ніхто зараз не може виправдати використання власного хостингу Git. Це просто божевілля – не витрачати таку смішну суму грошей, щоб GitHub або GitLab зробили це за вас. Це вирішена суперечка; немає ніякої переваги робити це самостійно. У міру того як безсерверні та просто технології загалом стають кращими, ця лінія поширюється всюди для всіх. Ви просто не збираєтеся створювати внутрішню групу баз даних або групу операцій, яка буде кращою, ніж у постачальників послуг, таких як ми. 

І навіть якби ви це знали, як би користувачі дізналися? Що це дасть для вашої бази користувачів? Дуже мало — у 99.9 відсотках випадків вони не піклуються про ваш стек технологій. Кожна компанія повинна майже лише робити те, що рухає голку для своїх власних користувачів, і використовувати якомога більше керованої інфраструктури.

Безпека — це проблема взаємодії з користувачем, і вона дуже фундаментальна. Важко бути в безпеці, якщо ви змушуєте своїх користувачів робити правильні речі.

Як ви бачите розвиток проблем безпеки та конфіденційності даних, особливо для провайдерів SaaS?

Кожен дбає про безпеку. Це те, до чого ми повинні дуже серйозно ставитися як компанія, яка розміщує дані людей. Я бачу одну тенденцію компанії йдуть на отримання сертифікатів відповідності набагато раніше, ніж раніше. Тепер ви повинні отримати Сертифікація SOC 2 майже відразу, інакше ви не зможете грати. (Якщо ви хочете добре почитати, Fly.io написав a публікація в блозі на SOC 2 це варто розглянути.)

І, загалом, компанії дуже зацікавлені в певних можливостях, які зараз є основними, такими як автентифікація єдиного входу, журнал аудиту та належні токени доступу, які можна відкликати.

Наприклад, тепер, якщо ви випадково перевірите облікові дані своєї бази даних у загальнодоступному репозиторії GitHub, ми негайно відкликаємо їх, щоб люди не могли отримати доступ до вашої бази даних. Раніше це траплялося — люди надсилали свої облікові дані AWS у сховище з відкритим кодом, а потім їхні облікові записи раптово використовували для майнінгу біткойнів, і вони накопичували рахунки на десятки тисяч доларів, або їхні дані там в Інтернеті

Зрештою, я вважаю, що безпека — це проблема взаємодії з користувачем, і вона дуже фундаментальна. Важко бути в безпеці, якщо ви змушуєте своїх користувачів робити правильні речі. Якщо ви робите безпеку не типовою, а тим, про що люди повинні думати та налаштовувати, вони, швидше за все, припустяться помилок. Так, наприклад, ви не можете підключитися до PlanetScale незашифрованим способом — ви не може. Люди хочуть, щоб було інакше, тому що вони хочуть бути ледачими або хочуть робити речі певним чином. Ми просто не робимо це можливим. Результатом є те, що ніхто не може зіпсуватись і надіслати свої дані у вигляді звичайного тексту через Інтернет. Це, знову ж таки, частина досвіду користувача. 

На кожну [хмарну послугу провайдера] — а їх сотні на Amazon — конкурують п’ять гарячих молодих стартапів. Стане дуже важко піклуватися про таку кількість користувачів і варіантів використання та підтримувати масштабування.

Ви згадали раніше про безсерверну систему. Яке ваше робоче визначення безсерверної системи?

Я описую це так: хороші безсерверні продукти повинні показувати лише те, що ви абсолютно потрібно контролювати, щоб виконувати завдання. Якщо ви завантажили файл у Dropbox, і вас запитали: «На скількох серверах ви хочете, щоб ми залишили його, щоб він залишався високодоступним?» Ви б сказали: «Хіба це не те, що я плачу ви для?» Це обіцянка хмари? Хмара має бути набагато більше, ніж просто додавання vCPU та пам’яті, але в хмарі. 

Serverless каже: «Яка одиниця значення для користувач? Що означає користувач хочеш зробити?» І це не змушує їх робити щось більше, ніж це. Отже, для мене це оптимістичний рух, спрямований на простоту та кращий дизайн продукту. 

Як би ви зараз оцінили відносини між вашою компанією та хмарними провайдерами? Чи справедливий опис слова «вороги»?

Це цікаво, тому що ми в деякому роді конкуруємо, але ми також значно більше використовуємо їхню платформу. Для клієнтів, які використовують нашу керовану хмарну версію, ми співпрацюємо з представниками Amazon, щоб люди не йшли, щоб перейти до Google; вони залишаються на Amazon і використовують наше програмне забезпечення. Таким чином, представники все ще отримують багато споживання, ми розуміємо всю цю угоду, і це чудово. Я думаю, що вони повільно рухатимуться назад, і такі компанії, як ми, стануть кінцевим користувачем. І зрештою вони все ще виграють, тому що вони все ще продають сервери у все більших і більших обсягах. 

Але ми перебуваємо на цьому цікавому середньому етапі, коли вони не просто великі роздрібні торговці. Вони все ще конкурують з нами з певними продуктами, але це стає набагато важче, тому що зараз на кожен їхній сервіс — а їх сотні на Amazon — конкурують п’ять гарячих молодих стартапів. І буде дуже важко піклуватися про таку кількість користувачів і варіантів використання та підтримувати масштабування.

Якщо ви той тип менеджера, який не намагається весь час підніматися по сходах, а просто виконує те, що ви обіцяєте робити, і ви колегіальні, коли це робите, і ви допомагаєте людям перемагати і просувати люди вперед — ви просто природно потрапляєте у більші кімнати.

Не пов’язано: ви спочатку не були генеральним директором PlanetScale. Як відбулася ваша зміна з CPO на CEO?

Коли я приєднався, компанія робила речі трохи інакше. Ми робили розміщений Vitess, який є старим продуктом, який у нас був. Я вирішив, що хочу створити дивовижний продукт бази даних, основою якого є Vitess, де Vitess був базовим механізмом, але не був кінцевим продуктом. Тому ми якось відкинули старий продукт і створили новий, і він став дуже успішним. А потім я найняв багато людей із моєї попередньої компанії, GitHub, і людей, яких я добре знав. 

На той момент більшість компанії та культури становили люди, які прийшли працювати зі мною — щоб знову працювати разом — тому подвійна зміна культури та продукту відбулася через те, що я хотів робити. Останньою логічною річчю було узгодити все під це бачення. Тому я став генеральним директором.

Це був простий перехід, який було зроблено та стерто дуже швидко. Я маю на увазі, що наші засновники чудові. Вони створили цю компанію, вони побудували компанію, а потім передали її, як це роблять багато засновників. Деякі компанії повинні були зробити це раніше.

Ви також досить швидко просунулися вгору в GitHub від DBA до віце-президента з інженерії. Що б ви порадили, щоб успішно здійснити такий тип переходів, а також вирішити, чи є правильним перехід до керівництва?

Перш за все, якщо ви працюєте в компанії, яка вимагає стати менеджером, щоб мати будь-який вплив, тоді ви не в тій компанії. Я думаю, що багато людей залишають роль індивідуального учасника, щоб піти стати менеджером, просто щоб залишитися в кімнаті, що жахливо. 

Моя порада - Станьте менеджером, якщо ви глибоко дбаєте про людей і дбаєте про результати, яких можуть досягти великі люди. Ви можете зайти занадто далеко в іншу сторону, коли ви просто менеджер з роботи з людьми і вас не дуже хвилює робота. Я думаю, що ви, зрештою, хочете бачити, як будуються великі речі, і ви досягаєте цього через чудову культуру та розширення можливостей людей. Отже, якщо ви дбаєте про ці речі і можете їх створити, станьте менеджером.

Я дійсно піклувався про ці речі. Я приєднався до GitHub як інженер, і я мав там вплив, і мені це сподобалося. І я знав, що для масштабування, для того, щоб ми продовжували робити чудову інженерну роботу, нам потрібен чудовий менеджмент. Я хотів побудувати високоефективну культуру з чудовими інженерами. Тож я почав це робити, і у нас відбулося багато змін. Компанія зростала, але я просто дуже послідовно працював з людьми, які, як я знав, роблять хороші речі, і просто виріс звідти. 

Вас завжди просять зробити більше. Якщо ви той тип менеджера, який не намагається весь час підніматися по сходах, а просто виконує те, що ви обіцяєте робити, і ви колегіальні, коли це робите, і ви допомагаєте людям перемагати і просувати люди вперед — ви просто природно потрапляєте у більші кімнати. Це просто сталося протягом певного періоду часу. І врешті-решт, так, я керував там великою командою як віце-президент, тому що я просто завжди робив саме те, що було необхідно для бізнесу, і застряг у цьому, наполегливо працював і надавав людям повноваження. 

І найбільше я пишаюся тим, скільки людей перейшли з GitHub на PlanetScale, тому що вони це знали. Ти знаєш, що я маю на увазі? Вони цього не зробили мати до. Для мене це було знаком того, що я показав, що можу постійно виконувати те, що я обіцяв робити як лідер. Люди прийшли за цим.

До речі: дуже часто керівники руйнують компанії. Ми написали а маніфест управління це викладає, як ми ставимося до цієї ролі.

Якщо ви не можете впоратися з ідеєю, що ваші помилки заважатимуть кар’єрі людей і що люди справді залежать від вас, тоді [менеджмент] не для вас. 

Якщо ви IC, який планує перейти на керівну посаду, який перший крок?

Я думаю, що вам слід почати соціологічно мислити про динаміку команди та людей навколо вас, а також про те, як ви можете впливати на те, як люди працюють разом як команда. Ставши a технічний керівник, наприклад, має набагато більше соціальної динаміки, ніж просто написання найкращого коду. Ви повинні думати про те, від чого ми залежимо, про людей, від яких ми залежимо, і про те, як ми формуємо нашу організацію, щоб вона відображала роботу, яку ми збираємося виконувати — без необхідності вникати в думки та почуття людей і фактично керувати ними . Отже, хороший спосіб - це спробуйте очолити проект, який має багато міжфункціональної роботи та залежностей, і вимагає, щоб люди добре працювали разом, щоб побачити, чи є у вас здатність надихати людей виконувати свою роботу групою. 

Якщо вам вдасться це зробити, ви зможете почати освоювати навички, необхідні для того, щоб справді добре працювати з людьми та бути їхнім менеджером. Тому що це важка роль; це роль рабства. Люди віддають свою кар’єру у ваші руки, і це те, до чого ви повинні ставитися дуже серйозно. Якщо ви не можете впоратися з думкою, що ваші помилки можуть зіпсувати кар’єри людей і що люди справді залежать від вас, тоді це не для вас. 

Якщо ви думаєте, що можете це зробити, і хочете допомогти людям стати кращими версіями самих себе, копайте.

Опубліковано 2 серпня 2022 р