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

Здраво, Хабр! Представљам вашој пажњи ауторски превод чланка Микросервис – комбинаторна експлозија верзија.

У време када се ИТ свет постепено креће ка микросервисима и алатима као што је Кубернетес, само један проблем постаје све уочљивији. Овај проблем - комбинаторна експлозија микросервисне верзије. Ипак, ИТ заједница верује да је тренутно стање много боље од "Пакао зависности" претходне генерације технологије. Међутим, верзионисање микросервиса је веома сложен проблем. Један доказ за то могу бити чланци попут "Врати ми мој монолит".

Ако и даље не разумете проблем читањем овог текста, дозволите ми да објасним. Рецимо да се ваш производ састоји од 10 микросервиса. Сада претпоставимо да је пуштена 1 нова верзија за сваку од ових микросервиса. Само 1 верзија - надам се да се сви можемо сложити да је ово врло тривијална и безначајна чињеница. Сада, међутим, хајде да још једном погледамо наш производ. Са само једном новом верзијом сваке компоненте, сада имамо 2^10 - или 1024 пермутације начина на који се наш производ може саставити.

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

Наставимо даље наше размишљање – шта ће се десити ако имамо 100 микросервиса и сваки има 10 могућих верзија? Цела ситуација постаје прилично непријатна - сада имамо 10^100 пермутација - што је огроман број. Међутим, радије бих ову ситуацију означио на овај начин, јер се сада више не кријемо иза речи попут „кубернетес“, већ се суочавамо са проблемом какав јесте.

Зашто сам толико фасциниран овим проблемом? Делом зато што смо, пошто смо претходно радили у свету НЛП-а и АИ, много расправљали о проблему комбинаторне експлозије пре 5-6 година. Само уместо верзија имали смо појединачне речи, а уместо производа реченице и пасусе. И иако проблеми НЛП-а и АИ остају углавном нерешени, мора се признати да је у последњих неколико година направљен значајан напредак (по мом мишљењу, напредак би се могао постићиоБило би боље када би људи у индустрији посветили мало мање пажње машинском учењу, а мало више другим техникама – али ово је већ ван теме).

Вратимо се у свет ДевОпс-а и микросервиса. Суочени смо са огромним проблемом, маскирајући се у слона у Кунсткамери - јер оно што често чујем је „само узми кубернете и кормило, и све ће бити у реду!“ Али не, неће све бити у реду ако се све остави како јесте. Штавише, аналитичко решење овог проблема не изгледа прихватљиво због његове сложености. Као иу НЛП-у, овом проблему прво треба да приступимо сужавањем опсега претраге — у овом случају, елиминисањем застарелих пермутација.

Једна од ствари која би могла помоћи је нешто што сам написао прошле године о потреби одржавања минималне разлике између верзија објављених за клијенте. Такође је важно напоменути да добро дизајниран ЦИ/ЦД процес у великој мери помаже у смањењу варијација. Међутим, тренутно стање са ЦИ/ЦД није довољно добро да реши проблем пермутација без додатних алата за компоненте рачуноводства и праћења.

Оно што нам је потребно је систем експериментисања у фази интеграције, где можемо да одредимо фактор ризика за сваку компоненту, а такође имамо аутоматизован процес за ажурирање различитих компоненти и тестирање без интервенције оператера – да видимо шта ради, а шта не.

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

1. Програмери пишу тестове (ово је критична фаза - јер иначе немамо критеријум за евалуацију - то је као означавање података у машинском учењу).
2. Свака компонента (пројекат) добија свој ЦИ систем - овај процес је сада добро развијен, а питање креирања ЦИ система за једну компоненту је у великој мери решено
3. „Систем паметне интеграције“ прикупља резултате различитих ЦИ система и саставља пројекте компоненти у финални производ, покреће тестирање и коначно израчунава најкраћи пут до добијања жељене функционалности производа на основу постојећих компоненти и фактора ризика. Ако ажурирање није могуће, овај систем обавештава програмере о постојећим компонентама и која од њих изазива грешку. Још једном, систем тестирања је овде од критичне важности – пошто систем интеграције користи тестове као критеријум евалуације.
4. ЦД систем, који затим прима податке од Смарт Интегратион Систем и директно врши ажурирање. Ова фаза завршава циклус.

Да резимирам, за мене је један од највећих проблема сада недостатак таквог „система паметне интеграције“ који би повезао различите компоненте у производ и тако вам омогућио да пратите како је производ у целини састављен. Занимају ме мишљења заједнице о овоме (спојлер - тренутно радим на пројекту Релиза, који може постати тако паметан систем интеграције).

Последња ствар коју желим да поменем је да за мене монолит није прихватљив ни за један пројекат чак и средње величине. За мене, покушаји да се убрза време имплементације и квалитет развоја враћањем у монолит изазивају велики скептицизам. Прво, монолит има сличан проблем управљања компонентама - међу разним библиотекама од којих се састоји, међутим, све то није толико приметно и манифестује се првенствено у времену које програмери троше. Последица проблема монолита је виртуелна немогућност измене кода - и изузетно спора брзина развоја.

Микросервис побољшава ситуацију, али тада се микросервисна архитектура суочава са проблемом комбинаторне експлозије у фази интеграције. Да, генерално, прешли смо исти проблем из фазе развоја у фазу интеграције. Међутим, по мом мишљењу, приступ микросервисима и даље доводи до бољих резултата, а тимови брже постижу резултате (вероватно углавном због смањења величине развојне јединице – или величина серије). Међутим, прелазак са монолита на микросервис још увек није довољно унапредио процес – комбинаторна експлозија верзија микросервиса је огроман проблем и имамо много потенцијала да побољшамо ситуацију док је решавамо.

Извор: ввв.хабр.цом