Višekorisnička arhitektura bez žargona: vodič za osnivače

U nekom trenutku izrade softverskog proizvoda programer će vam izgovoriti riječ "multi-tenant", pogledati vaše lice i pretpostaviti da ste razumjeli. Vjerojatno ste kimnuli. Većina osnivača to čini. No to je jedna od onih ranih odluka koje tiho postavljaju strop koliko brzo možete rasti, koliko jeftino možete poslovati i koliko loše stvari mogu poći po zlu ako kupac ikad ugleda podatke koji nisu njegovi. Vrijedi joj posvetiti deset minuta sada, jer je vrlo skupo vraćati se na nju kasnije.

Sjedio sam nasuprot mnogim netehničkim osnivačima — ljudima s oštrom idejom za SaaS proizvod i bez osobitog interesa za baze podataka. Dobra je vijest da ne morate naučiti programirati da biste ovu odluku donijeli dobro. Trebate jasan mentalni model i kratak popis pitanja. Upravo je to ovaj vodič. Bez pomodnih riječi, bez arhitektonskih dijagrama koje nikad više nećete pogledati, samo ono što vaš programer želi da ste razumjeli prije prve linije koda.

Ako odnesete jednu misao, neka bude ova: multi-tenancy nije značajka koju dodajete kasnije. To je temelj. Kuću možete preličiti, ali ne možete lako promijeniti ono na čemu stoji kad zidovi već stoje.

Što "multi-tenant" zapravo znači

Zamislite stambenu zgradu. Svaki stanar ima svoj stan — svoj ključ, svoj namještaj, svoja ulazna vrata. No svi dijele istu strukturu: temelje, vodovod, krov, dizalo. Vlasnik održava jednu zgradu, a ne pedeset zasebnih kuća, i upravo to čini stanarinu pristupačnom. Multi-tenant softver radi točno tako. Jedna aplikacija poslužuje mnogo kupaca — "korisnika" — i svaki je doživljava kao vlastiti privatni prostor, iako svi rade na istom zajedničkom sustavu ispod.

Suprotan pristup je single-tenant: svaki kupac dobiva vlastitu zasebnu kopiju softvera, kao da za svakoga gradite potpuno novu samostojeću kuću. Privatnije, prilagodljivije — i dramatično skuplje za izgradnju, pogon i ažuriranje, jer sada održavate pedeset kuća umjesto jedne zgrade.

Gotovo svaki proizvod koji svakodnevno koristite je multi-tenant. Vaš e-mail, vaš računovodstveni alat, vaš sustav rezervacija, CRM u kojem živi vaš prodajni tim. Vi i tisuću drugih tvrtki dijelite isti temeljni softver, a nitko od vas nikad ne vidi onog drugog. Ta nevidljivost — to čisto razdvajanje — cijela je vještina multi-tenancyja.

Zašto ova odluka dotiče cijeli vaš posao

Primamljivo je svrstati to pod "tehnički detalj kojim se bavi moj programer". No model koji odaberete izravno se prelijeva u dijelove posla do kojih vam jest stalo: vaš mjesečni račun za hosting, koliko brzo možete isporučiti novu značajku svima, što možete obećati nervoznom korporativnom kupcu i koliko štete može nanijeti jedan jedini bug.

Kad ispravite bug ili objavite značajku u dobro izgrađenom multi-tenant proizvodu, svaki kupac je dobiva odjednom, iz jednog ažuriranja. U single-tenant svijetu tu biste promjenu uvodili u pedeset zasebnih instalacija, od kojih je svaka možda već pomalo drugačija. Jedno je utorak poslijepodne. Drugo je projekt. Pomnožite to s godinama ažuriranja i vidite zašto SaaS industrija počiva na multi-tenancyju.

Druga je strana da dijeljenje infrastrukture podiže ulog na razdvajanju. U stambenoj zgradi kvar vodovoda može pogoditi više od jednog stana. U multi-tenant softveru pogreška u načinu na koji držite korisnike razdvojenima ne smeta samo jednom kupcu — može izložiti podatke svih odjednom. To nije razlog da izbjegavate multi-tenancy. To je razlog da ga izgradite kako treba, s nekim tko je to već radio.

Tri načina držanja korisnika razdvojenima

