company_banner

Почему мы в $ИЗВЕСТНОЙ_КОМПАНИИ перешли на $РАСКРУЧЕННУЮ_ТЕХНОЛОГИЮ

Автор оригинала: Saagar Jha
  • Перевод
Прим. перев.: эта шуточная статья, которую по праву охарактеризовали как иллюстрацию «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. от переводчика


Флант
DevOps-as-a-Service, Kubernetes, обслуживание 24×7

Комментарии 20

    +14
    We do what we must
    Because we can
      +1

      Do what you can and be what will be

        +34
        Так как увольнять специалистов по $ЗАУРЯДНЫЙ_ЯЗЫК увольнять дорого и жалко, а специалистов по @МОДНЫЙ_ЯЗЫК и $РАСКРУЧЕННАЯ_ТЕХНОЛОГИЯ нанимать еще дороже и дольше, то наш новый сайт на $МОДНЫЙ_ЯЗЫК написан спецами по $ЗАУРЯДНЫЙ_ЯЗЫК через жопу и мы нихера не понимаем что происходит
          –2

          Куча постоянно меняющихся «самых-самых» фреймворков нужна только работодателям для того, чтобы сбивать зарплатные ожидания кандидатов: «Так вы 5 лет кодили под Angular, а до этого 10 лет на PHP? А у нас, знаете ли, Vue.js — поэтому возьмём мы вас, максимум, мидлом»

            +1
            если только откликаться на вакансии вслепую
            0
            в точку, это именно то что происходило как минимум с первым ангуляром, когда все бросились со старых MVC и WebForms писать SPA, не потому что нужно, а потому что стало модно, в итоге фронт енд писался бэкэндерами, которые учили JavaScript и фронт энд прямо на ходу.
            Результат известен, во всех бедах был обвинен первый Angular, который якобы провоцировал писать говнокод, а не эти самые говнокодеры
              +7
              Естественно бекеновцы привыкли к нормальным языкам программирования, а тут им пришлось нетепизированной лапшой обматываться так, будто на неё можно делать приложения
            +4
            Требует редактуры в части они/мы, но в целом весьма забавно!
              +19
              После перехода на $МОДНЫЙ_ЯЗЫК и $РАСКРУЧЕННУЮ_ТЕХНОЛОГИЮ наши специалисты конечно же не смогли сразу осилить все их тонкости и нюансы, потому нам пришлось увеличить ресурсы наших серверов в 3 раза чтобы достичь прежней производительности. Но мы уже работаем над оптимизацией и рефакторингом нагенерируемого кода и в планах достигнем производительности $ЗАУРЯДНОГО_ЯЗЫКА через год, а затем даже обгоним его.
              P.S. Или найдем новый $МОДНЫЙ_ЯЗЫК и $РАСКРУЧЕННУЮ_ТЕХНОЛОГИЮ
                +1
                Хехе, норм.
                Интересно почитать (может даже кто-то из наших напишет) статью об изобретении $СВОЕГО_СОБСТВЕННОГО_ЭФФЕКТИВНОГО_РЕШЕНИЯ :)
                С одной стороны — велосипед, а с другой — реакт, кликхаус, тарантул, нжинкс.
                  0
                  Изобрести сложнее, больше компетенций нужно, чтобы решать проблемы, которых уже нет в других решениях. Если вы сможете написать свою БД, вы вряд ли будете выбирать БД по хайповости.
                  0
                  Я это сплагиачу! Я это обязательно буду использовать как основание, для топ менеджмента, о том, что технологический стэк нужно менять, и бабло восторжествует, независимо от уровня компетенции исполнителей.
                    +2
                    Программирование эти люди уже практически похоронили, теперь и за системными администраторами потихоньку приходят. Раньше ты одну ОС учил 10 лет, а теперь каждый год нужно по 10 новых не имеющих аналогов в мире тулз изучать. И все как одна — с громкими названиями, красивыми сайтами и обещаниями, что ну вот в этот раз наверняка.

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

                      Тем временем народ, который изначально сидел на Java, C++ и PHP чувствуют себя отлично

                        0
                        Потому что это всё немодно.
                      0
                      Да ладно. Что вы прикопались к эффективным менеджерам?!
                      Они работой заняты — бюджет осваивают.
                      <:o)
                        +2
                        Проблема в том, что они формируют рынок на самом деле. Про освоение бюджетов далеко не всегда так. Я видел как тот же самый Go начинал использоваться тем, где в нём по большому счёту особого смысла не было. Просто потому что он используется Google и позволил python-программистам легко въехать в hiload (на самом деле это было не так — сервис вышел очень слабый).

                        Для своего pet-проекта я сейчас использую Common Lisp, перед этим перепробовав множество вещей — от хайповых NodeJS, Dart и Elixir до узкоспециализированных Erlang и Racket. Остановился на Lisp-family не знаю почему. CL просто потому, что надоело делать патчи на базовые вещи в библиотеки для Racket. По сути — выкинул наработки на Racket (как до этого делал с другими языками) и начал сначала. Итог — начал использовать Woo (самый быстрый сервер, который я видел), освоил какую-то часть CL, проникся духом lisp-хакеров. Понравилось. Оглядываясь назад — да, всё это можно сделать на любом стеке, но мне удобнее Common Lisp.

                        А про модные стеки… есть нехорошая тенденция, которую можно проследить. Чаще всего популярными становятся примитивные инструменты с низким порогов вхождения и килотоннами денег затрат потом. Т.к. никто не пытается при выборе стека вот прям решить задачу, которая стоит. Так в своё время я принимал участие в проекте разработки мобильной версии сайта на Ember, который переписали на React в итоге. И знаете почему? Сверстал компоненты «эффективный тимлид» очень быстро и он работал быстрее. А вот после обвязки логикой… всё стало очень печально. Скорость работы была ± такая же, а вот архитектуры нормальной не было.
                          0
                          Любая смена ЯП/фреймворка/технологии и т.д. бесплатно не делается.
                          Для этого нужны ресурсы.
                          Вот у вас есть система, которая работает. Есть особо не просит. нагрузка стабилизировалась, т.к. расширения бизнеса растет очень медленно.
                          И тут у топ-топ менеджеров может возникнуть вопрос — «Зачем нам столько программистов, да и весь департамент?».
                          Чтобы «предупредить» такие вопросы, нужны «новые проекты». А т.к. новое придумать и сделать сложно, то начинают переделывать старое.
                          Ну а хайп и все остальное, это всего лишь «экономическое обоснование». ;-)
                        0
                        Ну так классика:
                        Но другая группа ... нашла ... фатальный недостаток – его писали не они!

                        Ничего не поменялось
                          +2
                          Сначала прочитал Hope Driven Development.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое