Проблеми деплою headless commerce на MACH-архітектурі ніколи не потрапляють на слайд із чотирма акуратними квадратиками. Microservices, API-first, Cloud-native, Headless — гарна абревіатура, і на whiteboard вона виглядає як майбутнє. А потім ти намагаєшся реально викотити це в прод, і прірва між діаграмою та реальністю виявляється звірською. Я знаю, бо місяців шість прожив не на тому боці цієї прірви.
Зізнання, від якого мені досі ніяково: наша стратегія відкату звучала буквально так — «викотити попередню версію і молитися». Хотів би я перебільшувати.
Гарна абревіатура, потворна реальність
Обіцянка MACH — це незалежність. Кожен сервіс володіє своїм життєвим циклом, релізиться у своєму ритмі, масштабується за своїми правилами. Тільки от про що мовчать: незалежність без координації — це не свобода, а хаос із додатковими кроками.
У нас кожен мікросервіс мав власний deployment-скрипт. Жодних спільних стандартів. Конфігурацію оточень правили руками, сервіс за сервісом. І ні в кого — ні в мене, ні в команди — не було чесної відповіді на найпростіше питання в офісі: «що взагалі зараз крутиться на staging?» Питаєш трьох — отримуєш три різні відповіді.
«Слабо зв'язані» сервіси насправді виявилися зв'язаними намертво — способами, які діаграма архітектури ввічливо приховувала:
- Проблеми service discovery: після передеплою сервіси переставали надійно знаходити одне одного.
- Залежності за порядком деплою: сервіс B був марний, поки не підніметься сервіс A, і ніщо цього не контролювало.
- Жах із parity оточень: staging і прод розходилися щотижня.
Момент, коли все склалося
Коли я вперше спробував відкотити невдалий деплой, уся ілюзія розсипалася. Не було жодного місця, яке знало б правильний стан системи. Кожен сервіс — сам собі острів. Я відкотив один — і тут-таки зламав API-контракт із двома іншими, що чекали на нову версію.
Ось тоді й клацнуло. У нас не проблема деплою. У нас проблема координації. Жодні пайплайни не врятують, поки жодна система не розуміє, як частини складаються в ціле.
Як я зібрав MACH Composer
Тому я зібрав composer-шар поверх GitHub Actions — платформу, єдине завдання якої ставитися до всіх сервісів як до одного цілісного деплой-юніту.
Усе зводиться до одного конфіга. У ньому описано кожен мікросервіс, його версію, його залежності та його вимоги до інфраструктури. Ти пушиш у main — і composer думає за тебе:
- Обчислює правильний порядок деплою з оголошених залежностей.
- Розбирається з конфігурацією оточень, щоб ніхто більше не правив значення руками.
- Проганяє health checks після кожного викату і відкочує автоматично, якщо вони падають.
Згори — real-time дашборд, який показує, яка версія якого сервісу крутиться в якому оточенні. Невідомість була найдорожчою частиною старого світу, і дашборд її прикінчив. Більше жодних «викотити і молитися». Більше жодних трьох відповідей на одне питання.
Архітектура знизу лишилася тією самою
Ось тут хочу бути чесним, бо в цьому весь урок: самі сервіси не змінювалися. У цьому й був сенс.
- Мікросервіси лишилися незалежними, версіонованими й тестованими окремо.
- API gateway дав усьому єдину точку входу.
- Service mesh узяв на себе міжсервісне спілкування: retries, circuit breakers, усю невдячну сантехніку.
- Terraform керував інфраструктурним шаром, тож зміни в коді автоматично тягнуть за собою зміни в інфрі, а не хтось тицяє в консоль об одинадцятій вечора.
Мені не треба було переписувати архітектуру. Мені треба було, щоб існувала платформа деплою, на якій цю архітектуру можна реально викочувати. Це дуже різні задачі, і я надто довго плутав одну з одною.
Що б я сказав собі минулому
MACH — це по-справжньому. Воно працює. Але в це «працює» тихо зашито шість місяців операційного болю, про який не попереджає жодна доповідь із конференції. Чотири літери описують, як ти проєктуєш систему. І жодного слова про те, як ти її викочуєш, відкочуєш і бодай бачиш.
Якби я міг надіслати одне повідомлення в минуле, воно було б таким: не будуй архітектуру раніше, ніж збудуєш спосіб її деплоїти. Я зробив у неправильному порядку — і мені досі трохи соромно.
MACH без оркестрації деплою — це не сучасна платформа. Це просто набір незалежно падаючих сервісів у дуже гарній абревіатурі.