Rozdzielenie baz danych w mikroserwisach

Kiedy w architekturze mikroserwisów lepiej tworzyć oddzielne schematy bazy danych per serwis a kiedy oddzielne instancje per serwis? Co brać pod uwagę przy podejmowaniu takiej decyzji?

Zawsze instancje. Jeśli masz jakiekolwiek powody, by dwa serwisy miały jedną bazę, to prawdopodobnie powinieneś je połączyć.

Używając jednej instancji tracisz jedną z największych zalet mikroserwisów, tj. niezależne skalowanie.

Być może są sytuacje, w których tańsze jest opłacenie jednej dużej bazy zamiast wielu mniejszych, ale z technicznego punktu widzenia takie rozwiązanie nie ma żadnych zalet.

Moim zdaniem tych czynników jest tak dużo, że można by napisać książkę na te temat.

"Ale to już było i nie wróci więcej lalala."

Do meritum. Zawsze jeden serwis jedna baza.

• Co ci z osobnych schematów jak przykładowo ci instancja bd padnie i automatycznie wszystkie serwisy się wyłożą?
• Co jeżeli któryś z mikroserwisów dostanie taki ruch że jego operacje na bazie danych zamulą pozostałe usługi?
• Co jeżeli zespół odpowiedzialny za mikroserwis B pójdzie sobie na skróty i będzie korzystał ze schematu serwisu A w swoich zapytaniach i usługa się wyłoży jak zespół A usunie kolumnę z tabelki w swoim schemacie? Tak wiem że można ogarnąć to dostępami na poziomie bd.
• Co jeżeli relacyjny model danych dla danego mikroserwisu nie jest optymalny bo robi dużo odczytów i wyszukiwań i lepiej byłoby zastosować którąś z baz NoSQL jak Cassandra?

Jeżeli aplikacja jest na tyle mała, że jest w stanie pracować na jednej instancji bazy danych, ale z różnymi schematami to tym bardziej jej architektura nie powinna być rozproszona czy tam oparta o mikrousługi. Dużo lepszym wyborem byłby modularny monolit, który później można pociąć na mniejsze kawałki.

A w ogóle przez oddzielną instancję bazy rozumiesz oddzielną bazę na jednym serwerze bazodanowym, czy oddzielny serwer bazodanowy?
Bo wszystkie odpowiedzi skupiają się na oddzielnym serwerze, a pytanie czy to w ogóle rozważasz, czy jednak chciałeś po prostu logicznie odseparować bazy na jednym serwerze.

@Productionserver: Odpowiem w poście nie komentarzu dla większego zasięgu.

jaki sposób komunikacji pomiędzy modułami preferujesz przy modularnym monolicie?

Przez zdarzenia zaimplementowane jakimś busem in memory jak dotnetowy MediatR. Trzeba tylko pamiętać, że wtedy mamy do czynienia z dostarczaniem wiadomości (zdarzenia) w modelu at-most-once, czyli że nie mamy możliwości przesłania wiadomości więcej niż raz. Po otrzymaniu zdarzenia z modułu A przez moduł B to jak coś złego się stanie z aplikacją - crash albo jakiś inny error a moduł B nie zdążył obsłużyć tego zdarzenia, to tracimy informację o tym zdarzeniu bezpowrotnie.

Jeżeli mamy wymaganie biznesowe w którym nie możemy sobie pozwolić na taką sytuację i potrzebujemy gwarancji dostarczenia wiadomości na poziomie at-least-once to trzeba się posiłkować prawdziwym busem jak RabbitMQ czy inny

markone_dev napisał(a):

