Mikroserwis vs Monolit.

4

Mam kilka pytan zwiazanych z architektura systemow. Ogolnie mam jakis wglad na architekture, chcialbym te "wiedze" porownac z rzeczywistoscia.

  1. Czy systemy monolityczne slusznie kojarza mi sie z przestarzala technogia?
  2. Monolity to najczesciej jedno repozytorium i jeden jezyk programowania a mikroserwisy to wiele jezykow i wiele repozytoriow?
  3. Jesli chodzi o skalowalnosc to wieksze problemy mamy z monolitem. Rosnące wymagania na zasoby mogą być coraz trudniejsze do spełnienia przy jednej dużej aplikacji. Przy mikroserwisach zwiększamy liczbe instancji wybranych usług i po problemie?
  4. Czas wdrożenia przy monolicie jest dluzszy bo jest tylko jeden "pipeline". W Mikro jest ich wiele.
  5. Elasytycznosc czyli wdrozenie nowej technologi bedzie lepsze przy mikroserwisie, bo ruszenie monolitu to czasami miesiace prace?
  6. Niezawodność- mikroserwis wygrywa bo w przypadku awari musimy odzyskac tylko jedna jednostke a nie jak w monolicie caly stos.
    Praktycznie wiekszosc rzeczy przemawia za mikroserwisami niz za monolitem. Jak to jest w rzeczywistosci?
5

Czy systemy monolityczne slusznie kojarza mi sie z przestarzala technogia?

Uważam że nie, po prostu czasem warto mierzyć siły na zamiary

Praktycznie wiekszosc rzeczy przemawia za mikroserwisami niz za monolitem. Jak to jest w rzeczywistosci?

MS to również jakiś overhead administracyjno-devopsowy-organizacyjny blabla, łatwiej jest ogarnąć 1 bazkę i 1 appke niż N/N

Dodatkowo przy monolicie łatwiej jest reasonować np. w jaki sposób obsługiwać błędy niż w przypadku MS, gdzie stosujesz jakieś różne mniej lub bardziej skomplikowane patterny Sagi itd

disclaimer: nie znam się

1

@p_agon:

Praktycznie wiekszosc rzeczy przemawia za mikroserwisami niz za monolitem.

Niby tak, ale zauważ, że dobrze skonstruowany monolit również będzie wymagał ( bardzo ) mało pracy administracyjnej.

8
  1. Czy systemy monolityczne slusznie kojarza mi sie z przestarzala technogia?

Kojarzą się, ma to swoje podstawy historyczne, ale nie jest to słuszne. Monolit można napisać w nowych technologiach, w oparciu o dobre standardy i architekturę.

  1. Monolity to najczesciej jedno repozytorium i jeden jezyk programowania a mikroserwisy to wiele jezykow i wiele repozytoriow?

I tak i nie. Faktycznie mikroserwisy to często wiele repo, ale jednak najczęściej pozostaje się przy jednej technologii. Chyba że mowa o wielkich molochach składających się z dziesiątek lub setek mikroserwisow.

  1. Jesli chodzi o skalowalnosc to wieksze problemy mamy z monolitem. Rosnące wymagania na zasoby mogą być coraz trudniejsze do spełnienia przy jednej dużej aplikacji. Przy mikroserwisach zwiększamy liczby instancji wybranych usług i po problemie?

Ogólnie rzecz biorąc to tak.

  1. Czas wdrożenia przy monolicie jest dluzszy bo jest tylko jeden "pipeline". W Mikro jest ich wiele.

Teoretycznie tak, ale różnie z tym bywa.

  1. Elasytycznosc czyli wdrozenie nowej technologi bedzie lepsze przy mikroserwisie, bo ruszenie monolitu to czasami miesiace prace?

Tak.

  1. Niezawodność- mikroserwis wygrywa bo w przypadku awariu musimy odzyskac tylko jedna jednoste a nie jak w monolicie caly stos.

Teoretycznie tak.

Praktycznie wiekszosc rzeczy przemawia za mikroserwisami niz za monolitem. Jak to jest w rzeczywistosci?

W rzeczywistości bywa różnie :) Owszem, mikroserwisy mają wiele zalet ale również mają wiele wyzwań. Trzeba znacznie ostrożniej projektować architekturę na wyższym poziomie, upewniać się że poszczególne serwisy mają dobrze wydzielone odpowiedzialności, pojawiają się wyzwania takie jak komunikacja między serwisami, unikanie nadmiernego wiązania ze sobą serwisów, propagowanie danych między serwisami, koordynacja złożonych procesów itp. W przypadku mniejszych systemów dobrze zaprojektowane monolity to szybsze I prostsze rozwiązanie. Ale "duży" i "mały" system to pojęcia względne.

2
  1. tak (99%)
  2. Najpierw w mikro mamy minus 20,30% wydajności ze względu na koszty, a potem mamy skalowalność horyzontalną (liczba wzięta z sufitu)

