В среде стартапов часто обсуждают «делание вещей, которые не масштабируются» в контексте маркетинга или продаж, но этот же принцип критически важен и в разработке программного обеспечения. Майкл Зайбель и Далтон Колдуэлл из Y Combinator на примерах Gmail, Facebook и Twitch разбирают, как «грязные» инженерные хаки и отказ от преждевременной оптимизации позволяют великим компаниям выживать на старте и находить соответствие продукта рынку (PMF).
🛠 Решение 90/10: как появился Gmail 0:52
Одним из главных идеологов «немасштабируемых» программных решений в Y Combinator является Пол Бакхайт (Paul Buchheit) — создатель Gmail и автор термина «решение 90/10» . По словам Майкла Зайбеля, суть этого подхода в вопросе: «Как получить 90% пользы, затратив всего 10% усилий?» . Основатели стартапов часто ненавидят этот совет, так как он заставляет их жертвовать чистотой кода ради скорости.
История Gmail — классический пример такого подхода:
- Использование чужого UI: Первый прототип Gmail Пол Бакхайт собрал, буквально «засунув» свою почту в интерфейс Google Groups (сервиса для рассылок и форумов) .
- Итеративная разработка: Бакхайт начал пользоваться этим UI сам и достраивал только те функции, которых ему не хватало в моменте. Например, он добавил возможность писать письма лишь после того, как несколько дней только читал их .
- Физический ремонт серверов: Когда Gmail (тогда еще внутренний продукт Google) упал, Бакхайт лично пошел в серверную с отверткой, чтобы заменить сбойный жесткий диск . По мнению спикеров, этот случай доказал Полу, насколько важным сервисом стала почта для пользователей.
- Инвайты как костыль: Знаменитая система приглашений в Gmail, которую многие считали гениальным маркетинговым ходом для создания дефицита, на самом деле была техническим ограничением . У команды просто не хватало серверных мощностей и места на дисках, чтобы открыть доступ всем желающим .
💾 Архитектура Facebook: одна школа — один сервер 5:37
Далтон Колдуэлл поделился воспоминаниями о временах, когда облачных сервисов вроде AWS не существовало, и основатели стартапов вручную устанавливали серверы в дата-центрах . Соседним арендатором его компании Imeem в дата-центре Санта-Клары был проект thefacebook.com .
Техническое устройство раннего Facebook, по наблюдениям Колдуэлла, было предельно простым и «немасштабируемым»:
- Физическая изоляция: Каждый сервер имел наклейку с названием университета (Stanford, Harvard и т.д.) .
- Копирование кода: Для каждой новой школы запускался отдельный экземпляр PHP, своя база данных MySQL и свой экземпляр Memcache .
- Отсутствие глобальной базы: Общей таблицы пользователей не существовало годами. Если вы учились в Гарварде, вы заходили на
harvard.thefacebook.com, и этот запрос шел в конкретную базу данных именно этого вуза .
Спикеры сошлись во мнении, что если бы Марк Цукерберг пытался сразу построить единую масштабируемую базу на миллионы пользователей, проект мог бы никогда не запуститься из-за несовершенства технологий того времени .
📉 Twitch и Justin.tv: борьба с пиками в 20x 10:12
Майкл Зайбель, будучи сооснователем Twitch (ранее Justin.tv), рассказал, что главной технической проблемой было не среднее потребление трафика, а непредсказуемые пики . Если обычные сайты проектируются под нагрузку в 2–4 раза выше средней, то на стриминговой платформе появление звезды могло вызвать мгновенный скачок в 20 раз .
Для решения этой проблемы использовались два «грязных» хака:
- Кнопка «Статический сайт»: Когда наплыв зрителей грозил обрушить серверы приложений, инженеры нажимали кнопку, которая превращала страницу трансляции в статичную . Все динамические функции (отображение имени пользователя, счетчик просмотров) отключались. Оставались только плеер и чат (работающий на другой системе), зато сайт выдерживал любой наплыв .
- Задержка трансляции ради масштабирования: Чтобы распределить поток видео на нужное количество серверов при внезапном старте эфира знаменитости, команда внедряла искусственную паузу . Стример думал, что он уже в эфире, но зрители видели видео только через несколько секунд, когда система успевала «раскопировать» поток по мощностям .
🎵 Imeem: видеохостинг без видео 15:08
Компания Далтона Колдуэлла Imeem столкнулась с проблемой воспроизведения музыки в браузере в эпоху до HTML5. В то время для этого требовались тяжелые плагины вроде RealPlayer, которые часто приводили к сбоям .
Решением стал «софтверный угон» технологий YouTube . Вместо того чтобы писать свой музыкальный плеер, команда Imeem:
- Взяла открытые инструменты для работы с Flash Video (FLV).
- Конвертировала все аудиофайлы в видеофайлы с нулевым битрейтом видеоряда (черный экран) .
- Использовала стандартные видеоплееры для прослушивания музыки .
Этот «грязный» трюк позволил сервису быстро запустить инновационный для того времени продукт, не тратя месяцы на разработку уникальной аудиотехнологии .
📡 Трюки с провайдерами и народный перевод 17:05
Когда Twitch столкнулся с нехваткой денег на оплату трафика (пиринг), Майкл Зайбель применил тактику агрессивного маркетинга против интернет-провайдеров . Один из шведских провайдеров отказывался от бесплатного обмена трафиком, что делало обслуживание пользователей из этой страны убыточным.
Команда Twitch внедрила блокировку: после 10 минут просмотра шведский пользователь видел заглушку с текстом: «Ваш провайдер отказывается сотрудничать с нами, поэтому мы не можем показывать вам видео. Если хотите пожаловаться — вот их телефон и почта» . По словам Зайбеля, это сработало на удивление быстро .
Еще одним примером экономии стала локализация. Вместо того чтобы платить агентствам «бесконечные деньги» за перевод интерфейса на 40 языков, Twitch заимствовал решение у Reddit . Они создали краудсорсинговую платформу, где сами пользователи-волонтеры бесплатно переводили строки интерфейса на свои языки .
🔍 Сломанный Google и рождение MapReduce 20:23
Далтон Колдуэлл пересказал историю (со ссылкой на очевидцев) о тяжелом периоде в жизни Google около 2001 года . В то время индекс интернета обновлялся не в реальном времени, а огромными пакетами (batch process). Скрипт переиндексации всей сети выполнялся около трех недель .
В какой-то момент процесс начал постоянно давать сбой. По утверждению Колдуэлла, в течение 3–4 месяцев поисковая выдача Google оставалась «замороженной»: пользователи видели старые результаты, а новые сайты не попадали в поиск .
Именно под этим экстремальным давлением (duress) инженеры Google разработали MapReduce — технологию распределенных вычислений, которая легла в основу Hadoop и всей современной работы с Big Data . Google не закрылся, пока все было сломано; они продолжали работать, пока не создали масштабируемое решение .
💡 Философия «включенного крана» 23:39
В завершение дискуссии спикеры предложили аналогию с водопроводными трубами в доме. Вместо того чтобы пытаться заранее угадать, какая труба потечет, и проверять их все, стартапу стоит «просто включить воду» . Только когда вода польется из щелей, станет ясно, какой участок требует ремонта .
Основные выводы выпуска:
- Масштабируемость — это привилегия: Сначала нужно создать то, что нужно людям, и только потом оптимизировать код .
- Не делайте «лучшее» врагом «хорошего»: Если у вас есть выбор между идеальной архитектурой и работающим костылем, выбирайте костыль, который даст результат сегодня .
- Учитесь у гигантов: Даже Apple начинала с ручной пайки плат Стива Возняка, что было абсолютно немасштабируемым процессом .