• Co ci z osobnych schematów jak przykładowo ci instancja bd padnie i automatycznie wszystkie serwisy się wyłożą?
• Co jeżeli któryś z mikroserwisów dostanie taki ruch że jego operacje na bazie danych zamulą pozostałe usługi?
• Co jeżeli zespół odpowiedzialny za mikroserwis B pójdzie sobie na skróty i będzie korzystał ze schematu serwisu A w swoich zapytaniach i usługa się wyłoży jak zespół A usunie kolumnę z tabelki w swoim schemacie? Tak wiem że można ogarnąć to dostępami na poziomie bd.
• Co jeżeli relacyjny model danych dla danego mikroserwisu nie jest optymalny bo robi dużo odczytów i wyszukiwań i lepiej byłoby zastosować którąś z baz NoSQL jak Cassandra?

Te same pytania mógłbyś zadać nt każdego monolitu - i jakie są odpowiedzi na te pytania wtedy?

Te same pytania mógłbyś zadać nt każdego monolitu - i jakie są odpowiedzi na te pytania wtedy?

Odpowiedź jest jedna - kompromis. To są to ficzery (wady) architektury monolitycznej na które się godzimy podejmując decyzję o pójściu w monolit. Odpowiadając na pytanie jakie może się pojawić w odpowiedzi to tak, dla dużej części a być może i większej części aplikacji biznesowych, ale nie tylko dobrze zbudowany monolit będzie wystarczający.

@markone_dev: "zawsze" to bardzo szeroki zakres. Oczywiście masz słuszne obserwacje, ale koncentrując się na skalowalności i niezawodności (chociaż to dyskusyjne, bo jak uczy doświadczenie, jak lecą bazy danych, to wszystkie w regionie...), a nie bierzesz pod uwagę innych czynników, które są cechami mikroserwisów:

• ograniczenie zakresu zmiany
• swoboda wyboru technologii
• "ownership" kodu przez jakiś zespół
• fizyczna separacja odpowiedzialności

Nie bierzesz też pod uwagę dość istotnego czynnika jakim są koszty. Te niezależne bazy danych kosztują więcej. Wyciągnięcie "izolowanego" schematu do osobnej bazy to krótka piłka, więc moim zdaniem nie ma sensu nastawiać się od razu na stawianie nie wiadomo ilu instancji serwerów baz danych.

@piotrpo:

a nie bierzesz pod uwagę innych czynników

• ograniczenie zakresu zmiany
• swoboda wyboru technologii
• "ownership" kodu przez jakiś zespół
• fizyczna separacja odpowiedzialności

To że czegoś nie wymieniłem w poście na forum nie znaczy, że nie biorę tego pod uwagę w codziennej pracy jako IT Architect, po prostu nie chce mi się za każdym razem pisać wypracowania, ale do meritum, pisałem w kontekście warstwy persystencji a konkretnie serwera baz danych.

ograniczenie zakresu zmiany

Napisałem: Co jeżeli zespół odpowiedzialny za mikroserwis B pójdzie sobie na skróty i będzie korzystał ze schematu serwisu A w swoich zapytaniach i usługa się wyłoży jak zespół A usunie kolumnę z tabelki w swoim schemacie? Tak wiem że można ogarnąć to dostępami na poziomie bd.

Więc wziąłem ten czynnik pod uwagę.

swoboda wyboru technologii

Napisałem: Co jeżeli relacyjny model danych dla danego mikroserwisu nie jest optymalny bo robi dużo odczytów i wyszukiwań i lepiej byłoby zastosować którąś z baz NoSQL jak Cassandra?

Więc wziąłem ten czynnik pod uwagę

"ownership" kodu przez jakiś zespół

Patrz j/w. Pisałem w kontekście bazy danych nie kodu aplikacji/usługi. Nie zmienia to faktu, że ten "ownership" podpada pod moją odpowiedź nt zmiany w strukturze schematu przez zespół A.

fizyczna separacja odpowiedzialności

J/w pytanie i odpowiedź tyczyła się baz danych nie kodu aplikacji/usługi.

Nie bierzesz też pod uwagę dość istotnego czynnika jakim są koszty.

