Wielodostępność bez żargonu: przewodnik dla założyciela

W pewnym momencie budowania produktu programista rzuci słowo "multi-tenant", spojrzy na Pana/Pani twarz i założy, że wszystko jest jasne. Pewnie kiwnął Pan/Pani głową. Większość założycieli tak robi. Ale to jedna z tych wczesnych decyzji, które po cichu wyznaczają granicę tego, jak szybko można rosnąć, jak tanio działać i jak źle może się skończyć, jeśli klient kiedykolwiek zobaczy dane, które do niego nie należą. Warto poświęcić temu dziesięć minut uwagi teraz, bo powrót do tego później jest bardzo kosztowny.

Siedziałem naprzeciwko wielu nietechnicznych założycieli — ludzi z trafnym pomysłem na produkt SaaS i bez szczególnego zainteresowania bazami danych. Dobra wiadomość jest taka, że nie trzeba uczyć się programować, by podjąć tę decyzję dobrze. Potrzeba jasnego modelu myślowego i krótkiej listy pytań. Tym właśnie jest ten przewodnik. Bez modnych haseł, bez diagramów architektury, na które nigdy więcej Pan/Pani nie spojrzy — tylko to, co programista chciałby, żeby Pan/Pani rozumiał przed pierwszą linijką kodu.

Jeśli ma Pan/Pani zapamiętać jedną myśl, niech będzie to ta: wielodostępności nie dodaje się później jak funkcji. To fundament. Dom można pomalować na nowo, ale nie da się łatwo zmienić tego, na czym stoi, gdy ściany są już postawione.

Co naprawdę znaczy "multi-tenant"

Proszę wyobrazić sobie blok mieszkalny. Każdy lokator ma własne mieszkanie — własny klucz, własne meble, własne drzwi wejściowe. Ale wszyscy dzielą tę samą konstrukcję: fundament, instalację wodną, dach, windę. Zarządca utrzymuje jeden budynek, a nie pięćdziesiąt osobnych domów, i to właśnie sprawia, że czynsz jest przystępny. Oprogramowanie wielodostępne działa dokładnie tak samo. Jedna aplikacja obsługuje wielu klientów — "najemców" — a każdy z nich doświadcza jej jak własnej, prywatnej przestrzeni, choć wszyscy działają na tym samym współdzielonym systemie pod spodem.

Podejście odwrotne to single-tenant: każdy klient dostaje własną, oddzielną kopię oprogramowania, jakby budować dla każdego nowy wolnostojący dom. Bardziej prywatne, łatwiejsze do dostosowania — i dramatycznie droższe w budowie, utrzymaniu i aktualizacji, bo teraz utrzymuje Pan/Pani pięćdziesiąt domów zamiast jednego budynku.

Niemal każdy produkt, z którego Pan/Pani korzysta na co dzień, jest wielodostępny. Poczta, narzędzie księgowe, system rezerwacji, CRM, w którym żyje dział sprzedaży. Pan/Pani i tysiąc innych firm dzielicie to samo oprogramowanie pod spodem i nikt nigdy nie widzi pozostałych. Ta niewidzialność — to czyste rozdzielenie — to cała sztuka wielodostępności.

Dlaczego ta decyzja dotyka całego biznesu

Kusi, by odłożyć to do szuflady "szczegół techniczny, którym zajmuje się programista". Ale wybrany model przenika wprost do tych części biznesu, na których Panu/Pani zależy: miesięcznego rachunku za hosting, tego, jak szybko można udostępnić wszystkim nową funkcję, co można obiecać zdenerwowanemu klientowi korporacyjnemu i ile szkód może wyrządzić jeden błąd.

Gdy naprawia Pan/Pani błąd lub wydaje funkcję w dobrze zbudowanym produkcie wielodostępnym, każdy klient dostaje to naraz, jedną aktualizacją. W świecie single-tenant wdrażałby Pan/Pani tę zmianę na pięćdziesiąt osobnych instalacji, z których każda może być już nieco inna. To pierwsze to wtorkowe popołudnie. To drugie to projekt. Pomnóż to przez lata aktualizacji, a zobaczy Pan/Pani, dlaczego branża SaaS opiera się na wielodostępności.

Druga strona medalu jest taka, że współdzielenie infrastruktury podnosi stawkę przy rozdzielaniu. W bloku awaria instalacji może dotknąć więcej niż jedno mieszkanie. W oprogramowaniu wielodostępnym błąd w sposobie oddzielania najemców nie tylko utrudnia życie jednemu klientowi — może naraz ujawnić dane wszystkich. To nie powód, by unikać wielodostępności. To powód, by zbudować ją porządnie, z kimś, kto robił to już wcześniej.

Trzy sposoby na oddzielenie najemców

