Na temat tego jakim uciążliwym długiem technologicznym jest monolityczny system napisano wiele, dzisiaj kolejne dwie ciekawe pozycje literatury: CMMI Compliant Modernization Framework to Transform Legacy Systems oraz Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices . Pierwsza publikacja opisuje metodę zaplanowania wyjścia z długu technologicznego z perspektywy analizy biznesowej, druga opisuje możliwą realizację techniczną z perspektywy architektury aplikacji i ewolucyjnej migracji z architektury monolitycznej do komponentowej (mikro-serwisy).

Czym jest monolit?

Jest to system, którego architektura stanowi jeden niepodzielny blok realizujący funkcje biznesowe. Kluczową cechą i zarazem wadą, monolitu jest wewnętrzna „zależność wszystkiego od wszystkiego”. Każda modernizacja z zasady dotyczy całego systemu, jest więc i bardzo kosztowna i bardzo ryzykowna.

W efekcie użytkownik jest uzależniony od jednego dostawcy, jakakolwiek zmiana organizacyjna pociąga za sobą prace porównywalne z nakładem środków i czasu jak w pierwotnym wdrożeniu tego systemu, a nie raz te koszty są większe. Upgrade takiego systemu, jeżeli był kastomizowany, zawsze wymaga powtórzenia całego wdrożenia od początku.

Jest to architektura rodem z lat 80-tych ubiegłego wieku (dlatego nazywana jest legacy system czyli system przestarzały), jej ogólna postać:

Architektura ta jest nadal główną cechą wielu systemów ERP na rynku, nawet tych bardzo znanych. W obecnych czasach jest to źródłem wielu kłopotów organizacji, które wdrożyły taki system i muszą szybko reagować na zmiany na rynku.

Wdrożenie w firmie jednego monolitycznego systemu ERP to tak zwany „big bang”, czyli wszystko albo nic, co w zasadzie nikomu sie nadal nie udało. Dlatego coraz częściej podejmowane są próby ewolucyjnego, bezpiecznego dla całej organizacji, płynnego wyjścia z tego długu jakim jest monolityczna architektura systemu IT. Jak to zrobić?

Etap 1: Analiza biznesowa

Na tym etapie należy zebrać dokumenty operacyjne: te opisujące posiadany „monolit” i te będące jego produktami (wydruki, formularze itp.). Analiza ich powinna zaowocować analitycznym modelem procesów biznesowych (modelowanie procesów). Dysponując tymi wszystkimi dokumentami oraz zebranymi oczekiwaniami interesariuszy, opracowujemy dokument wymagań wobec nowego systemu, w tym także jego ogólną architekturę:

Dokumentacja i utrzymanie wymagań:
KP 1.1 Przygotowanie Macierzy Śledzenia Wymagań w celu śledzenia spójnosci ich zmian
KP 1.2 Ustalenie ról i odpowiedzialności wszystkich uczestników projektu
KP 1.3 Omówienie potrzeb z interesariuszami i metod rozwiązania problemów
KP 1.4 Opracowana [w toku analizy] dokumentacja wymagań podpisana przez wszystkich interesariuszy

Etap 2: Realizacja

Tu polecam drugą publikację. Jest to jedna z ciekawszych pozycji na mojej półce. Opisuje ona metodę migracji z monolitycznej do bardziej otwartej i zwinnej architektury. Odbywa się to powoli, i na początek raczej w głowach projektantów, później dopiero w projektach i wdrożeniach.

Jak już wspomniano wyżej, kluczową wadą monolitów jest ich ociężałość, skutkująca tym, że ich rozwój i rozbudowa bardzo szybko zmienia się w walkę w ich wielkością. Powodem tego jest właśnie owa silna wewnętrzna „zależność wszystkiego od wszystkiego”.

Pewnym postępem jest wewnętrzne „upilnowanie” dziedzinowej separacji modułów, jednak separacja ta ma miejsce wyłącznie w części kodu podzielonego na moduły, jednak „pod spodem” nadal jest monolit czyli współdzielona baza danych.

W czasach obecnych, gdy firmy i ich otoczenie, zmieniają sie szybko, kula u nogi w postaci współdzielonego zbioru danych powoduje, że podział aplikacji na odrębne moduły nie wnosi zbyt wielkiej wartości. Owszem poprawia zarządzalność kodem i ułatwia wprowadzanie nieznacznych zmian, ale nadal jest to monolit.

Pojawia się więc kwestia migracji z monolitu do bardziej zwinnej architektury mikro serwisów. Jak nie trudno się domyśleć, rewolucja nie jest dobrym pomysłem, dlatego autorzy opisują jak dokonać takiej migracji ewolucyjnie.

Natychmiast pojawia się pytanie jak to zrobić bezpiecznie dla biznesu? Odpowiedź jest prosta (patrz początek tego artykułu): należy zrozumieć mechanizm działania firmy, czyli opracować model procesów biznesowych na poziomie pozwalającym zidentyfikować kluczowe dziedzinowe aktywności i każdej z nich przyporządkować mikro serwis, a następnie odwzorować logikę biznesową aplikacji odwzorowując przepływ dokumentów jako przepływ komunikatów.

Stan docelowy będzie odwzorowywał aktualną logikę biznesową.

Każda usługa – mikroserwis – wspiera określoną aktywność biznesową. Fakt, że każdy mikroserwis sam zarządza swoimi danymi nie współdzieląc ich z innymi, powoduje, że wskazana wyżej główna wada monolitów, zwana „wszystko zależy od wszystkiego”, tu po prostu nie występuje. To z czym najczęściej walczą posiadacze monolitów podzielonych na komponenty to postać i liczba wzajemnych odwołań (radzimy sobie z tym wzorcami np. Saga, które już opisywałem).

Tak więc „tak wygląda problem”. Nie jest tu moim zamiarem streszczanie tych publikacji. Sposób narracji oraz wiele schematów blokowych i kodu, czyni je obie rarytasem i dla koderów i dla analityków, projektantów, architektów.

Gorąco polecam pierwszą publiakcje (dostępna bepłatnie) i zakup drugiej pozycji.

Źródła

Szukasz pomocy?

Pomogę, zapraszam do kontaktu: NAPISZ DO MNIE.