Zapraszam wszystkich, którzy szukają pomocy, wiedzy oraz wsparcia w swoich projektach informatyzacji. Działam od 1991 roku, mój Blog działa nieprzerwanie od 1998 roku.
Jeżeli nie potrafisz czegoś narysować to znaczy że nadal tego nie rozumiesz. Jeżeli potrafisz coś narysować to potrafisz to także zbudować.
Od dość dawna śledzę Pańskie materiały (strona www, książka) i trafił mi się taki materiał (link poniżej), pomyślałem sobie że się podzielę.
Should I Build a Monolith or Microservices?
jestem ciekawy Pańskiego komentarza, oczywiście w wolnej chwili na linkedinie albo na stronie
Dzień Dobry
Kolejny przypadek tego jak “koderzy” potrafią niezrozumieć i zniszczyć pierwotny pomysł, a największymi niszczycielami są Ci od C++/JavaEE (kaskady dziedziczenia i kompozycji). Dlaczego?
Przede wszystkim nie mam na myśli autora cytowanego przez Pana referatu :), on opisuje konsekwencje. Mam na myśli tych, którzy z mikroserwisów zrobili piasek. Tu też słychać, o “dużej liczbie mikroserwosów”. Pytam się, “że co?”.
Idea microserwisów ma podobno początek w architekturze heksagonalnej [https://en.wikipedia.org/wiki/Hexagonal_architecture_(software). Ja zaryzykuję tezę, że jest to inna nazwa na znane od 30 lat komponenty, z naciskiem na ich hermetyzację: nie współdzielimy NICZEGO, bazy danych też nie [D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116., Wills, A. C., & D’Souza, D. (1997). Rigorous Component-Based Development.]
Poniżej schemat architektury: to są komponenty nazwane mikroserwisy (czasami mikroaplikacje). Pierwotna definicja mikroserwisu do samodzielna wewnętrzna usługa, ale usługa to zarządzenia komunikatem/dokumentem (u Evansa jest to agregat). Agregat to spójny kontekstowo i logicznie (walidacja) zestaw (nie raz zagnieżdżonych) atrybutów opisujących określony dziedzinowy byt (faktura, dane pracownika, opis nieruchomości, itp.). Idealną formą utrwalania agregatów jest XML/JSON (a nie winogrona kompozycji klas w kodzie). Taki agregat, np. string XML, zapisujemy jako wartość atrybutu obiektu będącego jego nośnikiem (wzorce repository i envelope).
Popatrzmy poniżej: ta nietrywialna aplikacja to pięć mikro serwisów a nie pięćset. Każdy z nich to taki “mały monolit” i słusznie, bo tu już nie ma co dzielić (ale ten monolit w środku jednak kilka klas (wzorzec łańcuch odpowiedzialności). Poniższy diagram to architektura HLD (High-Level Design), każdy z tych ko komponentów ma wewnętrzną architekturę LLD (Low-Level Design). Przykładem jest projekt demo Biblioteka, do pobrania na blogu.
Jak ktoś mówi o mikro serwisach i mówi że ma ich kilkaset to “coś poszło nie tak”. Ale jak ktoś uważa, że aplikacja większa od budy dla psa, może być monolitem, to też jest źle (jej koszty utrzymania i rozwoju będą ogromne). I pamiętajmy, że każda aplikacja, postawiona na jednej, współdzielonej, relacyjnej bazie danych SQL, to monolit. Nawet jeżeli kod będzie podzielomny na moduły, jest to nadal monolit.
Jarosław Żeliński: Po ukończeniu WAT w 1989 roku pracownik naukowy katedry Transmisji Danych i Utajniania. Od roku 1991 roku, po rozpoczęciu pracy w roli analityka i projektanta systemów przetwarzania informacji, nieprzerwanie realizuje kolejne projekty dla urzędów, firm i organizacji. Od 1998 roku prowadzi także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania systemów (modele jako przedmiot badań: ORCID), publikując je nieprzerwanie także na tym blogu. Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi 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.). Od 2020 roku na stałe mieszka w Szkocji (Zjednoczone Królestwo), nadal realizuje projekty dla firm i organizacji także w Polsce.
