Не гонимся за инновациями и смотрим на бизнес-метрики: как в FAVBET Tech выбирают стек и технологии

В FAVBET Tech не верят в идеальные технологии и не влюбляются в хайповые фреймворки, а смотрят: сколько будет стоить поддержка, найдутся ли специалисты и что произойдет, если изменятся правила игры. Все можно изменить, но нужно знать, как и зачем вы выбрали определенную технологию.

О том, какие решения выбирают в компании, почему решили добавить в стек Java (а не Go) и какие преимущества дает Erlang, рассказывает СТО FAVBET Tech Андрей Черныш.

Что в FAVBET Tech понимают под стеком и каким он является сейчас

Когда мы говорим о технологическом стеке, имеем в виду не просто язык программирования. Это целый набор компонентов: от языков и фреймворков до инфраструктуры, хостинга, CI/CD, мониторинга. Достаточно сложная конструкция, которая охватывает и уровень продукта, и уровень операционной поддержки.

На фронтенде у нас все довольно классически: TypeScript и React. В мобайле – нативная разработка: Kotlin для Android, Swift для iOS. Также много экспериментируем с Flutter для кроссплатформенности.

С бэкендом ситуация интереснее. Мы начинали с PHP и Node.js, но с ростом продукта появились новые вызовы, прежде всего нагрузка. Так в стек вошел Erlang, потому что это язык, который отлично работает с высоким параллелизмом и устойчивостью к сбоям.

Сейчас добавляем еще один язык – Java. Мы растем, задач больше, и нужно масштабироваться не только в продуктах, но и в команде. На рынке много специалистов по Java, она понятная, стабильная и способна решать весь спектр наших задач.

Андрей Черныш

CTO Favbet Tech

Инфраструктурный стек построен вокруг Kubernetes как основной платформы оркестрации, с GitOps-подходом на базе ArgoCD и Helm для управления деплойментами. Для мониторинга и observability мы активно используем Grafana Stack, который дает полную видимость системы. Для асинхронной обработки событий используются Kafka и RabbitMQ. Вся инфраструктура описывается через IaC (Infrastructure as Code) и полностью автоматизирована, что позволяет нам быстро масштабировать сервисы и безопасно разворачивать новые среды.

Этот стек не появился одномоментно, мы выстраивали его постепенно под наши задачи. В частности, смотрели на:

1. экспертизу внутри команды;
2. способность выдерживать высокую нагрузку;
3. скорость разработки без ущерба для качества;
4. простоту поддержки и масштабирования команд;
5. инфраструктурную интегрированность.

Мы постоянно пересматриваем свой стек. На это работают ежемесячные технические митинги, демо, технические гильдии. Мы следим за обновлениями инструментов, анализируем новые возможности и, если видим, что что-то стало обузой, заменяем это. Так, например, вместо Elasticsearch мы постепенно перешли на Grafana Stack: меньше затрат, лучшая интеграция с инфраструктурой, проще масштабирование.

Как выбираем технологию для новых сервисов в рамках стека

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

Например, есть команда, которая отвечает за Core-сервисы, в частности, регистрацию и логин пользователей. Если нам нужно добавить новую функцию, скажем, вход через соцсети, ее, вероятнее всего, будет реализовывать та же команда. И, скорее всего, она использует тот же язык, что и для основного сервиса. Это логично: команда уже понимает архитектуру, владеет кодом, знает все нюансы бизнес-логики.

Но есть и другие сценарии. Бывает, команда перегружена. Она могла бы реализовать фичу, но через месяц. Бизнес не может ждать – растет time-to-market, теряются возможности. В таких случаях мы начинаем искать варианты: кто из других команд свободен, какие языки они используют, подойдет ли их экспертиза под эту задачу.

Чтобы избегать ситуаций, когда решение приходится принимать в режиме «пожара», мы планируем заранее. Строим годовые роадмапы, даже если прогнозы пока общие. Они позволяют увидеть, где могут возникнуть пики нагрузки, и заранее найти ресурсы или понять, что часть функционала стоит передать другим командам или реализовать на другом языке.

Иногда это даже повод сменить технологию. У нас были кейсы, когда сервис исторически был написан на Erlang, но новый функционал требовал значительных изменений. Мы смотрели на задачу, на команду, на перспективу и принимали решение переписать сервис на Java. Это немного большие инвестиции на старте, но с точки зрения ROI (Return on Investment) выгоднее. Так мы снимаем нагрузку с команды Erlang, уменьшаем количество сервисов на этом языке и развиваем стек, который проще масштабировать.

Когда стандартного стека недостаточно: как мы принимаем новые технологические решения

В нашей компании работают два подхода – сверху вниз и снизу вверх. Это означает, что идеи могут подавать как архитекторы и бизнес, так и любой разработчик в команде.

Первая линия, к которой он может обратиться – это техлид. Обычно предложения точечные, как, например, в 99% случаев, если у PHP-разработчика есть необходимость написать часть функциональности на другом языке (потому что PHP не предоставляет для этого нужных инструментов), это будет Go.