Piszemy w kontekście architektury mikrousługowej więc z automatu musimy liczyć się ze zwiększonymi kosztami nie tylko za infrastrukturę, ale też kosztami w trudności utrzymania, debugowania i rozwoju rozwiązania w takiej architekturze. Myśląc o architekturach rozproszonych biznes musi być gotowy na poniesienie wyższych kosztów. A żeby być gotowym na poniesienie tych kosztów biznes musi mieć odpowiednią skalę uzasadniającą takie wydatki. Mikroserwisy to nie architektura dla małych i średnich biznesów.

więc moim zdaniem nie ma sensu nastawiać się od razu na stawianie nie wiadomo ilu instancji serwerów baz danych.

Nie stać cię na utrzymanie architektury rozproszonej to nie robisz mikroserwisów. Proste.

@markone_dev: Dobra, to się nie dogadaliśmy. Dla mnie schemat bazy danych, to wydzielony logicznie zbór tabel, które nie łączą się na poziomie bazy danych tabelami z innych schematów. Czyli mam to co nazywasz osobnymi bazami danych, tylko na pojedynczym serwerze i w pojedynczej bazie danych.
Nie mam na myśli sytuacji, w której jest pojedynczy schemat danych i każdy sobie do niego wali zmianami (albo nawet odczytami), jak mu się podoba.
Coś co można nazwać "komunikacją przez bazę danych", gdzie usługa A wrzuca tam jakieś dane, a usługa B robi z tych danych raporty uważam za błąd. Chociaż w tej chwili jestem w trakcie rozdzielania kilku "makroserwisów" w zbiór mikro usług i chociaz staram się z takiej sytuacji uciec, to wciąż w niej tkwię i było to działanie świadome.

Ogólnie mało kto rozumie mikroserwisy - większość ludzi słyszała ten termin; i 99% koderów jak się im da takie zadanie, to piszą po prostu trzy apki, które są ze sobą powiązane tak że jak jedna przestaje działać to wszystkie się wywalają.

Koncept wydaje mi się prosty, ale umiejętność wykorzystania tego w praktyce tak żeby to miało jakikolwiek sens wymaga bardzo dużego doświadczenia - tak dużego, że niestety większość którzy piszą microserwisy go nie mają.

Idea jest taka żeby oddzielić różne odpowiedzialności systemu na mniejsze aplikacje; ale jak sobie weźmiesz typowy "system mikroserwisów", to te odpowiedzialności nadal są rozmyte między aplikacjami tylko teraz zarządzasz odpowiedzialnościami nie w kodzie, tylko callami i requestami. Czyli całkowite przeciwieństwo tego, co MS obiecały robić.

@piotrpo:

Dla mnie schemat bazy danych, to wydzielony logicznie zbór tabel, które nie łączą się na poziomie bazy danych tabelami z innych schematów. Czyli mam to co nazywasz osobnymi bazami danych, tylko na pojedynczym serwerze i w pojedynczej bazie danych.
Nie mam na myśli sytuacji, w której jest pojedynczy schemat danych i każdy sobie do niego wali zmianami (albo nawet odczytami), jak mu się podoba.

Zgadza się, ale popatrz, że wciąż możesz zrobić

SELECT 
  --blabla
FROM customers.accounts c_a
JOIN sales.orders s_o
  ON c_a.id == s_o.customer_id
WHERE
  c_a.id = @customer_id

Żeby to obejść to musiałbyś zrobić tak, że usługa SalesService ma dostęp tylko do schematu sales a CustomerService do schematu customers za pomocą uprawnień na poziomie bazy danych. A co jeżeli SalesService potrzebuje wyciągnąć informacje o klientach np z tabeli customers.accounts? Jeżeli ustawisz poziom dostępu usługi tylko do jej schematu to masz problem.

