Микросервизите — комбинаторен взрив на версии

Здравей, Хабр! Представям ви авторски превод на статията Микросервизи – Комбинаторен взрив на версиите.

Въпреки че светът на ИТ постепенно преминава към микросервизи и инструменти като Kubernetes, все по-осезаема става само една проблема. Тази проблема е комбинаторен взрив на версиите на микросервисите. Въпреки това, ИТ общността вярва, че настоящата ситуация е значително по-добра от «Ад на зависимостите» от предишното поколение технологии. Все пак, управлението на версиите на микросервисите е доста сложен проблем. Едно от доказателствата за това могат да бъдат статии като «Върнете ми моя монолит».

Ако все още не разбирате проблема, позволете ми да обясня. Да предположим, че вашият продукт се състои от 10 микросервизи. Сега да предположим, че за всеки от тези микросервизи излиза 1 нова версия. Само 1 версия – надявам се, че всички можем да се съгласим, че това е доста тривиален и незначителен факт. Но сега нека погледнем отново на нашия продукт. С една нова версия за всеки компонент, сега имаме 2^10 – или 1024 пермутации на това как може да изглежда нашият продукт.

Ако все още имате неразбиране, позволете ми да разложа математиката. И така, имаме 10 микросервизи, всеки получава едно обновление. Тоест, получаваме 2 възможни версии на всеки микросервис (или стара, или нова). Сега, за всеки от компонентите на продукта можем да използваме която и да е от тези две версии. Математически, това е същото като да имаме двоично число от 10 знака. Например, да кажем, че 1 е новата версия, а 0 е старата версия – тогава една възможна пермутация може да бъде обозначена като 1001000000 – където 1-ви и 4-ви компоненти са обновени, а всички останали не. От математиката знаем, че двоично число от 10 знака може да има 2^10 или 1024 стойности. Тоест, потвърдихме мащабите на числото, с което имаме работа.

Нека продължим разсъжденията – какво ще се случи, ако имаме 100 микросервиза и всеки от тях има 10 възможни версии? Цялата ситуация става доста неприятна – сега имаме 10^100 пермутации – а това е огромно число. Въпреки това, предпочитам да обознача тази ситуация именно така, защото сега не се крием зад думи като „kubernetes“, а срещаме проблема такъв, какъвто е.

Защо тази проблема ме впечатлява толкова? Отчасти защото, когато работех преди в света на NLP и AI, много дискутирахме проблема с комбинаторния взрив преди 5-6 години. Само вместо версии имахме отделни думи, а вместо продукти - предложения и параграфи. И въпреки че проблемите на NLP и AI остават до голяма степен нерешени, трябва да признаем, че напредък е направен през последните няколко години. (според мен, напредъкът би могъл да бъде по-по-значителен, ако хората в индустрията обръщаха малко по-малко внимание на машинното обучение и малко повече на другите техники — но това е вече извън темата).

Върнах се към света на DevOps и микросервисите. Пред нас стои огромен проблем, който се маскира като слон в художествена галерия — често чувам „просто вземи Kubernetes и Helm и всичко ще е наред!“ Но не, всичко няма да е наред, ако оставим всичко както е. Освен това, аналитичното решение на този проблем не изглежда приемливо заради сложността. Както и в NLP, трябва първо да подходим към този проблем, като стесним обхвата на търсене — в този случай чрез изключване на остарели пермутации.

Едно от нещата, които биха помогнали — писах миналата година за необходимостта да се поддържа минимален разпад между версиите, предоставяни на клиентите.Също така е важно да се отбележи, че добре проработеният процес CI/CD много помага в намаляването на вариациите. Въпреки това, текущото състояние на CI/CD не е достатъчно добре за решаване на проблема с пермутациите без допълнителен инструментариум за проследяване и управление на компонентите.

Какво ни е нужно — това е система за експерименти в стадия на интеграция, където можем да определим фактора на риска за всеки компонент, а също така да имаме автоматизиран процес за обновление на различни компоненти и тестване без намеса от оператор — за да видим какво работи и какво не.

Такава система за експерименти може да изглежда по следния начин:

1. Разработчиците пишат тестове (това е критичен етап — защото иначе нямаме критерий за оценка — точно както маркирането на данни в машинното обучение).
2. Всеки компонент (проект) получава своя собствена CI система — този процес в наши дни е добре проработен, и въпросът за създаването на CI система за единичен компонент до голяма степен е решен.
3. „Умна интеграционна система“ събира резултатите от различни CI системи и агрегира проектни компоненти в финален продукт, извършва тестване и накрая изчислява най-краткия път до получаване на необходимата функционалност на продукта, базирайки се на наличните компоненти и рискови фактори. Ако обновлението е невъзможно, тази система уведомява разработчиците за наличните компоненти и за това, на кой от тях се появява грешка. Ще повторя, че системата за тестове тук е критично важна - тъй като интеграционната система използва тестовете като критерий за оценка.
4. CD системата, която след това получава данни от „Умната интеграционна система“ и извършва непосредственото обновление. Тази фаза завършва цикъла.

В обобщение, за мен една от най-големите проблеми в момента е липсата на такава „Умна интеграционна система“, която да свързва различни компоненти в продукта и по този начин да позволява проследяване на начина, по който е съставен самият продукт. Ще се интересувам от мнението на общността по този въпрос (спойлер - в момента работя по проект Reliza, който може да стане такава умна интеграционна система).

Една последна работа, която искам да спомена - за мен монолитът не е приемлив за който и да е проект с поне среден обем. Опитите да се ускори времето за реализация и качеството на разработка за сметка на връщането към монолита предизвикват голям скептицизъм у мен. На първо място, монолитът има подобен проблем с управлението на компонентите - сред различните библиотеки, от които се състои, но всичко това не е толкова забележимо и се проявява основно във времето, което разработчиците губят. Последствието на проблема с монолита е фактическата невъзможност за извършване на промени в кода - и изключително бавната скорост на разработка.

Микросервисите подобряват ситуацията, обаче след това микросервисната архитектура се сблъсква с проблема на комбинаторния взрив на етапа на интеграция. Да, като цяло, ние преместихме същия проблем - от етапа на разработка на етапа на интеграция. Въпреки това, според мен, подходът с микросервизите все пак води до по-добри резултати, и екипите достигат до решения по-бързо (вероятно, основно, заради намалените размери на единицата разработка - или batch size). Въпреки това, преходът от монолит към микросервизи все още не е довел до достатъчно подобрение в процеса — комбинаторният взрив на версиите на микросервисите е огромен проблем и имаме голям потенциал за подобрение на ситуацията, докато я решаваме.

Източник: habr.com