Na temat tego jakim uciąż­li­wym dłu­giem tech­no­lo­gicz­nym jest mono­li­tycz­ny sys­tem napi­sa­no wie­le, dzi­siaj kolej­ne dwie cie­ka­we pozy­cje lite­ra­tu­ry: CMMI Compliant Modernization Framework to Transform Legacy Systems oraz Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices . Pierwsza publi­ka­cja opi­su­je meto­dę zapla­no­wa­nia wyj­ścia z dłu­gu tech­no­lo­gicz­ne­go z per­spek­ty­wy ana­li­zy biz­ne­so­wej, dru­ga opi­su­je moż­li­wą reali­za­cję tech­nicz­ną z per­spek­ty­wy archi­tek­tu­ry apli­ka­cji i ewo­lu­cyj­nej migra­cji z archi­tek­tu­ry mono­li­tycz­nej do kom­po­nen­to­wej (mikro-ser­wi­sy).

Czym jest monolit?

Jest to sys­tem, któ­re­go archi­tek­tu­ra sta­no­wi jeden nie­po­dziel­ny blok reali­zu­ją­cy funk­cje biz­ne­so­we. Kluczową cechą i zara­zem wadą, mono­li­tu jest wewnętrz­na ​„zależ­ność wszyst­kie­go od wszyst­kie­go”. Każda moder­ni­za­cja z zasa­dy doty­czy całe­go sys­te­mu, jest więc i bar­dzo kosz­tow­na i bar­dzo ryzykowna.

W efek­cie użyt­kow­nik jest uza­leż­nio­ny od jed­ne­go dostaw­cy, jaka­kol­wiek zmia­na orga­ni­za­cyj­na pocią­ga za sobą pra­ce porów­ny­wal­ne z nakła­dem środ­ków i cza­su jak w pier­wot­nym wdro­że­niu tego sys­te­mu, a nie raz te kosz­ty są więk­sze. Upgrade takie­go sys­te­mu, jeże­li był kasto­mi­zo­wa­ny, zawsze wyma­ga powtó­rze­nia całe­go wdro­że­nia od początku.

Jest to archi­tek­tu­ra rodem z lat 80-tych ubie­głe­go wie­ku (dla­te­go nazy­wa­na jest lega­cy sys­tem czy­li sys­tem prze­sta­rza­ły), jej ogól­na postać: 

Architektura ta jest nadal głów­ną cechą wie­lu sys­te­mów ERP na ryn­ku, nawet tych bar­dzo zna­nych. W obec­nych cza­sach jest to źró­dłem wie­lu kło­po­tów orga­ni­za­cji, któ­re wdro­ży­ły taki sys­tem i muszą szyb­ko reago­wać na zmia­ny na rynku. 

Wdrożenie w fir­mie jed­ne­go mono­li­tycz­ne­go sys­te­mu ERP to tak zwa­ny ​„big bang”, czy­li wszyst­ko albo nic, co w zasa­dzie niko­mu sie nadal nie uda­ło. Dlatego coraz czę­ściej podej­mo­wa­ne są pró­by ewo­lu­cyj­ne­go, bez­piecz­ne­go dla całej orga­ni­za­cji, płyn­ne­go wyj­ścia z tego dłu­gu jakim jest mono­li­tycz­na archi­tek­tu­ra sys­te­mu IT. Jak to zrobić? 

Etap 1: Analiza biznesowa

Na tym eta­pie nale­ży zebrać doku­men­ty ope­ra­cyj­ne: te opi­su­ją­ce posia­da­ny ​„mono­lit” i te będą­ce jego pro­duk­ta­mi (wydru­ki, for­mu­la­rze itp.). Analiza ich powin­na zaowo­co­wać ana­li­tycz­nym mode­lem pro­ce­sów biz­ne­so­wych (mode­lo­wa­nie pro­ce­sów). Dysponując tymi wszyst­ki­mi doku­men­ta­mi oraz zebra­ny­mi ocze­ki­wa­nia­mi inte­re­sa­riu­szy, opra­co­wu­je­my doku­ment wyma­gań wobec nowe­go sys­te­mu, w tym tak­że jego ogól­ną architekturę: 

Dokumentacja i utrzy­ma­nie wyma­gań:
KP 1.1 Przygotowanie Macierzy Śledzenia Wymagań w celu śle­dze­nia spój­no­sci ich zmian
KP 1.2 Ustalenie ról i odpo­wie­dzial­no­ści wszyst­kich uczest­ni­ków pro­jek­tu
KP 1.3 Omówienie potrzeb z inte­re­sa­riu­sza­mi i metod roz­wią­za­nia pro­ble­mów
KP 1.4 Opracowana [w toku ana­li­zy] doku­men­ta­cja wyma­gań pod­pi­sa­na przez wszyst­kich interesariuszy

