Dekompozycja bardzo dużego monolitu na mikroserwisy

Jestem w trakcie wykonywania cwiczenia w którym mamy duża bazę relacyjną.
Jak wiadomo jest ona podzielona na tabele, naszym zadaniem jest podział tego na nowe zbiory, omawiając każdy atrybut i rzeczy z nim związane.

Pytanie jakie mam to jakie widziecie heurystyki dzięki którym będzie można zbudować pewien framework w postaci pytań jakie można zadać dla każdego atrybutu żeby odkryć całe szambo z nim związane?

Np atrybut Adres, pytania jakie można zadać to, w jakich procesach bierze udział, jakie są reguły jego zmiany (np. Nie można zmieniać adresu w dni nieparzyste), czy w całym systemie jest inne golden source of truth dla adresu, czyli czy występuje niespójność na poziomie systemu itd..

Może ktos wykonywał cos podobnego ewentualnie jest kreatywny.

Dalsze rozważania będą przydatne w celu stworzenia z tej bazy mikroserwisow.

@DKN:

Moja produkcyjna wiedza o uS jest od ewangelizatorów, więc sorry Batory
Ale wyrobiłem sobie zdanie, że nie istnieje złote narzędzie które zdekomponuje monolit na N (N większe od 2) mikroserwisów - raczej wycinanie w monolitu fukcjonalnosci etapami.

I odczytuję, że kryterium cięcia nie jest w 100% programistyczne, ale np w dużym stopniu biznesowe / hostingowe / podległości korporacyjnej itd.
To samo cięcie tego samego monolitu w firmie X bedzie bdb, ale bardzo kiepskie w odmiennych realiach firmy Y

ps. chciałem róznież pwoiedzieć, że cięcie monolitu tylko wg tabel (analizy bazy danych) ... coś mi tu nie gra

Cięcie tylko od tabel to punkt wyjścia.

Jednakże uwazam ze w systemach ktore bardziej przypominają repozytorium (zwykły crud), to wystarczający pattern, np. w bankach to właśnie atrybuty maja przypisana odpowiedzialność do jakiegoś zespołu czy działu co rzutuje na mikroserwisy.

My niestety nie mamy cruda.
Co do podziału na podstawie procesów i innych wytycznych to pełna zgoda.
Jednakże nie widzę innego sposobu od rozpoczęcia bardziej szczegółowej analizy niż właśnie analiza struktury.

Robiliśmy EventStromingi, dały nam big picture, jednakże nie sprawdzają się w kategoriach bardziej formalnych i niskopoziomowych - gdzie trzeba materializować ten podział na konkretne encje itd.

Może wrócimy i skorzystsmy z narzędzia jakim jest procesowy eventstorming, jednakże nie działa on gdy jest 1000 tabel każda ma 50 atrybutów i wszystko jest pomieszane ze sobą. A cała wiedza siedzi w głowach 4 osób i kodzie.

Trochę czuje się zagubiony, punkt zaczepienia w postaci rozpisania heurystyk i wyciagnięcia info o atrybutach wydaje się Ok.

Tak na oko to starałbym się szukać klastrów w bazie, czyli zbiorów tabel, które są ze sobą mocno powiązane (co niekoniecznie oznacza połączenie kluczami obcymi). Potem ogarniasz wszystkie możliwe sposoby na które te tabele są modyfikowane. Z tego próbujesz wykrzeszać serwis i patrzysz, czy:

• serwis zapewnia te wszystkie metody do modyfikacji i ma to sens
• czy cała reszta (pozostały monolit, reszta serwisów) jest w stanie działać, jeżeli odczyt tych tabel poprzez ten serwis będzie bardzo prosty. Idealnie to będzie jakieś get_by_id i różne searche ograniczone filtrami

Tak czy owak lepiej zacząć od modularyzacji na poziomie kodu, co ułatwia eksperymenty. Dopiero jak masz wszystko ładnie podzielone to można dzielić na osobne aplikacje. Czego nie robić tego teraz? Skoro działa to znaczy, że jeden monolit w zupełności wystarcza (raczej) i twoim kryterium jest ładny podział kodu (który jest zapewniony przez modularność) a reszta zalet zapewniana przez mikroserwisy jest pomijalna, jeśli dodamy do tego wady takiego rozwiązania

slsy napisał(a):