Kad se programeri prepiru o multi-tenancyju, obično se prepiru o tome koliko razdvojeni trebaju biti podaci svakog korisnika. Postoje tri uobičajena pristupa i smješteni su na ljestvici od "maksimalno dijeljenje, najniži trošak" do "maksimalno razdvajanje, najviši trošak". Ne morate sami birati — ali trebali biste razumjeti kompromis koji vaš programer čini u vaše ime.

1. Zajednička baza, zajedničke tablice

Podaci svih žive u istoj bazi, u istim tablicama, sa skrivenom oznakom — "tenant ID" — koja označava koji reci kome pripadaju. Softver je odgovoran uvijek filtrirati prema toj oznaci, tako da kupac A uvijek vidi samo retke kupca A. To je najjeftiniji i najskalabilniji model, onaj koji koristi većina ranih SaaS proizvoda. Kvaka: razdvajanje živi u kodu, pa je jedan propušten filtar način na koji podaci procure. Zahtijeva pažljiv, discipliniran inženjering.

2. Zajednička baza, odvojeni pretinci

Jedna baza podataka, ali svaki korisnik dobiva svoj ograđeni odjeljak unutar nje (programeri ih nazivaju "shemama"). Jače razdvajanje od prvog modela, i dalje razumno učinkovito, te lakše, recimo, čisto izvesti ili izbrisati podatke jednog kupca. Kompromis je više pokretnih dijelova za upravljanje kako rastete u stotine i tisuće korisnika.

3. Zasebna baza po korisniku

Svaki kupac dobiva vlastitu namjensku bazu podataka — najbliže davanju privatne kuće uz i dalje dijeljenje aplikacije. To je najjača izolacija i najlakša priča za ispričati korporativnom kupcu svjesnom sigurnosti. Ujedno je i najskuplja za pogon i upravljanje, pa se obično čuva za kupce visoke vrijednosti, regulirane industrije ili proizvode gdje bi pomiješanost podataka bila katastrofalna.

Dio koji ne smijete pogriješiti: izolacija

Ako postoji jedno mjesto na koje vrijedi potrošiti brigu, to je ovdje. Izolacija korisnika jest jamstvo da kupac A nikad, ni pod kojim okolnostima, ne može vidjeti, urediti ili čak naslutiti postojanje podataka kupca B. Zvuči očito. Ujedno je i najčešći izvor ozbiljnih bugova u multi-tenant proizvodima, jer je kvar tih — sve izgleda u redu sve do dana kad netko otvori izvještaj i u njemu ugleda tuđe kupce.

Razlog zašto se to događa je strukturni. U najjeftinijem modelu svaki pojedini zahtjev prema bazi mora se sjetiti filtrirati prema korisniku. Učinite to ispravno deset tisuća puta i pogrešno jednom, i imate curenje. Zato se iskusni timovi ne oslanjaju na to da će se programeri sjetiti — izolaciju ugrađuju u temelj, tako da zaboravljanje postaje nemoguće, a ne tek malo vjerojatno. Ne morate razumjeti kako to rade. Morate pitati rade li to.

Postoji i tiši rođak ovog problema: "bučni susjed". Budući da korisnici dijele infrastrukturu, jedan kupac koji radi nešto teško — golem uvoz, odbjegli izvještaj — može usporiti sustav za sve ostale, jednako kao što jedan stan koji pusti sve slavine može srušiti tlak vode u cijeloj zgradi. Dobar multi-tenant dizajn to predviđa granicama i pravednom raspodjelom. Vrijedi pitati, osobito ako očekujete nekoliko vrlo velikih kupaca.

Kad je single-tenant zapravo prava odluka

Multi-tenancy je zadana opcija za SaaS, ali nije religija. Postoje pošteni razlozi da kupcu date vlastitu zasebnu kopiju, i dobar će vam savjetnik reći kad ste naišli na takav, umjesto da sve nasilno trpa u zajednički model.

• Kupac u reguliranoj industriji — zdravstvu, financijama, državnoj upravi — čija pravila usklađenosti zapravo zahtijevaju da njegovi podaci žive negdje dokazivo odvojeno.
• Jedan veliki klijent koji plaća dovoljno da se namjenska postava isplati, a koji želi duboku prilagodbu za koju ne želite da se prelije u iskustvo svih ostalih.
• Podaci toliko osjetljivi da bi trošak curenja među korisnicima dokrajčio posao, čime maksimalna izolacija postaje vrijedna dodatnog troška.
• Zahtjev za radom on-premise, gdje softver mora raditi unutar kupčevih vlastitih zidova, a ne u vašem oblaku.

