Mikroserwisy a architektura multitenant

Witam,
staram się zrozumieć działanie mikroserwisów i chciałbym testowo napisać jakąś małą aplikację z ich wykorzystaniem, ale także, żeby aplikacja miała wielu "dierżawców" (np. dane dla dzierżawcy byłyby udostępniane po subdomenie). Zrobiłem sobie małą strukturę w dockerze i wykorzystałem Keycloack do autoryzacji i uwierzytelnania. Połączyłem to z ApiGateway (Kong), co sprawdza czy użytkownik jest zalogowany i przesyła JWT dalej do mikroserwisu. W serwisie (na razie tworzyłem w Symfony jakieś api ze zleceniami - ale to chyba mało ważne w czym). I teraz nasuwa mi się takie pytanie jak to działa w mikroserwisach, żeby rozdzielić dane w każdych serwisach na tego "realm'a" z Keycloacka? Bo w Keycloacku tworzyłbym oddzielny Realm dla każdego dzierżawcy. Teraz w serwisie z tokena moge sobie wyodrębnić nazwę dzierżawcy. Ale czy w tym sewisie muszę mieć także tabelę users zreplikowaną z użytkownikami z keycloaka ? I jeśli będę miał 5/10/15 serwisów, które w jakiś sposób są powiązane z realmem lub tylko userem, muszę tworzyć w bazie dla serwisu tabelkę realm/user z jakimś identyfikatorem?

I od razu może drugie pytanko, bardziej powiązane z samym z systemami IAM (tu Keycloakiem) a nie ze multiteant. Chodzi mi o to że chciałbym aby każdy użytkownik był przypisany do np. "salonu sprzedaży". W Keycloak mogę chyba utworzyć niestandardowy atrybut -> id_salonu ale pytanie gdzie mam trzymać tą jedną tabelę "salon sprzedaży"? W podejściu w którym nie używałbym gotowego rozwiązania do autoryzacji, zrobiłbym tabelę użytkownicy(id, imie, nazwisko, salon_id) oraz tabelę powiązaną salony(id, nazwa). A jak do tego podejść używając IAM, czy to Keycloak czy innego rozwiązania?
Mam nadzieję, że napisałem zrozumiale.

Obejrzyj sobie to:

Powinno dostarczyć Ci trochę odpowiedzi

Muszę przyznać że wsparcie dla multi-tenancy brzmi jak fajne ćwiczenie z modelowania systemów, taki np. multi-tenant monolith i jego różne warianty (one db, many dbs, etc)

Ale to w dzisiejszych, tak bardzo pochmurnych czasach, jest sens bawić się w inne multitenancy niż całkowita kopia infrastruktury, usług i aplikacji?

@somekind: Kopia wszystkiego na każdego klienta? Nie jestem znawcą, dopiero szukam i sprawdzam sobie różne rozwiązania jak to działa w apliakcjach Saas. Ale wymyślając przypadek 1000 firm chce korzystać z aplikacji i będzie miało 5/10 pracowników. Robię wtedy 1000x np. klaster K8s ? Do tego bazy na każdy serwis. Czy nie łatwiej zarządzać w takim podejściu multi-tenancy?

ciastko1742 napisał(a):

@somekind: Kopia wszystkiego na każdego klienta? Nie jestem znawcą, dopiero szukam i sprawdzam sobie różne rozwiązania jak to działa w apliakcjach Saas. Ale wymyślając przypadek 1000 firm chce korzystać z aplikacji i będzie miało 5/10 pracowników. Robię wtedy 1000x np. klaster K8s ? Do tego bazy na każdy serwis. Czy nie łatwiej zarządzać w takim podejściu multi-tenancy?

Oczywiście że łatwiej jeśli się współdzieli infrastrukturę. Dlatego część firm oferujących produkty w modelu SaaS ma możliwość uruchomienia dedykowanej instancji platformy dla dużych klientów o dużych wymaganiach, którzy są w stanie za to zapłacić dużo pieniędzy. Cała reszta musi się zadowolić byciem na instancji współdzielonej. I nie ma w tym nic złego. Wszystko zależy od modelu biznesowego firmy dostarczającej rozwiązanie.

