Wiem, że służą one głównie poprawie skalowalności i wydajności serwisu. Ułatwiają też prowadzenie dużych i ogromnych projektów. Chodzi głównie o to żeby obliczenia, obciążenie jednego serwera rozłożyć na więcej serwerów. I tu moja wiedza się kończy :D
Służą też poprawie efektywności i samopoczuciu zespołu, dużo prościej jest podbijać wersje bibliotek, języka, frameworka itp, jeśli masz mini aplikacje, niż jak masz wielki korpo monolit, którego samo włączenie trwa mnóstwo czasu i jest wyzwaniem... no i ten czas włączania, pracowałem w systemach w których po każdej zmianie kawałka kodu, musiałem tracić 5 minut na odpalenie systemu, po czym kilka do kilkunastu minut na wyklikanie tego co bym chciał. Nie mówiąc już o buildach w CI trwających wieczność.
Tylko że kluczowe tutaj jest, jak duży byłby nasz monolit, bo niektóre firmy mają całe projekty o rozmiarach pojedynczych mikroserwisów w korporacjach, to w takiej sytuacji nie ma sensu rozdrabnianie się na jeszcze większe mikro kawałki. Mikroserwisem powinien być niezależny obszar biznesowy, a nie wszystko co można nazwać modułem.
Docelowo zespół złożony z kilku programistów, powinien pracować nad jednym lub kilkoma mikroserwisami - niezależnymi projektami utrzymywanymi przez ten zespół.
Zakładam, że mamy aplikację web z n mikroserwisami. Rozumiem, że jak każdy taki mały serwis dostanie swój hardware (czy nawet wirtualne rdzenie) to działa szybciej niż jakby działał na jednym serwerze
Z tą wydajnością to jest jedno wielkie tak i nie, są w systemie obszary które mogą działać wolno i są takie które muszą być szybkie. Przykładowo dodawanie ogłoszeń może trwać kilka sekund, ale wyświetlanie i filtrowanie ich musi być natychmiastowe - taki książkowy przykład. W praktyce trzeba myśleć jeszcze o tym że komunikacja sieciowa zjada sporo mocy, bo trzeba to wszystko zserializować na jsony, przesłać po kablu, odebrać z kabla, przekierować do odpowiedniego sprzętu... po drodze zrobić mnóstwo innych rzeczy, później zdeserializować w docelowym projekcie... to nawet nie brzmi jak coś szybkiego, przekazanie adresu w ram, w ramach jednego procesu, jest dużo wydajniejsze.
W kilku przypadkach można zaoszczędzić na sprzęcie w mniej istotnych obszarach, ale raczej traci się finansowo a nie oszczędza. Ta oszczędność płynie bardziej z pracowników, którzy mają potężne wypłaty - to co napisałem wyżej, mając mikroserwisy dużo zmian da się wprowadzać sprawniej i praca potrafi iść szybciej (pod warunkiem że są dobrze zaprojektowane), zaoszczędzoną kase można władować w mocniejszy sprzęt i jeszcze wyjdzie sie na plus.
ale co z bazą danych w takim rozproszonym systemie
Mikroserwisy powinniśmy traktować jako niezależne produkty, a zespoły jako niezależne firmy, które współpracują ze sobą. Każdy mikroserwis powinien mieć swoją bazę danych, w której tylko on może wprowadzać zmiany. Korzyścią jest to, że jakiś typ z innego zespołu który średnio ogarnia naszą wizje, nie popsuje nam danych. Jeśli zmusimy inne zespoły do tego, żeby korzystały z naszej bazy jedynie za pomocą naszego api, to zawsze będą przechodzić przez nasze walidacje i zawsze dane będą sformatowane w prawidłowy sposób. Łatwiej też będzie zmienić strukture bazy danych, bo już nie używa jej połowa firmy, tylko jeden projekt z jednego zespołu, nie trzeba się martwić o to że rozbijając coś na więcej/mniej tabel, rozwalimy komuś projekt... i wracamy do tego co pisałem wyżej, proste zmiany są proste i nie wymagają wielu miesięcy negocjacji z połową firmy.
