Микроуслуги - комбинаторна експлозия от версии

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

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

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

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

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

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

Да се ​​върнем към света на DevOps и микроуслугите. Изправени сме пред огромен проблем, маскирайки се като слон в Kunstkamera - защото това, което често чувам е „просто вземете kubernetes и кормилото и всичко ще бъде наред!“ Но не, всичко няма да е наред, ако всичко остане както е. Освен това аналитичното решение на този проблем не изглежда приемливо поради неговата сложност. Както в НЛП, първо трябва да подходим към този проблем, като стесним обхвата на търсене - в този случай, като елиминираме остарелите пермутации.

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

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

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

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

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

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

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

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