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 Wiele instancji, jedna baza, eventy i odpowiedzialność 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ą.

6

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.

5

Mikroserwisy mają też swoje wady, np. trzeba poświęcić czas na ogarnięcie komunikacji pomiędzy mikroserwerwisami (w tym schemat danych, wersjonowanie API) znajdowanie błędów jest trudniejsze (błąd jest u mnie czy usługa w innym serwisie się zrypała?)
No i dochodzi problem z tym że te mikroserwisy też się komunikują więc jest dodatkowy koszt np. na połączenia HTTP zamiast na latanie danych po RAMie.

2

Dobrze piszą wyżej to się nie będę produkował, i tak więcej bym pewnie nie dodał. Jest w sumie jedno co chciałem zauważyć:

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?

Poczytaj sobie o skalowaniu wertykalnym i horyzontalnym i co to za sobą niesie, trochę się rozjaśni ;)

11

@p_agon:

Czy systemy monolityczne slusznie kojarza mi sie z przestarzala technogia?

Raczej z niemodną. Niemodna to nie znaczy przestarzała, moda wraca.

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

Monolity -- nnnnie. Jedno repozytorium to raczej tak. Jeden jezyk przeważnie jest nawet niemożliwy.
Mikroserwisy - niby miało być wiele jezyków, ale w każdym korpo dostajesz na twarz jakiś stos technologiczny, z którego nie da się wychylić i potem mam przykładowo 20 mikroserwisów w javaee (serio - znam ten przypadek. Technicznie możesz zrobić w czymkolwiek, ale co z tego... jak Cię złapią architekci).

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?

Tylko trzeba umieć zrobić mikroserwisy tak, żeby rzeczywiście się skalowały. Jest to nadal dość trudne. Z monolitem jest problem na etapie obserwacji - nie wiemy który faktycznie komponent klęka, bo wszystkie chodzą jako jeden proces.

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

Depends. Zależy jak na to patrzysz. Postawienie sensownej infrastruktury pod ms (od zera) to tytaniczne wyzwanie i w tym czasie zrobisz pięć monolitów i jeszcze wyjedziesz na rok na malediwy, żeby zobaczyć mikrowyspy:-)
Jak już ta infastruktura działa to faktycznie wdrażanie zmian jest dużo łatwiejsze pod ms.

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

Ogólnie prawda. Tyle, że infrastruktura pod ms .. to też jest technologia, mamy tam jakieś security, diagnostykę, monitoring i może się okazać, że zmiana tej inrastruktury to też niezły dramat...

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

Tak czy siak system nie będzie działać :-)

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

Moje uwagi.
Oryginalnie słowo monolit oznaczało rzeczy oraz zjawiska jednorodne, spójne, tworzące niezróżnicowaną całość.
Problem w tym, że większośc systemów określanych jako monolity to faktycznie ulepce tworzone przez różne zespoły, zebrane w jedną całość przy pomocy taśmy klejącej, zeschniętej kupy i trytytek.
Lepszym słowem na takie systemy byłby koprolit (czyli stara kupa). Stąd złe kojarzenie się słowa. (Dokładnie w tej chwili siedzę przy systemie, który składa się z 10 niespójnych kawałków, tylko dlatego, że w pewnym banku był za duży narzut biurokratyczny przy tworzeniu nowego projektu (git, jira, uprawnienia, wiki), więc zespół każdy nowy projekt dorzucał jako moduł do tego jednego, który udało się kiedyś przepchnąć).

Modułowy monolit, z nowoczesną architekturą to jest dla mnie nic złego. I wręcz uważam, że powinien być to default dla wiekszości startujacych projektów.

Mikroserwisami można docelowo osiągnąć dużo, dużo więcej, ale też o wiele większym kosztem i przy bardzo dużych początkowych nakładach pracy. Źle przygotowana infrastruktura pod mikroserwisy będzie dramatycznym problemem przy tworzeniu softu.
Dlatego wolałbym zwykle wjechać z monolitem na produkcje, a jak już system zacznie odnosić sukces to powoli wydzielać kawałki i rozbudowywać infrastrukturę i organizację pracy.

Pomiędzy monolitem, a mikroserwisami jest całe spektrum rozwiązań.

Wersja TL;DR;
Praktycznie większość rzeczy przemawia za tym, żeby spać w pałacu, a nie w szałasie. Ale jak jesteś daleko w lesie i zbiera się na deszcz, a nie masz gotowego pałacu pod ręką to zbudowanie szałasu nie jest takim złym pomysłem.

2

Lepszym słowem na takie systemy byłby koprolit (czyli stara kupa).

