Перехід від моноліту до мікросервісів

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

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

Спочатку моноліт

По-перше, поширений підхід «» спочатку моноліт «» повністю виправданий і бачиться розумним компромісом між вартістю розробки і швидкістю розробки. Невеликий монолітний додаток має кілька цілком очевидних переваг, одна з головних - швидкість додавання нової функціональності. У нашому монолітному проекті простіше переглянути зв'язність кодової бази і переконається, що нова, тільки що додана, функціональність працює. Безсумнівно, досвідчений читач зауважить, що мікросервіси дозволяють домогтися слабкої зв'язності різних частин програми, але не варто забувати, що в більшості випадків монолітні проекти, що активно розвиваються, мають кодову базу не найвищої якості.

Від мікросервісів не піти

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

Головне почати

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

Вищезгадані три твердження ставлять перед нами два питання: коли і як. Давайте по порядку.

Як зрозуміти, що настав той самий момент, що пора вже пиляти мікросервіси?

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

Виділяти мікросервіси вже стає запізно, якщо виникає бажання кешувати html-сторінки цілком, тому що гальмують, а щоб прискорити, потрібно переписати половину програми, замінити ORM або взагалі переписати все іншою мовою, де все добре і програми не гальмують.

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

І найголовніший критерій необхідності почати переходити на мікросервісну архітектуру - коли вартість додавання нової фічі починає перевершувати вигоду від цієї самої фічі.

З чого почати міграцію архітектури на користь мікросервісів?

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

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

У кінцевому рахунку, у разі переходу до мікросервісної архітектури можна назвати спосіб, коли основний монолітний додаток розбивається на кілька великокаліберних програм з сильною взаємною зв'язковістю. Після чого підприкладання розглядаються і рефакторяться окремо, попутно зачіпаючи сусідів і змушуючи їх пристосовуватися і змінюватися разом. Поступово такий підхід призведе до зменшення зв'язності і появи усталеного інтерфейсу кожного підприкладу. При досягненні такої ось усталеної часової точки, представляється можливим вносити зміни до підприкладів, не зачіпаючи при цьому сусідні. І цей підприклад розглядається, як моноліт простіший і рівнем нижче. І з ним виконуються аналогічні процедури. Поступово додаток б'ється на більш-менш рівні частини. Деякі частини в процесі стають непотрібними, деякі дублюють існуючі інші частини або взагалі зливаються в один загальний сервіс для усунення дублювання. У підсумку рано, або швидше пізно, виходить усталений додаток на мікросервісній архітектурі.

Замість висновків.

Мікросервіси - добре. Моноліт - добре. Хороший код - добре. Робочий код - добре. Стаття не закликає терміново змінювати принцип розробки в додатках, які гальмують, криво написані або написані не так, як хотілося б. Так само мікросервісна архітектура не є панацеєю від усіх бід розробників. У статті описуються точки і способи переходу від монолітної до мікросервісної архітектури.

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