Za bardzo skupiasz się na tym "jak", za mało "po co". Sporo zależy od wymagań, przewidywanej liczby tenantów, rodzaju przechowywanych danych.
Możesz zrobić wersję bieda i np. mieć dedykowane instancje usług (tam gdzie trzeba), przekierowując sobie na API Gateway żądania do odpowiedniej instancji.
Inna opcja, to każdy mikroserwis sprawdza id tenanta (np. z tego JWT) i jakoś rozdziela rekordy - albo na poziomie rekordu, schematu, bazy danych.
Może się zdarzyć, że w wymaganiach masz okreslone, że dane nie moga być przechowywane razem z cudzymi danymi, albo przetwarzane razem z obcymi danymi, albo wręcz masz wymaganie, że konkretny tenant chce mieć wszystko oddzielnie, bo bezpieczeństwo i takie tam. Z tego co pamiętam, filmik parę postów wyżej omawia to całkiem nieźle.

Ogólnie główny powód robienia usług multitenant to optymalizowanie kosztów chmury i utrzymania. @somekind - odpowiedź na twoje pytanie. Znacznie lepiej się to skaluje, ale trudniej (kosztowniej) rozwija, no i traci się na bezpieczeństwie, bo potencjalnie każdy włam, to dostęp do wszystkich danych i istnieje ryzyko jakiegoś głupiego błędu, gdzie tenant zobaczy dane innego tenanta.

ciastko1742 napisał(a):

@somekind: Kopia wszystkiego na każdego klienta? Nie jestem znawcą, dopiero szukam i sprawdzam sobie różne rozwiązania jak to działa w apliakcjach Saas. Ale wymyślając przypadek 1000 firm chce korzystać z aplikacji i będzie miało 5/10 pracowników. Robię wtedy 1000x np. klaster K8s ? Do tego bazy na każdy serwis. Czy nie łatwiej zarządzać w takim podejściu multi-tenancy?

Tak, a to jakiś problem ten 1000 klastrów?
Jest bezpieczniej, każdy klient może się skalować niezależnie, jak dla mnie same zalety.

markone_dev napisał(a):

Oczywiście że łatwiej jeśli się współdzieli infrastrukturę.

Co nazywasz infrastrukturą?

piotrpo napisał(a):

Ogólnie główny powód robienia usług multitenant to optymalizowanie kosztów chmury i utrzymania. @somekind - odpowiedź na twoje pytanie. Znacznie lepiej się to skaluje, ale trudniej (kosztowniej) rozwija, no i traci się na bezpieczeństwie, bo potencjalnie każdy włam, to dostęp do wszystkich danych i istnieje ryzyko jakiegoś głupiego błędu, gdzie tenant zobaczy dane innego tenanta.

Każdy tenant ma swoją domenę, sieć, swoje instancje usługi i swoje bazy. Wydaje mi się, że w takim podejściu jest raczej trudniej o podglądanie sobie nawzajem danych niż gdy baza jest jedna.

somekind napisał(a):

Tak, a to jakiś problem ten 1000 klastrów?

Myślę, że koszt. Spojrzałem na cenę AWS EKS. Cena jednego klastra działającego nieprzerwanie przez miesiąc to 73 USD. Zakładam, że jest 100 firm które generują mały ruch i jedną która generuje taki sam ja te 100. Także tej jednej można postawić oddzielną infrastrukturę. Ale reszcie, za ich wiedzą i przyzwoleniem oraz przez to że zapłacą mniej, robię wersję współdzieloną (tak jak opisał @markone_dev). I właśnie w takim przypadku chciałbym sprawdzić to podejście. Rozumiem, że optymalizacja kosztów obniża bezpieczeństwo i odwrotnie. Ale myślę, że trzeba dobrać rozwiązanie po środku. Czyli jeśli można współdzielić to tam dodaje tego tenanta, przy czym tworząc usługę kładę nacisk na testy bezpieczeństwa.