6. Coyote uparcie wstawia czwórkę Monolit może pracować miesiacami, czyli tzreba mu przypisać niezawodność 99,9(9) %
Niezawodność hordy mikroserwisów określa się inaczej, zależnie od szeregowo-rónolegle np z potęgowaniem. Ile jest 99.9 ^ 10 ? Wcale nie tak dużo

W ogóle ms "przyzwyczajają" do ograniczonej niezawodności, consistency się zmienia na eventual consistency itd

2

"Niezawodność- mikroserwis wygrywa bo w przypadku awari musimy odzyskac tylko jedna jednostke a nie jak w monolicie caly stos." - teoretycznie tak, ale ma to też swoje wady. Jeżeli monolit padnie to następuje ogólny pad i nie ma nowych danych w systemie. W przypadku systemu rozproszonego to już z tym może być różnie, jeden moduł nie działa, ale do innego są wprowadzane dalej dane przez użytkowników, a później to trzeba przetworzyć więc "nastrojenie" microserwisów biznesowo może być o wiele trudniejsze niż uruchomienie monolitu. Z drugiej strony przy dużych systemach nie da się już praktycznie stworzyć oprogramowania w postaci monolitu.

9

Czy systemy monolityczne slusznie kojarza mi sie z przestarzala technogia?

Nie, niekoniecznie. Jeśli twój system ma określony względnie mały zestaw wymagań i nie ma żadnych wymogów na temat skalowalności, to nic nie stoi na przeszkodzie zrobić monolit.

Monolity to najczesciej jedno repozytorium i jeden jezyk programowania a mikroserwisy to wiele jezykow i wiele repozytoriow?

Nie, niekoniecznie. Pracowałem przy wielu mikroserwisowych aplikacjach które były pisanie w dokładnie takim samym stacku technologicznym, przez tych samych ludzi. Niemniej teoretycznie jest to jak najbardziej możliwe. Aktualnie pracuje przy projekcie gdzie pewne serwisy są pisanie w Pythonie a inne w Javie.

Jesli chodzi o skalowalnosc to wieksze problemy mamy z monolitem. Rosnące wymagania na zasoby mogą być coraz trudniejsze do spełnienia przy jednej dużej aplikacji. Przy mikroserwisach zwiększamy liczbe instancji wybranych usług i po problemie?

Generalnie tak. Monolit wymaga skalowania całego monolitu, nie mozesz wyskalować jednej funkcji. Co więcej mikroserwisy generalnie są budowane przy założeniu że współpracuje ze sobą n:m nodów, podczas gdy monolit może w ogóle niemożliwy do skalowania, bo np. trzyma w pamięci jakiś stan i nie jest w stanie współdzielić go z kolejną instancją.

Czas wdrożenia przy monolicie jest dluzszy bo jest tylko jeden "pipeline". W Mikro jest ich wiele.

Nie. Wdrożenie sie w N mikroserwisów powiazanych ze sobą w jakąś złożoną strukturę wcale nie będzie takie proste. Ale faktycznie możesz wdrażać się np. tylko w jeden konkretny serwis.

Elasytycznosc czyli wdrozenie nowej technologi bedzie lepsze przy mikroserwisie, bo ruszenie monolitu to czasami miesiace prace?

Pewnie tak, bo jak masz mały mikroserwis to nawet przepisanie go od zera to może być kwestia kilku dni. W przypadku monolitu, szczególnie takiego gdzie ktoś nie podzielił kodu na odseparowane moduły, może być bardzo ciężko cokolwiek zmienić, bo inne kawałki kodu będą z tego korzystać. W przypadku serwisów interesuje cię tylko zeby zewnętrzny interfejs pozostał bez zmian.

Niezawodność- mikroserwis wygrywa bo w przypadku awari musimy odzyskac tylko jedna jednostke a nie jak w monolicie caly stos.

Mikroserwisy zwykle są wyskalowane na więcej instancji, więc crash jednej może w ogóle nie być zauważalny, bo wypadnie z load balancera i inne instancje przejmą jej działanie. Z drugiej strony debugowanie problemów może być dużo bardziej złożone...

Praktycznie wiekszosc rzeczy przemawia za mikroserwisami niz za monolitem. Jak to jest w rzeczywistosci?

there is no such thing as free lunch ;) Wszystko ma swoją cenę. Deployment mikroserwisów jest dużo bardziej złożony i implementacja całego systemu również wymaga pewnych decyzji technologicznych. Nie da się np. łatwo synchronizować operacji które są wykonywane na różnych nodach (np. do poczytania https://4programmers.net/Forum/Inzynieria_oprogramowania/345115-wiele_instancji_jedna_baza_eventy_i_odpowiedzialnosc_za_utrwalanie_danych )
Dla wielu ludzi synchronizacja wątków stanowi problem, a w systemie rozproszonym dostaniesz takie coś do kwadratu.

2

W teorii tak, w praktyce nie.

Na co dzień sytuacja jest zbliżona do kupna luksusowego auta jakim mógłbyś wozić się po mieście. Nie tylko rozwiążesz typowy problem związany z przemieszczaniem, ale fura też zadziała na zmysły, popsuje nie jeden dzień sąsiadom, a przy okazji uleczy kompleksy :-)