Gdy programiści spierają się o wielodostępność, zwykle kłócą się o to, jak bardzo oddzielone powinny być dane każdego najemcy. Istnieją trzy popularne podejścia, leżące na ruchomej skali od "maksymalne współdzielenie, najniższy koszt" do "maksymalne oddzielenie, najwyższy koszt". Nie musi Pan/Pani sam żadnego wybierać — ale powinien Pan/Pani rozumieć kompromis, jaki programista podejmuje w Pana/Pani imieniu.

1. Wspólna baza, wspólne tabele

Dane wszystkich leżą w tej samej bazie, w tych samych tabelach, z ukrytą etykietą — "identyfikatorem najemcy" — wskazującą, do kogo należą poszczególne wiersze. Oprogramowanie odpowiada za to, by zawsze filtrować po tej etykiecie, tak by klient A widział wyłącznie wiersze klienta A. To najtańszy i najlepiej skalujący się model, z którego korzysta większość wczesnych produktów SaaS. Haczyk: oddzielenie żyje w kodzie, więc jeden pominięty filtr to droga do wycieku danych. Wymaga starannej, zdyscyplinowanej pracy.

2. Wspólna baza, osobne przegrody

Jedna baza, ale każdy najemca dostaje w niej własną odgrodzoną sekcję (programiści nazywają je "schematami"). Silniejsze oddzielenie niż w pierwszym modelu, wciąż rozsądnie wydajne i łatwiej, powiedzmy, czysto wyeksportować lub usunąć dane jednego klienta. Kompromis: więcej ruchomych elementów do zarządzania, gdy rośnie się do setek i tysięcy najemców.

3. Osobna baza dla każdego najemcy

Każdy klient dostaje własną, dedykowaną bazę danych — najbliżej, jak można podejść do dania mu prywatnego domu, wciąż dzieląc aplikację. To najsilniejsza izolacja i najłatwiejsza opowieść dla świadomego bezpieczeństwa klienta korporacyjnego. Jest też najdroższa w utrzymaniu i obsłudze, więc bywa zarezerwowana dla klientów o wysokiej wartości, branż regulowanych lub produktów, w których pomylenie danych byłoby katastrofą.

Część, której nie wolno zepsuć: izolacja

Jeśli jest jedno miejsce, na które warto przeznaczyć swoje obawy, to właśnie tutaj. Izolacja najemców to gwarancja, że klient A nigdy, pod żadnym pozorem, nie zobaczy, nie zmieni ani nawet nie wyczuje istnienia danych klienta B. Brzmi oczywiście. Jest też najczęstszym źródłem poważnych błędów w produktach wielodostępnych, bo awaria jest cicha — wszystko wygląda dobrze aż do dnia, gdy ktoś otwiera raport i widzi w nim klientów obcej osoby.

Powód, dla którego tak się dzieje, jest strukturalny. W najtańszym modelu każde zapytanie do bazy musi pamiętać o filtrowaniu po najemcy. Zrób to dobrze dziesięć tysięcy razy i raz źle, a masz wyciek. Dlatego doświadczone zespoły nie polegają na pamięci programistów — wbudowują izolację w fundament, tak by zapomnienie stało się niemożliwe, a nie jedynie mało prawdopodobne. Nie musi Pan/Pani rozumieć, jak to robią. Musi Pan/Pani zapytać, czy to robią.

Jest też cichszy kuzyn tego problemu: "hałaśliwy sąsiad". Ponieważ najemcy dzielą infrastrukturę, jeden klient robiący coś ciężkiego — gigantyczny import, rozpędzony raport — może spowolnić system dla wszystkich pozostałych, tak jak jedno mieszkanie z wszystkimi odkręconymi kranami może obniżyć ciśnienie wody w całym budynku. Dobre projektowanie wielodostępne przewiduje to za pomocą limitów i sprawiedliwego podziału. Warto o to zapytać, zwłaszcza jeśli spodziewa się Pan/Pani kilku bardzo dużych klientów.

Kiedy single-tenant jest naprawdę słuszny

Wielodostępność to domyślny wybór dla SaaS, ale to nie religia. Istnieją uczciwe powody, by dać klientowi własną, osobną kopię, a dobry doradca powie Panu/Pani, kiedy taki powód się pojawił, zamiast wciskać wszystko w model wspólny.

• Klient z branży regulowanej — ochrona zdrowia, finanse, administracja — którego przepisy zgodności faktycznie wymagają, by jego dane leżały gdzieś w sposób dowiedlnie oddzielony.
• Jeden duży klient płacący tyle, że dedykowana konfiguracja jest tego warta, i który chce głębokiego dostosowania, którego nie chce Pan/Pani przeciekać do doświadczenia wszystkich pozostałych.
• Dane tak wrażliwe, że koszt wycieku między najemcami zakończyłby działalność, przez co maksymalna izolacja jest warta dodatkowego wydatku.
• Wymóg on-premise, gdzie oprogramowanie musi działać w obrębie własnych murów klienta, a nie w Pana/Pani chmurze.

