Прим. перев.: эта шуточная статья, которую по праву охарактеризовали как иллюстрацию «SEO-driven development», нашла очень большой отклик на Reddit и других ресурсах. Соглашаясь с актуальностью той истории, что пародируется автором оригинала, мы рады поделиться её переводом с русскоговорящим сообществом.
Сразу после своего основания в 2010 году $ИЗВЕСТНАЯ_КОМПАНИЯ вполне помещалась в $ГАРАЖЕ_БРАТАНА_ОСНОВАТЕЛЯ. С тех пор мы росли как на дрожжах, чему способствовали постоянные вливания средств венчурными капиталистами. Сегодня сотни миллионов ежедневно активных пользователей (DAUs) изо всех уголков мира пользуются нашими продуктами в мобильных приложениях и на сайте $famouscompany.com.
За это время мы уже несколько раз в панике чинили бэкенд, чтобы уменьшить свой технический долг (как правило, сразу после очередного масштабного сбоя) и наши серверы не навернулись. Имевшийся технологический стек верой и правдой служил нам все эти годы. Но со временем стало очевидно, что, переписав приложение «с нуля», мы сможем выжать из пользователей дополнительные 2 млрд долларов в год.
Поводы для перехода на новый стек
Как неоднократно упоминалось, исторически так сложилось, что бэкенд $ИЗВЕСТНОЙ_КОМПАНИИ был написан на $ЗАУРЯДНОМ_ЯЗЫКЕ и базировался на $ПРАКТИЧНОМ_OPEN_SOURCE-ФРЕЙМВОРКЕ. Чтобы удовлетворить имеющиеся потребности, мы разработали и выложили как Open Source-проект $ВЫБРАННЫЙ_ИНЖЕНЕРОМ_МИФОЛОГИЧЕСКИЙ_ПЕРСОНАЖ — высокодоступный, just-in-time компилятор для $ЗАУРЯДНОГО_ЯЗЫКА.
Но даже с получившимися суперскими доработками периодически наблюдались всплески в 99-м процентиле нашей статистики по задержкам. Они становились все более заметными по мере усилий выжать все возможное из приложения, чтобы справиться с ростом DAU. К счастью, всё наше ПО изначально разработано с учетом интроспекции, так что с помощью некоторых BPF-скриптов, скопированных с сайта Brendan Gregg, инструментов собственной разработки инженеры $ИЗВЕСТНОЙ_КОМПАНИИ смогли определить, что узкие места в производительности связаны со сборщиком мусора.
Сначала мы попробовали поиграться с настройками сборщика (смысл которых, как водится, абсолютно не понимали), но, к большому удивлению, это волшебным образом не решило актуальные проблемы. Тогда мы его просто отключили. Да, расход памяти слегка повысился, но механизм автоматического масштабирования в зависимости от запросов успешно справился с этой проблемой, как видно из графика ниже:
Неизбежный финал любой масштабируемой архитектуры: «Заведите больше инстансов».
В конечном итоге наше решение перейти на новый язык было вызвано сложностями с поиском специалистов, знающих $ЗАУРЯДНЫЙ_ЯЗЫК, что странно, поскольку его преподавали в десятках университетов во всех уголках США. Кроме того, наши публикации о $ПРАКТИЧНОМ_OPEN_SOURCE-ФРЕЙМВОРКЕ стали набирать меньше голосов на Reddit, и это усилило подозрения, что технологический стек устарел.
Переход на новый стек
Мы знали, что необходимо нечто, соответствующее масштабам $ИЗВЕСТНОЙ_КОМПАНИИ, и рассмотрели несколько перспективных альтернатив. Их строгий отбор проводился на основе следующих определяющих параметров:
- число абзацев в описании на сайте;
- частота появления на первой странице Hacker News.
Кроме того, мы завели таблицу ключевых характеристик языка (производительность, эффективность, сообщество, простота использования), которую сообща заполняли всем офисом.
Забавный факт
Оказалось, что наша таблица удовлетворяет жестким статистическим критериям абсолютной случайности, поэтому мы также использовали ее для криптографически стойкого генератора псевдослучайных чисел в приложении.
После тщательного рассмотрения было решено остановиться на $МОДНОМ_ЯЗЫКЕ и $РАСКРУЧЕННОЙ_ТЕХНОЛОГИИ. На это решение во многом повлияли результаты опроса разработчиков на сайте Stack Overflow, а также замечательное свойство $МОДНОГО_ЯЗЫКА — кроссплатформенность, позволившая переписать на нем все мобильные приложения. Переделать базовую инфраструктуру оказалось довольно просто: к счастью, у нас намного больше инженеров, чем мы когда-либо сможем загрузить работой; с другой стороны, мы понятия не имеем, что со всеми ними делать.
Итоговое решение было единственным верным: полностью заморозить работу над отчетами об ошибках и направить все усилия на $РАСКРУЧЕННУЮ_ТЕХНОЛОГИЮ. Сначала возникли определенные проблемы с адаптацией к некоторым странностям $МОДНОГО_ЯЗЫКА, а также мы обнаружили несколько багов в $РАСКРУЧЕННОЙ_ТЕХНОЛОГИИ, но в целом их мощные суперсовременные функции позволили устранить некоторые сложности, что досаждали в прошлом.
Развертывание изменений без простоя требовало внимательного подхода к планированию. Как всегда, на выручку пришла блестящая идея: мы на уровне кода отключили обновление страницы во время развертывания обновлений, заставляя пользователей гадать, работает наш сервис или нет. Ключевым моментом стало управление инкрементальным развертыванием: мы агрессивно тестировали код по методу А/В. Внутренние исследования показали, что периодическая демонстрация абсолютного нового интерфейса, а затем возвращение к старому при следующей загрузке страницы изрядно повышает вовлеченность пользователей. В итоге было принято решение реализовать эту систему (в ее основу легла статья на Medium про каких-то многоруких бандитов).
Теперь, когда переход состоялся и все клиенты активно пользуются новой версией приложения, можно уверенно заявить: наши усилия увенчались огромным успехом! Мы измерили результаты — они оказались воодушевляющими:
С переходом на новый стек значительно выросли все важные для нас метрики. Кроме того, мы отсеяли некоторые показатели, которые отныне не будут иметь значения: количество багов, фрустрация пользователей и затраты на обслуживание. Сегодня мы с воодушевлением заявляем об открытии части кода (которую можем позволить себе выложить в общий доступ) на нашей странице на GitHub! Сам по себе он бесполезен и полностью завязан на нашу инфраструктуру, но вы просто обязаны оценить внутренний порыв и поставить звезду!
Заключительные мысли
Принято считать, что задача с нуля переписать ПО сопряжена со множеством сложностей и подводных камней, но мы в $ИЗВЕСТНОЙ_КОМПАНИИ любим трудности и отважно их преодолеваем! В данном случае наше решение, очевидно, окупилось сполна. Эта публикация преимущественно посвящена изменениям в бэкенде, однако мы, как упоминалось ранее, используем $МОДНЫЙ_ЯЗЫК и в мобильных приложениях, поскольку ленимся у нас нет ресурсов писать приложения для каждой платформы.
К сожалению, эти изменения также означают, что мы больше не будем поддерживать сторонний API-доступ к нашим сервисам чтобы еще сильнее привязать пользователей. Мы знаем, что некоторые из пользователей с ограниченными физическими возможностями зависели от этих интерфейсов. Смеем вас заверить: мы в $ИЗВЕСТНОЙ_КОМПАНИИ всецело поддерживаем идею об адаптации сервисов для таких людей — конечно, если они не зависят от вспомогательных технологий, которые теперь не работают с нашими приложениями.
Надеемся, что вы воспримите историю нашей компании как некую непреложную истину и поделитесь ею со своим руководством, чтобы оно тоже рассмотрело возможность перепроектирования архитектуры (по нашему подобию). Впрочем, вы наверняка проигнорируете тот факт, что вы — это не мы: ведь у нас достаточно инженеров и ресурсов, чтобы делать всё что угодно. Это решение угробит ваш стартап, так что в обозримом будущем не ждем от вас публикаций об опыте работы с $РАСКРУЧЕННОЙ_ТЕХНОЛОГИЕЙ. Если вы не в состоянии повлиять на решения в компании, то все равно можете сослаться на наш опыт, когда в следующий раз возникнет спор о выборе подходящего языка.
У нас есть отличная новость для тех, кто читает эту статью, и кто увлечен $РАСКРУЧЕННОЙ_ТЕХНОЛОГИЕЙ так же, как и мы: нам нужны специалисты! Обязательно загляните на нашу страницу вакансий, где будет ноль позиций, связанных с $МОДНЫМ_ЯЗЫКОМ.
P.S. от переводчика
- «Больше разработчиков должны знать это о базах данных»;
- «Успех социального эксперимента с поддельным эксплойтом для nginx»;
- «Музыкальные пародии от SUSE про Kubernetes, Линуса Торвальдса и других».
Автор: Андрей Климентьев