Tyle, że w praktyce skalowalność to wciąż forma (zieeeww....) optymalizacji. Koncentracja od samego początku na optymalizacji nie wystarczy, aby utrzymać się na rynku. Tak samo możesz od samego początku kreatywnie optymalizować swoje podatki, ale przy niskich osiągach to będzie sztuki dla sztuki, niepotrzebne ryzyko i tym podobne rzeczy.

Optymalizacja ma sens, gdy w excelu Ci wychodzi, że jej potrzebujesz, bo przepłacasz. Nudne, ale prawdziwe.

6
p_agon napisał(a):
  1. Czy systemy monolityczne slusznie kojarza mi sie z przestarzala technogia?

Tak i nie, monolit nie musi być przestarzały a mikroserwis możesz pisać używając nieaktualnych narzędzi. Systemy rozproszone są stare jak sieć.

  1. Monolity to najczesciej jedno repozytorium i jeden jezyk programowania a mikroserwisy to wiele jezykow i wiele repozytoriow?

Różnie, można napisać fragmenty monolitu w różnych językach (np Java i Kotlin) a można pisać mikroserwisy w jednym.

Co do repozytoriów w mikroserwisach - raczej tak, choć są też pomysły typu monorepo. Nie widziałem jeszcze monorepo na kod mikroserwisów, ale widziałem monorepo na infrastructure-as-code dla mikroserwisów i za każdym razem było to ciężkie do ogarnięcia.

  1. Jesli chodzi o skalowalnosc to wieksze problemy mamy z monolitem. Rosnące wymagania na zasoby mogą być coraz trudniejsze do spełnienia przy jednej dużej aplikacji. Przy mikroserwisach zwiększamy liczbe instancji wybranych usług i po problemie?

Nie tak szybko z tym skalowaniem mikroserwisów, bo możesz niby skalować instancje usług, ALE dobijesz do momentu gdy wąskim gardłem będzie np DB, sieć albo inna część infrastruktury.

  1. Czas wdrożenia przy monolicie jest dluzszy bo jest tylko jeden "pipeline". W Mikro jest ich wiele.

Tak i nie, mikroserwis można szybciej bo jest mniejszy, ale też więcej rzeczy może pójść źle w systemie rozproszonym, więcej czarnych scenariuszy trzeba wziąć pod uwagę etc. Poza tym wiele pipeline'ów może też oznaczać większy bajzel itd.

  1. Elasytycznosc czyli wdrozenie nowej technologi bedzie lepsze przy mikroserwisie, bo ruszenie monolitu to czasami miesiace prace?

To bardzo mocno zależy od tego jak działa firma i jak mocno mikroserwisy są ze sobą powiązane. Widziałem np. sytuację gdzie te mikroserwisy musiały być deployowane razem (po części dlatego, że biznes/mgmt tak wymusił, po części dlatego, że były ze sobą zespawane na amen) i to był dramat.

  1. Niezawodność- mikroserwis wygrywa bo w przypadku awari musimy odzyskac tylko jedna jednostke a nie jak w monolicie caly stos.

No tak i nie, w monolicie sytuacja jest o tyle prosta że albo całość działa, albo całość nie działa. W mikroserwisach rzeczy mogą pójść źle na milion sposobów, przeprowadzenie spójnej transakcji jest utrudnione (gdzie w monolicie dosłownie użył byś jednej transakcji bazodanowej, tu kombinujesz z sagami i robieniem rollbacku na poziomie usług), jeśli usługa nie działa lub działa częściowo (np jest przeciążona i rzuca 500tkami na cześć requestów) to musisz wybierać jak system ma na to reagować i tak dalej.

Praktycznie wiekszosc rzeczy przemawia za mikroserwisami niz za monolitem. Jak to jest w rzeczywistosci?

Za wszystkie benefity płacisz większym skomplikowaniem całości i większą liczbą miejsc i sposobów, gdzie coś może pójść nie tak. Niektóre zmiany trudniej jest wprowadzić (jeszcze trudniej, gdy zmiana jest np. na granicy zespół/zespół) o trzeba wziąć pod uwagę, że w danym momencie może żyć dowolna liczba instancji innych serwisów, które mają z Twoim jakiś kontrakt, znają np schemat modeli API w wersji takiej lub innej, umieją przyjąć event z takimi a takimi atrybutami i mogą nie być kompatybilne z Twoimi nowymi zmianami. Nawet jeśli tych kontraktów nie zdefiniowano wprost, to one przecież są.

5

W większości przypadków najlepszym rozwiązaniem jest modularny monilit (dany moduł to odpowiednik ms). Jeśli brakuje wydajności to wydzielasz sobie moduł który jest wąskim gardłem i on może być skalowany. Jak dla mnie to ms przejaw mody, zazwyczaj zbędne, bardzo często odpalona jest tylko jedna instancja takiego serwisu i sporo zasobów jest marnowane na obsługę takiej architektury.

1 użytkowników online, w tym zalogowanych: 0, gości: 1