Primijetite obrazac: single-tenant je iznimka kojoj namjerno pribjegavate, obično za određenog kupca visoke vrijednosti, a ne zadana opcija na kojoj gradite cijeli posao. Ako programer predlaže single-tenant za vaš standardni proizvod od prvog dana, zatražite da vam objasni zašto — to obično znači mnogo viši trošak pogona i sporija ažuriranja, a vi želite da to bude izbor, a ne nezgoda.

Pitanja koja treba postaviti prije nego itko napiše kod

Ne morate projektirati arhitekturu. Morate se uvjeriti da je osoba koja je projektira promislila o pravim stvarima. Evo kratkog popisa koji bih želio da netehnički osnivač donese na taj prvi razgovor — ispišite ga, postavite pitanja, promatrajte koliko se samouvjereno na njih odgovara.

1. 1
   Kako ćete držati podatke korisnika razdvojenima?

   Slušate strukturni odgovor — sustav to provodi — a ne "bit ćemo oprezni". Ovo je ono o čemu se ne pregovara.
2. 2
   Koji model koristimo i zašto?

   Zajedničke tablice, odvojeni pretinci ili baza po korisniku. Nema pogrešnog odgovora, ali treba postojati razlog koji odgovara vašim kupcima i proračunu.
3. 3
   Možemo li velikom klijentu kasnije ponuditi namjensku izolaciju?

   Čak i ako počnete potpuno dijeljeno, dizajn treba ostaviti prostora da jednom velikom ili reguliranom kupcu date jače razdvajanje bez pregradnje.
4. 4
   Što se događa kad jedan kupac postane golem?

   Kako sustav sprječava da jedan težak korisnik usporava sve ostale? Želite čuti da su scenariji bučnog susjeda razmotreni.
5. 5
   Kako čisto izvozimo ili brišemo podatke jednog kupca?

   Kupci odlaze, a zakon o privatnosti zahtijeva da na zahtjev uklonite njihove podatke. To treba biti jednostavna, dobro shvaćena operacija, a ne panika.

Ne ocjenjujete tehnički detalj odgovora. Provjeravate da nijedno od ovih pitanja ne padne kao iznenađenje. Tim koji je već gradio multi-tenant softver imat će jasne, gotovo dosadne odgovore na svih pet. Oklijevanje kod prvog ili trećeg signal je da usporite i kopate dublje.

Kratak, životan primjer

Osnivač nam je došao s radnim prototipom alata za zakazivanje termina namijenjenog malim klinikama. Već je imao tri kupca koji plaćaju — i tihi problem. Da bi brzo izašao na tržište, prvi je programer svakoj klinici dao vlastitu zasebnu kopiju aplikacije. Tri kupca, tri instalacije, tri malo različite verzije, jer je svaka usput zatražila malu izmjenu.

Radilo je prekrasno na tri. Osnivačeva noćna mora bila je pomisao na trideset. Svaki ispravak buga značio je prijavu na tri mjesta. Svaka nova značajka značila je tri implementacije i tri stvari za testiranje. Nova klinika trošila je gotovo cijeli tjedan za ručno postavljanje. Model koji ih je doveo do lansiranja sada je bio ono što je ograničavalo njihov rast — upravo problem temelja o kojem govori cijeli ovaj članak.

Nismo sve dramatično iščupali u prepisivanju. Jezgru smo iznova izgradili na zajedničkom multi-tenant temelju s izolacijom provedenom na razini sustava, prilagodbe po klinici zadržali kao postavke koje se mogu konfigurirati umjesto zasebnih baza koda, i tri postojeće klinike preselili jednu po jednu, paralelno, tako da nitko nije imao strašan dan prijelaza. Uvođenje nove klinike prešlo je s tjedna ručnog rada na samostalnu prijavu. Nove značajke sada dolaze do svakog kupca iz jednog izdanja.

Brojke su ovdje ilustrativne, a ne obećanje — svaki je proizvod drugačiji — ali oblik je tipičan: pregradnja je koštala pravog novca i nekoliko mjeseci, i isplatila se već unutar prve nekolicine novih kupaca koje su iznenada mogli uvesti bez i da prstom maknu. Pouka koju je osnivač izvukao bila je jeftinija: da su na početku postavili pet pitanja, ne bi bilo ničega za pregraditi.

Česta pitanja