ScyllaDB спонсировала этот пост.
«Мне нравится поговорка: «У некоторых людей есть хорошие идеи. У некоторых идей есть люди». Когда ваша идея переживет вас, это успех». — Келси Хайтауэр
Карьера Келси Хайтауэр – прекрасный тому пример. Его идеи обрели собственную жизнь, выйдя далеко за рамки его работы в Puppet, CoreOS, до KubeCon и Google. И он продолжает увеличивать свое влияние с помощью своих фирменных выступлений без сценария, а также полноценной книги «Kubernetes Up and Running».
Мы были очень рады, что Хайтауэр присоединился к саммиту ScyllaDB Monster SCALE, чтобы поделиться своим опытом и советами по масштабному проектированию. И чтобы расширить его идеи среди тех, кто присоединился к нам для выступления в прямом эфире, мы запечатлели здесь некоторые из самых запоминающихся моментов и выводов.
Monster SCALE Summit 2026 пройдет 11–12 марта, в нем примут участие Antirez, создатель Redis; Камиль Фурнье, автор книги «Путь менеджера и разработка платформы»; Мартин Клеппманн, автор книги «Проектирование приложений с интенсивным использованием данных») и более 50 других. Мероприятие бесплатное и виртуальное; зарегистрируйтесь и присоединяйтесь к сообществу для оживленного общения.
Потерпите неудачу, прежде чем масштабироваться
Интервью с ведущим Тимом Купмансом началось с резкого предупреждения для участников конференции, посвященной масштабированию: не гонитесь за масштабированием только потому, что вы очарованы стратегиями и достижениями других в области масштабирования. Сначала вам нужно действительно испытать некоторую боль лично. Как выразился Хайтауэр:
«Многие люди приходят посмотреть выступление на конференции — я, вероятно, сам виноват в этом — а затем пытаются «делать масштабные вещи», прежде чем у них даже появится опыт того, что они делают. Еще в Puppet Labs многие люди писали сценарии оболочки с плохой обработкой ошибок. Все шло наперекосяк, когда условия были неидеальными. Затем они перешли к управлению конфигурацией, и те, кто прошел этот путь, могли понять компромиссы. Те, кто начинал непосредственно с Puppet, часто этого не делали».
«Убедитесь, что у вас есть причина, — сказал он. — Поэтому, прежде чем чрезмерно оптимизировать проблему, которая у вас, возможно, даже не существует, вам следует спросить: «Насколько все плохо на самом деле? Где показатели, доказывающие, что вам нужно более масштабируемое решение?» Иногда вы можете ничего не делать и просто ждать, пока масштабирование станет опцией по умолчанию».
В конечном счете, вам следует надеяться на «хорошую проблему», когда растущий спрос приведет к тому, что вы достигнете предела своих технологий, сказал он. Это намного лучше, чем иметь мало клиентов и переусердствовать в решении проблем, которых у вас нет.
Сделайте лучший выбор, какой только можете… на данный момент
Разговор перешел к тому, на какой уровень масштаба должны ориентироваться команды при первоначальном технологическом стеке и каждой последующей итерации. Стоит ли оптимизировать ситуацию для будущего состояния, которое еще не произошло? Будьте осторожны на случай, если рынок изменится?
«Если вы не уверены, что находитесь в правильном стеке… Я обещаю вам, что все изменится», — сказал Хайтауэр. «Сделайте лучший выбор, какой только можете, на данный момент. Вы можете потратить весь год на оптимизацию ради «самого лучшего», но это может оказаться не лучшим решением через 10 лет. Допустим, вы выбираете базу данных, идете ва-банк, изучаете лучшие практики. Но добавьте небольшую сноску в свой проектный документ: «Вот как мы бы это изменили». Оцените стоимость переключения. Если вы сделаете это, вы не застрянете в заблуждении о невозвратных издержках позже».
Вместо того чтобы пытаться предсказать будущее, подумайте о том, как не попасть в ловушку. Вы не хотите, чтобы зависимости или расширения ограничивали вашу возможность миграции, когда придет время выбрать лучший (или просто другой) путь.
«Изменения – это не провал», – подчеркнул он. «Планируйте это, не бойтесь этого».
По мнению Хайтауэра, решения по масштабированию должны начинаться на доске, а не в коде.
«Когда я работал в Google, мы проводили технические занятия с доской. Проведите линию — самое время. Сегодня мы здесь. Наша платформа позволяет нам это делать. Это хорошо или плохо?» Затем забегайте вперед: «Где мы хотим быть через два года?»
Он продолжил: «Обычно это определяется командами и потребностями клиентов. Вы не можете сделать все сразу. Поэтому запланируйте вехи — шесть месяцев, год и т. д. Вы можете сдвинуть дело с мертвой точки к моменту появления новых библиотек или инструментов. Если появляется что-то новое, что мгновенно продвинет вас на два года вперед, отлично. Наличие графика дает вам свободу без чувства вины за то, что вы не можете отправить все сегодня».
Вы действительно готовы к Боингу 747?
Продолжая тему Google, Купманс спросил: «Мне бы хотелось услышать о практических способах, с помощью которых Google позволяет избежать чрезмерного проектирования при масштабном проектировании». Чтобы проиллюстрировать, почему решения «масштаба Google» не всегда подходят всем остальным, Хайтауэр использовал запоминающуюся аналогию:
«Однажды мой клиент сказал: «Нам нужна локальная версия BigQuery». Я сказал: «Вы делаете?» Правда? Хорошо, сколько у тебя денег? И это была одна из тех компаний, у которых было много капитала, так что проблема была не в этом. Я сказал им: «Это все равно, что пойти в аэропорт, посмотреть в окно, увидеть новенький Боинг 747 и сказать авиакомпании, что вам нужен этот самолет». Даже если тебе позволят купить его, у тебя нет лицензии пилота, ты не знаешь, чем его заправить. Где ты собираешься его припарковать? Вы собираетесь гонять его по своему микрорайону, обезглавливая крыши домов соседей?» Некоторые вещи просто не предназначены для всех».
В конечном счете, является ли это чрезмерной инженерией или нет, зависит от целевого пользователя. Поймите, кто они, как они работают и какие инструменты используют, а затем стройте с учетом этого.
Хайтауэр также предостерег от отношения к «лучшим практикам» как к универсальным истинам: «Один из вопросов, который задает большинство клиентов: «Каковы лучшие практики?» Для меня это не обязательно лучшие практики. Они просто хотят знать, что делают все остальные. Я думаю, что это может быть еще одним анти-шаблоном в этой смеси, когда вас волнует только то, что делают все остальные, и вы не привносите необходимый контекст для хорошей рекомендации».
Как лидерам следует думать об инструментах разработки
«Сериализация инженерной культуры» (фраза Хайтауэра), как это сделал Google со своим монорепозиторием google3, позволяет тысячам новых инженеров легко присоединиться к команде и начать вносить свой вклад почти мгновенно. За время его работы в Google было интегрировано все — от gRPC до инструментов развертывания. Инженеры просто открывали браузер, добавляли код, и обзоры начинались автоматически.
Однако существует тонкая грань между сериализацией и подавлением. Хайтауэр считает, что запрещать инженерам даже устанавливать Python на свои ноутбуки, например, является излишним: «Это все равно, что сказать Пикассо, что он не может использовать свою любимую кисть».
Он продолжил: «Все работают по-разному. Будучи лидером, узнайте, какие инструменты люди на самом деле используют, и поощряйте совместное использование. Пусть инженеры покажут свои рабочие процессы — ярлыки, настройки и плагины, которые делают их продуктивными. Вот откуда берут начало креативность и скорость. Поделитесь нюансами. Большинство людей думают, что их трюки слишком малы, чтобы иметь значение, но это так. Я хочу видеть ваши точечные файлы! Вы вдохновите других».
Посмотрите полное выступление
Как заметил Хайтауэр: «У некоторых людей есть хорошие идеи. У некоторых идей есть люди». Его подход к масштабу — прагматичный, контекстно-ориентированный и человечный — показывает, почему некоторые идеи действительно переживают людей, которые их создали.
Полную версию выступления вы можете увидеть ниже.
Интересный факт: Это было действительно интервью без сценария, — настаивал Хайтауэр! Команда встретилась с ним в вестибюле отеля тем утром, немного поболтала за кофе, подготовила ракурсы… и внезапно Хайтауэр и Купманс начали трансляцию для 20 000 зрителей по всему миру.
ScyllaDB спроектирована для обеспечения предсказуемой производительности в любом масштабе. Его используют организации, которым требуется сверхнизкая задержка, даже при рабочих нагрузках, превышающих 1 млн операций в секунду. Наша уникальная архитектура использует возможности современной инфраструктуры, что приводит к меньшему количеству узлов, меньшему администрированию и меньшим затратам. Узнайте больше Последние новости от ScyllaDB ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одного эпизода. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Синтия Данлоп пишет о разработке и тестировании программного обеспечения гораздо дольше, чем ей хотелось бы признать. В настоящее время она является старшим директором по контент-стратегии в ScyllaDB. Узнайте больше от Синтии Данлоп