W wracając do kwestii technicznych:
@piotrpo

Inna opcja, to każdy mikroserwis sprawdza id tenanta (np. z tego JWT) i jakoś rozdziela rekordy - albo na poziomie rekordu, schematu, bazy danych.

Tak chciałbym spróbować to zrobić. I co to tego było bardziej moje pytanie. Czy prawidłowym podejściem jest to że każda mikrousługa powinna w swojej bazie danych mieć swoją tabelę tenant i user. Po przesłanym JWT sprawdzam nazwa tenanta i użytkownika, jeśli go nie ma ich w bazie usługi to je dodaje i po tych danych filtruje wszystkie inne operacje z bazy? I tak w każdej usłudze.

No i mam jeszcze ten jeden problem.

I od razu może drugie pytanko, bardziej powiązane z samym z systemami IAM (tu Keycloakiem) a nie ze multiteant. Chodzi mi o to że chciałbym aby każdy użytkownik był przypisany do np. "salonu sprzedaży". W Keycloak mogę chyba utworzyć niestandardowy atrybut -> id_salonu ale pytanie gdzie mam trzymać tą jedną tabelę "salon sprzedaży"? W podejściu w którym nie używałbym gotowego rozwiązania do autoryzacji, zrobiłbym tabelę użytkownicy(id, imie, nazwisko, salon_id) oraz tabelę powiązaną salony(id, nazwa). A jak do tego podejść używając IAM, czy to Keycloak czy innego rozwiązania?

Utrzymuję jeden projekt na multitenancie. Każdy tenant ma swoją oddzielną schemę w bazie danych. Fronty wysyłają odpowiedni nagłówek w zapytaniu z nazwą tenanta i na tej podstawie jest wybierana baza danych. Fronty biorą nazwę tenanta z url strony, Więc trzeba skonfigurować odpowiednia subdomenę lub jeżeli klient chce, fronty mogą również działać pod jego własnym adresem. Dzięki temu mamy jeden serwer na AWS z frontami i jeden serwer z backendem (faktycznie jest ich więcej, ze względu na skalowalność i niezawodność).

Tak, a to jakiś problem ten 1000 klastrów?

PTSD wśród SRE lub DevOpsów, zwał jak zwał.

Koszt samej chmury i ludzi co beda to utrzymywać ze względu na operational complexity
Datacenters też mają określone capacity i jak rośniesz to możesz sie nie zmieścić

Jak dochodzi skalowanie cross region to juz w ogole zaczyna sie complicated gdzie czesc uslug nie umie w cross region i musi byc osobna instancja

Ja zawsze staram sie traktować EKS itp. jako Runtime i nic tam nie trzymać, data, storages, logs zawsze mozna wyizolowac

Przede wszystkim zastanowiłbym sie od definicji tenanta i aktorów
Tenant - co to? user z internetu, firma, kraj, region, whatever

Mikroserwisy imo najlepiej sprawdzaja sie w przypadku tego pierwszego robisz super-saas.com public service i sklalujesz globalnie
Jak ktos jest Software House i musi miec wszystko osobno, to najlepiej jakby to stało u tego klienta.

Jak robisz takiego Confluent Kafka https://www.confluent.io/confluent-cloud/pricing/
To dajesz wybor, swoja infra, dedytkowane konto z osobnym billingiem

Ewentualnie mozna pomyslec o deployu do infry klienta i dac wjazd ludziom od takiej Produktu typu Kafka

somekind napisał(a):

markone_dev napisał(a):

Oczywiście że łatwiej jeśli się współdzieli infrastrukturę.

Co nazywasz infrastrukturą?

To przy pomocy czego i na czym jest uruchomiona aplikacja, czyli serwery aplikacji, bazy danych, kolejki, sieć, load balancery, itd. Przykładowo można aplikację uruchomić na k8s a można na tradycyjnych vm-kach, w modelu serverless lub kombinacji tego wszystkiego.

Tutaj +/- jest opisane jak do MTA podchodzi Salesforce:
https://developer.salesforce.com/wiki/multi_tenant_architecture