Jak duże mikroserwisy WARTO robić?

Na bazie dyskusji z zespołami u mnie w projekcie doszło do dyskusji jak porozdzielać odpowiedzialności dla prostej strony, będącej częścią dużego serwisu. Strona (OPA) ma robić dwie, niezbyt skomplikowane rzeczy i pojawiło się w dyskusji trochę możliwości:

1. Podejście podręcznikowe na pełnej mocy:
   Stawiamy sobie za głównym API gatewayem następujące serwisy:

• fasadę (gateway) z zadaniem grupowania endpointów wykorzystywanych przez aplikację webową
• uS dla funkcjonalności A - prosta zmiana w bazie danych
• uS dla funkcjonalności B - przyjęcie tego pliku na klatę i orkiestracja działania innych serwisów (już istniejących)
• na istniejącym już serwerze www publikujemy endpoint (raczej nie ma sensu stawiać osobnych serwisów do serwowania statycznych plików)

2. Podejście "konformistyczne":

• stawiamy serwis, który zawierać będzie w sobie całą logikę opisaną w podejściu wyżej
• Na istniejącym API gateway'u dodajemy trochę przekierowań

Argumenty padające za pierwszym rozwiązaniem, to wiadomo - jasny podział odpowiedzialności, jak wchodzimy w mikroserwisy, to na całość itp.
Argumenty za drugim podejściem, to "za dużo repozytoriów gubimy się", "więcej serwisów, to więcej zasobów (wszystko chodzi w k8s, więc trochę moim zdaniem na wyrost)

I pytanie - które z powyższych podejść jest lepsze w dużym projekcie, wszystko publikowane w chmurze, łącznie kilkadziesiąt osób zaangażowanych w zabawę (bezpośrednio w tę część 5 ludzi). Zależy mi na praktycznym podejściu, jak jest w książkach wiem.

A jaki zysk będziesz miał z tego że rozbijesz tą funkcjonalność na dwa mikroserwisy?

1. Napiszę raz, opublikuję, nie muszę pamiętać o tym przez następne 10 lat
2. Skoro mogę wrzucić 2 różne odpowiedzialności w jeden serwis, to dlaczego nie 20?
3. Mogę niezależnie skalować każdą z funkcjonalności (tutaj trochę na wyrost, ale mogę).
4. Za chwilę, rozbijając na drobne bazę danych, mogę zrobić to z sensem, a nie tak jak mi narzuci już istniejąca struktura serwisów.
5. Jeżeli konieczne będą zmiany, deployment robi się łatwiejszy (mniejsze pole rażenia ewentualnych błędów
6. Jak coś się zacznie sypać, to utracimy tylko jedną z 2 funkcji systemu.
7. Im mniejszy serwis do podniesienia, tym szybciej wstaje - automatyczne skalowanie ma szansę działać dużo lepiej.
   To takie główne jedynie. Są też koszty takiego podejścia:
8. Trochę więcej zasobów - narzut Springboota
9. Dodatkowe repozytorium, o którym trzeba pamiętać, podłączyć do CI/CD, dokumentować, testować, wydawać

piotrpo napisał(a):

Argumenty padające za pierwszym rozwiązaniem, to wiadomo - jasny podział odpowiedzialności, jak wchodzimy w mikroserwisy, to na całość itp.

To jest argument przeciw, a nie za - More the merrier

Przypominam, że mikroserwisy są architektura wdrożeniowa. To znaczy, po to dzielisz i komplikujesz sobie życie, żeby zespoły odpowiedzialne za różne konteksty, mogły dostarczać wartość biznesowa niezależnie. Czyli, jeśli masz zespół odpowiedzialny za ficzur X i Y, to mogą one być w jednej usłudze. Jeżeli natomiast te ficzury dotyczą różnych kontekstów biznesowych, to coś nie pykło na poziomie prawa Conwaya.

Pragmatyczne podejście nigdy nie jest takie, ze robimy w sposób X wszystko albo nic.

To zależy. Co z tego będziesz miał że je podzielisz? Np
Osobno się skalują? A muszą? Będą zjadać mniej zasobów?
Osobne zespoły będą pracować nad nimi?

Z tego co piszesz, to w tym momencie macie mało zysków z tego podejścia a więcej problemów. Skupiłbym się na zrobieniu modularnego monolitu. Czyli napiszcie ten kod tak, żeby dało się w razie potrzeby go wyciągnąć na dwa serwisy, ale póki co siedzi to razem. Żadnego spagetti ale moduły. Osobne tabele/kolekcje. Możecie nawet jeśli to wam ułatwi pracę użyć jakiś kolejek wewnątrz. Ale podejrzewam, że to przerost formy nad treścią.

Jesli to dobrze zrozumialem ( bo to nie pelny obraz) to jest tylko jeden powod zeby rozbic to na mikroserwisy.
Wpis do CV i nauka kosztem tego projektu/klienta. To juz decyzja bardziej polityczna i biznesowa czasem, niz techniczna. Np moze byc tak, ze nastepny projekt bedzie mocno mikroserwisowy i teraz lepiej zaplacic koszt nauki nowych rzeczy na tym, kosztem tez czasu realizacji, a przy nastepnym sie to zwroci. Tu zakladam te sama firme/klienta zeby bylo uczciwie.

Oprogramowanie projektuje się pod konkretny problem a nie zgodnie z religijnymi regułami, chyba że to (x)DDD...
Dzielenie czegoś na mikroserwisy powinno byc podyktowane:

• Skalowalniem i wdrożeniem -> jeśli jakis element systemu chcesz skalować 10x mocniej niż inny, to warto je od siebie oddzielic
• Cyklem życia -> jeśli jakiś element systemu ewoluuje dużo szybciej i wymaga częstych zmian, to bardzo możliwe, ze lepiej niech będzie osobno
• Podziałem pracy -> jak masz 100 developerów którzy mieszają w tym samym kodzie i wchodzą sobie na głowę, to znów lepiej to jednak jakoś podzielić i ich od siebie uniezależnić

Nie rozumiem czemu chcesz robić wszystko albo nic. To nie ma sensu. Dobieraj narzędzia do problemu.

Shalom napisał(a):

Nie rozumiem czemu chcesz robić wszystko albo nic. To nie ma sensu. Dobieraj narzędzia do problemu.

Mam jakieś tam zdanie w tej dyskusji (wewnętrznej), teoretycznie wiem jaki sens mają mikroserwisy, znam wzorce itd. Problem z literaturą jest jednak taki, że pozycji opisujących konkretne rozwiązanie jest dużo, ale brakuje wiedzy KIEDY warto tego używać. Kryteria, które podałeś brzmią bardzo sensownie, dzięki.

Walnij sobie monolitycznego klocka, wyrzeźbił go niczym Fidiasz, to będzie to pomnik trwały, trwalszy od spiżu.