To jest bardzo dobre określenie. Jak pracowałem w KS to tam wiele zespołów komitowało do tego samego repo. Nikt nie wiedział czyj kod jest czyj i co można zmienić. Niby był podział na pakiety (tak, pakiety, nawet nie moduły) ale i tak zależności i kopa ciekły i się mieszały :(

Przy "mikroserwisach" jest czesto tak że "jeden zespół - jeden mikroserwis". I mniej więcej wiadomo co robi dany kod.
Z tego mój prywatny wniosek że jak w całej firmie masz tylko 10 osób pracujących nad produktem to oczywiście możesz iść w mikroserwisy, ale tych mikroserwisów powinno być jeden góra dwa :D

8

Nie czytałem innych odpowiedzi (chcę napisać co myślę zanim przeczytam co napisali inni, więc mogę się powtarzać):

Czy systemy monolityczne slusznie kojarza mi sie z przestarzala technogia?
NIE - modular monolit wrócił znowu do gry, jako zalecana architektura na start dla małych zespołów.

Monolity to najczesciej jedno repozytorium i jeden jezyk programowania a mikroserwisy to wiele jezykow i wiele repozytoriow?
NIE - można mieć monorepo przy mikroserwisach, Google tak pracuje, ja też tak obecnie pracuje. Generalnie monorepo to nie jest zabawka dla małych firm i zespołów, tylko dla tych co mają już ze 100+ deweloperów. Generalnie przy tym podejściu musi być dedykowany zespół który ogranie build infrę (np. jak to ogarnąć na Jenkinsie żeby nie budować całości, wykonywać tylko właściwy podzbiór testów itp.).

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 pod warunkiem że problem da się zrównoleglić (nie każdy się da). Inna sprawa że wszystko kosztuje więc może się okazać że jest szybko ale za drogo. Kolejki (jako decoupling) bardzo tutaj pomagają.

Czas wdrożenia przy monolicie jest dluzszy bo jest tylko jeden "pipeline". W Mikro jest ich wiele.
NIE - obecnie przy auto deployach, można monolit w góra 5min wsadzić na produkcje z green blue deploymentem (czyli nowe środowisko stawiamy od zera, wgrywamy apkę puszczamy testy i powoli przerzucamy ruch, po czym wygaszamy stare środowisko).

Elasytycznosc czyli wdrozenie nowej technologi bedzie lepsze przy mikroserwisie, bo ruszenie monolitu to czasami miesiace prace?
He he he, przy mikroserwisach jest szybciej bo są to młodsze projekty, ocenimy za 10 lat jak to będzie faktycznie wyglądać. Generalnie mikroswerisy a modularny monolit nie ma za dużej różnicy tu i tu można zrobić kopię wybranej usługi/modułu i tam rzeźbić sobie na spokojnie w nowych technologiach.

Niezawodność- mikroserwis wygrywa bo w przypadku awari musimy odzyskac tylko jedna jednostke a nie jak w monolicie caly stos.
he he he, niezawodność całości to iloczyn niezawodności części. Przy mikroswerwisach więcej rzeczy może się spier**lić ale zazwyczaj odetnie to tylko część funkcjonalności. Czyli przy mikroserwisach applikacja działa, ale jej obszary funkcjonalne mogą szwankować. Przy monolicie jak jest wyciek pamięci to kaplica. Należy też dodać że debugowanie mserwisów to wyższy poziom wtajemniczenia.

Praktycznie wiekszosc rzeczy przemawia za mikroserwisami niz za monolitem. Jak to jest w rzeczywistosci?
Mały projekt i jeden lub dwa zespoły -> modularny monolit. Mikroserwisy są po to żeby: 1) skalować aplikacje przetwarzające olbrzymi ilości danych 2) ogarnąć pracę dużej ilości zespołów > 7 (na oko wartość), tak żeby sobie nie deptały po piętach

Jeden lub dwa zespoły -> modularny monolit, >7 mikroswerwisy, pomiędzy szara strefa. Wiele firm jeżeli myśli o rozbudowie IT do wielu zespołów to będzie się skłaniać do podejścia mikroswerisy od początku. W sumie to nie takie złe tyle że trzeba płacić wolnym startup'em i setup'em projektu (np. setup JWT lub innego auth cośtam, agregacji logów, gateway'i itp).

1

Bez powielania tego co było napisane wyżej, jeszcze dodam, że zazwyczaj zbudowanie architektury mikroserwisowej jest trudniejsze niż monolitycznej.
Jeżeli bierze się za to ktoś, kto miał mało z tym do czynienia, to zazwyczaj wychodzi rozproszony monolit, a to jest jeszcze gorsze.
Może i w rozproszonym monolicie nie ma zalet monolitu, ale za to nie ma też zalet mikroserwisów.

2

Jeszczą są self-contained systems :p. Ja w projektach ich używam i sprawdza sie całkiem spoko :). https://scs-architecture.org/

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