W rozwiązaniu opartym o mikroserwisy, gdzie każda usługa ma swoją bazę danych taki problem nie występuje ponieważ SalesService trzyma sobie "kopię" danych o klientach z poddziedziny biznesowej CustomerService obsługiwanej przez tenże serwis. Oczywiście nie trzyma wszystkich danych o klientach tylko podzbiór, który jest wymagany do obsługi dziedziny głównej czyli sprzedaży. Oczywiście wiąże się to z duplikacją danych, integralnością danych (eventual consistency) itd. więc trzeba o tym pamiętać, że nie ma róży bez kolców i musimy coś poświęcić, żeby osiągnąć coś innego.

W twoim rozwiązaniu musiałbyś duplikować dane na poziomie schematu, czyli schemat sales musiałby mieć analogiczną tabelę jak customers.accounts z kopią danych z tabeli accounts w schemacie customers. Czy to ma sens? Moim zdaniem w bazie relacyjnej nie. Po to mamy bazę relacyjną żeby mieć zagwarantowany ACID i normalizację danych, zwykle do 3 PN. Takie rzeczy robi się np w Cassandrze, gdzie dążymy do denormalizacji danych aby uniknąć kosztownych złączeń i móc robić szybkie odczyty.

Dlatego argumenty na temat izolacji danych za pomocą schematów w pojedynczej relcyjnej bazie danych w architekturach rozproszonych uważam za błędne. Do tego można dołożyć problemy wydajnościowe, gdy 15 usług zacznie gadać do tej samej instancji bazy danych zawierających kilka milionów rekordów. Długo by wymieniać.

Jeżeli mówimy o SQL to tutaj musisz sobie zadać pytanie: Czy rzeczywiście potrzebuję mikroserwisow i chce wziąć na siebie odpowiedzialność zarządzania integralnością baz danych(PK,FK) pomiędzy serwisami itd.? Oczywiście jest SAGA, fajnie wpisać to do CV ale praktyka bywa brutalna. Szczerze, ja czuję się bezpieczniej kiedy mam tę bazę SQL, potem wszystko idzie przez wzorze transactional outbox do Kafki (przez Kafka connect) i stamtąd każdy pracuję z tymi danymi. W razie DR zawsze mam tę integralną bazę danych która mogę wrzucić do Kafki.(Lub każdej innej kolejki która spełnia wymagania).

Jeżeli mówimy o no-sql, to rzeczywiście lepiej mieć instancje bazy danych dla konkretnego serwisu. Jeżeli, jest to np. Elasticsearch to masz oddzielny index, zarządzasz sobie tym indeksem, wersjami, mapowaniem itd. z poziomu serwisu lub pipeline itd. Niestety, przyjdą koszty itd. i może okazać się, że musisz iść na kompromisy.

marlukk napisał(a):

Kiedy w architekturze mikroserwisów lepiej tworzyć oddzielne schematy bazy danych per serwis

To znaczy ze masz na mysli ze jest jedna baza danych a w niej 10 schematow kazdy dla roznego serwisu?

marlukk napisał(a):

Kiedy w architekturze mikroserwisów lepiej tworzyć oddzielne schematy bazy danych per serwis a kiedy oddzielne instancje per serwis? Co brać pod uwagę przy podejmowaniu takiej decyzji?

Najpierw należy się zastanowić czy w ogóle potrzebujemy bazy danych, a potem znaleźć naprawdę dobry powód, aby użyć bazy danych ze schematem. Potem, gdy się okaże, że jakieś 0,5% naszych serwisów takiej potrzebuje, to użyć oddzielnych instancji - bo lepiej się będą skalowały.

dmw napisał(a):

Jeżeli mówimy o SQL to tutaj musisz sobie zadać pytanie: Czy rzeczywiście potrzebuję mikroserwisow i chce wziąć na siebie odpowiedzialność zarządzania integralnością baz danych(PK,FK) pomiędzy serwisami itd.?

No jeśli ktoś chce mieć FK między serwisami, to powinien się od mikroserwisów trzymać daleko.

Jedyne zastosowanie jakie widzę to reduckja kosztów choć i tak najpierw lepiej się skupić na innych opcjach np. wybór tańszej bazy do mniej wymagającego serwiu.

