У FAVBET Tech не вірять в ідеальні технології та не закохуються в хайпові фреймворки, а дивляться скільки коштуватиме підтримка, чи знайдуться фахівці і що станеться, якщо зміняться правила гри. Усе можна змінити, але потрібно знати, як і навіщо ви вибрали певну технологію.
Про те, які рішення вибирають у компанії, чому вирішили додати до стека Java (а не Go) та які переваги дає Erlang, розповідає СТО FAVBET Tech Андрій Черниш.
Зміст
Що у FAVBET Tech розуміють під стеком і який він у них зараз
Коли ми говоримо про технологічний стек, маємо на увазі не просто мову програмування. Це цілий набір компонентів: від мов і фреймворків до інфраструктури, хостингу, CI/CD, моніторингу. Досить складна конструкція, що охоплює і рівень продукту, і рівень операційної підтримки.
На фронтенді в нас усе доволі класично: TypeScript і React. У мобайлі – нативна розробка: Kotlin для Android, Swift для iOS. Також багато експериментуємо з Flutter для кросплатформності.
З бекендом ситуація цікавіша. Ми починали з PHP та Node.js, але зі зростанням продукту з’явились нові виклики, насамперед навантаження. Так у стек увійшов Erlang, бо це мова, яка чудово працює з високим паралелізмом і стійкістю до збоїв.
Зараз додаємо ще одну мову – Java. Ми зростаємо, задач більше, і потрібно масштабуватись не лише у продуктах, а й у команді. На ринку багато фахівців із Java, вона зрозуміла, стабільна і здатна вирішувати увесь спектр наших задач.
Інфраструктурний стек побудований навколо Kubernetes як основної платформи оркестрації, з GitOps-підходом на базі ArgoCD і Helm для управління деплойментами. Для моніторингу та observability ми активно використовуємо Grafana Stack, що дає повну видимість системи. Для асинхронної обробки подій використовуються Kafka та RabbitMQ. Уся інфраструктура описується через IaC (Infrastructure as Code) та повністю автоматизована, що дозволяє нам швидко масштабувати сервіси та безпечно розгортати нові середовища.
Цей стек не з’явився одномоментно, ми вибудовували його поступово під наші задачі. Зокрема, дивилися на:
- експертизу всередині команди;
- здатність витримувати високе навантаження;
- швидкість розробки без шкоди для якості;
- простоту підтримки й масштабування команд;
- інфраструктурну інтегрованість.
Ми постійно переглядаємо свій стек. На це працюють щомісячні технічні мітинги, демо, технічні гільдії. Ми стежимо за оновленнями інструментів, аналізуємо нові можливості і, якщо бачимо, що щось стало тягарем, замінюємо це. Так, наприклад, замість Elasticsearch ми поступово перейшли на Grafana Stack: менше витрат, краща інтеграція з інфраструктурою, простіше масштабування.
Як вибираємо технологію для нових сервісів у межах стека
Ми працюємо з мікросервісною архітектурою, тож кожна нова фіча – це потенційно окремий сервіс. Але наша організація побудована не навколо технологій, а навколо бізнес-доменів.
Наприклад, є команда, яка відповідає за Core-сервіси, зокрема, реєстрацію та логін користувачів. Якщо нам потрібно додати нову функцію, скажімо, вхід через соцмережі, її, найімовірніше, реалізовуватиме та сама команда. І, швидше за все, вона використає ту саму мову, що й для основного сервісу. Це логічно: команда вже розуміє архітектуру, володіє кодом, знає всі нюанси бізнес-логіки.
Але є й інші сценарії. Буває, команда перевантажена. Вона могла б реалізувати фічу, але через місяць. Бізнес не може чекати – зростає time-to-market, втрачаються можливості. У таких випадках ми починаємо шукати варіанти: хто з інших команд вільний, які мови вони використовують, чи підійде їхня експертиза під цю задачу.
Щоб уникати ситуацій, коли рішення доводиться ухвалювати в режимі «пожежі», ми плануємо заздалегідь. Будуємо річні роадмапи, навіть якщо прогнози поки загальні. Вони дозволяють побачити, де можуть виникнути піки навантаження, і завчасно знайти ресурси, або зрозуміти, що частину функціоналу варто передати іншим командам чи реалізувати іншою мовою.
Іноді це навіть привід змінити технологію. У нас були кейси, коли сервіс історично був написаний на Erlang, але новий функціонал вимагав значних змін. Ми дивилися на завдання, на команду, на перспективу й ухвалювали рішення переписати сервіс на Java. Це трохи більші інвестиції на старті, але з погляду ROI (Return on Investment) вигідніше. Так ми знімаємо навантаження з команди Erlang, зменшуємо кількість сервісів цією мовою і розвиваємо стек, який простіше масштабувати.
Коли стандартного стека недостатньо: як ми ухвалюємо нові технологічні рішення
У нас у компанії працюють два підходи – зверху вниз і знизу вгору. Це означає, що ідеї можуть подавати як архітектори та бізнес, так й будь-який розробник у команді.
Перша лінія, до якої він може звернутися – це техлід. Зазвичай пропозиції точкові, як-от у 99% випадків, якщо у PHP-розробника є необхідність написати частину функціональності іншою мовою (через те, що PHP не надає для цього потрібних інструментів), це буде Go.
Ми робили це вже неодноразово, тож рахуємо TCO (Total Cost of Ownership – повна вартість розробки, тестування, підтримки тощо) і, якщо цифра нас влаштовує, погоджуємось.
Якщо йдеться про щось глибше, як-от впровадження нової технології на постійній основі, робимо детальніше дослідження – незалежно від того, чи була ця пропозиція зверху чи знизу.
До обговорення залучаються архітектори, техліди, DevOps, інфраструктурна команда, DevSecOps, продуктова команда та юристи – залежно від контексту.
Контрольні питання, які досліджуємо:
- Чи вирішує ця технологія нашу задачу краще, ніж те, що ми вже маємо?
- Чи зможемо швидко знайти або виростити команду під неї?
- Наскільки добре вона інтегрується з нашою CI/CD-інфраструктурою?
- Чи зручно буде її підтримувати у продакені?
- Який рівень підтримки, спільноти, оновлень?
Також звертаємо увагу на сигнали, що говорять про ризик: якщо у технології погано з підтримкою, складна ліцензія чи немає шляху оновлення, ми її не розглядаємо.
Востаннє ми розширили стек мовою Erlang, вона дозволяє нам витримувати високі навантаження, але також вона має обмежену кількість фахівців на ринку. Ми запустили внутрішні курси й навчаємо людей, але нам треба зростати швидше, тож ми вирішили додати якусь нову технологію. Нею стала Java.
Перш ніж її вибрати, ми провели маркетинговий аналіз: подивилися, скільки розробників є на ринку для різних мов, яка серед них конкуренція. Зокрема, порівняли Java та Go і побачили, що зі знанням Go на Djinni 40 активних кандидатів, а з Java – понад 700. Це сильно вплинуло на вибір.
Також ми зробили технічний рисьорч. Порівнювали фреймворки (Spring, Quarkus), віртуальні машини (JVM, GraalVM), дивилися на cost-efficiency та метрики продуктивності. Потім ми ви брали найкращу конфігурацію, написали MVP, запустили його паралельно зі старим сервісом і розділили трафік.
Ми знімали всі ключові показники – швидкість, стабільність, споживання ресурсів. Зараз, коли шляхом досліджень підтвердили, що нове рішення справді краще, можемо рухатись далі та починати поступове масштабування.
Адаптація команди до нових технологій
Нова мова або фреймворк – це не лише про код, а й про те, як його будуть писати, підтримувати, передавати. Тому адаптація команди – обовʼязкова частина процесу.
Іноді це означає, що хтось у команді змінює напрям. Наприклад, один з наших Go-розробників завершив проєкт, і ми запропонували йому перейти в нову Java-команду. Розробник погодився, влився в нову команду і продовжує роботу вже в іншому стеку.
Ми вважаємо, що перехід між мовами – це нормальна частина розвитку інженера. Тому створюємо для цього умови:
- у нас є технічні гільдії, де люди з різних команд обмінюються досвідом;
- ми проводимо внутрішні воркшопи;
- фіксуємо технічні рішення в документації (наприклад, через ADR);
- надаємо доступ до навчальних ресурсів – і для новачків, і для тих, хто хоче заглибитись.
Це дозволяє людям не «застрягати» в одному стеку, а компанії масштабуватись без болю.
Як ефективно вибирати стек
Універсального ідеального стека не існує. У кожної компанії свої цілі, команда і швидкість зростання. Крім того, у виборі технології завжди є фактор невизначеності. Як-от Unity – хороший варіант для інді-розробки ігор, який різко став непридатним, коли у 2023 компанія запровадила додаткові комісії.
Втім, це не означає, що планувати не потрібно. Треба розуміти, і де ви зараз, і де хочете бути за п’ять років. Наприклад: чи плануєте швидкий exit, чи створюєте платформу, яка має масштабуватись роками? Чи бачите ви себе локальним сервісом, чи хочете виходити на нові ринки?
Ще до повномасштабного вторгнення був цікавий кейс. Один стартап зробив дуже влучне рішення й одразу закрив увесь локальний ринок. Але на цьому все. Далі – або великі інвестиції в інші країни, або глухий кут. З технічного погляду там усе було ідеально, але через таке обмеження зростання не відбулося.
Цілі компанії напряму впливають на вибір технологій:
- Якщо ви запускаєте ШІ-продукт – логічно брати Python, а не Java.
- Якщо робите ecommerce – WordPress дасть вам швидкий старт.
- Якщо ж плануєте виходити на великі навантаження – варто дивитись у бік Erlang, Rust, Java, Scala, Kotlin, .NET.
Найгірше – це коли технологія не відповідає задачі (наприклад, важкий фреймворк для простого сервісу). Але варто пам’ятати: те, що допоможе на старті, із часом може почати гальмувати.
Уявімо, що ви робите стартап і можете використати готовий фреймворк, написаний на Clojure: він дасть вам 80% потрібної функціональності з коробки. Але Clojure – дуже нішева технологія, якою володіють дуже мало фахівців. Чи буде вибір Clojure помилкою? Складно сказати: адже стартап швидко запуститься та матиме шанс зайняти ринок. Тому важливо закладати гнучкість у виборі й іноді йти на свідомий компроміс. А також закладати точку перегляду: коли «майбутні ви» оціните, чи ще працює вибір.
Наостанок ось топ п’яти порад компаніям, які хочуть побудувати прозорий процес вибору технологій і загалом ухвалення техрішень:
- Залучайте людей, які потім це реалізовуватимуть.
- Давайте місце для PoC і технічних експериментів.
- Фіксуйте, що та чому вибрали, навіть якщо потім зміните.
- Формалізуйте технічне рішення – створіть просту, але зрозумілу структуру технічного обґрунтування.
- Перевіряйте рішення через призму бізнес-метрик.
Повідомити про помилку
Текст, який буде надіслано нашим редакторам: