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). Architektura ta jest nadal głów­ną cechą wie­lu sys­te­mów ERP, 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 ryn­ku. 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, wyj­ścia z tego dłu­gu. 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

Oliveira Rocha, H. F. (2022). Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices. Apress. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 1‑4842 – 7468‑2

Szukasz pomocy?

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

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 2 komentarzy

  1. Daniel

    Bardzo dobry arty­kuł. W sumie jak więk­szość mate­ria­łów przy­go­to­wy­wa­nych przez Pana 🙂 Nie spo­sób poru­szyć wszyst­kie aspek­ty archi­tek­tu­ry mono­li­tycz­nej i modu­lar­ne­go mono­li­tu w jed­nym arty­ku­le (w tym migra­cji do archi­tek­tu­ry mikro­ser­wi­so­wej). Chciałbym jed­nak dodać, że posia­da­jąc jed­ną bazę danych przy modu­lar­nym mono­li­cie moż­na zasto­so­wać kon­tekst bazy danych per sche­mat bazy. Każdy z modu­łów może posia­dać swój sche­mat i łączyć się z obiek­ta­mi bazy danych tyl­ko z tego sche­ma­tu. Jak każ­da archi­tek­tu­ra ma swo­je wady i zale­ty. Ale nie ma ide­al­nych roz­wią­zań. archi­tek­tu­ra mikro­ser­wi­so­wa roz­wią­zu­je pew­ne pro­ble­my ale rów­nież adre­su­je nowe. Jak to mówią, życie to sztu­ka wyboru.

    1. Jarosław Żeliński

      Dziękuję za opi­nię. Zgadzam się z tym co Pan napi­sał. Warto jed­nak czy­tel­ni­kom wyja­śnić (o ile dobrze Pana zro­zu­mia­łem), że baza danych, jako jed­no­li­ty zestaw tabel powią­za­nych rela­cyj­nie, oraz tak zwa­ny motor baz danych” to nie to samo. Więc owszem, moż­na na jed­nym moto­rze” utrzy­my­wać wie­le nie­za­leż­nych baz danych” (sche­ma­tów) i wte­dy są to odręb­ne bazy danych”. Przyznaję, że w swo­ich arty­ku­łach, pisząc o bazach danych, mam na myśli rela­cyj­ne sche­ma­ty a nie moto­ry”, gdyż taką zasa­dę przy­ję­to na świe­cie w publi­ka­cjach o archi­tek­tu­rze apli­ka­cji. Czym innym jest archi­tek­tu­ra śro­do­wi­ska, gdzie może­my mieć jeden motor baz danych” a czym archi­tec­tu­re zin­te­gro­wa­nych apli­ka­cji, każ­da mają­ca tu swo­ją baz danych” a inte­gra­cja jest jed­nak na pozio­mie REStfull API.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.