Z praktycznych zastosowań to może to być przydatne np. na środowisku testowym. Posiadanie 10 logicznych baz danych na jednym silniku sprawa, że semantyka będzie zachowana a możemy np. oszczędzić koszt czy ułatwić debugowanie jak np. mamy burdel i patrzymy po kolei w różne bazy co poszło nie tak

To przykład jakiegoś sklepu. Mamy bazę z produktami, nie ważne SQL/NoSQL czy w pliku. Mikroserwisy muszą jakoś współdzelić informacje o stanie magazynowym bo inaczej strona z informacjami może pokazać że produkt X jest dostępny i jego stan magazynowy to 15, a tymczasem produkt został wyłączony przez kogoś z obsługi ze sprzedaży, czy też jego stan magazynowy spadł do zero.
Na razie mój poziom rozumienia abstrakcji i brak doświadczenia z mikro serwisami mówi mi, że co najmniej ciężko by było to zrobić aby było jakieś jedno single source of true dla takiej bazy produktów.
Jak to więc jest robione?

@jurek1980: Eventual Consistency. W takim rozwiązaniu usługa o roboczej nazwie ProductCatalogService wysyła informację do pozostałych zainteresowanych usług poprzez szynę danych/kolejkę wiadomości, że stan towaru się zmienił w taki czy inny sposób. Usługi które są tym faktem zainteresowane otrzymują tą informację i sobie ją przetwarzają, tworząc u siebie w bazie tak jakby kopię tej wiadomości. Dzięki temu nie muszą potem uderzać przez API czy w jakiś inny sposób do usługi ProductCatalogService, tylko pobierają tą informację ze swojej lokalnej bazy danych. Dzięki temu jak usługa ProductCatalogService padnie, to sklep może sobie dalej działać.

Oczywiście może się stać, że sprzedamy produkt którego nie mamy na stanie, ale jest to ryzyko jakie się wiąże ze stosowaniem architektur rozproszonych, gdzie dane mogą znajdować się w różnych miejscach i synchronizacja danych nie jest natychmiastowa tylko rozciągnięta w czasie. Coś za coś, w tym przypadku wysoka dostępność kosztem spójności danych.

Jest to kolejny dowód na to, że architektury mikroserwisowe to architektura dla dużych firm, mających odpowiednią skalę i będących w stanie sobie z taką sytuacją poradzić na szczeblu biznesowym, wysyłając użytkownikowi notkę z przeprosinami że nie ma już produktu na stanie i kuponem rabatowym na następne zakupy jako forma zadośćuczynienia.

No właśnie @markone_dev nawet jeśli powiedzmy przepuścimy coś przez kolejkę to jakiś narzut na komunikacji między serwisami będzie. Tak samo powiedzmy jeśli mamy 50 serwisów z własną bazą która musi się zaktualizować w momencie gdy zmieni się stan magazynowy to mamy 50x update czyli lekkie marnotrawstwo zasobów. Chyba muszę poczytać o tym jakąś książkę.

@jurek1980:
Z pewnością wszystkie 50 serwisów nie będzie zainteresowane faktem, że zmienił się stan magazynowy. Rozważmy takie poddziedziny jak Fakturowanie, Płatności, Powiadomienia, Reklamacje, Marketing i Komunikacja. Czy któraś z nich musi wiedzieć że stan jakiegoś produktu na magazynie się zmienił? Dużo zależy od procesów w firmie, ale odpowiedziałbym, że nie. Przynajmniej w takim klasycznym rozumieniu procesów sprzedażowych, więc ten narzut nie będzie znowu taki duży.

Oczywiście ilość danych wymienianych pomiędzy usługami będzie duża, ale od tego jest message broker/szyna danych aby sobie z takimi rzeczami poradzić.

jurek1980 napisał(a):

