240+
людей
4
продукта
5+
років на ринку
4
міжнародних офіси
У 2016 році IT-компанія Newage починала з десяти програмістів та невеликої орендованої кімнати, де з локальних комп'ютерів піднімали перші сервери, а першочерговим завданням кожного новачка було обтиснути виту пару та під'єднатися до мережі.
За цей час компанія зуміла побудувати екосистему комерційно успішних продуктів, один з яких — B2B SaaS iGaming-платформа на 30 млн користувачів, а також вирости до більш ніж 240 людей в чотирьох міжнародних локаціях: в Україні, Грузії, Польщі та на Кіпрі. При цьому Newage зберегла атмосферу стартапу та пристрасть до інновацій.
AIN.UA розповідає, як компанія впроваджує та адаптовує для роботи практики Amazon та Google, як обирає технологічний стек для свого основного продукту — платформи iGaming, а також як допомагає співробітникам та країні під час війни.
Сторінка сайтуУ 2016 році, коли компанія почала роботу над SaaS iGaming-платформою, це був достатньо серйозний виклик: адже доводилося конкурувати з таким монстром, як EveryMatrix, якщо не бюджетами, то технологіями.
Як згадує Scala Lead Сергій Волох, що працював із проектом від самого початку, тоді Newage була маленьким стартапом, із зарядженою командою. «Не знаю, як так вийшло, але зібрали дуже мотивованих і водночас дуже прокачаних людей, націлених на результат», — згадує він. Команда одразу намагалася обрати для платформи технології, які дозволили б їй швидке зростання та масштабування.
Згодом з’ясувалось, що це рішення було правильним: SaaS-платформа розвивалась доволі стрімко. За рік команда отримала мальтійську геймінгову ліцензію MGI, платформа вийшла у продакшн, а компанія отримала перших клієнтів. Уже 2017 року на платформі відбувалося по 300 000 фінансових транзакцій і по 1000 реєстрацій на день. На сьогодні тут — понад 30 млн користувачів, до 50 000 реєстрацій та п’ятнадцять мільйонів транзакцій щоденно, а сама платформа виросла до 250 сервісів та 30 000 ігор.
Але технологічний фундамент для такого розвитку було закладено ще на самому початку проекту.
2017 — 2022
Користувачів
300тис.
30млн
Транзакцій (день)
$300тис.
15млн
Реєстрацій (день)
1тис.
50тис.
300 тис.
30млн
10 000%
Користувачів
$300 тис.
$15 млн
5 000%
Транзакцій
(день)
1 тис.
50 тис.
5 000%
Реєстрацій
(день)
На початку роботи з платформою команда думала над тим, якою має бути її архітектура для того, щоби вона була максимально гнучка, легко адаптувалася до змін (як бізнесових, так і технічних), а також підтримувала скейлінг. Фундамент для розвитку та масштабування ми закладали з самого початку проекту.
Cергій Маяков
SRE
DDD
Реактивний підхід
Саме ці базові речі, які дозволили масштабувати та активно розвивати проект, а не тонути в монотонному рефакторингу. Зараз Event-driven architecture уже мало кого здивуєш, але тоді правильно робити це вміли не так багато спеціалістів.
Не скажу, що одразу все складалося ідеально, але при такому підході ми швидко тестували ідеї. Наприклад, потрібно зробити якусь нову фічу — робимо окремий сервіс або функціональну декомпозицію наявного, й одразу тестуємо.
Є альтернативний підхід: із детальними прорахунками, документуванням на кожному кроці й перестраховиками. Та ми вирішили використовувати гнучкі процеси: Extreme Programming (XP), ітеративні процеси, agile-архітектуру, — завдяки яким нам вдавалося і вдається швидко запускати та тестувати нові фічі та отримувати зворотний зв'язок. Для платформи із сотнями мікросервісів це важливо.
У нас зберігався дух стартапу: ми весь час експериментували й обирали технології, які водночас були на хайпі та найкраще розв'язували наші задачі. Робимо так і зараз:
Найскладніші критичні сервіси у нас на Scala.
Мікро-фронтенди — на React.
Широко впроваджений Node.js.
Рекомендаційні системи та репортінг — на Python.
Такий експериментаторський підхід означав і те, що певні ідеї ми тестували й відкинули:
Ми починали із Java-Scala гібриду, але зараз на ньому лишилося кілька сервісів, та й ті ми переписуємо. І це не тому, що Java в чомусь погана, це суто практичне рішення: основний фреймворк, який ми використовуємо — Akka, а він на Scala. Плюс, на Scala дуже зручно реалізовувати потужні DDD-агрегати й чисті event-driven сервіси.
Експериментували з різними базами даних, у результаті відкинули Mongo та MariaDB, і лишили ElasticSearch, Postgres, ClickHouse, BigQuery.
Починали запускати все на Docker Swarm, до K8s тільки приглядалися, але все ж два роки тому перейшли повністю на нього, що загалом додало нашим серверам та платформі багато корисних плюшок, пов'язаних із масштабуванням, CD-процесами та reliability.
Спочатку платформа була cloud agnostic, а деякі сервіси тримали локально. Але з її розростанням перевели все на інфраструктуру AWS, і це також позитивно позначилося на продуктивності та суттєво покращило availability-рівень. Зараз AWS використовуємо по максимуму: спот-інстанси, RDS, балансери, нові процесори Graviton, Serverless-підходи і багато всього іншого.
Через такий гнучкий підхід технології ніколи не були у нас вузьким місцем: ми або одразу підбирали відповідний стек під завдання та цілі, або досить швидко міняли його. Так, перехід на Scala (десь 60% усієї платформи наразі) дав нам доступ до потужного Scala-ком’юніті, тож у нас завжди є цікаві завдання, з одного боку, та ентузіазм заряджених людей, які готові над ними думати, з іншого.
Окрім гнучкого підходу до технологій, на яких працює платформа, команда застосовує в роботі проектні та менеджерські практики з досвіду Google, Amazon та Netflix.
Якщо раніше команда Newage фокусувалася лише на результаті, то з розвитком платформи та зростанням компанії саме поняття «результату» розмилося. Тож фокус змістився з «лише результату» на «результат та процес його досягнення».
Щоб краще організувати процеси, команда використала підходи Google та Amazon, прибравши звідти усю бюрократію та лишивши тільки практичні речі, приміром SRE — це ті інженерні принципи, які дозволяють компаніям деліверити надійні та високодоступні онлайн-сервіси.
Продукт
Планування та розвиток
Технології та найкращі практики
Аналіз першопричин
Моніторинг і сповіщення
SRE-підходи — це піраміда, де вгорі є продукт, але починається все із самого низу, із Monitoring та Alerting, Root Cause Analysis, Technologies та Best Practices, Capacity Planning та Development. Щоб ефективно працювали всі ці рівні, необхідно широке бачення усієї системи, розуміння всіх рівнів інфраструктури, транзитивних залежностей, природи та специфіки навантаження.
Ми також повністю міняємо фокус аналізу помилок. Наприклад, у нас є SRE-борд, де можна бачити стан усієї платформи, хай яка б гігантська вона не була. І якщо раніше наша служба підтримки реагувала на інциденти, що вже відбулися, зараз ми намагаємось реагувати до того, як щось сталося. Кожен інцидент проходить крізь серйозний Correction-of-errors (аналог пост-мотерм в Amazon) — це аналіз причин та наслідків того, що сталося.
Такий аналіз не просто показує причини якоїсь проблеми. Він показує її вплив, який може бачити та розуміти кожен член команди. Також формулюються action items — кроки, необхідні для того, щоби проблема не повторилася. Усі ці кроки переводять у задачі в Jira.
Команда також активно користується 5W-підходом. Це — п’ять Why або питань, що шар за шаром знімають з кожної проблеми усі поверхневі пояснення і дають дійти до самої її суті.
У компанії складений величезний роадмап, як дійти до необхідного рівня SLA (Service Level Agreement) для найкритичніших сервісів.
Усе це дає кожному члену команди загальне розуміння того, куди рухається компанія та як мають розвиватися її сервіси, забезпечують спільне бачення того, над чим і навіщо працює кожен.
Навантаження на платформі iGaming може коливатися у сім разів, а кількість запитів на платформу доходить до 6000 за секунду. Для команди це означає нетривіальні технічні та бізнес-виклики, до яких треба адаптуватись.
Cергій Волох
Коли ми лише починали будувати платформу, єдиним способом вирізнитися з-поміж величезних, але неповоротких конкурентів було за рік зробити продукт технологічно таким, який наші конкуренти побудують за 5 років. Для того ми вибрали нестандартні на той час підходи та стек, найняли топових інженерів. Це також означало досить серйозні технологічні виклики для нас.
Навантаження на платформу в піках доходить до 3000-6000 запитів за секунду, наші критичні сервіси обробляють до 15 млн фінансових транзакцій на день, і щомісяця ми б’ємо рекорди по трафіку і фінансах. Звісно, така динаміка передбачає постійні челенджі.
Компанія та бізнес повністю tech driven, саме tech формує структуру та визначає здатність бізнесу до масштабування. У компанії наші інженери фокусуються як на tech, так і на бізнес-частині розвитку продукту. Я, як tech- та team-lead, залучений до продакт-овнершипу свого домену, формую бачення його розвитку. Це зовсім інший рівень залученості та мотивації.
Наприклад, один із клієнтів хотів будувати на нашій платформі масштабні маркетингові кампанії так, щоб гравець, виконавши певні умови, міг отримати винагороду і потрапляв би одразу до іншої кампанії. Це мали бути різні сутності: зв’язки із дюжиною кампаній, дюжиною екранів і конфігурацій, подекуди навіть більше.
Враховуючи тисячі сегментів гравців і відповідно кампаній, цим було б ультраскладно керувати. Тому я запропонував іншу концепцію — «Багаторівневі кампанії»: один екран і багато рівнів, що конфігуруються. Це експоненційно зменшило операційну складність використання продукту.
Фактично, я як інженер приніс бізнес-профіт, максимально спростив потреби клієнта та втілив їх у tech. Це і є наш підхід до складних завдань.
Ще одним величезним завданням для нас було побудувати платформу на мікросервісній архітектурі. 2016 року в Києві про мікросервіси лише починали говорити, ми всі активно фоловили закордонні техно-блоги FAANG-компаній, Twitter та Reddit тож були в курсі всіх трендів.
Натхненні мікросервісною архітектурою Netflix, ми почали використовувати Kafka та івент-дрівен-дизайн, що дозволило масштабувати бізнес і будувати платформу на сотнях мікросервісів, робити продукт, який буде максимально кастомізуватися на UI та бекенді.
Але, мабуть, найскладнішим викликом від самого початку було провести важливу ментальну реінкарнацію. Замінити аутсорсні підходи, коли інженер робить лише те, що йому сказали, на усвідомлений підхід: коли інженер end-to-end відповідальний за свою роботу, а часом і цілий продукт, він як ніколи усвідомлює свою цінність та вагомість для продукту. На когнітивні зміни у нас пішло від 9 до 12 місяців, але нам це вдалося, і водночас ми вийшли із MVP у продакшен.
Завдяки цікавим технологічним викликам та подібній усвідомленості у компанії — неймовірний ретеншен, у нас багато людей в команді, що працюють тут по 6 і більше років.
Наш продукт постійно росте, і нам як інженерам потрібно рости разом із ним, щоразу пробиваючи стелю своїх знань і можливостей.
FrontEnd Lead Вадим Долока приєднався до компанії шість років тому: прийшов до команди як фронтенд-розробник і працював над бекофісом iGaming. Він згадує про те, що саме його зацікавило і мотивувало до зростання.
Вадим Долока
В Newage майже від початку втілювалися хайп-технології, з якими усі прагнули працювати. Але ми не просто робили те, що «на слуху», ми обирали технології, виходячи з того, як вони застосовуватимуться на нашому проекті. В цьому плані у нас від початку була свобода дій та свобода вибору, і дотепер нічого не змінилося.
Наприклад, ми починали з моноліта для нашого UI на React + Redux, потім почали писати для себе Backend For Frontend (BFF) який був GraphQL-сервером з використанням Apollo Server, почали відмовлятись від Redux і використовували більше Apollo Client з його стейтами та кешуванням, а згодом коли наш моноліт став занадто великим, то ми прийняли рішення розділити його на багато маленьких UI компонентів або роутів (перейшли на мікрофронтенд) які працюють на основі WebComponents (коли ми починали ще не було Webpack Module Federation). Наш GraphQL також почали розділяти на мікросервіси використавши там Apollo Federation.
У нас кожен може вплинути на те, як працює весь продукт. Приміром, у нас усе засновано на версійності, і кожен environment у нас складається з версій різних сервісів. Сервісів у нас сотні, і в якийсь момент стало складно ходити між environmentами, перевіряти та звіряти різні версій. Я не люблю рутинні задачі, тож зробив UI, розділений по доменах команд, де різницю версій може подивитись будь-хто. Спочатку цей UI використовувала лише моя команда, а згодом — увесь продукт, усім зайшло. Це неймовірно круто: бачити реальний вплив своєї праці.
Відповідно, ми беремо до себе тих людей, яких це також хвилює. На співбесідах мені неважливо, наскільки людина знає теорію, мені важливо, як вона думає, ми робимо акцент на тому, як саме кандидат підходить до розв’язання задач.
До нас гарно вписуються життєрадісні люди із жагою до нових знань, яким цікаво розвиватися і впливати на весь продукт. У нас завжди вітаються пропозиції, які могли б оптимізувати роботу. Більшість ідей з розвитку нашого бекофісу виходить від нашої фронтенд-команди. Кожен намагається пропонувати якісь більш зручні та елегантні рішення, які зрештою впливають на те, наскільки користувачеві приємно користуватися нашим продуктом.
Через це постійне залучення та небайдужість люди швидко ростуть: з моєї команди троє прийшли як верстальники, а стали фронтенд-розробниками.
В нашій команді, хай ти джавіст, скаліст чи пишеш на реакті, маєш хоч трохи розуміти інфраструктурні речі. Кожен наш розробник на фронтенді трохи, але розбирається в K8s, може глянути логи на GraphQL-cервері. Можна вивчити дуже багато такого, куди у звичайній компанії девопс тебе просто не пустить.
А у нас так заведено: тобі цікаво розібратись? Ось тобі зелене світло на це, вчись, їзди на конференції. Тобто, кожен інженер має шанс прокачатись і як системний архітектор, і як системний дизайнер. У нас працюють люди, що обожнюють вчитися, та не бояться експериментувати. Компанія завжди таке підтримує.
Йдеться не лише про підтримку в саморозвитку та зростанні. Компанія опікується також і базовою безпекою та почуттям команди. Адже глобально штат Newage налічує понад 240 людей, з яких 160 працюють в Україні.
Newage зберігає усі робочі місця та продовжує найм в український офіс. Усім співробітникам, які служать в ТрО або ЗСУ, повністю зберігаються робочі місця та зарплата.
Люди, що працюють в нашій компанії, стали для мене немов частина моєї родини. І Newage як роботодавець несе відповідальність перед своїми співробітниками.
Георгій Алексідзе
У квітні Newage перерахувала $500 000 Криптовалютному фонду України для забезпечення потреб армії.
Для співробітників, що постраждали від війни, компанія організувала фонд допомоги, із первинним внеском у $100 000 та продовжує його поповнення.
Спільно з Міністерством цифрової трансформації України компанія взяла участь у створенні Звіту «Цифровий спротив України російській агресії» та представила його широкій аудиторії на заході Atlantic Council.
Команда долучилася до розробки порталу «Збір фактів порушення прав людини», де збираються докази воєнних злочинів російської армії для представлення в Європейському суді з прав людини та Міжнародному суді ООН.
Разом із партнерами команда брала участь у розробці програмного забезпечення, яке дозволяє автоматично налаштовувати списки повідомлень у каналах Telegram для запобігання дезінформації та пропаганді. Розробка йшла у співпраці з СБУ.
Newage продовжує активний найм в український офіс, докладаючи зусиль для розвитку бізнесу та команди, щоб підтримувати економіку країни у кризові часи.
Самі члени команди характеризують Newage як компанію, куди топові та заряджені інженери приходять і залишаються там працювати надовго. Адже тут є можливість працювати із технологічно цікавими та масштабованими проектами, постійне зростання яких вимагає від усіх спеціалістів рости у такому ж професійному темпі. Компанія реагує на виклики часу та дослухається до своєї команди, підтримуючи їх у кризові часи.
Тож, якщо вам цікаво було б долучитися до української команди, що працює за принципами Amazon та Google, заохочує ініціативу та розвиток — саме зараз Newage запрошує до співпраці найкращих інженерів.
