Генеральный директор PlanetScale о Cloud-Prem и восхождении по лестнице инженерных разработок

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

В этом интервью Ламберт обсуждает ряд тем, связанных с облачными моделями доставки программного обеспечения, в том числе то, как выглядит хороший бессерверный сервер, кто должен запускать Kubernetes, а также появление «cloud-prem» — модели развертывания, которая сочетает в себе сильные стороны on-line. Программное обеспечение премиум-класса и предложения SaaS. Он также делится своим опытом в качестве генерального директора, не являющегося учредителем, и советами о том, когда и как перейти от разработки к управлению.

---

БУДУЩЕЕ: Вы описали, что делает PlanetScale — по крайней мере, это не чисто SaaS-предложение — «облачные» вычисления. Как вы определяете этот термин?

СЭМ ЛАМБЕРТ: Облако-прем — это новая модель — по сути, облачное решение для локальной среды. Традиционно компаниям приходилось либо иметь на прем решение или облако решение, а совмещать оба варианта традиционно очень сложно. В GitHub у нас были проблемы с запуском github.com, а также с продажей GitHub Enterprise как локального решения. С облачным продуктом мы должны были иметь возможность постоянно продвигать и доставлять. Сокращение выпуска на основе этого было действительно сложной задачей, и построение архитектур для обоих означало, что мы не доставляли локальное решение так хорошо, как могли бы; это было просто очень трудно сделать. 

Когда мы пришли в PlanetScale, мы решили, что хотим быть только облачными, но, конечно, вы не можете просто сделать это с продуктом базы данных или продуктом, который имеет строгие требования соответствия. Таким образом, с помощью cloud-prem мы, по сути, развертываем плоскость данных нашего продукта в VPC управляется пользователем, где они используют нашу плоскость управления для его организации, а мы управляем им. По сути похоже, что вы просто используете обычный облачный продукт SaaS, но данные находятся в вашей учетной записи. Ваша группа безопасности может провести его аудит, и они чувствуют безопасность и доверие, поскольку оно находится в границах их инфраструктуры, без недостатков, связанных с необходимостью самостоятельно устанавливать исправления, выпускать и управлять локальным программным обеспечением.

Есть еще одно дополнительное преимущество: если вы являетесь крупным клиентом с отличной договорной ставкой с Amazon, например, вы все еще можете платить по этой ставке и сохранять свои выделенные расходы с Amazon внутри своей учетной записи.

Какой отпор вы получаете? Есть несколько заядлых SaaS и on-prem магазинов…

Мы можем предоставить вам чистый SaaS, где мы размещаем данные внутри нашей учетной записи, и людей это полностью устраивает. Настоящим противодействием является то, что люди просто хотят работать на месте. Но модель облачных премий действительно начинает находить отклик. У нас есть регулируемые компании, использующие продукт, потому что они видят двойную выгоду в хранении данных локально, чтобы обеспечить безопасность или соответствие требованиям, но также и в том, что им не нужно управлять ими. 

Вот почему эта модель настолько уникальна и актуальна во времени: потому что она решает проблему отсутствия компаний, не желающих работать на месте — и в основном это старая, мертвая модель — но все еще в основном отвечающая требованиям. это было бы на месте.

Но, да, вы все еще иногда встречаете сопротивление. Есть некоторые компании, которые просто не доверяют программному обеспечению SaaS, но облако быстро избавляет от этого. Например, вы не можете решать, когда и как Amazon обновит S3 и сделает S3 лучше, это просто происходит. Все дело в том, чтобы завоевать доверие многих клиентов, что вы лучшая компания для выполнения конкретной работы для них, и помочь им освоиться с этим. 

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

Разработчики могут быть довольно самоуверенными в отношении баз данных, которые они используют. Как облачная модель развертывания влияет на опыт разработчиков?

Это больше похоже на то, что модель развертывания устраняет блокировщики. Вы не можете обеспечить наилучшее взаимодействие с разработчиком, когда поставляете локальное программное обеспечение. Вы не можете постоянно улучшаться. Вы не можете управлять качеством, доступностью, временем безотказной работы — все эти вещи являются частью опыта. Если вы не управляете сервисом самостоятельно, очень сложно создать такой высокий уровень обслуживания. 