Nie, teraz jest raczej przesadny hype na mikroserwisy (i jakieś potworki gdzie ktoś napisał "mikroserwis" w projekcie, a z twarzy to podobne do niczego).

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

Monolit w przypadku SPA to co najmniej 2 języki (front + back end). Repozytoria - co kto woli.

  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?

Trochę tak - to czy możesz skalować jakąś usługę zależy od tego czy jest ona stanowa, czy nie. Jeżeli będziesz mieć bezstanowy monolit to też możesz go skalować horyzontalnie. Da się też napisać stanowy mikroserwis i jego horyzontalne skalowanie będzie trudne. Różnica w skalowaniu polega na tym, że jesteś w stanie zwiększyć zasoby w tym kawałku systemu, gdzie ich brakuje, a nie od razu po całości.

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

Nie, czas wdrożenia systemu w przypadku mikroserwisów jest dłuższy. Trik polega na tym, że w przypadku poprawnej architektury uS na raz wdrażasz jej pojedyncze elementy.

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

Nie wiem czy dobrze rozumiem pytanie. Przy (ppoprawnych) uS masz możliwość zdecydowania na etapie dopisywania kolejnej usługi "tutaj bardziej będzie pasować język X". W praktyce jak już masz 20 innych usług pisanych w języku Y, to przydałoby się mieć dobry powód do tego, żeby tego nowego języka użyć

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

W poprawnej architekturze uS na ogół wiesz która konkretna usluga walnęła. Czyli musisz grzebać w kilkuset liniach kodu, a nie w kilkuset tysiącach,

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

Mikroserwisy są architekturą trudną i kosztowną. Mają parę zalet typu (kolejność przypadkowa, bez brnięcia w detale):

  • łatwa skalowalność
  • możliwość robienia rolling updates
  • możliwość przypisania konkretnych usług do konkretnych zespołów
  • bezpieczeństwo wdrożenia - mały zakres, czyli jak coś walnie to kawałek systemu, a nie całość (chyba, ze masz pecha), jak trzeba wrócić z wersją, to też łatwiej to zrobić (albo i nie...)

Inżynieria oprogramowania, to dobieranie takich rozwiązań do wykonywanych zadań, żeby zalety przynosiły korzyści, a wady nie były w konkretnym przypadku istotne. Nie da się ogólnie odpowiedzieć "uS > monolit" To tak jak byś zapytał czy lepiej kupić ciągnik siodłowy z naczepą, czy jakis supercar bez brania pod uwagę czy chcesz rwać laski na blachę, czy przewieźć 30 ton towaru.

2

18 minut o mikroserwisach od mojego ulubionego internetowego kaznodziei (Martin Fowler - błąd, Dave Farley), pozwoli poukładać sobie temat.

1

Możesz sięgnąć do książki współautora tego terminu Sam Newman "Od monolitu do mikrousług. Ewolucyjne wzorce przekształcania systemów monolitycznych" są tam opisane problemy związane z architekturą mikrousług i konkluzja, że nie zawsze to jest dobre rozwiązanie.

4
superdurszlak napisał(a):
p_agon napisał(a):
  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.

Baza danych pod mikroserwisem jest częścią tego mikroserwisu. Tzn jeśli mikroserwis nie jest właścicielem i jedynym użytkownikiem swojej bazy danych, to ja tego wolę nie nazywać architekturą mikroserwisową.

5

Baza danych pod mikroserwisem jest częścią tego mikroserwisu. Tzn jeśli mikroserwis nie jest właścicielem i jedynym użytkownikiem swojej bazy danych, to ja tego wolę nie nazywać architekturą mikroserwisową.

W mikroserwisach chodzi o biznesowe właścicielstwo danych i rozdzielność dostępu. Postawienie mikrousług na jednym klastrze ma jak najbardziej sens. Skalowanie stanu to inne zagadnienie niż skalowanie samych usług.

1
ArchitektSpaghetti napisał(a):

Baza danych pod mikroserwisem jest częścią tego mikroserwisu. Tzn jeśli mikroserwis nie jest właścicielem i jedynym użytkownikiem swojej bazy danych, to ja tego wolę nie nazywać architekturą mikroserwisową.

