Уніфікація як ключ до масштабування: кейс міграції BackBase

Уже понад чотири роки команда Levi9 Ukraine розвиває екосистему банкінгу BackBase для 80 країн. Реліз артефактів, послуги з інтеграції, SaaS-платформа — усе це моделі доставки продуктів у BackBase. За кожну модель відповідає окремий підрозділ. Кожен окремий підрозділ використовує різні практики й тулінг у повсякденній роботі. Так було, а потім прийшла уніфікація.

Мене звати Владислав Пишенко, я DevOps Tech Lead у Levi9. Нещодавно наша команда разом із колегами з BackBase брала участь у міграції проєкту, оскільки використовувані підходи й рішення не давали змоги продовжити розвиток. Як виявилось, все може бути зручніше і краще, ніж було, головне — не боятися змін. Пропоную детальніше поговорити про мотивацію міграції, мету та винесені уроки з не простого процесу перетворення лялечки на метелика.

Що змусило задуматись про єдину систему для всіх

Варто почати з кількох фактів про BackBase: 800+ співробітників, 3000+ релізів на рік, 2000 спринтів, 100+ команд і понад 100 000 створених за рік тестових середовищ. Додамо сюди різні моделі доставки продуктів та різні практики й тулзи в кожному підрозділі, що заважало подальшому зростанню та покращенню ефективності, тому  ухвалили рішення про уніфікацію процесів. 

Візьмемо два підрозділи, які розробляли і SaaS: обидва використовували AWS як хмарне рішення, але тулінг для створення середовищ, доставки й зберігання коду кардинально відрізнялися. SaaS використовували зв’язку з Github, Flux і Terraform для розгортання середовищ, яка дозволяла масштабуватись, але через обмеження Flux була менш зручна для цілей розробки. 

RnD-підрозділ використав зв’язку з Bitbucket Jenkins та інструменти власної розробки для розгортання тестових середовищ і доставки коду. Рішення працювало і було добре відлагоджене, але гірше масштабувалось і потребувало чимало зусиль для адміністрування. Для прикладу, Jenkins міг одномоментно обслуговувати 1500 активних завдань.

Кардинальна різниця була і у конфігурації. Хоча загальною її мовою є Helm і кожен компонент системи описаний у Helm-чарті, проблема була у тому, що кожен підрозділ використовував різний підхід при розгортанні середовища.

RnD використовував Helmfile, тоді як SaaS користувався Umbrella chart на базі Helm. Обидва підходи мають свої переваги й недоліки: Helm та Umbrella chart дозволяє легше маніпулювати чартами без потреби використання додаткового тулінгу, але Helmfile більш гнучкий. Та врешті вони виконували одну й ту саму роль, що змушувало дублювати конфігурацію при деплойменті на dev середовище і SaaS.

Куди мігрували та чому

Найпершим завданням була уніфікація платформ і підходів між підрозділами, розробка єдиної системи розробки й доставки коду, а також створення тестових і продакшн середовищ з єдиним набором інструментів і практик. Це все базуючись на використанні cutting edge технологій і підходів.

Чому GitOps? Все просто: максимальна продуктивність через постійний зворотний звʼязок від системи, краща якість роботи завдяки керуванню тільки маніфестами з репозиторію та стабільність — постійна наявність аудиту того, що відбувається в системі. 

Раніше для зберігання та збірки коду використовувалась зв'язка bitbucket + jenkins. Та з розвитком компанії навантаження на систему росло. В один момент їх підтримка та обслуговування стали шалено дорогими, тому потрібно було шукати більш оптимальне рішення. Разом з іншими командами ми вирішили робити все на єдиній платформі і зупинились на Github, з Reusable workflows. 

Сам по собі Github дуже популярне рішення, яке охоплює як інструменти управління кодом, так і його доставкою (Github actions). Також він є частиною екосистеми Microsoft, яку ми активно використовуємо в компанії, дає досить хорошу гнучкість для бізнес-користувачів в управлінні ресурсами й повністю знімає операційне навантаження.

Reusable workflows, в свою чергу, дає змогу винести повторювані частини пайплайну і повторно використовувати їх в інших, де це потрібно. Це значно спрощує побудову релізного процесу і уніфікує підходи до нього в командах. Також дозволяє не переписувати дубльовані частини, що також значно зменшує кількість помилок при підготовці релізних пайплайнів, так як використовуються готові відтестовані компоненти. Як клауд-рішення для нової платформи був обраний Azure, котрий надавав більш вигідні умови для компанії.

Найважчим рішенням був вибір інструменту для деплойменту. Обирали між Flux2 і ArgoCD. У них схожий набір функціоналу й однаково гарна якість роботи. Але в фіналі зупинились на AgroCD, як на проєкті, що підтримується  CNCF і є більш гнучким. Інструмент дозволяє використовувати систему кастомних доповнень (плагінів) і має нативну підтримку Helm, котрий обраний як стандарт в організації. До того ж, використання Примітивів Argo значно спростило управління конфігураціями для різних середовищ і допомогло виробити один підхід в управлінні Helm чартами компонентів. А ще – UI гарний. Тепер наша схема має такий вигляд:

Уроки, винесені під час міграції

Хоча наразі ми знаходимось тільки в процесі завершення “переїзду”, вже помітні переваги внесених змін. Нам вдалось вивести кілька важливих уроків, якими б хотіли поділитись. 

Рішення мають строк придатності

Звичайно релізний процес був налагоджений, система працювала, але наша інфраструктура була дуже розрізнена і за її розвиток та підтримку відповідали різні люди. В якийсь момент це почало гальмувати подальше зростання і більше заважати, аніж допомагати. Тут ми й зрозуміли, що час змін настав.

Змінюй незмінюване

На перший погляд, змінити підхід до релізу оновлень в організації, де працюють 800+ спеціалістів, звучить складно і не дуже доцільно — все ж і так працює. Але, як результат, відсутність необхідності повторювати одну і ту ж саму роботу під час релізу на різні платформи, вже оптимізує багато часу. Також робить процес більш прозорим, що значно пришвидшує онбординг нових спеціалістів.

Уникай «ручної роботи»

Разом з колегами нам вдалось імлементувати повністю автоматизований процес розгортання інфраструктури (dev, stage, production), для внутрішніх і зовнішніх клієнтів. Ми використали стандартні інструменти, які дозволяють описувати елементи інфраструктури, такі як бази даних, кластери та репозиторії за допомогою коду (Helm, Terraform). Також даний підхід значно спростив і інфраструктуру на всіх етапах від розробки до релізу, RnD інфраструктура тепер повністю відповідає Production без виключень. На додачу вдалось відмовитись від значної кількості самописних інструментів, підтримка яких вимагала чимало зусиль.

Рекомендації іншим 

Часом дуже важко відійти від традицій у компанії, впровадивши щось нове. Але завжди потрібно намагатись дивитися зі сторони і не сприймати продукт, над яким працюєш, як щось абсолютно довершене й досконале.