«Винесіть з моноліту один сервіс — стане на 50 % швидше»: чи завжди треба переходити на мікросервіси

Зараз все більшої популярності набуває мікросервісна архітектура як більш гнучкий інструмент у розробці проєктів. За останнє десятиріччя чимало BigTech-компаній, серед яких eBay, Amazon, Netflix та понад десяток інших, зробило вибір на користь мікросервісної архітектури та успішно розвиває проєкти з її допомогою.

В чому переваги такого типу архітектури, коли на неї варто мігрувати та на що звернути увагу під час переходу, розповідає Tech Lead Manager у Preply та лектор курсу «Мікросервісна архітектура» Влад Карнаушенко.

Мікросервісна архітектура (microservice architecture, MSA) — це один з підходів до проєктування, під час застосування якого єдиний застосунок складається з набору невеликих незалежних компонентів, які називаються мікросервісами. Кожен з них працює в окремому процесі, відповідає за конкретний функціонал та взаємодіє з іншими модулями.

Влад Карнаушенко, Tech Lead Manager у Preply та лектор курсу «Мікросервісна архітектура»

Чому мікросервіси не панацея — і які в них підводні камені

— Які переваги є у мікросервісної архітектури?

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

Термін «монолітна архітектура» практично не використовується поза контекстом мікросервісів. Якщо загуглити «які компанії використовують монолітну архітектуру», то більшість матеріалів будуть новинами про те, що компанія N перейшла з моноліту на мікросервіс. Виділяється хіба що Ілон Маск, який почав заперечувати цю ідеологію та закликає «рухатися назад». В індустрії починаються розмови про наносервіси — і це одна крайність, моноліт — інша, а мікросервіси — це здоровий баланс між ними.

Мікросервісна архітектура дозволяє масштабувати не тільки технічні рішення, але й команди розробників. Продавати новий підхід компаніям намагаються саме інженери (не в останню чергу і через хайп навколо нього) та очікують, що це річ, яка підніме технічні характеристики системи на небачений рівень, що не зовсім так. Адже найбільше переваг вдасться отримати саме на організаційному рівні: у випадку з монолітною архітектурою часто трапляється так, що 50 людей працюють в одному коді та одне одному заважають. Потім людей стає умовно 500 — і проблеми тільки наростають.

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

— Які є виклики та ризики в разі переходу на мікросервіси і як з ними боротися?

— Сам по собі перехід на мікросервісну архітектуру не є апріорі позитивом, бо якщо зробити це незважено, то стане тільки гірше. Це досить поширена проблема, якщо за перехід беруться люди, які не мають досвіду та знань у цьому.

Але навіть якщо ви знаєте, як правильно спроєктувати та реалізувати мікросервіси, залишається відкритим питання, як з ними потім жити:

• Перше, про що інженери часто забувають, — це необхідність погодити організаційну структуру з новою архітектурою. Наприклад, якщо у вас при монолітній архітектурі була одна команда з 30 людей, під час переходу на мікросервіси є сенс розбити ці 30 людей на менші команди по п’ять працівників.
• Під час переходу більш актуальним стає питання девопсингу. При моноліті здебільшого мають один сервер, а у випадку з мікросервісною архітектурою — безліч серверів, про які треба дбати, моніторити та розгортати там код. Навіть прості операції з інфраструктурою в цій ситуації будуть ускладнені, тож готуйтесь інвестувати в девопс-культуру та високоякісних інженерів.
• Також не слід забувати про моніторинг. Раніше у вас все оброблялося в одному місці, де писали логи, і було достатньо їх там почитати, щоби зрозуміти, що коїться. А тепер у вас один запит користувача стрибає по різних сервісах — і вам треба розуміти, де в цей момент щось пішло не так.
• Те саме стосується і питань безпеки. Умовно, у вас є десь бридж, через який намагається потрапити зловмисник. А чи знатимете ви, куди саме він намагається потрапити, чи це залишиться для вас непоміченим?

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

— У яких випадках мікросервісна архітектура буде не найкращим рішенням і від неї краще утриматися?

— Передусім якщо ви тільки починаєте проєкт і маєте слабке уявлення про те, що розроблятимете. В цьому випадку зосередьтеся на предметі розробки, зробіть якийсь proof of concept, а далі подивіться, які у вас є проблеми й чи можливо розв’язати їх мікросервісами. Крім того, враховуйте й домен вашого проєкту та його особливості.

Іноді монолітна система — це свідомий вибір компаній, що обирають тримати невелику команду, як це робить Stack Overflow. Команди можуть бути досить компактні, а продукти — доволі великі та успішні. І якщо команда мала, то це ускладнить життя одного інженера, якому доведеться бігати по десятках мікросервісів, коли вас усього пʼятеро. Маленька команда — це точно не застереження до використання мікросервісів, але фактор, на який треба зважати.

Також у випадку мікросервісної архітектури складніше розв’язати питання розподілу транзакцій. Уявімо сайт із продажу квитків у кіно:

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

В якій послідовності рухатися?

• якщо ми спочатку беремо гроші, а потім бронюємо місце, то ми можемо взяти гроші за заброньоване місце;
• а якщо спочатку бронювати — так користувач зможе забронювати весь зал без викупу квитків.

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

Як перейти на мікросервіси вчасно та без проблем

— Які проблеми зазвичай розв’язує мікросервісна архітектура?