To przykład jakiegoś sklepu. Mamy bazę z produktami, nie ważne SQL/NoSQL czy w pliku. Mikroserwisy muszą jakoś współdzelić informacje o stanie magazynowym bo inaczej strona z informacjami może pokazać że produkt X jest dostępny i jego stan magazynowy to 15, a tymczasem produkt został wyłączony przez kogoś z obsługi ze sprzedaży, czy też jego stan magazynowy spadł do zero.
Na razie mój poziom rozumienia abstrakcji i brak doświadczenia z mikro serwisami mówi mi, że co najmniej ciężko by było to zrobić aby było jakieś jedno single source of true dla takiej bazy produktów.
Jak to więc jest robione?

Wyobraz sobei to tak, ze masz usluge bookowania lotow (tak jak ten bookingkom czy cos) i chcesz zabukowac lot do grecji, system sie pyta czy chcesz taksowke? hotel? i ty mowisz ze chcesz.
Zatem jeden mikroserwis bukowania lotow zapytuje przez API do drugiego mikroserwera jak wyglda wypozyczanilnia samochodow? mowi: daj mi jakas liste samochodow z tej miejscowosci? i api zwaraca liste.

Leci kolejne zapytanie (one niesa w kolejce tylko jednoczesnie sa wysylane do roznych API te zapytania) do mikroserwisu hoteli , pokaz mi liste hoteli ktore moge zabukowac? w tej danej miejscowosci.

Dzieki temu masz te koleczka ktore sie kreca bo system czeka az mikroserwis ci zwroci : liste hoteli, liste samochodow. Ty decydujesz czy czekasz na calosc czy pozwolisz uzytkownikowo wybrac serwis ktory sie juz wczytal. Jesli np cos zepsute jest w mikroserwisie od hoteli to masz zwrotke API ERROR i dajesz info ze w tej chwili hotele nie sa dostepne ale nadal mozesz zabukowac lot i taxowke

Gdy robisz mikroserwisy musisz zadbac o synchronizacje bazy danych, dlatego kazdy z nich ma swoja baze i dostep do odpytywania jej przez api. minusem jest to ze musisz dbac o synchro bazy, wydluza sie czas dostepu, odpada testowanie oprogramowania tak latwe jak w monilicie, spada wydajnosc, bo mozesz miec rozne szybkie maszyny ale jednak musza sie laczyc miedzy soba roznymi drogami i z roznymi opoznieniami na laczach, czasem jeden mikroserwis moze miec wplyw na kilka innych wiec to juz kwestia architekta

Monolit ma same plusy bo masz wszytsko w jednej bazie, dostepne natychmiast ale jesli cos sie zepsuje w aplikacji to leza wszystkie serwisy.

markone_dev napisał(a):

Zgadza się, ale popatrz, że wciąż możesz zrobić

SELECT 
  --blabla
FROM customers.accounts c_a
JOIN sales.orders s_o
  ON c_a.id == s_o.customer_id
WHERE
  c_a.id = @customer_id

Oczywiście, że można. Można też wpisać dzielenie przez zero. Ogólnie, implementacja błędu nie jest wielkim problemem.

Żeby to obejść to musiałbyś zrobić tak, że usługa SalesService ma dostęp tylko do schematu sales a CustomerService do schematu customers za pomocą uprawnień na poziomie bazy danych. A co jeżeli SalesService potrzebuje wyciągnąć informacje o klientach np z tabeli customers.accounts? Jeżeli ustawisz poziom dostępu usługi tylko do jej schematu to masz problem.

W praktyce wystarczy, że każdy z tych mikroserwisów połączy się do bazy własnym użytkownikiem, założy tabelki i nikt z wyjątkiem DBA się do nich nie dostanie...