Etap 2: Realizacja

Tu pole­cam dru­gą publi­ka­cję. Jest to jed­na z cie­kaw­szych pozy­cji na mojej pół­ce. Opisuje ona meto­dę migra­cji z mono­li­tycz­nej do bar­dziej otwar­tej i zwin­nej archi­tek­tu­ry. Odbywa się to powo­li, i na począ­tek raczej w gło­wach pro­jek­tan­tów, póź­niej dopie­ro w pro­jek­tach i wdrożeniach. 

Jak już wspo­mnia­no wyżej, klu­czo­wą wadą mono­li­tów jest ich ocię­ża­łość, skut­ku­ją­ca tym, że ich roz­wój i roz­bu­do­wa bar­dzo szyb­ko zmie­nia się w wal­kę w ich wiel­ko­ścią. Powodem tego jest wła­śnie owa sil­na wewnętrz­na ​„zależ­ność wszyst­kie­go od wszystkiego”. 

Pewnym postę­pem jest wewnętrz­ne ​„upil­no­wa­nie” dzie­dzi­no­wej sepa­ra­cji modu­łów, jed­nak sepa­ra­cja ta ma miej­sce wyłącz­nie w czę­ści kodu podzie­lo­ne­go na modu­ły, jed­nak ​„pod spodem” nadal jest mono­lit czy­li współ­dzie­lo­na baza danych. 

W cza­sach obec­nych, gdy fir­my i ich oto­cze­nie, zmie­nia­ją sie szyb­ko, kula u nogi w posta­ci współ­dzie­lo­ne­go zbio­ru danych powo­du­je, że podział apli­ka­cji na odręb­ne modu­ły nie wno­si zbyt wiel­kiej war­to­ści. Owszem popra­wia zarzą­dzal­ność kodem i uła­twia wpro­wa­dza­nie nie­znacz­nych zmian, ale nadal jest to monolit. 

Pojawia się więc kwe­stia migra­cji z mono­li­tu do bar­dziej zwin­nej archi­tek­tu­ry mikro ser­wi­sów. Jak nie trud­no się domy­śleć, rewo­lu­cja nie jest dobrym pomy­słem, dla­te­go auto­rzy opi­su­ją jak doko­nać takiej migra­cji ewolucyjnie.

Natychmiast poja­wia się pyta­nie jak to zro­bić bez­piecz­nie dla biz­ne­su? Odpowiedź jest pro­sta (patrz począ­tek tego arty­ku­łu): nale­ży zro­zu­mieć mecha­nizm dzia­ła­nia fir­my, czy­li opra­co­wać model pro­ce­sów biz­ne­so­wych na pozio­mie pozwa­la­ją­cym ziden­ty­fi­ko­wać klu­czo­we dzie­dzi­no­we aktyw­no­ści i każ­dej z nich przy­po­rząd­ko­wać mikro ser­wis, a następ­nie odwzo­ro­wać logi­kę biz­ne­so­wą apli­ka­cji odwzo­ro­wu­jąc prze­pływ doku­men­tów jako prze­pływ komunikatów.

Stan doce­lo­wy będzie odwzo­ro­wy­wał aktu­al­ną logi­kę biznesową.

Każda usłu­ga – mikro­ser­wis – wspie­ra okre­ślo­ną aktyw­ność biz­ne­so­wą. Fakt, że każ­dy mikro­ser­wis sam zarzą­dza swo­imi dany­mi nie współ­dzie­ląc ich z inny­mi, powo­du­je, że wska­za­na wyżej głów­na wada mono­li­tów, zwa­na ​„wszyst­ko zale­ży od wszyst­kie­go”, tu po pro­stu nie wystę­pu­je. To z czym naj­czę­ściej wal­czą posia­da­cze mono­li­tów podzie­lo­nych na kom­po­nen­ty to postać i licz­ba wza­jem­nych odwo­łań (radzi­my sobie z tym wzor­ca­mi np. Saga, któ­re już opi­sy­wa­łem).

Tak więc ​„tak wyglą­da pro­blem”. Nie jest tu moim zamia­rem stresz­cza­nie tych publi­ka­cji. Sposób nar­ra­cji oraz wie­le sche­ma­tów blo­ko­wych i kodu, czy­ni je obie rary­ta­sem i dla kode­rów i dla ana­li­ty­ków, pro­jek­tan­tów, architektów. 

Gorąco pole­cam pierw­szą publiak­cje (dostęp­na bepłat­nie) i zakup dru­giej pozycji. 

Źródła

Szukasz pomocy?

Pomogę, zapra­szam do kon­tak­tu: NAPISZ DO MNIE.