No dobra, opowiem wam dlaczego nie lubię mikroserwisów. Opowiem o projekcie, który bardzo fajnie pokazują patologie, do których one potrafią doprowadzić.
W jednej firmie mięliśmy z 8letniego monolita w PHP. Wszyscy narzekali na niego, że ciężko to utrzymać, pełno bugów, ale mimo to hajs zarabiał.

W pewnym momencie kolega z biurka obok dostał "awans" czyli został architektem. Naczytał się jakichś książek i poczuł wiatr we włosach. Ale nie o tym...
Mniej więcje w tym samym momencie powstał projekt przerobienia kawałka tego monolitu od nowa. Hurra, wszyscy szczęśliwi. Ja też, ale nie tak bardzo jak ten architekt.
Odbyło się zabranie, gdzie ustalaliśmy jaka będzie architektura nowego rozwiązania. Były dyskusje, że monolita mamy i "nigdy więcej". Więc co przyszło nam z pomocom? Oczywiście mikroserwisy.
Z racji, że cała firma stała na PHP to i owe serwisy PHP sa napędzane. Dla mnie spoko. Postanowiono rozbić całą domenę na kilka mniejszych kroków:

[s1] zlecenie zrobienia zrzutu ekranu z przeglądarki
[s2] stworzenie zrzutu ekranu
[s2] wrzucenie owego screenshota na aws s3 + aktualizacja w bazie (monolitowej|) z linkiem do screena
[s3] odczyt z bazy danych takowych "świerzych" screenów, resize[s4] oraz ponowny upload na aws s3 (czyli tworzenie miniaturki)
[s5] zaktualizacja danych w bazie danych tak, aby klient zlecający owego screena wiedział, że operacja jest wykonana

Dodam tylko, że każdy z tych punktów to był oddzielny mikroserwis. Co ciekawe, to resize wykonywał też kolejny mikroserwis.
Generanie, osoby, które pracowały z robieniem screenów z przeglądarek z CLI to wiedzą, że demonem szybkości to nie jest. Tak więc, projekt rozrósł się do około 6 mikroserwisów.

Sugerowałem, że skoro serwis s2 ma już tego screena, to przecież może od razu zrobić resize i wrzucić na s3 oba pliki za jednym zamachem. Nie potrzeba przepychać kilka megabajtów per obrazek na s3 i z powrotem bo to strata czasu i transferu. Argument przeciw mojemu pomysłowi: a co jeśli jeden upload się uda a kolejny nie? Będą niekompletne dane. Odpada. - oczywiście nie udało mi się przekonać.

Było jeszcze kilka takich dyskusji dlaczego tyle serwisów. Choćby to, że a co jeśli będziemy chcięli skalować serwis [s3] albo [s5] inaczej niż całą resztę? Oczywiście głucho było na argument, że to właśnie [s2] jest bottleneckiem w całym procesie. Nic nie skórałem.

Było tego jeszcze parę rzeczy, ale teraz wisienka na torcie. Infrastruktura.
Serwisy były uruchamiane na jakiejś wirtualce poprzez ansible przez adminów. Ręcznie. Z CLI. Oczywiście nie chciało im się co parę godzin wchodzić do konsoli, to robiliśmy to w patchach. Średnio raz w tygodniu.

Wszystkie te serwisy były w jednym katalogu. Jeden koło drugiego, tylko odpalane na innych portach. Nie było żadnego skalowania, bo ani nie było ec2 czy k8s. Więc zawsze wszystko chodziło w jednej instancji.

Observability? No proszę... Logi wyplute do jakiegoś serwera, który zbierał logi z innych serwerów musiały nam wystarczyć. Pliki te oczywiście były kompresowane, aby zaoszczędzić trochę miejsca na dysku. zgrep rządził. Olewając już oczywiście fakt, że te rozwiązanie potrafiło gubić logi i aby mieć absolutną pewność, że wszystko jest OK to musiałeś i tak przez ssh wejść na ten serwer i sobie pogrepować.
Alerting? Brak
Metryki? Brak

Tylko te logi na dysku...

Teraz też spotykam się z patologiami, ale nie na aż tak wielką skalę. Przykładem jest to, że jakaś domena została pokrojona na kilka kawałków. Dwa z nich są baaardzo ze sobą związane. Tak bardzo, że stukają do siebie na wzajem po dane, które potrzebują :)

Im bardziej w las, tym mniej mikroserwisy lubię...