W rozwiązaniu opartym o mikroserwisy, gdzie każda usługa ma swoją bazę danych taki problem nie występuje ponieważ SalesService trzyma sobie "kopię" danych o klientach z poddziedziny biznesowej CustomerService obsługiwanej przez tenże serwis. Oczywiście nie trzyma wszystkich danych o klientach tylko podzbiór, który jest wymagany do obsługi dziedziny głównej czyli sprzedaży. Oczywiście wiąże się to z duplikacją danych, integralnością danych (eventual consistency) itd. więc trzeba o tym pamiętać, że nie ma róży bez kolców i musimy coś poświęcić, żeby osiągnąć coś innego.

No trzeba, są to jakieś tam koszty pójścia w mikroserwisy. Np. trzeba sobie "emulować" transakcyjność jakimś tam wzorcem rozproszonej transakcji.

W twoim rozwiązaniu musiałbyś duplikować dane na poziomie schematu, czyli schemat sales musiałby mieć analogiczną tabelę jak customers.accounts z kopią danych z tabeli accounts w schemacie customers. Czy to ma sens? Moim zdaniem w bazie relacyjnej nie. Po to mamy bazę relacyjną żeby mieć zagwarantowany ACID i normalizację danych, zwykle do 3 PN. Takie rzeczy robi się np w Cassandrze, gdzie dążymy do denormalizacji danych aby uniknąć kosztownych złączeń i móc robić szybkie odczyty.

Czyli jeżeli duplikuję dane pomiędzy różnymi schematami, to źle, jak je duplikuję pomiędzy różnymi bazami danych to dobrze?

Dlatego argumenty na temat izolacji danych za pomocą schematów w pojedynczej relcyjnej bazie danych w architekturach rozproszonych uważam za błędne. Do tego można dołożyć problemy wydajnościowe, gdy 15 usług zacznie gadać do tej samej instancji bazy danych zawierających kilka milionów rekordów. Długo by wymieniać.

Jeżeli baza pada jak 15 usług zacznie gadać do bazy z kilkoma milionami rekordów, to ktoś użył ORM'a bez zastanawiania się co jest pod spodem. Ale tak, masz rację to w większości przypadków jest bez sensu, bo niby mamy skalowalne usługi, a wszystko i tak rozbija się o słabo skalowalną bazę relacyjną. Ale skalowalność to nie jest jedyna cecha mikroserwisów, która daje jakieś korzyści. Może mi np. zależeć na ograniczeniu zakresu zmian podczas deploymentu, możliwości robienia rolling update itp. Pojedyncza baza danych, to też jednak trochę mniej zarządzania i sporo niższe koszty, bo każda z tych baz danych coś tam kosztuje, ma swoją VM'kę (nawet jeżeli jest to usługa zarządzalna). Idąc twoim tokiem myślenia(który uważam za słuszny, ale nie aż tak, że by z niego robić przykazanie), można się zastanowić czy mikroserwisy komponują się z relacyjną bazą danych. Jeżeli są małe, to i liczba tabel będzie mała, więc o elastyczności modelu bazy możemy zapomnieć, o jakimś narzędziu do raportowania, którym się podłączasz i wyciągasz co chcesz też możesz zapomnieć, pozostaje zatem pytanie, jakie korzyści nam ta relacyjność przynosi. W większości przypadków, mam wrażenie, że jest to jedynie kwestia przyzwyczajenia i "zespół zna hibernate'a".

Trochę dziwi mnie to pytanie. Mikroserwis nie musi wcale wiedzieć, czy łączy się do serwera bazodanowego na wyłączność (aka 1 baza danych na jednym Postgresie) czy współdzielonego (aka wiele baz danych na jednym Postgresie). W projekcie gdzie aktualnie jestem, aplikacja dostaje URLa do bazy danych (typu jdbc:hostname:5432/mojabaza) i nic więcej - to, czy baza jest dedykowana czy współdzielona, konfigurowane jest poza zasięgiem aplikacji. Decyzję o takim a nie innym podziale podejmuje się na podstawie metryk i zdrowego rozsądku, czasem bezpieczeństwa danych, integralności backupu itp. :)