Прывітанне, Хабр! Уяўляю вашай увазе аўтарскі пераклад артыкула .
У часы калі мір IT паступова пераходзіць на мікрасэрвісы і прылады накшталт Kubernetes, усё больш прыкметнай становіцца толькі адна праблема. Гэтая праблема - версій мікрасэрвісаў. Усё ж IT супольнасць мяркуе, што сённяшняя сітуацыя значна лепшая, чым папярэдняга пакалення тэхналогій. Тым не менш, кіраванне версіямі мікрасэрвісаў вельмі складаная праблема. Адным з доказаў гэтаму могуць служыць артыкулы накшталт .
Калі вы чытаючы гэты тэкст пакуль не разумееце праблему, дазвольце мне растлумачыць. Выкажам здагадку, ваш прадукт складаецца з 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 не дастаткова добра для вырашэння праблемы пермутацый без дадатковага інструментара ўліку і адсочвання кампанентаў.
Што нам трэба – гэта сістэма эксперыментаў на стадыі інтэграцыі, дзе мы маглі б вызначыць фактар рызыка па кожным кампаненце, а таксама мець аўтаматызаваны працэс абнаўлення розных кампанентаў і тэсціравання без умяшання аператара – каб бачыць што працуе, а што не.
Такая сістэма эксперыментаў магла б выглядаць наступным чынам:
- Дэвелаперы пішуць тэсты (гэта крытычны этап – таму што інакш у нас няма крытэра ацэнкі – гэта як разметка дадзеных у машынным навучанні).
- Кожны кампанент (праект) атрымлівае сваю ўласную CI сістэму - гэты працэс на сённяшні дзень добра прапрацаваны, і пытанне стварэння CI сістэмы для адзінкавага кампанента шмат у чым вырашана
- "Разумная сістэма інтэграцыі" збірае вынікі розных CI сістэм і збірае праекты-кампаненты ў фінальны прадукт, запускае тэставанне і нарэшце вылічае найбольш кароткі шлях да атрымання патрэбнай функцыянальнасці прадукта зыходзячы з існуючых кампанентаў і фактараў рызыка. Калі здзейсніць абнаўленне немагчыма, гэтая сістэма апавяшчае распрацоўнікаў аб наяўных кампанентах і на якім з іх адбываецца памылка. Яшчэ раз паўтару, што сістэма тэстаў тут валодае крытычнай важнасцю - бо сістэма інтэграцыі выкарыстоўвае тэсты як крытэр ацэнкі.
- CD сістэма, якая затым атрымлівае дадзеныя з "Разумнай сістэмы інтэграцыі" і вырабляе непасрэдна абнаўленне. Гэтая стадыя заканчвае цыкл.
Падагульняючы, для мяне адна з самых вялікіх праблем цяпер - гэта адсутнасць такой "Разумнай сістэмы інтэграцыі", якая б звязвала розныя кампаненты ў прадукт і такім чынам дазваляла адсочваць, якім чынам прадукт у цэлым складзены. Мне будуць цікавыя думкі супольнасці з гэтай нагоды (спойлер - я зараз працую над праектам , якая можа стаць такой разумнай сістэмай інтэграцыі).
Адна апошняя рэч, якую я хачу згадаць, — для мяне маналіт не з'яўляецца прымальным для любога праекту хаця б сярэдняга памеру. Для мяне выклікаюць вялікі скептыцызм спробы паскорыць час рэалізацыі і якасць распрацоўкі за рахунак вяртання да маналіту. Па-першае, маналіт мае падобную праблему кіравання кампанентамі – сярод розных бібліятэк, з якіх ён складаецца, аднак усё гэта не так прыкметна і выяўляецца ў першую чаргу ў часе, які марнуюць распрацоўшчыкі. Следствам праблемы маналіта з'яўляецца фактычная немагчымасць уносіць змены ў код - і вельмі павольная хуткасць распрацоўкі.
Мікрасэрвісы паляпшаюць сітуацыю, аднак затым мікрасэрвісная архітэктура сутыкаецца з праблемай камбінаторнага выбуху на стадыі інтэграцыі. Так, у цэлым, мы перасунулі тую ж самую праблему - са стадыі распрацоўкі на стадыю інтэграцыі. Аднак, на мой погляд, падыход мікрасэрвісаў усё ж прыводзіць да лепшых вынікаў, і каманды дасягаюць вынікаў хутчэй (верагодна, у асноўным, з-за памяншэння памераў адзінкі распрацоўкі – або памер партыі). Аднак, пераход ад маналіта да мікрасэрвісаў пакуль не даў дастатковага паляпшэння працэсу – камбінаторны выбух версій мікрасэрвісаў – гэта велізарная праблема, і ў нас ёсць вялікі патэнцыял паляпшэння сітуацыі па меры яе рашэння.
Крыніца: habr.com