Технорадар Lamoda 2020: что изменилось за два года

    Технологический радар — диаграмма, на которой можно увидеть IT технологии и инструменты, которые мы используем в Lamoda, разделенные по областям применения и статусам. В 2018 году мы выкладывали здесь на Хабре подробную статью с расшифровкой актуального на тот момент техрадара. Что изменилось за два года, и зачем мы продолжаем регулярно обновлять радар — читайте в этой статье.

    image

    На самом деле, технологический радар — не просто картинка, которую мы можем показать на конференции. Хотя мы используем его и так тоже — он отлично подходит, чтобы составить быстрое впечатление об IT-составляющей нашей компании. В 2018 году мы были единственной компанией, которая использовала для «представления» такой инструмент визуализации — а сейчас на каждой конференции мы с радостью замечаем по 2-3 новых радара у различных компаний. Что сказать — это действительно очень наглядно и удобно!

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

    Во-вторых, на этой картинке не просто зафиксирована ситуация, которая как-то сама по себе сложилась. Изменения на техрадаре — это отражение деятельности Архитектурного комитета. В него входят руководители всех основных IT-направлений, и каждая новая технология, которую хотят использовать специалисты, сперва должна пройти проверку и получить одобрение у комитета. Мы делаем это для того, чтобы сдерживать «распухание» технологического стека. У нас много сложных и совершенно разных систем, так что стек и так весьма внушительный.

    Конкретный специалист просто не может знать всё, что уже применяется где-то в компании. Часто оказывается, что инструмент, нужный ему для решения задачи, уже внедрен другой командой. Тогда ему конечно лучше пойти за экспертизой к коллегам, чем самому придумывать велосипед. При таком размере IT-подразделения информация уже не распространяется достаточно хорошо сама по себе, по этой причине мы внедрили практики обмена знаниями. Техрадар — одна из таких практик.

    Я буду подробнее говорить про это дальше, но хочу подчеркнуть сразу: политика Архитектурного комитета направлена не на то, чтобы запрещать экспериментировать с новыми технологиями, а на то, чтобы эти эксперименты были более осознанными и управляемыми. Наши специалисты не оказываются зажаты в узкие рамки конкретных языков и инструментов на всё время работы в компании. Наоборот, благодаря понятному циклу внедрения новых (или хорошо забытых старых) технологий, если специалисту становится скучно с теми инструментами, с которыми он работает, мы практически всегда можем предложить ему принять участие в экспериментальном проекте. При этом ему не придётся полностью менять направление, и он сможет использовать накопленную экспертизу по той системе, над которой работал.

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

    Пройдем последовательно по четырем секторам радара, соответствующим основным IT-направлениям: Языки, Управление данными, Платформы и Инфраструктура, Фреймворки и Инструменты.

    Но сначала напомню, что означают четыре слоя (статуса принятия технологии) на нашем радаре:

    • ADOPT — технологии и инструменты, которые внедрены и активно используются;
    • TRIAL — технологии и инструменты, которые уже прошли этап тестирования и готовятся к тому, чтобы работать с продакшн (или даже уже работают там);
    • ASSESS — пробные инструменты, которые в данный момент оцениваются и пока не влияют на продакшн. С их участием реализуются только тестовые проекты;
    • HOLD — в этой категории у нас есть экспертиза, но упомянутые инструменты используются только при поддержке существующих систем — новые проекты на них не запускаются.

    Языки



    image

    Как видите, по сравнению с 2018 годом точек в этом секторе стало меньше. Прямо сейчас у нас нет никаких языков в статусе «Assess» или «Trial». Почему так получилось? Для каждой задачи у нас уже есть язык, который нас устраивает. Конечно, мы следим за развитием области и знаем интересные и перспективные языки, которые не используются сейчас в Lamoda, например Rust, — но по своим возможностям они являются по сути дублирующими для тех, на которых написаны наши системы. Собственно, одна из целей ведения радара как раз в том, чтобы внедрение новых технологий происходило осознанно и с четким пониманием, какие плюсы нам это принесёт — а не просто потому, что язык модный и о нем все говорят.

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

    Именно так у нас произошло с Go. Когда мы начали активно развивать микросервисную архитектуру, то поняли, что Go для решения многих задач подходит лучше, чем PHP, на котором мы привыкли писать. Да, потребовалось приложить некоторые усилия, чтобы всей командой перейти на него (подробнее мы писали об этом тут). Но в результате очень выросла скорость работы приложений, да и по другим параметрам язык оказался удобен. За два года его стало у нас гораздо больше, в частности он практически полностью вытеснил Python из веб-разработки (но, конечно, Python остался в Data Science и других местах, где необходимо работать с большими массивами данных — в таких задачах он однозначно лидер).

    На радаре 2018 года видно, что мы «пробуем» Kotlin, но в 2020 мы уверенно присваиваем ему статус «Adopt». Больше двух лет назад мы решили перевести часть Android-разработки на Kotlin — язык казался очень перспективным, а наше мобильное приложение только развивалось и мы могли позволить себе эксперимент. Сейчас мы однозначно рады, что приняли такое решение. Не только все наши приложения под Android написаны на этом языке, но также часть бэкенда — пока что это эксперимент, но мы возлагаем на него большие надежды. Помимо других очевидных достоинств, Kotlin очень универсальный язык — а это значит, что на нем можно писать разные части систем, и передача экспертизы между командами сильно упрощается. И находить новых специалистов на рынке тоже становится проще.

    Также по сравнению с 2018 годом из «Trial» в «Adopt» переместился TypeScript.
    Он сильно расширяет возможности JavaScript, а весь наш огромный сервис доставки написан на нём, работает отлично, и мы пока не планируем это менять.

    Управление данными


    image

    Практически все базы данных у нас по-прежнему реализованы на PostgreSQL (также мы используем MongoDB, а вот MySQL окончательно перевели в статус «Hold»).

    Но за прошедшие два года у нас появились и новые технологии. В настоящий момент мы пилотируем использование СУБД Greenplum для задач развития нашей платформы данных. В нашем арсенале есть Oracle и Vertica — прекрасные базы, но мы ищем способы удешевить стоимость владения инфраструктурой, поэтому рассматриваем Opensource решения. Возможно, это будет не замена, а дополнение — время покажет.

    Мы решили заменить Tableau на Microsoft Power BI как средство создания BI дашбордов, и уже завершили эту миграцию. Мы посчитали, что хотим дать доступ к дашбордам всем желающим, и в Power BI это выходит дешевле, так как на просмотр отчетов покупать лицензии не нужно.

    Также мы внедрили Oracle APEX в качестве создания Web интерфейсов для ведения ручных справочников в хранилище данных. Ранее для этого использовались XLS-файлы, загружаемые с сетевого диска. Oracle APEX позволил нам сделать удобный интерфейс для бизнес-пользователей, теперь они могут самостоятельно обновлять данные в удобном Web приложении.

    На радаре изменений в этом месте нет, но стоит отметить еще более глубокое проникновение Apache Airflow в процессы создания платформы данных. Сейчас это основной оркестратор задач обработки данных, он пришел у нас на замену Luigi.

    Интересно произошло с RabbitMQ — в свое время мы внедрили его, но он не всем нас устраивал, и мы даже думали совсем от него отказаться. Но потом пришли новые специалисты в команду администрирования, и оказалось, что RabbitMQ хорош, мы просто не умели его готовить. После того, как мы перешли с FreeBSD на Linux, RabbitMQ уверенно находится в статусе «Adopt».

    Платформы и инфраструктура


    image

    Вот здесь большие изменения произошли. Когда мы первоначально выбирали инструменты для деплоя, то остановились на связке Nomad + Consul. У нас был большой кредит доверия к компании Hashicorp, которая их выпускает, и в целом решение нас устраивало — пока не произошло несколько критических падений при апгрейдах оборудования. Устранение неполадок каждый раз требовало много времени и ресурсов, а компания понесла определенные убытки. Тогда мы перешли на ставший более популярным Kubernetes.

    Возможно, новые версии Nomad работают более стабильно, но у нас после той истории, можно сказать, остался шрам — так что нет желания проверять. Тем более, что Kubernetes в связке с Docker нас полностью устраивают.

    Среди инструментов для сбора метрик и алертинга по сервисам, которые крутятся в нашем кластере Kubernetes мы используем связку Icinga2 + Prometheus. Помимо этого, в качестве мониторинга состояния железа и виртуальных машин «пробуем» Zabbix, который в последний версиях умеет в prometheus-exporters. Для визуализации всех наших метрик мы активно используем Grafana и не планируем ее менять :)

    Фреймворки и инструменты


    image
    Пожалуй, именно в этом сегменте новые «модные» технологии появляются чаще всего. И именно здесь мы видим, как работает техрадар и Архитектурный комитет, сдерживая неоправданную трату ресурсов на эксперименты на продакшне (которые в последствии привели бы к необходимости управлять разношерстной системой, написанной на множестве фреймворков, или унифицировать её — и то, и другое очень трудозатратно).

    image Например, мы пробовали разные фреймфорки для JavaScript, но старались экспериментировать на некритичных для бизнеса задачах. А главное, мы помнили, что это эксперимент, и в итоге мы хотим выбрать минимальный набор подходящих нам инструментов. Такая политика привела к тому, что React, например, так и не стал использоваться на проде. AngularJS и другие фреймворки ушли в статус «Hold», и в основном на фронтенде мы используем vue.js, который показал себя в этом «соревновании» лучше остальных.

    Естественно, какие-то фреймворки уходят вместе с языками, для которых их использовали. Так например произошло у нас с Django, когда Go почти полностью вытеснил Python из веб-разработки.

    Это нам подходит!


    В заключении статьи 2018 года мы сказали «в двух словах… мы пишем на GO, PHP, Java, JavaScript, держим базы на PostgreSQL, а деплоим на Docker и Kubernetes».
    Такое обобщение верно и сейчас — единственное, в список основных языков однозначно ворвался Kotlin.

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

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

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

    Мы рассчитываем, что в нашей системе «естественного отбора» технологий эти инструменты пройдут свой путь от «Assess» до «Adopt» и при необходимости заменят текущие.
    Lamoda
    Russian Fashion Tech

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

      0
      Почему у вас Spark в управлении данными, а не во фреймворках?
      Spark вы используете активно, но Scala у вас в hold. Пишите на python или java?
        +1
        both!

        В смысле спарк конечно scala и питон. Фундаментально новые вещи на спарке пишутся на питоне. То что scala в hold вовсе не означает что на этом языке вообще нет новых коммитов, но область его применения уже.

        На радаре есть и склад, и управление данными и просто расчёты, спарк это больше про данные чем про фреймворки (кажется даже официальный тэглайн это что они «analytics engine», но такого раздела на радаре нет :)
          –1
          Почему мигрировали с luigi на airflow? И насколько гладко прошло все? Какие видите преимущества?
            0
            Нельзя сказать что мы прям мигирировали с luigi, он был не так сильно в инфраструктуре и хотя и использовался, делал это постольку-поскольку. Один из очевидных минусов это то что в luigi было сложнее перезапускать блок зафейленных задач за какой-то промежуток времени в прошлом из-за того что щедулер не является частью системы (ну и то что вроде бы (тут уж не уверен) какое-то время ходили слухи что luigi уже не поддерживается и не развивается и вообще там всё ещё тянется второй питон — вроде бы это всё не подтвердилось и сейчас с проектом всё хорошо). К тому же luigi-комьюинити сильно меньше и общее развитие проекта было под вопросом.

            Вообще, astronomer отличный выпуск подкаста с автором luigi делали, советую послушать если вас интересуют детали soundcloud.com/the-airflow-podcast/episode-4-competitors

            А про то, почему и как мы используем airflow есть в нашей другой статье: habr.com/ru/company/lamoda/blog/518620
              0
              какое-то время ходили слухи что luigi уже не поддерживается и не развивается

              Т.е. лучше доверится слухам, чем заглянуть в github проекта?
                0
                :) Ваша буквальность восхищает! Нет, не только по слухам. Мы ещё составили расклад по картам Таро и так как это был январь то ещё и святочный расклад у той самой светской ведьмы.

                Конечно же (и в моём комменте сообщении это, имхо, считывается) по гитхабу это видно: и поинт про «не подтвердились», и, что важнее, поинт про комьюнити. Если вам удобнее читать список буллетов, у того же астрономер есть небольшая статья на эту тему: www.astronomer.io/guides/airflow-vs-luigi
        0
        Даже roadrunner успели попользовать. С ним всё плохо?
          +1
          Roadrunner у нас в качестве эксперимента, в 1 системе на фреймворке Slim. По характеру, приложение — это большое количество довольно простых API, работающих с базой.

          Самый главный вопрос, конечно, есть ли увеличение производительности. Достовернее всего было бы сравнить одно и то же приложение на roadrunner и php-fpm, но нам это пока только предстоит. Если грубо и быстро сравнить время ответа этого с сервиса с похожим приложением на php-fpm, то у rr 95-ая персентиль довольно ровно лежит в районе 0.090s, когда как у php-fpm приложения, колеблется в около 0.230s с скачками вверх. Звучит хорошо, но лучше, конечно, сравнивать сравнимое, мало ли почему так.

          Из плюсов использования, например, из коробки prometheus-endpoint есть с пачкой метрик о прожорливости и вообще жизнедеятельности сервиса roadrunner.dev/docs/beep-beep-metrics

          Из минусов, нельзя использовать stdout для логов, он нужен самому roadrunner для сборки response, приходится изворачиваться github.com/spiral/roadrunner/issues/208, ещё и внутренний механизм логирования не очень-то конфигурируется. Обещают в 2.0 переделать. Приходится дополнительно настраивать dev-режим, он отличается от привычного php-разработчику и поэтому не всем нравится. Ещё на этапе стабилизации смутно помню были какие-то нюансы с передачей правильных header'ов для json.

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

            github.com/gotzmann/comet

            Работает без Nginx / RoadRunner и в разы быстрее (бенчмарки в репозитории есть).
          0
          А чем гугл клауд не подошел? И для чего Azure, AWS используете?
            0
            Гугл клауд вполне себе подошел, мы там сделали отличный полугодовой пилот qa/dev окружения (для понимания масштабов это более сотни жирных инстансов), но по определенным причинам (спасибо ковид) были вынуждены вернуться обратно в онпрем.
            В Azure у нас dev окружение нашей ERP MS Dynamics AX.
            В AWS у нас есть кусочек прода — сервис, не обеспечивающий сбор персданных, и не сильно завязанный на latency между основным цодом.

            Вообще вопрос клауд стратегии — это важная для нас тема.
            Нельзя просто так взять и переехать в клауд (с) — думаю если бы в России был представлен хоть один из большой тройки — было бы все куда проще.
            Нас волную такие вопросы как:
            1. обработка и хранение при сборе персданных на территории РФ — это сложно обеспечить когда в силу специфики работы компонентов нашей платформы мы не можем просто выделить один сервис, отвечающий за сбор ПдН и оставить его в России.
            2. latency — мы бьемся за каждую миллисекунду при обмене нашей сотни микросервисов, и к фрагментации по клаудам и онпрем мы пока не сильно готовы — это вызов для нас.
            3. гравитация данных — сейчас наше ядро сети пропускает через себя более 120 гбит/сек — кусочки систем между клаудами могут стоить дороже по трафику, чем по compute ресурсам.
            4. утилизация нашего онпрем — мы сейчас очень зрелы в нашем онпрем датацентре. миграция в клауд для ее экономической эффективности должна занять не менее срока жизненного цикла последней партии серверов.
            0
            Почему в сторону cloud.yandex.ru не смотрите?
              0
              Для некоторого бизнеса uptime очень важен, для Lamoda — критически важен.
              Сравните SLA Yandex.Cloud и AWS
              yandex.ru/legal/cloud_sla_compute
              aws.amazon.com/ru/compute/sla

              Текущий SLI Lamoda (аптайм онлайн магазина, кнопки «купить») — 99.95% (это 4 часа в год)
              Бизнес не готов добавить еще столько же или больше просто за счет переезда в клауд.

              Моя мечта — когда российский клауд сравнится по качеству и по доступности с мировыми. Точно не в этом или следующем году, имхо. Но я верю.

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

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