Kiedy rozdzielać kod na mikroserwisy?

Mam problem z podejściem architektonicznym do mojego problemu. Rozwijam sobie własny projekt, główny soft + SDK. SDK to nic innego jak biblioteka zbierająca dane i wysyłające do softu napisanego w NodeJS (ale to w sumie bez znaczenia). I teraz tak, z racji, że moje SDK zbiera dane dość często postanowiłem po odebraniu requestu od niego dodać payload do kolejki SQS na AWS. Dodatkowo za każdym razem kiedy do SQS wlatuje nowy item, triggerowana jest funkcja na AWS Lambda która processuje ten payload (obrabia, zapisuje itd.). Cały soft to generalnie rzecz ujmując monolit, zgrabny bo ładnie rozwijany ale monolit. I teraz mam pytania.

1. Czy endpoint odbierające dane z SDK powinien być osadzone na oddzielnym mikroserwisie aby odciążyć główny soft? - jedyne co jest robione to odbieranie request.body i dodawanie do kolejki SQS. Chyba, że lepiej byłoby go również osadzić na AWS?
2. Czy jest sens pisania handlera do SQS na oddzielnym mikroserwisie kiedy sama funkcja jest eksportowana do Lambdy? - w końcu kod i tak się nie wykonuje na instancji serwera a jedynie na instancji AWS Lambdy.
3. Kiedy należy rozdzielać kod na mikroserwisy? Powiedzmy, że mam takie cztery główne funkcjonalności na ten moment, czyli obsługę danych z SDK, obsługę użytkownika, obsługę kolejek czy obsługę webSocketów. Czy jest zawsze sens to wszystko rozdzielać?

Dzięki za każde podpowiedzi!

z racji, że moje SDK zbiera dane dość często postanowiłem po odebraniu requestu od niego dodać payload do kolejki SQS

Chyba nie do końca rozumiem tą motywacje. Kolejka raczej sugeruje że np. chcesz przetwarzać dane asynchronicznie i np. chcesz żeby ci nic nie "zginęło" jakby serwis padł. Częstotliwość zbierania trochę nijak się tu ma do czegokolwiek.

a każdym razem kiedy do SQS wlatuje nowy item, triggerowana jest funkcja na AWS Lambda która processuje ten payload

To w połączeniu z zbiera dane dość często sugeruje że koszty mogą być spore. Lambda jest spoko, kiedy tych triggerów jest mało. Jak robią się cały czas, to może być taniej postawić serwis który działa cały czas i obrabia dane z kolejki.

Kiedy należy rozdzielać kod na mikroserwisy? Powiedzmy, że mam takie cztery główne funkcjonalności na ten moment, czyli obsługę danych z SDK, obsługę użytkownika, obsługę kolejek czy obsługę webSocketów. Czy jest zawsze sens to wszystko rozdzielać?

Ja bym wyszedł od takich pytań:

1. Czy potrzebujemy skalować jakiś element systemu horyzontalnie? Czyli np. z tego SDK przychodzi ci 100k rq/s i fizycznie nie obsłużysz tego jedną instancją i trzeba ten element systemu który przyjmuje dane zwielokrotnić i postawić za jakimś load balancerem.
2. Jak mocny jest coupling tych elementów? Bo może się okazać ze zrobisz sobie tzw "rozproszony monolit", czyli niby masz jakieś serwisy, ale w praktyce wszystko jest od wszystkiego zależne.
3. Jaki jest lifecycle tych elementów? Może np. część systemu odpowiedzialna za interakcje z użytkownikiem zmienia się często, a część związana z odbieraniem danych nie? Jeśli pracując nad zmianami zawsze dotyczą one tylko jednego z komponentów, to wygodniej jest pracować tylko z tym komponentem.

Rozbijaj na mikrouslugi, aby (1) mieć niezależność wdrożeń (podział domenowy) i/lub (2) obsługiwać różne charakterystyki ruchu (np. dużo zapisów vs complex query). Wtedy jest szansa, że taki ruch Ci się spłaci, wpp. to czysta edukacja lub technologiczny onanizm. Oczywiście dużo tez zależy, jaką masz skalę - ile osób rozwija system (zakładam, że 1) oraz jaki masz ruch.

Najkrótszą odpowiedzią jest, że warto stosować mikroserwisy, kiedy jest jakiś powód ku temu. Wyczuwam nosem, że wybrałeś architekturę deploymentu i szukasz uzasadnień, zamiast wyjść od problemu i zastanawiać się które narzędzie do niego najlepiej pasuje. Mikroserwisy są trudne i pracochłonne w rozwoju i utrzymaniu. Nie jestem przeciwnikiem takiej architektury, ale warto pamiętać, że to nie jest uniwersalne narzędzie do rozwiązania każdego problemu, a już na 100% nie jest to podejście od którego należy startować myślenie w sensie "jak mikroserwisy nie podpasują, to przerobimy na monolit".
Problemy, które takie podejście jest w stanie rozwiązać:

• muszę dynamicznie skalować jakąś część funkcjonalności

• mam jakieś legacy bagienko i chcę dorobić nowe funkcjonalności

• chcę jakieś serwisy ponownie użyć w innych projektach organizacji (podobno, jeszcze nie widziałem na żywo)

• chcę zwiększyć niezawodność poprzez ograniczenie zakresu zmian i zwiększenie ich częstotliwości, łatwość rollbacku (dyskusyjne), ograniczenie zakresu awarii do jakichś tam ścieżek (np. nie da się zarządzać sklepem, ale wciąż da się sprzedawać)

• podawany tutaj powód z którym średnio się zgadzam - inaczej nie da się wymusić faktycznej izolacji modułów/warstw itp. Kończy się takim burdelem jak był w monolicie, tylko podniesionym do kwadratu

  Więc pytanie do ciebie - jaki problem chcesz rozwiązać?
  Dodatkowo, mikroserwisy potrafią spowodować bardzo ostre przywalenie w ścianę, jeżeli stosuje się je na siłę idzie na skróty i nie poświęci się na początku sporo czasu, żeby sobie zautomatyzować budowanie, testowanie, deployment, monitoring, logowanie itd.

Lambda to nic innego jak jakaś tam forma mikroserwisu, więc nie ma sensu jej dublować (pytanie, czy warto jej używać).