Технологический радар — диаграмма, на которой можно увидеть IT технологии и инструменты, которые мы используем в Lamoda, разделенные по областям применения и статусам. В 2018 году мы выкладывали здесь на Хабре подробную статью с расшифровкой актуального на тот момент техрадара. Что изменилось за два года, и зачем мы продолжаем регулярно обновлять радар — читайте в этой статье.
На самом деле, технологический радар — не просто картинка, которую мы можем показать на конференции. Хотя мы используем его и так тоже — он отлично подходит, чтобы составить быстрое впечатление об IT-составляющей нашей компании. В 2018 году мы были единственной компанией, которая использовала для «представления» такой инструмент визуализации — а сейчас на каждой конференции мы с радостью замечаем по 2-3 новых радара у различных компаний. Что сказать — это действительно очень наглядно и удобно!
Но, во-первых, техрадар существует не как одна страничка с инфографикой, а как журнал — мы регулярно обновляем его, и интереснее всего сравнивать радары за разные месяцы — можете попробовать сами вот здесь.
Во-вторых, на этой картинке не просто зафиксирована ситуация, которая как-то сама по себе сложилась. Изменения на техрадаре — это отражение деятельности Архитектурного комитета. В него входят руководители всех основных IT-направлений, и каждая новая технология, которую хотят использовать специалисты, сперва должна пройти проверку и получить одобрение у комитета. Мы делаем это для того, чтобы сдерживать «распухание» технологического стека. У нас много сложных и совершенно разных систем, так что стек и так весьма внушительный.
Конкретный специалист просто не может знать всё, что уже применяется где-то в компании. Часто оказывается, что инструмент, нужный ему для решения задачи, уже внедрен другой командой. Тогда ему конечно лучше пойти за экспертизой к коллегам, чем самому придумывать велосипед. При таком размере IT-подразделения информация уже не распространяется достаточно хорошо сама по себе, по этой причине мы внедрили практики обмена знаниями. Техрадар — одна из таких практик.
Я буду подробнее говорить про это дальше, но хочу подчеркнуть сразу: политика Архитектурного комитета направлена не на то, чтобы запрещать экспериментировать с новыми технологиями, а на то, чтобы эти эксперименты были более осознанными и управляемыми. Наши специалисты не оказываются зажаты в узкие рамки конкретных языков и инструментов на всё время работы в компании. Наоборот, благодаря понятному циклу внедрения новых (или хорошо забытых старых) технологий, если специалисту становится скучно с теми инструментами, с которыми он работает, мы практически всегда можем предложить ему принять участие в экспериментальном проекте. При этом ему не придётся полностью менять направление, и он сможет использовать накопленную экспертизу по той системе, над которой работал.
Итак, к чему же привела за два года такая политика? Подробно об используемых технологиях можно прочитать в предыдущей статье, здесь я расскажу об основных изменениях и каких-то интересных моментах.
Пройдем последовательно по четырем секторам радара, соответствующим основным IT-направлениям: Языки, Управление данными, Платформы и Инфраструктура, Фреймворки и Инструменты.
Но сначала напомню, что означают четыре слоя (статуса принятия технологии) на нашем радаре:
Как видите, по сравнению с 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, а весь наш огромный сервис доставки написан на нём, работает отлично, и мы пока не планируем это менять.
Практически все базы данных у нас по-прежнему реализованы на 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».
Вот здесь большие изменения произошли. Когда мы первоначально выбирали инструменты для деплоя, то остановились на связке Nomad + Consul. У нас был большой кредит доверия к компании Hashicorp, которая их выпускает, и в целом решение нас устраивало — пока не произошло несколько критических падений при апгрейдах оборудования. Устранение неполадок каждый раз требовало много времени и ресурсов, а компания понесла определенные убытки. Тогда мы перешли на ставший более популярным Kubernetes.
Возможно, новые версии Nomad работают более стабильно, но у нас после той истории, можно сказать, остался шрам — так что нет желания проверять. Тем более, что Kubernetes в связке с Docker нас полностью устраивают.
Среди инструментов для сбора метрик и алертинга по сервисам, которые крутятся в нашем кластере Kubernetes мы используем связку Icinga2 + Prometheus. Помимо этого, в качестве мониторинга состояния железа и виртуальных машин «пробуем» Zabbix, который в последний версиях умеет в prometheus-exporters. Для визуализации всех наших метрик мы активно используем Grafana и не планируем ее менять :)
Пожалуй, именно в этом сегменте новые «модные» технологии появляются чаще всего. И именно здесь мы видим, как работает техрадар и Архитектурный комитет, сдерживая неоправданную трату ресурсов на эксперименты на продакшне (которые в последствии привели бы к необходимости управлять разношерстной системой, написанной на множестве фреймворков, или унифицировать её — и то, и другое очень трудозатратно).
Например, мы пробовали разные фреймфорки для JavaScript, но старались экспериментировать на некритичных для бизнеса задачах. А главное, мы помнили, что это эксперимент, и в итоге мы хотим выбрать минимальный набор подходящих нам инструментов. Такая политика привела к тому, что React, например, так и не стал использоваться на проде. AngularJS и другие фреймворки ушли в статус «Hold», и в основном на фронтенде мы используем vue.js, который показал себя в этом «соревновании» лучше остальных.
Естественно, какие-то фреймворки уходят вместе с языками, для которых их использовали. Так например произошло у нас с Django, когда Go почти полностью вытеснил Python из веб-разработки.
В заключении статьи 2018 года мы сказали «в двух словах… мы пишем на GO, PHP, Java, JavaScript, держим базы на PostgreSQL, а деплоим на Docker и Kubernetes».
Такое обобщение верно и сейчас — единственное, в список основных языков однозначно ворвался Kotlin.
Получается, что выбранные нами два года назад основные инструменты и технологии оказались действительно подходящими под наши задачи и наш подход к разработке.
И благодаря работе Архитектурного комитета и, в частности, ведению техрадара, мы знаем, что конкретно эти технологии попали в наш стек не случайно. Они честно победили своих конкурентов в борьбе на экспериментальных проектах, и обоснованно используются на продакшне.
Конечно, на рынке будут появляться новые инструменты, которые подходят нам больше тех, что мы используем сейчас.
Мы рассчитываем, что в нашей системе «естественного отбора» технологий эти инструменты пройдут свой путь от «Assess» до «Adopt» и при необходимости заменят текущие.
На самом деле, технологический радар — не просто картинка, которую мы можем показать на конференции. Хотя мы используем его и так тоже — он отлично подходит, чтобы составить быстрое впечатление об IT-составляющей нашей компании. В 2018 году мы были единственной компанией, которая использовала для «представления» такой инструмент визуализации — а сейчас на каждой конференции мы с радостью замечаем по 2-3 новых радара у различных компаний. Что сказать — это действительно очень наглядно и удобно!
Но, во-первых, техрадар существует не как одна страничка с инфографикой, а как журнал — мы регулярно обновляем его, и интереснее всего сравнивать радары за разные месяцы — можете попробовать сами вот здесь.
Во-вторых, на этой картинке не просто зафиксирована ситуация, которая как-то сама по себе сложилась. Изменения на техрадаре — это отражение деятельности Архитектурного комитета. В него входят руководители всех основных IT-направлений, и каждая новая технология, которую хотят использовать специалисты, сперва должна пройти проверку и получить одобрение у комитета. Мы делаем это для того, чтобы сдерживать «распухание» технологического стека. У нас много сложных и совершенно разных систем, так что стек и так весьма внушительный.
Конкретный специалист просто не может знать всё, что уже применяется где-то в компании. Часто оказывается, что инструмент, нужный ему для решения задачи, уже внедрен другой командой. Тогда ему конечно лучше пойти за экспертизой к коллегам, чем самому придумывать велосипед. При таком размере IT-подразделения информация уже не распространяется достаточно хорошо сама по себе, по этой причине мы внедрили практики обмена знаниями. Техрадар — одна из таких практик.
Я буду подробнее говорить про это дальше, но хочу подчеркнуть сразу: политика Архитектурного комитета направлена не на то, чтобы запрещать экспериментировать с новыми технологиями, а на то, чтобы эти эксперименты были более осознанными и управляемыми. Наши специалисты не оказываются зажаты в узкие рамки конкретных языков и инструментов на всё время работы в компании. Наоборот, благодаря понятному циклу внедрения новых (или хорошо забытых старых) технологий, если специалисту становится скучно с теми инструментами, с которыми он работает, мы практически всегда можем предложить ему принять участие в экспериментальном проекте. При этом ему не придётся полностью менять направление, и он сможет использовать накопленную экспертизу по той системе, над которой работал.
Итак, к чему же привела за два года такая политика? Подробно об используемых технологиях можно прочитать в предыдущей статье, здесь я расскажу об основных изменениях и каких-то интересных моментах.
Пройдем последовательно по четырем секторам радара, соответствующим основным IT-направлениям: Языки, Управление данными, Платформы и Инфраструктура, Фреймворки и Инструменты.
Но сначала напомню, что означают четыре слоя (статуса принятия технологии) на нашем радаре:
- ADOPT — технологии и инструменты, которые внедрены и активно используются;
- TRIAL — технологии и инструменты, которые уже прошли этап тестирования и готовятся к тому, чтобы работать с продакшн (или даже уже работают там);
- ASSESS — пробные инструменты, которые в данный момент оцениваются и пока не влияют на продакшн. С их участием реализуются только тестовые проекты;
- HOLD — в этой категории у нас есть экспертиза, но упомянутые инструменты используются только при поддержке существующих систем — новые проекты на них не запускаются.
Языки
Как видите, по сравнению с 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, а весь наш огромный сервис доставки написан на нём, работает отлично, и мы пока не планируем это менять.
Управление данными
Практически все базы данных у нас по-прежнему реализованы на 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».
Платформы и инфраструктура
Вот здесь большие изменения произошли. Когда мы первоначально выбирали инструменты для деплоя, то остановились на связке Nomad + Consul. У нас был большой кредит доверия к компании Hashicorp, которая их выпускает, и в целом решение нас устраивало — пока не произошло несколько критических падений при апгрейдах оборудования. Устранение неполадок каждый раз требовало много времени и ресурсов, а компания понесла определенные убытки. Тогда мы перешли на ставший более популярным Kubernetes.
Возможно, новые версии Nomad работают более стабильно, но у нас после той истории, можно сказать, остался шрам — так что нет желания проверять. Тем более, что Kubernetes в связке с Docker нас полностью устраивают.
Среди инструментов для сбора метрик и алертинга по сервисам, которые крутятся в нашем кластере Kubernetes мы используем связку Icinga2 + Prometheus. Помимо этого, в качестве мониторинга состояния железа и виртуальных машин «пробуем» Zabbix, который в последний версиях умеет в prometheus-exporters. Для визуализации всех наших метрик мы активно используем Grafana и не планируем ее менять :)
Фреймворки и инструменты
Пожалуй, именно в этом сегменте новые «модные» технологии появляются чаще всего. И именно здесь мы видим, как работает техрадар и Архитектурный комитет, сдерживая неоправданную трату ресурсов на эксперименты на продакшне (которые в последствии привели бы к необходимости управлять разношерстной системой, написанной на множестве фреймворков, или унифицировать её — и то, и другое очень трудозатратно).
Например, мы пробовали разные фреймфорки для JavaScript, но старались экспериментировать на некритичных для бизнеса задачах. А главное, мы помнили, что это эксперимент, и в итоге мы хотим выбрать минимальный набор подходящих нам инструментов. Такая политика привела к тому, что React, например, так и не стал использоваться на проде. AngularJS и другие фреймворки ушли в статус «Hold», и в основном на фронтенде мы используем vue.js, который показал себя в этом «соревновании» лучше остальных.
Естественно, какие-то фреймворки уходят вместе с языками, для которых их использовали. Так например произошло у нас с Django, когда Go почти полностью вытеснил Python из веб-разработки.
Это нам подходит!
В заключении статьи 2018 года мы сказали «в двух словах… мы пишем на GO, PHP, Java, JavaScript, держим базы на PostgreSQL, а деплоим на Docker и Kubernetes».
Такое обобщение верно и сейчас — единственное, в список основных языков однозначно ворвался Kotlin.
Получается, что выбранные нами два года назад основные инструменты и технологии оказались действительно подходящими под наши задачи и наш подход к разработке.
И благодаря работе Архитектурного комитета и, в частности, ведению техрадара, мы знаем, что конкретно эти технологии попали в наш стек не случайно. Они честно победили своих конкурентов в борьбе на экспериментальных проектах, и обоснованно используются на продакшне.
Конечно, на рынке будут появляться новые инструменты, которые подходят нам больше тех, что мы используем сейчас.
Мы рассчитываем, что в нашей системе «естественного отбора» технологий эти инструменты пройдут свой путь от «Assess» до «Adopt» и при необходимости заменят текущие.