• Розростання організації, коли люди починають заважати одне одному через величину команд. Якщо з приходом нової людини в команду швидкість розробки не зростає, а інколи навіть спадає, то варто придивитися до мікросервісів.
• Набір технологій, які ви обрали, починає вас сильно обмежувати. Умовно, код написано на Java, а тепер вам потрібне machine learning рішення з бібліотеками на Python. Різними мовами в одній кодовій базі ви писати не будете, тож це шлях до сервіс-орієнтованої архітектури. У цьому випадку ви можете реалізувати окрему частину іншою мовою або з іншою базою даних.
• Масштабування системи. Уявімо, що у вас є новинний сайт і умовний графік користувацької активності. Наприклад, о 14:00 люди йдуть на обід і читають новини: починається наплив користувачів, а далі активність знову падає до звичної. В цьому випадку немає потреби платити за великі потужності протягом усієї доби: вони потрібні лише в моменти пікового навантаження. Тут дуже виручає мікросервісна архітектура, яка дає можливість підсилитися саме там, де потрібно.

курс: Мікросервісна архітектура

Владислав Карнаушенко Tech lead manager у Preply

 

— На якому етапі варто задуматися про перехід на мікросервіс?

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

Ще один важливий момент — навантаження. Ваш продукт росте, кількість користувачів подвоюється, умовно, щомісяця чи раз на пів року. В цьому випадку ви можете спрогнозувати потенційні навантаження, які вас чекають через рік-півтора, і проаналізувати, чи витримаєте їх. Якщо так, то чи адекватною буде ціна цих ресурсів і чи не дешевше це обходитиметься в разі використання мікросервісної архітектури.

— Що робити, коли вже пора, а тімлід сумнівається і не поспішає переходити на мікросервіси?

— Покажіть ефективність мікросервісів на конкретному прикладі. Винесіть з моноліту один мікросервіс, прийдіть до керівництва і покажіть: «Було отак, а стало на 50 % швидше. Хочете, щоби ми рухалися в такому напрямку? Пріоритезуйте це завдання, виділіть ресурси — і працюємо».

З іншого боку, якщо керівництво досі не хоче полишати моноліт, то тепер на певні технічні проблеми ви маєте право реагувати аргументом «а якби ми перейшли на мікросервіс, то цього не було б» (сміється. — Ред.). З етичних міркувань це не найправильніший спосіб, але доволі дієвий.

Важливо розуміти, хто в кінцевому результаті є бізнесовим стейкхолдером. Завдання тех- і тімліда — виконати роботу за встановлений час та з належною якістю. Але досить часто вони можуть опускати бізнесові потреби або не застосовувати стратегічного роду мислення. У результаті через умовні два роки на старій архітектурі ви змушені будете призупинити розробку, адже закопаєтеся настільки, що далі рухатися буде неможливо.

Тому гарним рішенням буде спробувати мітинг у форматі n+1: зібратися командою та поговорити з керівником вашого керівника і розказати про ваші побоювання. Бо якщо тех- чи тімлід фокусується на технічному виконанні роботи, то СТО першою чергою думає про гроші. І якщо ви зможете звести все до фінансів — це вже половина успіху.

Ціна переходу на мікросервіс

— Якраз якщо говорити про фінанси, то скільки це коштує і наскільки виправдана така інвестиція?

— Оцінюючи потенційний перехід, варто застосувати cost-benefit аналіз: що ми отримаємо і скільки на це витратимо. Якщо ви вирішили переїжджати на мікросервіси, то перш за все вам потрібно схематично намалювати вашу архітектуру і зрозуміти, який після завершення міграції все матиме вигляд.

Дещо спрощена, але зрозуміла схема архітектури

Деталізована схема архітектури з мобільним застосунком та вебверсією

Далі слід оцінити, скільки ресурсів потрібно для цього і чи розв’яже остаточний результат проблеми, які стали причиною переходу на мікросервісну архітектуру.

Оцінили, все зважили, тепер починаємо рахувати:

• Нехай нам потрібно буде залучення 20 фахівців протягом шести місяців. Рахуємо вартість їхньої роботи.
• Також у нас є низка проблем, через які ми вирішили мігрувати на мікросервіси. Вплив цих проблем, найімовірніше, теж можна порахувати у грошовому еквіваленті: скільки ми втрачаємо через те, що наша архітектура така, якою є зараз.
• Далі постає питання, за скільки часу мікросервіс себе окупить. Більша частина витрат буде локалізована в часі: умовно, ми передбачаємо три місяці активних витрат, які окупатимуться наступні два роки. І якщо компанія бачить майбутнє цього проєкту в такій часовій перспективі, а витрати виправдані, то рішення про перехід є очевидним.

— Чи можна виокремити якісь КРІ переходу на мікросервісну архітектуру?

— У першу чергу треба відштовхуватися від проблем, які надихнули вас на міграцію. В архітектурі є поняття нефункціональних вимог. Наприклад, є сайт з продажу книг, і його головний функціональний обовʼязок — продавати книги, а нефункціональні вимоги — бути стабільним, безпечним тощо. Нефункціональні вимоги різняться залежно від типу сервісу (приміром, для банку в пріоритеті безпека), тому ви аналізуєте та вимірюєте, які показники хочете змінити.

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

Також не варто забувати про guard-rail метрики та речі, на яких ви не фокусуєтеся першою чергою під час міграції на мікросервісну архітектуру, але які також не мають просідати.

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