Tak czy owak lepiej zacząć od modularyzacji na poziomie kodu, co ułatwia eksperymenty. Dopiero jak masz wszystko ładnie podzielone to można dzielić na osobne aplikacje. Czego nie robić tego teraz? Skoro działa to znaczy, że jeden monolit w zupełności wystarcza (raczej) i twoim kryterium jest ładny podział kodu (który jest zapewniony przez modularność) a reszta zalet zapewniana przez mikroserwisy jest pomijalna, jeśli dodamy do tego wady takiego rozwiązania

Właśnie, nazwałeś mi to, co czułem. Jeśli w obecnym monolicie nie ma modularyzacji, to ...

@DKN:

A tak naprawdę, to co boli, że musisz zmienic na uS ? Jakie motywacje ? Rytm wydawania wersji / przypisanie programistów ? Wydajność jakiejś części ?
Cyt :

a reszta zalet zapewniana przez mikroserwisy jest pomijalna, jeśli dodamy do tego wady takiego rozwiązania

Kompletnie nie rozumiem dlaczego zaczynacie od poziomu bazy danych.
To już na samym starcie może wam położyć projekt bo możecie mieć strasznie skopaną strukturę i na tej właśnie kupie postawicie sobie nowy projekt, nad którym będzie latać rój much zanim do czegoś w ogóle dojdziecie.
Struktura bazy nawet jako punkt wyjścia to proszenie się o problemy.

Dalsze rozważania będą przydatne w celu stworzenia z tej bazy mikroserwisow

Do czego wam te mirkoserwisy potrzebne? Obawiam się, że jeżeli nie umiecie zrobić modularnego monolitu to tym bardziej nie będziecie umieli zrobić mikroserwisów (widać to po tym, że zaczynacie od bazy danych a nie od modelu dziedziny i wydzielenia bounded contextów) i skończycie z rozproszonym monolitem.

Wydaje mi się, że to czego potrzebujecie to wpierw uporządkować kod w swojej aplikacji, a zabieracie się do tego od najgorszej strony myśląc że podział na mikroserwisy wprowadzi wam do projektu porządek. Błąd, wprowadzi jeszcze większy bałagan.

Uporządkujcie kod, zastanówcie się PO CO wam mikroserwisy i dopiero wtedy szukajcie wzorców na dzielenie monolitu. Od siebie mogę polecić podejście Monolith First https://martinfowler.com/bliki/MonolithFirst.html

https://martinfowler.com/articles/break-monolith-into-microservices.html

Czuje się nie zrozumiany, ale stwierdzam, ze to moja wina i postaram się wytłumaczyć to inaczej.

W naszej organizacji istnieją już domeny z mikroserwisami, które działają dobrze. Wspomiany monolit jest dość starym klockiem który komunikuje się z nimi, robiąc za orkiestratora, ale tez ma swoją bazę itd. Cel projektu jest taki by go skasować a dane powinny zostać zaabsorbowane przez domeny.

Czyli case jest taki, żeby zbiory danych z monolitu przypisać do istniejących domen (domenę dla uproszczenia rozumieniem jako segment organizacji danych który składa się z kilku mikroserwisow).

Co do patternu dekompozycji za pomocą modularyzacji monolitu. Brzmi to ładnie, tez czytałem ksiazki gdzie był ten pattern, ale wprowadzenie jakichkolwiek zmian w systemie jest mega kosztowne i niebezpieczne.
System jest napisany w c++, ma 25 lat, robi orkiestracja prac dla całej korpo. Deployment to koszmar.
Budowanie proxy, fasad tez wydaje się nam zbyt kosztowne.

Stad pattern w którym nasłuchujemy na logi bazy i tworzymy streaming eventow które są publikowane na domeny jest lepszy.
Dziala i jest spójnie - dla 1 domeny poszło gładko.

Moim pytaniem do którego wracam jest to : Czy dla tej bazy danych analizując atrybuty można znaleźć pewne heurystyki w postaci pytań które mogą naprowadzić nas analitykow i ekspertów domenowych która domena powinna wziąć odpowiedzialność za owy atrybut.

No to trochę zmienia postać rzeczy :P

Też stosuję CDC do integracji starych i wrażliwych systemów, których nikt nie chce kijem dotykać i fajnie, że tego używacie.

Czy dla tej bazy danych analizując atrybuty można znaleźć pewne heurystyki w postaci pytań które mogą naprowadzić nas analitykow i ekspertów domenowych która domena powinna wziąć odpowiedzialność za owy atrybut.

