Zapraszamy do lektury artykułu przygotowanego przez naszego partnera – firmę Pega. Autorką tekstu jest Yasia Romanetes, która dzieli się praktycznymi spostrzeżeniami na temat wyzwań i strategii multi-tenancy w systemach opartych na Kafka i OpenSearch.
Moja przygoda z IT zaczęła się nieco ponad 10 lat temu jako inżynierka wsparcia operacyjnego. W tamtych czasach zajmowałam się małym klastrem VMs działającym w data center klienta. Planowanie zasobów było dość proste matematycznie, ale bardzo długoterminowe – zamówienie na jakikolwiek dodatkowy sprzęt trzeba było składać z kilkumiesięcznym wyprzedzeniem. Musiało ono uzyskać niezbędne zgody; serwery musiały zostać dostarczone i fizycznie podłączone do racka, aby połączyć się z szerszym ekosystemem. Często nadmiernie rezerwowałam flotę – tak na wszelki wypadek, ponieważ feedback loop był niezwykle długi. Szybkie przejście o 5 lat do przodu – i stała się magia. Teraz mamy AWS i auto-scaling groups. Mogę dostać nową maszynę na żądanie; mogę zmniejszyć skalę, kiedy tylko potrzebuję. Życie jest prostsze.
Ale teraz pojawiają się pytania, prawie zachłannie – czy mogę zrobić z tym więcej? O ile więcej mogę obniżyć koszty? Czy moje obciążenie operacyjne zmniejszy się wykładniczo?
Wiem, iż nie tylko ja zadawałam sobie te pytania wtedy – a ponad 5 lat od tego momentu, są one przez cały czas aktualne. Wiem, iż prawie każda dyskusja architektoniczna przez cały czas zaczyna się od pytania – w jakim stopniu możemy uczynić ten system multi-tenant?
W mojej karierze byłam operations engineer, software engineer, DevOps engineer, infrastructure engineer, a teraz jestem Director of Cloud Engineering w Pega. Niech jednak tytuł nie zwiedzie – przez cały czas traktuję gorące dyskusje architektoniczne jako dobry trening cardio i wolę zajrzeć do kodu, żeby zrozumieć, jak wszystko ze sobą współgra, zamiast słuchać, jak ktoś inny to wyjaśnia (niektórzy nazwaliby to “control freak”; inni, milsi ludzie nazwaliby to “ciekawość”). Mając to doświadczenie za sobą, w tym artykule chciałabym zbadać kompromisy w wyścigu o optymalizację kosztów i efektywność operacyjną. Chcę przedstawić pewne filozoficzne rozważania dotyczące wyboru, czy system powinien być multi-tenant czy single-tenant – i w jakim zakresie.
Moim celem jest, aby po przeczytaniu tego artykułu mieli Państwo w zasięgu ręki framework – listę kontrolną do przejścia podczas rozważania, co zrobić ze swoją architekturą i którą ścieżkę wybrać. Zacznijmy od zdefiniowania, co oznaczają systemy multi-tenant i single-tenant.
System single-tenant zapewnia każdemu klientowi własną, dedykowaną instancję systemu i wspierającej infrastruktury, w tym oddzielne bazy danych i wdrożenia aplikacji.
System multi-tenant jest trudniejszy do zdefiniowania. W skrócie, jest to pojedyncza instancja aplikacji systemu i jej podstawowej infrastruktury, która obsługuje wielu różnych klientów (tenants).
Jednak multi-tenancy może przyjmować różne kształty i formy na różnych warstwach. Na przykład, runtime może być współdzielony w systemie multi-tenant, ale bazy danych mogą być oddzielne ze względów compliance. jeżeli baza danych jest współdzielona, dane muszą być logicznie izolowane i szyfrowane, aby zapobiec przypadkowemu dostępowi krzyżowemu.
Koszt jest wyższy w systemach single-tenant, ale czynniki takie jak blast radius, noisy neighbors i troubleshooting mogą być łatwiejsze do opanowania.
W tym artykule chcę zbadać wybór pomiędzy single-tenancy a multi-tenancy w kontekście technologii, których używamy w Pega – Kafka i OpenSearch. Obie stwarzają unikalne wyzwania w trzech obszarach – bezpieczeństwie, sporach o zasoby i złożoności operacyjnej. Szczegółowo omówię każdy z nich, zaczynając od Kafki.
KAFKA W ŚWIECIE MULTI-TENANT: TY DOSTAJESZ QUOTĘ, I TY DOSTAJESZ QUOTĘ!
Chociaż Kafka nie jest technologią przeznaczoną do trwałego, długoterminowego przechowywania danych, zaprojektowanie bezpiecznej, zgodnej i wydajnej konfiguracji Kafki stwarza swoje własne wyzwania.
BEZPIECZEŃSTWO
Często powtarzam, iż uważam Kafkę za protokół komunikacyjny. Mamy swoich consumers i producers, którzy mogą komunikować się ze sobą dzięki Kafka topics. Jakie są zatem wyzwania, jeżeli chodzi o bezpieczeństwo w Kafce?
Upewnienie się, iż tylko określeni consumers i producers mają dostęp do konkretnych topics. Można to zrobić dzięki ACLs – np. w środowisku microservices, można stworzyć użytkownika dla wszystkich microservice i odpowiednio skonfigurować ACLs, aby usługa mogła consume’ować/produkować z/do konkretnych topics. Podobnie, można to wykorzystać do rozdzielenia na poziomie środowiska – dev, stg i prod otrzymałyby własnych użytkowników i ACLs, aby zapewnić separację danych między etapami.
Tenant message encryption – podczas gdy w świecie single-tenant prawdopodobnie zaszyfrowałabym ruch do Kafka w transporcie i sam wolumen EBS, musiałabym pójść o krok dalej i zaszyfrować rzeczywisty payload wiadomości dla wszystkich tenant – co oznacza, iż zarówno consumer, jak i producer musieliby mieć dostęp do klucza, aby zapisać lub odczytać wiadomość. jeżeli latency jest dużym problemem w systemie, należy uwzględnić czasy enkrypcji/dekrypcji w obliczeniach.
SPORY O ZASOBY
Spory o zasoby są, z mojego doświadczenia, najczęstszą przeszkodą w zarządzaniu multi-tenant Kafką. Kilka strategii zarządzania nimi obejmuje:
QUOTAS
Quotas są bardzo skutecznym, choć skomplikowanym mechanizmem w Kafka. Najczęstsze to network bandwidth quotas (ograniczające producers i consumers pod względem maksymalnej przepustowości danych) oraz request rate quotas (wyrażone jako procent network i I/O threads, zapobiegające przeciążeniu brokerów zbyt wieloma żądaniami).
Obie są ustawiane dla wszystkich użytkownika na każdym brokerze.
Network bandwidth quotas będą ograniczone np. przez typy instancji AWS. Tj. przez EBS i Network bandwidth. Przepustowość EBS jest tutaj kluczowa, ponieważ Kafka bardzo zachłannie zapisuje na dysk. Np. dla rg6.large i rg6.2xlarge, suma wszystkich producer i consumer byte rate quotas dla wszystkich użytkowników podłączonych do Kafka cluster nie może przekroczyć 4750Mi.
Request rate quotas są trudniejsze i będą zależeć od liczby network i I/O threads skonfigurowanych w klastrze. Request rate quotas ograniczają procent czasu, przez jaki klient może używać request handler i network threads każdego brokera podczas określonego przedziału czasowego. Jest to obliczane dzięki następującego wzoru: ((num.io.threads + num.network.threads) * 100)%. Na przykład, jeżeli mamy 3 I/O threads i 8 network threads, ta wartość w klastrze wyniesie 1100% ((3+8)*100%). Zatem 1100% będzie wartością, którą możemy rozdzielić między użytkownikami na każdym brokerze.
Quota, którą otrzyma każdy użytkownik, nie dyktuje ich użycia – jest to górna granica, której nie będą mogli przekroczyć, co pozwala nam na zarządzanie i zapobieganie zakłóceniom ze strony noisy neighbors.
Istnieją różne strategie wdrażania quotas, i nie ma jednego podejścia. Zależy to od przewidywanego użycia i krytyczności każdego klienta. W świecie microservices, gdzie każda z usług ma równe prawa do Kafki, najlepszym podejściem byłoby równe rozdzielenie quotas między wszystkie usługi (chyba iż uznajemy konkretną usługę za bardziej krytyczną niż pozostałe). Wyzwania pojawią się, gdy dołączą nowe usługi, ponieważ quotas potencjalnie będą musiały zostać przeliczone dla wszystkich.
Jeśli system jest multi-environment zamiast multi-tenant (tj. jeden klient końcowy używa systemu, a wszystkie jego typy środowisk, takie jak dev, stg i production, korzystają z tej samej infrastruktury), sugeruję rozważyć nie wiązanie produkcji z żadnymi quotas, decydując się jedynie na ograniczenie niższych środowisk. W ten sposób, jeżeli produkcja klienta potrzebuje więcej zasobów, będzie to widoczne w metrykach serwera Kafki zamiast w request throttling.
ODDZIELNE KLASTRY DO OBSŁUGI OBCIĄŻEŃ DEV & STG VS PROD
Innym podejściem jest rozdzielenie klastrów według typu obciążenia – tzn. przydzielenie produkcji własnego klastra, a niższe typy środowisk pozostawienie na innym klastrze. Wady tego podejścia obejmują zwiększone koszty i nieco inne środowiska niższych poziomów niż produkcja, więc jeżeli chcemy, aby testy były jak najbardziej zbliżone do rzeczywistości, to może nie być najlepszym rozwiązaniem.
ZŁOŻONOŚĆ OPERACYJNA
Wszystko powyższe wpływa na złożoność operacyjną. Jest też kilka innych czynników.
UPGRADES
W Kafce, upgrade’y z reguły są dość bezbolesne. Klienci mogą używać starszej wersji klienta Kafki niż wersja serwera Kafki. Kafka jest niesamowicie kompatybilna wstecz. Kiedy po raz pierwszy zaczynałam pracować z Kafką, przeprowadziłam test z moim zespołem, aby sprawdzić upgrade’y po zmianie API/protocolu, która nastąpiła w wersji 0.10. Testowaliśmy upgrade z Kafki 0.9.0.1 do 2.7.0, podczas gdy producenci przez cały czas zapisywali do topików, a consumerzy przez cały czas z nich czytali. System był całkowicie stabilny, i wszyscy przez cały czas mogli zapisywać i czytać wiadomości.
Mimo to, choć wszystko działa, nie ma gwarancji, iż wszystko będzie działać szybko. Na przykład podczas jednego z incydentów odkryliśmy, iż kilku consumerów używało starszego klienta Kafki z naszym nowszym serwerem Kafki. Wiadomości były przetwarzane, ale widzieliśmy dziwne lagi, dodające czasem choćby sekundę do całkowitego czasu przetwarzania. Przy aktualizacji multi-tenant Kafka klastra do nowszej wersji zatem trzeba rozważyć, jak każdy tenant będzie musiał być skoordynowany w celu aktualizacji swojego klienta.
OBSERVABILITY
Dodatkowym czynnikiem, który sprawia, iż multi-tenancy w Kafce jest bardziej wymagająca, jest observability. Oprócz regularnego monitorowania metryk klienta i serwera (np. metryki brokerów oraz producentów/consumerów), warto zbudować dashboardy specyficzne dla tenantów oraz dashboardy monitorujące quotas. Idealnie, dashboard specyficzny dla tenanta powinien zawierać dane ze strony klienta (tj. aby zobaczyć, ile czasu zajmuje przetwarzanie wiadomości z perspektywy klienta) oraz ze strony serwera (ile czasu serwer faktycznie potrzebuje na przetworzenie wiadomości), wraz z metrykami throttling, aby sprawdzić, czy quotas są skonfigurowane zgodnie z użyciem.
CAPACITY PLANNING & BLAST RADIUS
Pytanie, jak będzie wyglądał Kafka cluster pod względem brokerów, jest częstym punktem. Wybór skalowania pionowego lub poziomego to ważna kwestia. Na szczęście, w przeciwieństwie do niektórych innych technologii, skalowanie w dół w Kafce z odpowiednimi replication factor i partition reassignment jest dość łatwe, więc nie trzeba wybierać jednego lub drugiego.
Więc, jak skalować Kafkę? Podobnie jak z quotas, nie ma jednego adekwatnego podejścia.
Ogólnie rzecz biorąc, Kafka jest zaprojektowana do skalowania poziomego – z Zookeeper, klaster składający się z 500 brokerów może działać normalnie; z Kraft, teoretycznie, możemy skalować do ponad 1000 node’ów. Observability dla takiej liczby brokerów będzie wyzwaniem, więc osobiście nie poszłabym tak daleko bez wyraźnej potrzeby. Powszechny soft limit dla partycji per broker wynosi 4000, więc należy przydzielić odpowiednią liczbę brokerów, aby to pomieścić, pamiętając, iż replication factor zwiększy całkowitą liczbę partycji.
W świecie multi-tenant, wszystko, co robimy, będzie miało większy blast radius. Dodając dodatkowych brokerów, ważne jest, aby wziąć pod uwagę obciążenie klastra – podczas dużego obciążenia dodawanie brokerów nie jest dobre, ponieważ nowe brokery nie obsługują jeszcze żądań, a jednocześnie proszą istniejące brokery o wysyłanie im danych. Skalowanie pionowe może być w tym scenariuszu lepsze, gdy potrzebujemy szybkiego zwiększenia wydajności. Niemniej jednak, podczas resize brokera, ten broker stanie się niedostępny na pewien czas, co oznacza mniejszą pojemność, dopóki resize nie nastąpi.
Moją zasadą jest zwykle początkowe udostępnianie większej liczby małych lub średnich node’ów oraz skalowanie w górę pionowo podczas działania, jeżeli zajdzie taka potrzeba. Ponieważ quotas są obliczane na broker, daje mi to również wyższą wartość bezwzględną do rozdzielenia między użytkownikami Kafki.
OPENSEARCH W ŚWIECIE MULTI-TENANT: INDEXING BEZ TAJEMNIC
Search służy do przechowywania trwałych informacji, do indeksacji danych. Kluczowym problemem z searchem jest dostęp do danych i enkrypcja. Jak zapewnić, iż dane są zaenkryptowane, ale przez cały czas przeszukiwalne?
BEZPIECZEŃSTWO
Jak przeszukiwać w pełni zaenkryptowane dane? Można zaszyfrować frazę i wyszukać hash, oczywiście. Ale co, jeżeli chcemy wyszukać część frazy? Mało prawdopodobne, żebyśmy znaleźli ten hash. A co z semantycznym wyszukiwaniem, gdzie kontekst i trafność koncepcyjna również odgrywają rolę?
Do niedawna enkrypcja nie była możliwa dla OpenSearch w kontekście przeszukiwania zaenkryptowanych danych. Dlatego większość rozwiązań, które dbały o compliance danych, musiały wybrać opcję single-tenant.
Zmieniło się to w ciągu około ostatniego roku wraz z wydaniem Portal26 plugin. Plugin zapewnia “encryption-in-use”, co oznacza, iż dane pozostają zaenkryptowane choćby podczas aktywnych indeksacji i wyszukiwania. Wykracza to poza tradycyjną enkrypcję data-at-rest i data-in-transit. Umożliwia budowanie zaenkryptowanych indeksów oraz przechwytuje i przekształca kwerendy na chronionych danych. Portal26 plugin pozwala na index-level encryption keys. Umożliwia to przechowywanie danych wielu klientów na tym samym node, zapewniając jednocześnie pełną izolację danych między tenantami.
Oczywiście wiąże się to z pewnym narzutem na wydajność, ale nie jest on znaczący.
SPORY O ZASOBY
W OpenSearch, podobnie jak w Kafce, spory o zasoby są kluczowym wyzwaniem w środowiskach multi-tenant. Noisy neighbors mogą znacząco wpływać na wydajność całego klastra.
Kluczowe metryki do monitorowania obejmują: CPU, memory, disk I/O i network throughput na poziomie node’a i indeksu. Strategie minimalizujące spory obejmują:
- Shard Allocation Awareness: Strategiczne rozmieszczanie shards (podstawowych jednostek przechowywania danych w OpenSearch) na różnych node’ach, availability zones, a choćby rackach. Pomaga to unikać “hot spots” i zapewnia lepszą odporność na awarie.
- Index Templates with Routing: Pozwalają na automatyczne kierowanie danych dla określonego tenanta do określonych grup node’ów lub choćby dedykowanych node’ów. Takie podejście umożliwia priorytetyzowanie krytycznych tenantów lub izolowanie tych, które generują największe obciążenie.
- Circuit Breakers: Wbudowane mechanizmy w OpenSearch, które zapobiegają temu, by pojedyncze, zbyt kosztowne kwerendy zużywały wszystkie zasoby klastra, co mogłoby prowadzić do niestabilności.
- Client-side Throttling/Rate Limiting: Wymuszanie limitów na aplikacji klienta, aby zapobiec wysyłaniu zbyt wielu kwerend w krótkim czasie przez jednego tenanta. Jest to proaktywne podejście, które chroni klaster przed przeciążeniem.
- Dedicated Nodes: Dla najbardziej krytycznych lub zasobożernych tenantów, warto rozważyć przydzielenie dedykowanych data node’ów, a choćby całych, mniejszych klastrów. Chociaż częściowo zaciera to granicę między multi- i single-tenant, jest to skuteczna strategia izolacji.
Dla stabilności klastra, regułą kciuka jest klaster OpenSearch mający do 30 000 indeksów i do 75 000 shardów. W ustawieniu multi-tenant, jeżeli spodziewamy się wzrostu danych klientów, zalecałabym udostępnienie nowego multi-tenant klastra dla kolejnych klientów, gdy osiągniemy około 40-50% pojemności klastra (pod względem indeksów i shardów). To proaktywne podejście uwzględnia wzrost klientów i zapobiega późniejszej złożoności operacyjnej, zwłaszcza jeżeli chcemy przechowywać wszystkie dane konkretnego klienta w jednym klastrze. To eliminuje potrzebę przenoszenia danych między klastrami.
ZŁOŻONOŚĆ OPERACYJNA
Złożoność operacyjna w multi-tenant OpenSearch jest równie wysoka jak w Kafka, a być może choćby wyższa ze względu na charakter indeksacji i wyszukiwania.
UPGRADES
Upgrade’y w OpenSearch mogą być wykonywane w sposób rolling (zero downtime), ale wymagają starannego planowania, zwłaszcza w środowisku multi-tenant. Zmiany w API, zachowań indeksacji lub logiki samego wyszukiwania mogą wpływać na wszystkich tenantów. Testowanie compatibility klienta i potencjalnych regresji jest kluczowe. Koordynowanie update’ów po stronie klienta z każdym tenantem może być logistycznym koszmarem.
OBSERVABILITY
Podobnie jak w Kafce, kompleksowe observability jest absolutnie niezbędne. Oprócz standardowych metryk klastra (CPU, memory, disk, network) oraz metryk indeksacji/wyszukiwań, potrzebujemy:
- Tenant-Specific Dashboards: Wizualizacja metryk, specyficznych dla wszystkich tenanta, takie jak:
- Search Latency: Czas odpowiedzi dla kwerend dla danego tenanta.
- Indexing Rates: Jak gwałtownie dane są indexowane dla danego tenanta.
- Query Success/Failure Rates: Procent udanych i nieudanych kwerend.
- Resource Consumption per Index/Tenant: Do identyfikacji, który tenant zużywa najwięcej zasobów.
- Query Monitoring: Warto też śledzić kosztowne kwerendy, które mogą obciążać klaster i przypisywać je do konkretnych tenantów, aby zidentyfikować “noisy neighbors”.
CAPACITY PLANNING
Capacity planning w OpenSearch koncentruje się na liczbie i rozmiarze shardów i node’ów. OpenSearch skaluje się horyzontalnie poprzez dodawanie kolejnych data nodes.
- Shard Management: Niepoprawna liczba shards (zbyt wiele małych, zbyt mało dużych) może prowadzić do problemów z wydajnością i zużyciem zasobów. Każdy shard (i każda kopia shardu) to oddzielna instancja Lucene. Oznacza to, iż utworzenie wielu mniejszych shardów spowoduje uruchomienie wielu instancji Lucene, które będą zużywać CPU i memory. Zbyt wiele shardów może prowadzić do niepotrzebnego zużycia zasobów i problemów z wydajnością.
Zbyt wiele dużych shardów również nie jest idealne. Klastry OpenSearch często przerzucają (rebalance’ują) shardy pomiędzy node’ami, aby utrzymać równomierny rozkład danych i obciążenia. Przenoszenie bardzo dużych shardów podczas tych operacji zużywa więcej przepustowości sieciowej i zasobów CPU, co sprawia, iż proces jest wolniejszy i potencjalnie wpływa na wydajność klastra. Gdy shardy stają się nadmiernie duże, kwerendy realizowane są dłużej, ponieważ każda kwerenda musi przetworzyć większą objętość danych w ramach tego jednego shard. Każda operacja wyszukiwania na shardzie wykorzystuje pojedynczy wątek CPU, co oznacza, iż większy zestaw danych na tym shardzie będzie skanowany i przetwarzany dłużej. Znalezienie adekwatnej równowagi jest kluczem. - Impact of Schema Changes (Mapping): W środowisku multi-tenant, gdzie każdy tenant może mieć nieco inne wymagania dotyczące schematu danych, zarządzanie i wdrażanie zmian w index mappings staje się złożone i może wpływać na wielu tenantów jednocześnie.
PODSUMOWANIE: WYBÓR DROGI DO SUKCESU
Podróż przez labirynt architektur multi-tenant i single-tenant, zwłaszcza w kontekście technologii takich jak Kafka i OpenSearch, ujawnia, iż nie ma jednej, uniwersalnej odpowiedzi. Jak widzimy, bezpieczeństwo, spory o zasoby i złożoność operacyjna – wszystko to stwarza unikalne wyzwania, które wymagają dogłębnej analizy i strategicznego podejścia.
Kafka, z jej rolą protokołu komunikacyjnego i trwałego dziennika zdarzeń, wymaga skrupulatnego zarządzania ACLs i rozważenia message-level encryption dla poszczególnych tenants. Spory o zasoby można złagodzić dzięki rozbudowanych quotas i inteligentnego capacity planning, ale wszystko to zwiększa złożoność operacyjną, zwłaszcza w kontekście upgrade’ów i observability.
OpenSearch, jako potężne narzędzie do indeksacji i wyszukiwania, stawia na czoło wyzwanie enkrypcji danych w użyciu. Tutaj pluginy, takie jak Portal26, stają się przełomem, umożliwiając bezpieczne przeszukiwania zaenkryptowanych danych. Jednakże spory o zasoby i złożoność operacyjna, wynikające z zarządzania shardami, kwerendy, i wdrażania update’ów, pozostają kluczowymi punktami do rozważenia.
CZAS NA DZIAŁANIA
Teraz nadszedł czas, aby wykorzystać tę wiedzę i zastosować ją w praktyce. Zamiast ślepo podążać za trendem multi-tenancy lub trzymać się bezpiecznej przystani single-tenancy, zadajmy sobie następujące pytania:
1. Jaki jest prawdziwy koszt obecnej architektury? Czy korzyści finansowe multi-tenancy przewyższają potencjalne koszty operacyjne i ryzyka bezpieczeństwa?
2. Jakie są wymagania dotyczące bezpieczeństwa i compliance? Czy posiadamy narzędzia (takie jak Portal26) i procesy, które mogą spełnić te wymagania w środowisku współdzielonym?
3. Jaki jest oczekiwany wzorzec obciążenia i jego zmienność? Czy nasi tenanty będą “noisy neighbors”, czy też potrafimy skutecznie zarządzać sporami o zasoby?
4. Jaki jest poziom dojrzałości mojego zespołu operacyjnego? Czy jesteśmy gotowi na dodatkową złożoność zarządzania, monitorowania i rozwiązywania problemów w środowisku multi-tenant?
5. Czy posiadamy odpowiednie narzędzia observability i automation, aby skutecznie skalować i utrzymywać tak złożony system?
KORZYŚCI W ZASIĘGU RĘKI
Świadomie podchodząc do tych pytań i oceniając bezpieczeństwo, spory o zasoby oraz złożoność operacyjną swojej architektury, zbudujemy systemy, które są:
- Bardziej Odporne: Lepsza izolacja i zarządzanie zasobami minimalizują ryzyko awarii i zakłóceń.
- Bardziej Kosztowo Efektywne: Optymalne wykorzystanie zasobów przekłada się na niższe rachunki za infrastrukturę.
- Bardziej Bezpieczne: Przemyślane strategie bezpieczeństwa chronią nasze dane i dane naszych klientów.
- Łatwiejsze w Zarządzaniu: Zrozumienie złożoności pozwala na proaktywne rozwiązywanie problemów i efektywne planowanie.
Wybór między multi-tenancy a single-tenancy nie jest decyzją typu wszystko albo nic, ale spektrum możliwości. Pamiętajmy, iż choćby w systemie multi-tenant możemy wdrożyć elementy izolacji single-tenant w krytycznych obszarach. Kluczem jest zrozumienie kompromisów i podejmowanie świadomych decyzji, które najlepiej służą naszemu produktowi i naszym klientom.
The English version of the article is available here.
Nadchodzące eventy
31
12
cała Polska