Jeżeli piszesz że usługa A ma korzystać z innej bazy danych niż usługa B, (czyli usługi nie mają się ze sobą komunikować poprzez warstwę danych) to jak najbardziej OK. Sprawa się komplikuje przy skalowaniu. Np. masz usługę z kontami użytkowników (ServiceUser), ruch idzie w górę, skalujesz usługę do, ServiceUser1...ServiceUser10, ale nie jesteś równie łatwo skalować DbUser. Albo skorzystasz z jakiejś usługi zarządzalnej o gwarantowanym dostępie (chmura gwarantuje ci czas dostępu niezależny od obciążenia), albo zakładasz, że skalowanie wertykalne załatwi ci problem (podkręcasz zasoby dla DB), albo musisz zainwestować sporo wysiłku w projekt i implementację, żeby każda instancja usługi miała swoją własną izolowaną instancję źródła danych.

1

@piotrpo: jemu bardziej chodziło chyba o to aby usługa która nie jest ServiceUser nie odwoływała się do jej bazy. bezpośrednio.
No bo w mikroserwisach, to chodzi o to przecież aby to były od strony "działania" niezależne byty. Jeżeli wszystkie mają tę samą bazę danych, to tak trochę wypaczone to to jest nie?

1

@.andy: ale przecież dla pewnej definicji DB Kafka, NATS, etc. też się wpisują w definicję "bazy danych". Do tego masz jeszcze wszelkie systemy eventowe, które też można wliczyć do takiej formy pracy z danymi. Więc jak najbardziej DB są, i będą, współdzielone pomiędzy różnymi mikroserwisami (dla pewnej definicji DB).

3
hauleth napisał(a):

@.andy: ale przecież dla pewnej definicji DB Kafka, NATS, etc. też się wpisują w definicję "bazy danych".
Do tego masz jeszcze wszelkie systemy eventowe, które też można wliczyć do takiej formy pracy z danymi. Więc jak najbardziej DB są, i będą, współdzielone pomiędzy różnymi mikroserwisami (dla pewnej definicji DB).

No ale Kafka to przecież broker wiadomości. Ma ona za zadanie łączyć ze sobą mikroserwisy. Producent produkuje a konsumenci konsumują.
No nie do końca się z tym mogę zgodzić. No ale ja świeżak jestem w tych tematach i mogę się mylić ;)

3

Albo skorzystasz z jakiejś usługi zarządzalnej o gwarantowanym dostępie (chmura gwarantuje ci czas dostępu niezależny od obciążenia), albo zakładasz, że skalowanie wertykalne załatwi ci problem (podkręcasz zasoby dla DB), albo musisz zainwestować sporo wysiłku w projekt i implementację, żeby każda instancja usługi miała swoją własną izolowaną instancję źródła danych.

yyyy, no nie do końca? To tez zalezy od typu bazy danych. Jak masz np. Elastica to możesz po prostu uruchomić wiele instacji. Oczywiście to nie działa tak, że dwa razy więcej instacji = dwa razy większa wydajność (bo jest routing itp), ale mimo wszytko nie każda baza danych = 1 leader + kilka followersów.

No ale Kafka to przecież broker wiadomości.

No zgadzam się. Kafka czy tego typu narzędzia są rozwiązaniami służącymi do komunikacji.

2

@Aleksander32: Wiele rzeczy można, na SQL też możesz zrobić np. read replicas. Tylko o ile skalowanie usług to sekundy, skalowanie infrastruktury minuty, to skalowanie horyzontalne baz danych jest już grubszą sprawą. Celem skalowania jest nie tylko odpowiedź na duży ruch. To również powinno działać w drugą stronę.

7

Skalowanie jako takie też nie jest takie proste jak się wydaje. To, że dołożymy 10 dodatkowych replik danego serwisu (węzłów) wcale nie musi oznaczać, że będzie "10 razy szybciej" albo będziemy mogli w stanie obsłużyć "10 razy większy ruch". Po drodze jest jeszcze prawo skalowalności Amdahla i prawo skalowalności uniwersalnej:

Wydaje się, że nie ma w tym temacie silver bullet. Trzeba zdefiniować metryki, mierzyć ruch i zachowanie zasobów, a potem to obserwować i wyciągać wnioski znając ograniczenia wynikające z teorii.

Edit:
Btw. w temacie skalowania i zgadywania fajne pytanie zadał kiedyś Piotr Stapp na swojej prezentacji, na Boiling Frogs: "ile serwerów minimalnie potrzebuje nasza aplikacja?" - odpowiedź można policzyć tutaj.

1

Chyba nie było ...

The Majestic Monolith

https://m.signalvnoise.com/the-majestic-monolith/

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