A czy tego wam nie powinien dostarczyć event storming, który robiliście? Bo brzmi to na problem biznesowy (przynajmniej dla mnie). Problem jaki tu widzę jest taki, że weźmy smutną tabelę Orders w typowym e-commerce. No i teraz jest tak, że informacjami o zamówieniach będą zainteresowane takie poddziedziny jak sprzedaż, Hurtownia Danych/BI, obsługa reklamacji i pewnie jeszcze znajdzie się kilka innych w zależności od tego czego wymaga i jak działa biznes, moglibyśmy nawet mówić tutaj o architekturze korporacyjnej (Enterprise Architecture), ale do rzeczy.

To co chcę powiedzieć, to że nie da się (znów moim zdaniem) na podstawie nazw tabel i pól powiedzieć który poddziedziny będą zainteresowane tymi danymi. To tak jak mówiłem powinien odkryć event storming, albo jakiś inna metodyka destylacji i modelowania dziedzin.

Jakoś nie za bardzo widzę ten podział. Piszesz, że macie już komponenty, które powinny przejąć po kawałku zakresu odpowiedzialności tego molocha.
Ale nie jesteście w stanie określić co gdzie włożyć.

Zamiast szukać jakieś kompletnie sztucznej mechaniki zrobienia tego podziału to radzę skonsultować się z ekspertami domenowymi bo inaczej zrobicie jeszcze większe g***o tyle że rozproszone.

Oprócz zakresów odpowiedzialności za jakiś kawałek danych należy się zastanowić nad ich użyciem w różnych kontekstach, co też wymaga wiedzy domenowej i wątpię żeby udało się to zrobić dobrze bazując na strukturze tabelek.

Nie rozumiem do końca pytania ale jeżeli chodzi o archeologię to podszedłbym do tematu w ten sposób. Jako, że nie zawsze można bazować na kluczach, ja bym zaczął od sprawdzenia czy da sie wyłuskiwać historie zapytan w rdbms jakiego uzywacie, jak nie to dodał proxy i rejestrował. Potem rozkładałbym zapytania do czego bija i jakich zależności wymagają (widoki, triggery etc.). Potem jak miałbym już las drzew zapytanie -> zależności zaznaczyłbym które zapytania maja cześci wspólne w zależnosciach. Na tym etapie juz by wyklarowało sie co gdzie mozna wyjebac ale chyba nie chodzi tylko o to aby przenieść problem na wiele problemów, więc przeanalizowałbym czy te części wspólne mają sens i czy struktura jest dla nich optymalna pod względem domeny czy nie trzeba przemigrować danych i nie posprzatac tego.

mozre sie przyda
ksiazka Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith
http://libgen.is/book/index.php?md5=72E0E29D71B8AA9767B46F16780FE14B

Ktoś rzuca tekstem, ze brakuje „rozmowy z biznesem”
Pada stwierdzenie, ze „rozmowa z biznesem” to rozwiąże.
Tak jakbyśmy traktowali rozmowę z biznesem jako magiczne czarne pudełko z którego wyciągamy zawsze odpowiedzi.

Zdradzę, ze od x czasu w tygodniu mamy kilka warsztatów i ogólnie ciągła dobra i wartosciowa komunikację. Tez uważam ze ta „rozmowa z biznesem” jest ważnym, a może nawet najważniejszym punktem do zrozumienia swiata.

Powtórzę jeszcze raz, system zawierający tysiące atrybutów ma swoje zaszłości, niespójności z innymi systemami, pewna logikę na poziomie atrybutu która trzeba uwzględnić podczas migracji jej do odpowiedniej domeny. Zawiera swoje osobliwe dane, które gromadził i trzeba cos z nimi zrobić, należy rozważyć koegzystencję na poziomie pewnych atrybutów itd..

Pytanie dotyczyło tego, czy znacie jakieś heurystyki - konkretne pytania, którymi można się posługiwać podczas analizy.
W tym tygodniu udało mi się kilka wymyślić.
Dla przykładu to czym mogę sie pokazac.
Podzieliłem je na 3 kategorie.

Analiza rzeczownikowa (lingwistyczna) :
Jakie sa faktyczne relacje strukturalne atrybutu z innymi (tabela nie ma relacji ze względów na wydajnośc). Krotnosci.

Analiza funkcjonalna (badająca zachowanie)
W jakich procesach uczestniczy atrybut
Jak reaguje na zmianę
Czy da się zawsze go zmienić - jaka jest ifologia zabezpieczająca zmianę
Jakie są konswenkcje zmiany (polityki)

