Oddzielne bazy danych vs. oddzielne serwery baz danych

Przyjmijmy, że jest kilka zespołów, każdy czuwających nad paroma swoimi mikroserwisami, które razem komponują jakiś większy system.

Załóżmy, że serwisy często korzystają z bazy danych MongoDB.

Czy każdy serwis powinien stawiać swój własny mongoDB database server i nim zarządzać? Wydaje mi się to jakimś horrorem.

Dla porównania, co gdyby był tylko jeden server, być może zarządzany centralnie przez jakiś zespół od infrastruktury, i poszczególny serwisy dokładałyby tam tylko swoje bazy danych...? Czy takie podejście jest state-of-art?

Podsumowując chodzi mi o to, czy serwisy powinny stawiać sobie cały database server, czy tylko dokładać swoją bazę danych do istniejącego servera?

EDIT: Dla porównania zakładam, że Kafka jest jedna i zespoły dokładają tylko swoje topici, a nie stawiają od zera swoich brokerów... Może są jakieś wyjątki od tego.

Orginalna idea mikroserwisów już dawno została zatracona na rzecz jakichś innych tworów.

Dla przypomnienia, początkowo idee mikroserwisów były dwie:

• Mają być niezależnie deployowalne (a więc nie można ich przetestować razem - z definicji)
• Mają być na tyle małe, że zamiast wprowadzać jakąś większą zmianę do nich, to bardziej się opłaca ją usunąć i napisać od nowa - dlatego micro service.

Oczywiście wymaga to wiedzy, doświadczenia, bardzo dobrych zdolności optymalizacyjnych, bardzo dobrego pipeline'u deployowania, i bardzo dobrej zdolności do automatyzacji wielu rzeczy.

Niestety aktualna "wizja" mikroserwisów jest nieco inna - pipeline'y robi się ręcznie (a nie automatycznie), serwisy nie są "mikro" tylko mają całe wielkie feature'y w sobie, nie są niezależnie deployowalne (bo deployuje i testuje się wszystkie na raz), i nie są odseparowane od siebie - tylko nadal są silnie połączone, nie mają niezależnych interfejsów (bo zmiana czegoś w jednym często psuje rzeczy w innym), nie są niezależne (bo często się wydziela z nich jakieś commonsy, przez co tworzy się połączenie między nimi), etc.

Więc odpowiadając na Twoje pytanie: "jak powinno być", odpowiedź w zasadzie nie istnieje.

Mówisz o etapie developmentu ? Czy produkcji ?
Ja bym oddzielne bazy developerów na jednym materialnym serwerze akceptował (z gwiazdką u dołu)

Na produkcji i tak się to w sposób nieplanowany rozproszy, bo pewnie o to chodzi w wyborem bazy rdzennie cloudowej

gwiazdka u dołu *)
Nawet jeśli development, troszkę niedostestowane będą okoliczności crashu serwera, recovery, bezpeiczników itd
Będziecie pracować na nadmiernie optymistycznej konfiguracji

A może takie podejście?

Jeśli bazę danych ewidentnie trzeba skalować niezależnie od innych, to robimy jej dedykowany database server. Jeśli nie, to wrzucamy do wspólnego wora. Jakby w przyszłości wymagało niezależnego skalowania, to przenosimy się na dedykowany server.

Jeśli jest separacja logiczna (ten sam fizyczny serwer ale żaden mikroserwis nie dotyka danych dotykanych przez inny) to IMO wszystko jedno. Na pewno w takim wypadku dochodzą problemy pod tytułem a co jak serwis A zajedzie tak bazę, że B nie będzie działał, ale nie powinno być zadnych problemów z natury logiki aplikacji

Oczywiście, gdy tak nie jest i serwisy piszą/czytają te same dane to tak nie może być

Jeśli bazę danych ewidentnie trzeba skalować niezależnie od innych, to robimy jej dedykowany database server. Jeśli nie, to wrzucamy do wspólnego wora. Jakby w przyszłości wymagało niezależnego skalowania, to przenosimy się na dedykowany server.

Jedyny sens jaki widzę to oszczędność. IMO nie warto się tak babrać na produkcji i robić porządnie od początku

Riddle napisał(a):

• Mają być niezależnie deployowalne (a więc nie można ich przetestować razem - z definicji)

A czemu nie? To, że serwis A musi być przygotowany na działanie z wieloma wersjami serwisu B (z zachowaniem interfejsu) nie sprawia, że przetestowanie dwóch konkretnych wersji jest bezcelowe. Praktycznie każdy bardziej skomplikowany kontrakt potrafi być złamany i jedyną opcją na uniknięcie tego typu błędów to testy E2E lub olanie tematu i skupienie się na monitoringu i wycofywaniu deploymentów, które "szkodzą"

@DisposableUserException:

O czym jest ta rozmowa , kurcze

Zagadnienie jest bardzo szerokie i zależy od ogromnej ilości czynników m.in. tych o których koledzy wspomnieli powyżej.
Prawda jest taka, że bez przedstawienia tutaj przynajmniej zarysu projektu systemu to każda udzielona tu odpowiedź na Twoje pytanie może być tak samo dobra jak i zła.

1. Być może baza wystarczy jedna bo np. gromadzone są w niej online ogromne ilości danych a jest na tyle wydajna, że nie ma sensu nic dzielić jeśli mikroserwis będzie z niej jedynie czytał.
2. Może być też tak, że baza główna "ledwo dyszy" i każde kolejne zapytanie do niej to dobijanie umierającego i wówczas wydzielenie części operacji do zewnętrznej bazy może okazać się zbawieniem.
3. a może obciążające są same obliczenia wykonywane przez mikroserwis...

itp. itd.

Trzeba zacząć od podstaw czyli np. od oceny gdzie w całym systemie są wąskie gardła i jak można tymi mikroserwisami je wspomóc. Co stanowi największe obciążenie, gdzie zależy nam na uzyskaniu maksymalnie szybkich odpowiedzi.
I najważniejsze - zadać sobie pytanie po co i dlaczego robimy mikroserwisy?
Czy dlatego, że już nie panujemy nad architekturą systemu?
Czy dlatego, że nie chcemy dać uprawnień do "czegoś"?
Czy dlatego, że chcemy mieć jak najbardziej elastyczny system nawet kosztem wydajności - a może właśnie odwrotnie.

Bez takiej analizy na pytanie:

Czy każdy serwis powinien stawiać swój własny mongoDB database server i nim zarządzać? Wydaje mi się to jakimś horrorem.

mogę odpowiedzieć zdecydowanie TAK a właściwie to NIE.

Hmm bardzo ciekawy temat.

Wszystko zależy od stabilności systemu bazodanowego moim zdaniem.

W sumie, to zarządzał ktoś zdockeryzowaną instancją bazy danych?
Kontener ciężki nie jest, ale podejrzewam, ze backupy muszą być wesołym zadaniem

rjakubowski napisał(a):

Hmm bardzo ciekawy temat.

i trudny. Raczej bez możliwości udzielenia jednoznacznej prostej, pomocnej i ogólnej odpowiedzi.
Same rozmiary kontenerów i ich backupy to już problem wtórny.