Sorry, za rantowanie, ale chciałbym znać odpowiedź na pytanie z tytułu. Czy ktoś tu pracuje w projekcie, gdzie czuje, że mikroserwisy są dobrze zrobione i mają sens?
Przewinąłem się już przez kilka projektów, w których były mikroserwisy i, uwzględniając to że każdy definiuje je inaczej, zauważam kompletne oderwanie wyników od obietnic, tak jakby ludzie robili te mikroserwisy zupełnie z innego powodu niż powinni, lub zupełnie na odwrót niż jest to opisywane w książkach.
Projekt 1.
Wiemy, co robimy. Klon istniejącego rozwiązania. Może być dużo użytkowników, ale bez przesady.
4 programistów - 10 mikroserwisów. Każdy commituje do każdego codziennie.
Podział na serwisy warstwowy(WTF) - większość zapytań z frontu powoduje, że każdy serwis dostaje jakiegoś rest-calla.
W rezultacie mamy spaghetti, ale zamiast na poziomie kodu, to na poziomie RESTa.
Projekt 2.
Zespół 4 osobowy - domena niejasna - będzie odkrywana wraz z wymaganiami - mocno w data science.
Nie wiemy, co robimy. Prawdopodobnie wszystko przepiszemy ze trzy razy, zanim będziemy wiedzieć, co chcemy. Najpierw trzeba sprzedać proof-of-concept nieznanemu klientowi.
Dzielimy to na kilka mikroserwisów, bo taka moda. Oczywiście już teraz wiemy, jaki jest najlepszy podział.
Organizacja ma problem z wdrożeniem Dockera (wszyscy pracują na Windowsach). Operations i procedury mają state-of-the-art ale z roku 2008.
Projekt 3.
Znana domena, zmieniana nieczęsto, zgodnie z wolą ustawodawcy. Liczba aktywnych użytkowników ograniczona przez liczbę powiatów w Polsce. SLA co do dostępności: ma działać 9-17 w dniach roboczych. System podzielony na kilka serwisów. Pod spodem wspólna baza danych - każdy serwis zapisuje i odczytuje z tego samego schematu.
Organizacja ma problem z załatwieniem admina na Windowsy dla programistów, a pcha się w mikroserwisy.
Tu mógłbym posądzić oryginalnego pomysłodawcę o CV - driven development. Oczywiście nikt już nie wie, kto to był. Nie zalecałbym innego wzorca architektury niż ładny monolit.
Projekt 4.
Duże korpo. Jakiś podział jest koniecznością, po prostu ze względu na skalę tego potwora.
Ale:
- Wszystkie zespoły commitują do wszystkich serwisów. Jak jest problem, to ten kto ostatni dotykał, naprawia.
- Synchronicznych wołań jest tyle, że każdy serwis staje się point-of-failure.
- Seniorzy mają problemy ze zrozumieniem, że np Kafka wymaga innego podejścia niż @Transactional na twarz i pchasz.
- Współdzielony kod-framework powoduje wymioty.
- Nie ma testów automatycznych obejmujących coś więcej niż jeden serwis.
- Wszystko i tak jest wdrażane big-bangiem.
Projekt 5.
Startup. Mamy ogólny zarys pomysłu. Zamiast zrobić jak najszybciej MVP, które będziemy mogli często zmieniać, albo nawet wyrzucić i przepisać, inwestujemy sporo czasu w architekturę mikroserwisową.
Podział początkowo wydaje się sensowny - klient naciskał, żeby od razu skalować się na miliony. Architektura teraz wydaje się kupą, bo projekt poszedł w inną stronę.
Podsumowując, jeśli w projekcie masz "mikroserwisy" i występuje jeden z symptomów poniżej, to jest bardzo źle, bo kompletnie zapomniałeś, po co wdrażałeś mikroserwisy i jakie są zagrożenia. Najprawdopodobniej i tak nie myślałeś o tym na początku.
- Masz więcej mikroserwisów niż programistów.
- Twoi programiści nie rozumieją problemów rozproszonych.
- Masz takie obciążenie, że możesz hostować na Raspberry Pi
- Twoi architekci zbudowali 15 letnią karierę na gaszeniu pożarów w monolicie. To mądrzy ludzie. Na pewno dadzą sobie radę ze zmianą paradygmatu.
- Modyfikacje wymagań często obejmują wiele serwisów.
- Nie znasz wymagań, ale znasz już architekturę.
- Programista musi znać i tak wszystkie moduły.
- Biznes nie rozumie podziału.
- Biznes nie ma korzyści z podziału.
- Developerzy nie rozumieją, jak ich kod trafia na proda.