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

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

В епохата, когато светът на ИТ постепенно преминава към микросервизи и инструменти като 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