@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.