Modularny monolith vs microservices

Jakis czas temu doszedlem do wniosku, ze wlasciwie jedyne co mi tak naprawde przeszkadza w monolith'ie to:

• koniecznosc pull'a calej aplikacji:
  -- wyjatkowo nieoptymalne podejscie przypadku koniecznosci realizacji jakiegos drobnego ficzera lub usuniecia trywialnego bug'a
  -- ryzyko pelnego dostep do partii kodu, ktore mozna okreslic jako "wrazliwe" lub "pufne" dla osob, ktore taki dostep moga potencjalnie wykorzystac w celu niepozadanym
• problem ilosci zasobow, koniecznych do zaangazowania nawet w przypadku banalnych zapytan.
• problem skalowalnosci aplikacji

What if...

Budowac monolith skladajacy sie z wyspecjalizowanych modulow, ktore bylyby w stanie funkcjonowac zarowno jako integralne elementy calej aplikacji, jak i niezalezne serwisy? Tego rodzaju podejscie pozwala rozwiazac wymienione wczesniej przeze mnie problemy.

Ostatnio zaczalem sobie cos takiego przygotowywac i zastanawiam sie czy ktos z Was ma za soba jakies doswiadczenia, proby na tym polu.

Skoro praca całego systemu jest możliwa jedynie wtedy gdy wszystkie mikroserwisy działają, to faktycznie monolit by się sprawdził. Niemniej modularność przynosi inne bolączki, które uderzą na pewno - ludzie nie potrafią git'a a szczególnie submodułów, po rozwinięciu plugina i tak trzeba go przetestować integracyjnie z resztą systemu, pluginy w DLL są mnie kompatybilne z innymi elementami niż komunikujące się po REST serwisy.

Po 20 latach pisania aplikacji desktopowych ( typowych monolitów ) i ponad 10 latach pisania aplikacji rozproszonych do postaci różnych API i kilku front-endów czyli generalnie całkowitej odwrotności do aplikacji desktopowej zdecydowanie jestem zwolennikiem tych drugich... ale nie do końca :-)

Za idealne rozwiązanie uważam "hybrydę", w której front end piszemy w cywilizowanym środowisku takim jak Java, Delphi, C# a back-end mamy w postaci API jako serwerowych aplikacji pisanych w PHP, JAVA ( oczywiście same narzędzia mogą być inne w zależności od gustów i upodobań ). To ile czego będzie po której stronie musi być uzasadnione wymogami samej aplikacji i głęboką analizą systemu przed podjęciem działań programistycznych. Nie mam tutaj złotej rady co po której stronie bo czasem nawet lepiej w całości pozostać po jednej.

babel100 napisał(a):

Budowac monolith skladajacy sie z wyspecjalizowanych modulow, ktore bylyby w stanie funkcjonowac zarowno jako integralne elementy calej aplikacji, jak i niezalezne serwisy? Tego rodzaju podejscie pozwala rozwiazac wymienione wczesniej przeze mnie problemy.

Monolit zawsze wymaga bardziej wyspecjalizowanej załogi do pisania. Proste mikroserwisy można zlecać komukolwiek. Bardzo cenne w przypadku gdy realizują mniej istotne dla systemu fragmenty.
Mikroserwisy nie mają ograniczeń technologii jeden możesz napisać w NodeJS drugi w PHP a trzeci w Python. Ściśle pilnować trzeba jedynie spójności komunikacji pomiędzy elementami systemu.

@pragmaticdev:

Skoro praca całego systemu jest możliwa jedynie wtedy gdy wszystkie mikroserwisy działają,

Nie do konca. Aplikacja zbudowana w sposob o ktorym wspomnialem nie wymaga ani dzialania ani obecnosci wszystkich wymaganych modulow, w przeciwnym przypadku nie porownywalbym tego rozwiazania do mikroserwisow.

ludzie nie potrafią git'a a szczególnie submodułów

a mimo to ujadaja na 4programmers :D

po rozwinięciu plugina i tak trzeba go przetestować integracyjnie z resztą systemu

pelna zgoda

pluginy w DLL są mnie kompatybilne z innymi elementami niż komunikujące się po REST serwisy

Wszystko zalezy od tego w jaki sposob piszesz te pluginy. Jesli piszesz je we wlasciwy sposob, nawet nie myslisz o kompatybilnosci.

@katakrowa:

Monolit zawsze wymaga bardziej wyspecjalizowanej załogi do pisania. Proste mikroserwisy można zlecać komukolwiek.

Pelna zgodna. Ja jednak pisze o modularnym tworzeniu monolitu w sposob ktory umozliwia wykorzystanie zalet kodu opartego o mikroserwisy.

Mikroserwisy nie mają ograniczeń technologii jeden możesz napisać w NodeJS drugi w PHP a trzeci w Python. Ściśle pilnować trzeba jedynie spójności komunikacji pomiędzy elementami systemu.

Pelna zgoda. Wlasciwie zwrociles uwage na sedno problemu zwiazanego z mikroserwisami. Cala masa projektow rozbija na sile strukture jednorodnej jezykowo aplikacji na mikroserwisy bez jakiegokolwiek uzasadnienia poza tym iz jest to "trendy". Potem okazuje sie ze wyswietlenie aktualnego czasu na stronce wymaga odpalanie kilku-nastu-dziesieciu requestow w tle, a aplikacja bez cache'u nie nadaje sie do uzytku.

Zgodzę się, że dowolność technologii jest zarówno zaletą, ale też poważną wadą. Co prawda i monolity można pisać w różnych technologiach, ale jest to trudniejsze. Uważam, że system powinien być technologicznie spójny, ilość technologi minimalna, a cały zespół powinien mieć kompetencje ich używania.

