Що таке “розпил моноліту” і коли він закінчиться? (версія 2019 року)
Майже 4 роки тому ми почали процес, який називався “розпил моноліту”. Тоді ми були в ситуації, коли не могли масштабувати команду розробки через те, що наша система була настільки звʼязана, що додаючи нових розробників в команду, загальна швидкість команди зменшувалась, а не зростала!
Тоді ми вирішили зайнятись нашим монолітом — “розпилити” його. Трохи згодом я написав статтю, в якій пояснював колегам, що таке моноліт, чому він виник і що нам з ним робити. Публікую статтю без зміни контенту.
Що таке “розпил моноліту” і коли він закінчиться? (версія 2019 року)
Впевнений, більшість з вас часто чують фразу “розпил моноліту”. А в декого ця фраза вже викликає блювотний рефлекс. Та попри це мало хто дійсно розуміє, що таке моноліт, чому його потрібно розпилювати, а головне — коли це закінчиться.
У цій статті я спробую змінити цю ситуацію і відповісти на найбільш актуальні запитання щодо цієї теми:
- Що таке моноліт і чому він у нас виник?
- Чому моноліт це погано і чи погано це?
- Що ми робимо в рамках проєкту “розпил моноліту”?
- На якій стадії цього проєкту ми знаходимось?
- Які плани на майбутнє?
- Коли це все закінчиться?
Я спробував написати статтю максимально просто. Для цього перевіряв її на своїй десятирічній сестрі. Вона нарешті зрозуміла, чим займається її брат. Тепер вважає, що я електрик-монтажник 😅 Чому? Про це далі у статті.
Що таке моноліт і чому він виник?
Почнемо з того, як працює платформа для спілкування, яку ми створюємо.
Щоб було ще простіше розібратись, уявімо два будиночки. В кожному сидять різні типи юзерів, які хочуть соціалізуватись. Та щоб це було можливо, між будинками потрібен зв’язок.
Отже, треба поставити стовп між будинками та провести перші дроти. Нехай це будуть дроти для телефонного звʼязку. Тепер перші юзери платформи можуть почати спілкуватись.
Але! Щоб утримати користувачів на платформі та наростити їх кількість, потрібно постійно додавати нові фічі на продукт. Так, окрім телефонного звʼязку ми додали ще телебачення, радіо, інтернет і т.д.. Тобто ми збільшили кількість проводів, які йдуть між цими будиночками. Завдяки цьому користувачі платформи можуть отримувати значно більше можливостей.
З часом поруч з’явилися нові будиночки з новими “типами” користувачів — модерація, внутрішня адмінка, ще одна адмінка і т.д.. І всі вони для своїх цілей використовували один і той же стовп.
Згодом до нас почали приєднуватись нові програмісти-електрики, які прокладали нові дроти. Часом на платформі проводили різні тести: випробовували дроти, змінювали одні на інші (більш сучасні), додавали нові та, на жаль, не завжди видаляли непотрібні. З часом дротів стало так багато, що інколи, коли щось ламалося, легше було провести новий дріт і не шукати несправний.
І це нормально — для бізнесу тоді було важливіше швидко рухатися, а з зайвими дротами можна було розібратись пізніше.
Думаю, уже стало зрозуміло, що цей стовп у результаті й став тим монолітом, про який ви всі чули.
Чому моноліт це погано?
Багато людей впевнені, що моноліт — це зло. Та це не так. Часто на противагу монолітній архітектурі ставлять мікросервісну. Насправді і в монолітній, і в мікросервісній архітектурі (яку часто протиставляють монолітній) є свої плюси та мінуси. І моноліт може бути цілком хорошим рішенням.
Проблема не в моноліті, а в поганому коді: висока зв’язаність, неструктурованість, відсутність тестів тощо. Усе це дуже блокує і не дає нам рухатися з необхідною швидкістю. Якщо повертатися до прикладу зі стовпом: уявіть наскільки там складно знайти дріт, який не працює.
Окрім того, що такий процес вимагає багато зусиль, це ще й досить небезпечно (ага, може йо**ути). Під дією власної ваги дроти можуть обриватись, а стовп взагалі може впасти. Також існує досить значна ймовірність, що коли розробник-електрик фіксить щось одне, то може зламати щось абсолютно інше. Так коли ремонтуєш телефонний зв’язок між користувачами та модераторами, можеш залишити без світла адмінів. А коли пофіксиш світло у юзерів, раптом розумієш, що залишив усіх без телебачення.
В один момент стало зрозуміло, що збільшення кількості електриків не тільки не вирішить, а ще й ускладнить цю проблему. Мало того, що вони почнуть заважати один одному на тому стовпі, так ще й у кожного свої правила та підходи. Хтось звик кріпити дроти на металеві штирі, а хтось досі використовує дерев’яні. Від цього хаос тільки зростає, а швидкість руху зменшується.
Критичний момент в цій історії настав, коли частина проводів обвалилась і ми не могли їх підняти впродовж декількох днів.
Що з цим усім робити?
Після тих подій, понад рік тому, стало зрозуміло, що настав час діяти. Пора гасити технічний борг, який ми взяли на себе. Саме тоді виник проєкт “розпил моноліту” і почався “великий рефакторинг”. Ми вирішили на певний час заморозити розробку нових фіч для того, щоб навести порядок на нашому стовпі (це вартує окремої статті, бо далеко не кожному вдається переконати бізнес заморозити продуктову розробку на місяці). План був такий:
- Знаходимо дроти, які просто звисають, бо їх ніхто не використовує, та видаляємо їх.
- Намагаємось розв’язати та логічно згрупувати дроти на стовпі: телебачення до телебачення, чати до чатів тощо.
- Беремо окремо кожну групу та намагаємося перенести її на окремий стовп as is.
- Робимо ревізію цих усіх дротів на новому стовпі та по можливості оптимізуємо їх використання.
Звісно, заморозити продуктову розробку в моменті було неможливо, тому спочатку доводилось поєднувати рефакторинг з вирішенням продуктових задач. Проте навіть такий підхід дав нам змогу отримати те чого ми хотіли.
Де ми зараз?
Ми вже поділили на групки проводи на нашому великому стовпі та поставили новий стовп (сервіс, який займається спілкуванням користувачів в чаті). Ми вже “перекинули” на нього необхідні дроти та перевели користувачів з одного стовпа на інший. Тепер ми дещо оптимізуємо чати, щоб вносити зміни стало простіше. Потім перейдемо до наступного стовпа. Процес не безболісний, але ми точно справимося.
Для чого ми це робимо?
Як тільки ми перенесемо частину дротів з моноліту на інший стовп, то зможемо організувати окрему кросфункціональну команду-бригаду спеціалістів, яка буде займатись лише цим стовпом. Вони будуть працювати над тими фічами, які через нього проходять, і будуть впевнені, що не залишать без світла всі будники. А головне, для чого ми все це робимо — хочемо забезпечити такий швидкий ріст та розвиток платформи, як і раніше (а то й більше).
Коли це все закінчиться?
На жаль, сказати конкретну дату, коли закінчиться проєкт “розпил моноліту” неможливо. Результат не є бінарним (розпилили чи не розпилили), а залежить від багатьох факторів і вимірюється також купою факторами. Часто, коли я проводжу співбесіди із Senior Backend інженерами, ставлю їм запитання: “Які компоненти потрібно виносити з моноліту і коли варто зупинитись? “. Більшість відповідає не правильно: “Виносити потрібно максимум: скільки можна — стільки й випилюйте”. Ми ж використовуємо таке правило:
Якщо щоб винести компонент з моноліту, потрібно більше часу та зусиль, ніж щоб його підтримати (чи розвивати) — його не варто виносити.
Рефакторинг справа не проста і для того, щоб якийсь компонент винести з моноліту, потрібно витратити дуже багато часу досвідчених розробників. А якщо цей компонент не потребує підтримки та розвитку в майбутньому, то весь час буде витрачено просто в нікуди.
Тому висновок простий: ми будемо розпилювати моноліт до того часу, поки це буде раціонально відповідно до правила вище. Звучить, як погроза, але це не так 😄
Насправді вже зараз проєкт “розпил моноліту” не є блокером для більшості фіч (окрім чатів і того, що з ними пов’язано). З кожною новою ітерацією ми робимо крок вперед і покращуємо наш продукт, що дає можливість для його розвитку. Уже зовсім скоро ми розблокуємо роботу, що стосується чатів, і зможемо робити нові фічі пов’язані з ними. Після цього візьмемося за наступний компонент й оптимізовуватимемо його.
Last but not least
Наостанок хотів би подякувати всій команді, яка займається розпилом моноліта за їхню “міць”, а всім іншим — за терпіння та розуміння. Пам’ятайте: no pain — no gain. І повірте: настане день, коли розробка перестане бути блокером змін і почне бути їхнім енейблером.
P.S. коли прочитав останнє речення зі статті вище, то в животі залітали метелики і я почав задоволено посміхатись. Десь на початку 2022 року наш СРО сказав фразу, яка підтверджує той факт, що проєкт “розпил моноліту” був не дарма 🤌
Розробка вперше перестала бути bottle neck’ом: ми робимо більше ніж встигаємо продіскаверити.