Основным препятствием для SaaS-only, конечно же, является необходимость для некоторых пользователей держать данные под своим контролем. Основным блокирующим фактором для локальной среды может быть масштабируемость. Таким образом, модель облачных премий больше похожа на механизм, позволяющий избавиться от этих блокировщиков и дать каждому лучшее из обоих миров.

Какова роль 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 написал запись в блоге на SOC 2 на это стоит обратить внимание)

И, в целом, компании очень заинтересованы в определенных возможностях, которые сейчас являются важными, такими как аутентификация единого входа, ведение журнала аудита и надлежащие токены доступа с возможностью отзыва.

Например, теперь, если вы случайно проверите свои учетные данные базы данных в общедоступном репозитории GitHub, мы немедленно аннулируем их, чтобы люди не могли получить доступ к вашей базе данных. Это то, что случалось раньше: люди загружали свои учетные данные AWS в репозиторий с открытым исходным кодом, а затем их учетная запись внезапно использовалась для майнинга биткойнов, и они получали счета на десятки тысяч долларов, или их данные там в интернете

В конечном счете, я считаю, что безопасность — это проблема взаимодействия с пользователем, и она очень фундаментальна. Трудно быть в безопасности, если вы мешаете своим пользователям делать правильные вещи. Если вы сделаете безопасность нестандартной, а людям придется обдумывать и настраивать ее, они с большей вероятностью совершат ошибки. Так, например, вы не можете подключиться к PlanetScale незашифрованным способом — вы не может. Люди хотят другого, потому что хотят быть ленивыми или хотят делать что-то определенным образом. Мы просто не делаем это возможным. В результате никто не может ошибиться и отправить свои данные в виде простого текста через Интернет. Это, опять же, часть пользовательского опыта. 

На каждую [услугу облачного провайдера] — а их на Amazon сотни — приходится пять горячих молодых стартапов, конкурирующих с ней. И будет очень сложно заботиться о таком количестве пользователей и вариантов использования и поддерживать масштабирование.

Вы уже упомянули бессерверные решения. Каково ваше рабочее определение без сервера?

Я описываю это так: хорошие бессерверные продукты должны раскрывать только то, что вы абсолютно необходимо контролировать, чтобы добиться цели. Если вы загрузили файл в Dropbox, и вас спросили: «Сколько серверов вы хотите, чтобы мы сохранили его, чтобы он оставался высокодоступным?» Вы бы сказали: «Разве это не то, что я плачу являетесь за?" Это обещание облака? Облако должно быть намного больше, чем просто добавление виртуальных ЦП и памяти, но в облаке. 

Serverless говорит: «Какова единица ценности для пользователь? Что это пользователь хочу сделать?" И это не заставляет их делать что-то большее. Так что для меня это оптимистичное движение, направленное на простоту и лучший дизайн продукта. 

Как бы вы сейчас оценили отношения между вашей компанией и облачными провайдерами? Является ли «заклятые враги» справедливым описанием?

Это интересно, потому что мы конкурируем в некоторых отношениях, но мы также приносим гораздо больше пользы их платформе. Для клиентов, использующих нашу управляемую облачную версию, мы работаем с представителями Amazon, чтобы люди не уходили в Google; они остаются на Amazon и используют наше программное обеспечение. Таким образом, представители по-прежнему получают массу потребления, мы получаем свою долю от всей этой сделки, и это здорово. Я думаю, что они постепенно будут двигаться назад, и такие компании, как мы, станут конечным пользователем. И в конечном счете они все еще выигрывают, потому что они все еще продают серверы во все больших и больших объемах. 

Но мы находимся в этой интересной промежуточной фазе, когда они не просто крупные розничные продавцы. Они по-прежнему конкурируют с нами по некоторым продуктам, но это становится намного сложнее, потому что теперь на каждую их услугу — а их на Amazon сотни — приходится пять горячих молодых стартапов. И будет очень сложно заботиться о таком количестве пользователей и вариантов использования и поддерживать масштабирование.