Proszę zauważyć schemat: single-tenant to wyjątek, po który sięga się świadomie, zwykle dla konkretnego klienta o wysokiej wartości, a nie domyślny wybór, na którym buduje się cały biznes. Jeśli programista proponuje single-tenant dla Pana/Pani standardowego produktu od pierwszego dnia, proszę poprosić go, by wyjaśnił dlaczego — zwykle oznacza to dużo wyższy koszt utrzymania i wolniejsze aktualizacje, a chce Pan/Pani, by był to wybór, a nie przypadek.

Pytania, które należy zadać, zanim ktokolwiek napisze kod

Nie musi Pan/Pani projektować architektury. Musi Pan/Pani upewnić się, że osoba, która to robi, przemyślała właściwe rzeczy. Oto krótka lista, którą chciałbym, by nietechniczny założyciel przyniósł na tę pierwszą rozmowę — proszę ją wydrukować, zadać i obserwować, jak pewnie pada odpowiedź.

1. 1
   Jak utrzymacie oddzielenie danych najemców?

   Słucha Pan/Pani odpowiedzi strukturalnej — system to egzekwuje — a nie "będziemy ostrożni". To punkt nienegocjowalny.
2. 2
   Którego modelu używamy i dlaczego?

   Wspólne tabele, osobne przegrody czy baza na najemcę. Nie ma złej odpowiedzi, ale powinien istnieć powód pasujący do Pana/Pani klientów i budżetu.
3. 3
   Czy możemy później zaoferować dużemu klientowi dedykowaną izolację?

   Nawet jeśli zaczyna Pan/Pani w pełni wspólnie, projekt powinien zostawić miejsce na danie jednemu dużemu lub regulowanemu klientowi silniejszego oddzielenia bez przebudowy.
4. 4
   Co się stanie, gdy jeden klient stanie się ogromny?

   Jak system powstrzyma jednego ciężkiego najemcę przed spowalnianiem wszystkich pozostałych? Chce Pan/Pani usłyszeć, że scenariusze hałaśliwego sąsiada zostały rozważone.
5. 5
   Jak czysto wyeksportujemy lub usuniemy dane jednego klienta?

   Klienci odchodzą, a prawo o ochronie prywatności wymaga usunięcia ich danych na żądanie. To powinna być prosta, dobrze zrozumiana operacja, a nie panika.

Nie ocenia Pan/Pani technicznych szczegółów odpowiedzi. Sprawdza Pan/Pani, czy żadne z tych pytań nie spada jak zaskoczenie. Zespół, który już budował oprogramowanie wielodostępne, będzie miał na wszystkie pięć ostre, niemal znudzone odpowiedzi. Wahanie przy pierwszym lub trzecim to sygnał, by zwolnić i wejść głębiej.

Krótki, realistyczny przykład

Założyciel przyszedł do nas z działającym prototypem narzędzia do planowania dla małych przychodni. Miał już trzech płacących klientów — i cichy problem. Aby szybko wejść na rynek, pierwszy programista dał każdej przychodni własną, osobną kopię aplikacji. Trzech klientów, trzy instalacje, trzy nieco różniące się wersje, bo każda po drodze poprosiła o drobną zmianę.

Przy trzech działało to wyśmienicie. Koszmarem założyciela była myśl o trzydziestu. Każda naprawa błędu oznaczała logowanie się w trzech miejscach. Każda nowa funkcja oznaczała trzy wdrożenia i trzy rzeczy do przetestowania. Nowa przychodnia zajmowała większość tygodnia ręcznej konfiguracji. Model, który doprowadził ich do startu, był teraz tym, co ograniczało ich wzrost — dokładnie ten problem fundamentu, o którym jest cały ten artykuł.

Nie wyrywaliśmy wszystkiego w dramatycznym przepisaniu. Przebudowaliśmy rdzeń na wspólny fundament wielodostępny z izolacją egzekwowaną na poziomie systemu, zachowaliśmy dostosowania poszczególnych przychodni jako konfigurowalne ustawienia zamiast osobnych baz kodu i przenieśliśmy trzy istniejące przychodnie pojedynczo, równolegle, tak by nikt nie miał strasznego dnia przełączenia. Wdrożenie nowej przychodni przeszło z tygodnia ręcznej pracy do samoobsługowej rejestracji. Nowe funkcje docierają teraz do każdego klienta z jednego wydania.

Liczby tutaj są poglądowe, nie obietnicą — każdy produkt jest inny — ale kształt jest typowy: przebudowa kosztowała realne pieniądze i kilka miesięcy, a zwróciła się w obrębie pierwszej garstki nowych klientów, których nagle mogli wdrożyć bez kiwnięcia palcem. Lekcja, którą założyciel wyniósł, była tańsza: gdyby zadali pięć pytań na początku, nie byłoby nic do przebudowy.

Częste pytania