Андрей Черныш

CTO Favbet Tech

Мы делали это уже неоднократно, поэтому считаем TCO (Total Cost of Ownership – полная стоимость разработки, тестирования, поддержки и так далее) и, если цифра нас устраивает, соглашаемся.
Если речь идет о чем-то более глубоком, как, например, внедрение новой технологии на постоянной основе, мы делаем более детальное исследование – независимо от того, было ли это предложение сверху или снизу.

К обсуждению привлекаются архитекторы, техлиды, DevOps, инфраструктурная команда, DevSecOps, продуктовая команда и юристы – в зависимости от контекста.

Контрольные вопросы, которые мы исследуем:

1. Решает ли эта технология нашу задачу лучше, чем то, что у нас уже есть?
2. Сможем ли мы быстро найти или вырастить команду под нее?
3. Насколько хорошо она интегрируется с нашей CI/CD-инфраструктурой?
4. Удобно ли будет ее поддерживать в продакшене?
5. Какой уровень поддержки, сообщества, обновлений?

Также обращаем внимание на сигналы, которые говорят о риске: если у технологии проблемы с поддержкой, сложная лицензия или нет пути обновления – мы ее не рассматриваем.

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

Прежде чем ее выбрать, мы провели маркетинговый анализ: посмотрели, сколько разработчиков есть на рынке для разных языков, какая среди них конкуренция. В частности, сравнили Java и Go и увидели, что со знанием Go на Djinni 40 активных кандидатов, а с Java – более 700. Это сильно повлияло на выбор.

Также мы сделали технический ресерч. Сравнивали фреймворки (Spring, Quarkus), виртуальные машины (JVM, GraalVM), смотрели на cost-efficiency и метрики производительности. Затем мы выбрали лучшую конфигурацию, написали MVP, запустили его параллельно со старым сервисом и разделили трафик.

Мы снимали все ключевые показатели – скорость, стабильность, потребление ресурсов. Сейчас, когда с помощью исследований подтвердили, что новое решение действительно лучше, можем двигаться дальше и начинать постепенное масштабирование.

Адаптация команды к новым технологиям

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

Иногда это означает, что кто-то в команде меняет направление. Например, один из наших Go-разработчиков завершил проект, и мы предложили ему перейти в новую Java-команду. Разработчик согласился, влился в новую команду и продолжает работу уже в другом стеке.

Мы считаем, что переход между языками – это нормальная часть развития инженера. Поэтому создаем для этого условия:

• у нас есть технические гильдии, где люди из разных команд обмениваются опытом;
• мы проводим внутренние воркшопы;
• фиксируем технические решения в документации (например, через ADR);
• предоставляем доступ к учебным ресурсам – и для новичков, и для тех, кто хочет углубиться.

Это позволяет людям не «застревать» в одном стеке, а компании масштабироваться без боли.

Как эффективно выбирать стек

Универсального идеального стека не существует. У каждой компании свои цели, команда и скорость роста. Кроме того, в выборе технологии всегда есть фактор неопределенности. Как, например, Unity – хороший вариант для инди-разработки игр, который резко стал неподходящим, когда в 2023 компания ввела дополнительные комиссии.

Тем не менее, это не значит, что планировать не нужно. Нужно понимать, где вы сейчас и где хотите быть через пять лет. Например: планируете ли вы быстрый exit или создаете платформу, которая должна масштабироваться годами? Видите ли вы себя локальным сервисом или хотите выходить на новые рынки?

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

Цели компании напрямую влияют на выбор технологий:

• Если вы запускаете AI-продукт, логично брать Python, а не Java.
• Если делаете ecommerce – WordPress даст вам быстрый старт.
• Если же планируете выходить на большие нагрузки, стоит смотреть в сторону Erlang, Rust, Java, Scala, Kotlin, .NET.

Хуже всего, когда технология не соответствует задаче (например, тяжелый фреймворк для простого сервиса). Но стоит помнить: то, что поможет на старте, со временем может начать тормозить.

Представим, что вы делаете стартап и можете использовать готовый фреймворк, написанный на Clojure: он даст вам 80% нужной функциональности из коробки. Но Clojure – очень нишевая технология, которой владеют очень мало специалистов. Будет ли выбор Clojure ошибкой? Сложно сказать: ведь стартап быстро запустится и получит шанс занять рынок. Поэтому важно закладывать гибкость в выборе и иногда идти на осознанный компромисс. А также закладывать точку пересмотра: когда «будущие вы» оцените, работает ли еще выбор.

Напоследок вот топ-5 советов компаниям, которые хотят построить прозрачный процесс выбора технологий и в целом принятия техрешений:

1. Привлекайте людей, которые потом это будут реализовывать.
2. Давайте место для PoC и технических экспериментов.
3. Фиксируйте, что и почему выбрали, даже если потом измените.
4. Формализуйте техническое решение – создайте простую, но понятную структуру технического обоснования.
5. Проверяйте решения через призму бизнес-метрик.