Inne.
Czy element w tej bazie jest golden sourcem dla całej organizacji
Czy jest cześć danych która jest tylko tutaj a nie ma innej części systemu bo np nie ma synchronizacji, jeżeli tak to co chcemy robić robić z tymi danymi np Stare pula PESEL, może z racji na rodo mamy polityke ich utylizacji wiec w dupie z nimi, usuwanie nawet wyjdzie na plus, albo musimy bo to klienci segmentu biznes i nam zależy na ich danych bo sa cenę, a z rodo cos się ogarnie.

Dekomponując takiego kloca dobrze trzymać się klucza. Wiadomo z pewnymi odchyleniami, ale nie wyobrażam sobie kilka tysięcy atrybutów omawiać bez narzuconej wcześniej struktury w postaci pytań.

Po inwentarzu pewnej puli atrybutów i uzyskaniu odpowiedzi na tak postawione pytania mamy świetny materiał do wskazania atrybutów do domem. Bo wiemy jak wyglada cały kontekst atrybutu, znamy jego około orbitalne problemy.

Może ja cos złe mysle albo jestem głupi przez genetykę ale to wydaje mi się najlepszym sposobem.

A to rozbicie na mikroserwisy jest konieczne? Może wystarczy po prostu dobrze rozbić monolit na osobne moduły.

Zmiana czekolowiek w tym kolosie to ryzyko, a dodanie modulowosci byłoby rewolucja i kosztowałoby bardzo duzo.
Również koniec końców i tak inne domeny musiałby wziąć swoje komponenty, wiec krok pośredni w postaci modulowowosci w kodzie nie wydaje się dobry.
Chcemy zbudować modulowosc w inny sposób.
Stad pattern oparty o cdc wydaje się lepszy.

DKN napisał(a):

Zmiana czekolowiek w tym kolosie to ryzyko, a dodanie modulowosci byłoby rewolucja i kosztowałoby bardzo duzo.
Również koniec końców i tak inne domeny musiałby wziąć swoje komponenty, wiec krok pośredni w postaci modulowowosci w kodzie nie wydaje się dobry.
Chcemy zbudować modulowosc w inny sposób.
Stad pattern oparty o cdc wydaje się lepszy.

A każe Ci ktoś zmieniać? Po prostu napisz od nowa jeden projekt podzielony na moduły.

Zacząłeś temat od podziału aplikacji na mikroserwisy - co jest niczym innym jak podzieleniem aplikacji na moduły, tylko że każdy z nich jest osobną aplikacją. Oszczędź sobie zachodu kodzenia tego wszystkiego, i zrób to w jednym projekcie - tylko że podzielonym na pakiety.

Nie widzę nadal zysku z tego kroku.
Dodaje tylko problem z synchronizacja i spójnością danych, potencjalnym tworzeniem warstw proxy itd.

Skoro mam dane a po analizie z ekspertami również mam procesy związane z danymi + mam stworzone domeny i strukturę organizacji firmy tak, ze są ludzie od domeny dla np. produktów, marketingu co maja swoich programistów i już swoje aplikacje to jedyne co chce to wyznaczyć co istniejące domeny musza zaabsorbować do swojej odpowiedzialności.

To nie jest greenfield i nie tworzymy od zera świata domenowego a musimy sie zaadaptować do istniejącego jednocześnie go wykorzystując.

DKN napisał(a):

Nie widzę nadal zysku z tego kroku.
Dodaje tylko problem z synchronizacja i spójnością danych, potencjalnym tworzeniem warstw proxy itd.

A zrobienie tego na mikroserwisach nie daje? :D

@DKN: To co próbuję Ci powiedzieć, to to że z programistycznego punktu widzenia mikroserwisy dodają sporo complexity, i takie samo "rozdzielenie" zależności, można zrobić zwykłymi modułami w języku programowania. Albo nawet polimorfizmem zwykłym.

Pełna zgoda.

Tez mi jest ciężko wyjaśnić cały background projektu.
Starając się kompresować info okazuje sie ze ucieka cos ważnego xd i widzę ze czegoś jeszcze nie dopisałem.

Ogólnie sytuacja jest taka, ze apka jest w c++ a cały świat korpo w javie, właściciel biznesowy procesu żeby cos zrobić musi patrzec na to co tam jest w tym c++ schowane i zanim wprowadzi zmiany u siebie musi pokornie analizować jak działa kawałek procesu legacy - nie zawsze, ale wystarczy ze nie jest masterem danych/procesu i Time to market spada.

Zakładając ze powstałyby komponenty z domenami to nie wyobrażam sobie trzymać zduplikowanej bezsensu logiki w c++ z jakimiś programistami i warstawami proxy ktore uspójnialiby dane. Skoro mogę Od razu oddać to do docelowego mikroseriwsu.