Одавно сам желео да напишем чланак на тему микросервисне архитектуре, али су ме две ствари стално спречавале – што сам више залазио у тему, све ми се више чинило да је оно што знам очигледно, а оно што не знам. т знати треба проучавати и проучавати. С друге стране, мислим да већ има о чему да се разговара у широкој публици. Дакле, алтернативна мишљења су добродошла.
Конвејев закон и однос између пословања, организације и информационог система
Још једном ћу себи дозволити да цитирам:
"Свака организација која дизајнира систем (у ширем смислу) добиће дизајн чија структура реплицира структуру тимова у тој организацији."
- Мелвин Конвеј, 1967
По мом мишљењу, овај закон се више односи на изводљивост организовања бизниса, него директно на информациони систем. Дозволите ми да објасним на примеру. Рецимо да имамо прилично стабилну пословну прилику са животним циклусом такве дужине да има смисла организовати предузеће (ово није грешка у куцању, али ми се јако свиђа овај термин који сам украо). Наравно, систем подршке овом послу ће организационо и процесно одговарати овом послу .
Пословна оријентација информационих система
Дозволите ми да објасним на примеру. Рецимо да постоји пословна прилика да се организује посао продаје пице. У верзији В1 (назовимо то прединформацијом) фирма је била пицерија, каса и доставна служба. Ова верзија је била дуготрајна у условима ниске варијабилности животне средине. Затим је верзија 2 дошла да га замени – напреднија и способна да користи информациони систем у својој сржи за пословање са монолитном архитектуром. А овде је, по мом мишљењу, једноставно страшна неправда у односу на монолите - наводно монолитна архитектура не одговара пословном моделу домена. Да, да је тако, систем уопште не би могао да функционише – у супротности са истим Конвејевим законом и здравим разумом. Не, монолитна архитектура је у потпуности у складу са пословним моделом у овој фази развоја пословања – ту, наравно, мислим на фазу када је систем већ креиран и пуштен у рад. Апсолутно је дивна чињеница да ће, без обзира на архитектонски приступ, и сервисно оријентисана архитектура верзија 3 и микросервисна архитектура верзија Н радити подједнако добро. Шта је цака?
Све тече, све се мења, или су микросервисе средство за борбу против сложености?
Пре него што наставимо, погледајмо неке заблуде о архитектури микросервиса.
Заговорници коришћења микросервисног приступа често тврде да разбијање монолита на микросервисе поједностављује развојни приступ смањењем базе кода појединачних услуга. По мом мишљењу, ова изјава је потпуна бесмислица. Озбиљно, очигледна интеракција унутар монолитног и хомогеног кода изгледа компликовано? Да је то заиста тако, сви пројекти би се у почетку градили као микросервис, док пракса показује да је миграција са монолита на микросервисе много чешћа. Комплексност не нестаје; она се једноставно креће са појединачних модула на интерфејсе (било да су у питању магистрале података, РПЦ, АПИ-ји и други протоколи) и системи оркестрирања. А ово је тешко!
Предност коришћења хетерогеног стека је такође упитна. Нећу тврдити да је и то могуће, али у стварности се то ретко дешава (Гледајући унапред – ово би требало да се деси – али пре као последица, а не као предност).
Животни циклус производа и животни циклус производа
Погледајте још једном дијаграм изнад. Није случајно што сам приметио опадајући животни циклус посебне верзије пословања – у савременим условима за успех је одлучујуће убрзање транзиције пословања између верзија. Успех производа је одређен брзином тестирања пословних хипотеза у њему. И ту, по мом мишљењу, лежи кључна предност микросервисне архитектуре. Али идемо редом.
Пређимо на следећу фазу у еволуцији информационих система – на сервисно оријентисану архитектуру СОА. Дакле, у неком одређеном тренутку смо истакли у нашем производу дуговечне услуге - дуговечне у смислу да када се крећете између верзија производа, постоји шанса да ће животни циклус услуге бити дужи од животног циклуса следеће верзије производа. Логично би било да их уопште не мењамо – ми Оно што је битно је брзина преласка на следећу верзију. Али авај, принуђени смо да правимо сталне промене у услугама – и овде све функционише за нас, ДевОпс праксе, контејнеризација и тако даље – све што нам падне на памет. Али то још увек нису микросервис!
Микросервис као средство за борбу против сложености... управљање конфигурацијом
И овде коначно можемо да пређемо на дефинишућу улогу микросервиса – ово је приступ који поједностављује управљање конфигурацијом производа. Детаљније, функција сваког микросервиса описује управо пословну функцију унутар производа према моделу домена – а то су ствари које не живе у краткотрајној верзији, већ у дуговечној пословној прилици. А прелазак на следећу верзију производа се дешава буквално непримећено – промените/додајете један микросервис, а можда и само шему њихове интеракције, и одједном се нађете у будућности, остављајући иза себе уплакане конкуренте који настављају да скачу између верзија њихови монолити. Сада замислите да постоји прилично велика количина микросервиса са унапред дефинисаним интерфејсима и пословним могућностима. А ви долазите и градите структуру свог производа од готових микросервиса – једноставним цртањем дијаграма, на пример. Честитамо - имате платформу - и сада можете привући посао за себе. Дреамс Дреамс.
Налази
- Архитектура система треба да буде одређена животним циклусом његових компоненти. Ако компонента живи у верзији производа, нема смисла повећавати сложеност система коришћењем микросервисног приступа.
- Микросервисна архитектура би требало да се заснива на моделу домена – јер је пословна прилика најдуговечнији домен
- Пракса испоруке (ДевОпс праксе) и оркестрација су једни од најважнијих за микросервисну архитектуру – из разлога што повећање стопе промене компоненти поставља повећане захтеве за брзином и квалитетом испоруке.
Извор: ввв.хабр.цом