Если вы относитесь к тому типу менеджеров, которые не пытаются все время подниматься по карьерной лестнице, а просто делают то, что, как вы говорите, собираетесь делать, и вы ведете себя коллегиально, когда делаете это, и вы помогаете людям побеждать, и вы подталкиваете люди вперед — вы просто естественным образом попадаете в большие комнаты.

Независимо от этого: вы не были генеральным директором PlanetScale с самого начала. Как произошел ваш переход от CPO к CEO?

Когда я пришел, компания работала немного по-другому. Мы занимались хостингом Vitess, это старый продукт, который у нас был. Я решил, что хочу создать потрясающий продукт для баз данных, ядром которого будет Vitess, где Vitess будет базовым механизмом, но не конечным продуктом. Поэтому мы как бы выбросили старый продукт и создали новый, и он стал очень успешным. А потом я нанял много людей из моей предыдущей компании, GitHub, и людей, которых я хорошо знал. 

В тот момент большая часть компании и культуры состояла из людей, которые пришли работать со мной — чтобы снова работать вместе — так что благодаря тому, что я хотел сделать, произошла двойная смена культуры и продукта. Последней логикой было привести все в соответствие с этим видением. Именно поэтому я стал генеральным директором.

Это был простой переход, который был сделан очень и очень быстро. Я имею в виду, наши основатели великолепны. Они основали эту компанию, они построили компанию, а затем передали ее, как это делают многие основатели. Некоторые компании должны были сделать это раньше.

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

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

Мой совет: станьте менеджером, если вы глубоко заботитесь о людях и заботитесь о результатах, которых могут достичь великие люди. Вы можете зайти слишком далеко в другом направлении, где вы просто менеджер по персоналу, и вас не слишком заботит работа. Я думаю, что вы, в конечном счете, хотите, чтобы строились великие дела, и вы делаете это с помощью великой культуры и расширения прав и возможностей людей. Итак, если вы заботитесь об этих вещах и можете их построить, станьте менеджером.

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

Вас всегда просят сделать больше. Если вы относитесь к тому типу менеджеров, которые не пытаются все время подниматься по карьерной лестнице, а просто делают то, что, как вы говорите, собираетесь делать, и вы ведете себя коллегиально, когда делаете это, и вы помогаете людям побеждать, и вы подталкиваете люди вперед — вы просто естественным образом попадаете в большие комнаты. Это просто произошло через какое-то время. И затем, в конце концов, да, я руководил там большой командой в качестве вице-президента, потому что я всегда делал именно то, что было необходимо для бизнеса, и застрял в этом, много работал и наделял людей полномочиями. 

И чем я больше всего горжусь, так это тем, сколько людей перешло с GitHub на PlanetScale, потому что знали об этом. Если вы понимаете, о чем я? Они не иметь к. Для меня это было знаком того, что я продемонстрировал, что могу последовательно делать то, что обещал делать как лидер. За этим пришли люди.

На заметку: очень часто менеджеры разоряют компании. Мы написали манифест менеджмента это излагает, как мы относимся к этой роли.

Если вы не можете смириться с мыслью, что ваши ошибки повлияют на чью-то карьеру и что люди действительно зависят от вас, тогда [управление] не для вас. 

Если вы IC и хотите перейти в управление, каков первый шаг?

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

Если вы можете сделать это успешно, то вы можете начать изучать навыки, необходимые для того, чтобы действительно хорошо работать с людьми и быть их менеджером. Потому что это трудная роль; это роль рабства. Люди доверяют свою карьеру в ваши руки, и вы должны относиться к этому очень серьезно. Если вы не можете смириться с мыслью, что ваши ошибки повлияют на чью-то карьеру и что люди действительно зависят от вас, то это не для вас. 

Если вы думаете, что можете это сделать, и хотите помочь людям стать лучшими версиями самих себя, копайте.

Опубликовано: 2 августа, 2022