babel100 napisał(a):

Jakis czas temu doszedlem do wniosku, ze wlasciwie jedyne co mi tak naprawde przeszkadza w monolith'ie to:

• koniecznosc pull'a calej aplikacji:

ale w PHPie? chyba tylko w niektórych frameworkach

@Miang:

ale w PHPie? chyba tylko w niektórych frameworkach

We wszystkich. Jesli sie myle podaj przyklad jednego, ktory nie implikuje tej koniecznosci. Mowie serio, bez ironii i bez podtekstow :)

Mikroserwis, który może działać w trybie REST/standalone, albo trybie aplikacji - gdzie wywołujesz bezpośrednio metody modułu, lub symulujesz RESTowy request http. To pozwala na dużą elastyczność, ale z drugiej strony trzeba się więcej napracować nad modułem.

Jeżeli mikroserwis jest zintegrowany z aplikacją to jego modularność sprowadza się głównie do osobnej przestrzeni nazw plus implementacji jakiegoś interfejsu do komunikacji, gdzie symulujesz REST.

Przecież jak chcesz pisać monolit i nie chcesz, żeby cały kod był modyfikowany, to możesz pisać paczki do composera, albo zlecać takowe do napisania, później je zaciągnąć podpiać i hula, nie trzeba aplikacji rozbijać na nie wiadomo co.
Z jsem i webpackiem można tak samo.

@omenomn2: w koncu ktos ogarniety zajarzyl o co chodzi :D.

Chociaz pozostaje Ci jeszcze dodatkowo:

• kwestia rozwiazania zasobow w taki sposob aby nie byly one ladowane wszystkie (dla kazdej paczki) przy kazdym request'ie
• kwestia swobody podpinania/odpinania paczki do paczki, paczki do grupy paczek, paczki do aplikacji, grup paczek do aplikacji - i nie chodzi tu o proste uzycie composera bo caly czas mamy do czynienia z ekonomika gospodarowania zasobami
• kwestia funkcjonowania paczki/grupy paczek rowniez jako osobyny serwis w razie potrzeby

Dokladnie tym sie bawie ale na 357 wejsc w tej chwili tylko ty zajarzyles "o czym ja w ogole rozmawiam" :D

@TomRZ:

Jeżeli mikroserwis jest zintegrowany z aplikacją to jego modularność sprowadza się głównie do osobnej przestrzeni nazw plus implementacji jakiegoś interfejsu do komunikacji, gdzie symulujesz REST

No nie do konca. Paczka/modul ktora jest zarowno integrowalna w wiekszej grupie paczek lub calej aplikacji, i kazdy z tych poziomow integracji paczka/grupa/aplikacjia ma wymagalna umiejetnosc funkcjonowania rowniez w sposob samodzielny zarowno jako REST'owy client i endpoint lub modul aplikacji wymaga odrobiny wiecej wyrafinowania :D. Tutaj nie ma miejsca na symulowanie czegokolwiek zwlaszcza jesli masz na uwadze swobodna skalowalnosc. Dodaj do tego unikalny zestaw (routing, konifiguracja, middleware, views etc) dla kazdej paczki/grupy paczek i zabawa staje sie coraz bardziej skomplkowana w momencie kiedy celem jest angazowanie tylko tego co niezbedne w danej chwili, a nie tego co zawiera config/routing etc calej aplikacji.

babel100 napisał(a):

Pelna zgoda. Wlasciwie zwrociles uwage na sedno problemu zwiazanego z mikroserwisami. Cala masa projektow rozbija na sile strukture jednorodnej jezykowo aplikacji na mikroserwisy bez jakiegokolwiek uzasadnienia poza tym iz jest to "trendy". Potem okazuje sie ze wyswietlenie aktualnego czasu na stronce wymaga odpalanie kilku-nastu-dziesieciu requestow w tle, a aplikacja bez cache'u nie nadaje sie do uzytku.

Może dlatego, że ktoś próbuje na siłę przenieść wzorce z monolitu na mikroserwisy. To, że w monolicie odpytanie o aktualny czas wymaga przebicia się przez 15 warstw abstrakcji nie oznacza, że po zamianie na mikroserwisy trzeba odpytywać łańcuch 15 mikroserwisów. My mamy mikroserwisy i w znakomitej większości przypadków jest tak, że jeśli serwis A potrzebuje danych z serwisu B, to serwis A łączy się bezpośrednio do serwisu B. Głównym wyjątkiem jest fasada dla frontendu, która upraszcza (oraz ujednolica, przyspiesza, lepiej monitoruje, itp itd) zapytania idące z frontendu do backendu.

kwestia swobody podpinania/odpinania paczki do paczki, paczki do grupy paczek, paczki do aplikacji, grup paczek do aplikacji - i nie chodzi tu o proste uzycie composera bo caly czas mamy do czynienia z ekonomika gospodarowania zasobami

Jak robisz paczke dla composera to tak samo możesz podpinać zależności, więc możesz zrobić załóżmy paczkę "Panel Admina" i mieć tam inna paczkę np. "Jwt token" i używać jej jednocześnie w "Panel Admina" jak i bezpośrednio w głównej apce.

Dokladnie tym sie bawie ale na 357 wejsc w tej chwili tylko ty zajarzyles "o czym ja w ogole rozmawiam" :D

Spoko ;)

@omenomn2: zeby wrocic do meritum, w jaki sposob/w ktorym miejscu ladujesz konfiguracje paczek odpalajac aplikacje ? :D

@Wibowit: sorry za wczesniejszy wpis, pelna zgoda.