Večnajemniška arhitektura brez žargona: vodnik za ustanovitelje

Na neki točki izdelave programskega izdelka vam bo razvijalec izrekel besedo »multi-tenant«, pogledal vaš obraz in predpostavil, da ste razumeli. Verjetno ste prikimali. Večina ustanoviteljev to stori. A to je ena tistih zgodnjih odločitev, ki tiho postavi strop temu, kako hitro lahko rastete, kako poceni lahko poslujete in kako hudo gredo stvari lahko narobe, če stranka kdaj vidi podatke, ki niso njeni. Vredno je deset minut vaše pozornosti zdaj, saj se je k temu zelo drago vračati pozneje.

Sedel sem nasproti mnogim netehničnim ustanoviteljem — ljudem z bistro idejo za SaaS izdelek in brez posebnega zanimanja za baze podatkov. Dobra novica je, da se vam za dobro odločitev ni treba naučiti programirati. Potrebujete jasen miselni model in kratek seznam vprašanj. Točno to je ta vodnik. Brez modnih besed, brez arhitekturnih diagramov, ki jih ne boste nikoli več pogledali, le tisto, kar vaš razvijalec želi, da bi razumeli pred prvo vrstico kode.

Če odnesete eno misel, naj bo ta: multi-tenancy ni funkcija, ki jo dodate pozneje. Je temelj. Hišo lahko prebarvate, ne morete pa zlahka spremeniti tega, na čemer stoji, ko zidovi že stojijo.

Kaj »multi-tenant« v resnici pomeni

Predstavljajte si stanovanjsko stavbo. Vsak najemnik ima svoje stanovanje — svoj ključ, svoje pohištvo, svoja vhodna vrata. A vsi si delijo isto zgradbo: temelje, vodovod, streho, dvigalo. Lastnik vzdržuje eno stavbo, ne petdeset ločenih hiš, in prav to ohranja najemnino dostopno. Multi-tenant programska oprema deluje točno tako. Ena aplikacija streže mnogim strankam — »najemnikom« — in vsaka jo doživlja kot svoj zasebni prostor, čeprav vse tečejo na istem skupnem sistemu spodaj.

Nasprotni pristop je single-tenant: vsaka stranka dobi svojo ločeno kopijo programske opreme, kot bi za vsako zgradili povsem novo samostojno hišo. Bolj zasebno, bolj prilagodljivo — in dramatično dražje za izgradnjo, obratovanje in posodabljanje, saj zdaj vzdržujete petdeset hiš namesto ene stavbe.

Skoraj vsak izdelek, ki ga dnevno uporabljate, je multi-tenant. Vaša e-pošta, vaše računovodsko orodje, vaš rezervacijski sistem, CRM, v katerem živi vaša prodajna ekipa. Vi in tisoč drugih podjetij si delite isto temeljno programsko opremo in nihče od vas nikoli ne vidi drugega. Ta nevidnost — ta čista ločitev — je celotna umetnost multi-tenancyja.

Zakaj se ta odločitev dotika celotnega vašega poslovanja

Mamljivo je to uvrstiti pod »tehnično podrobnost, ki jo ureja moj razvijalec«. A model, ki ga izberete, se neposredno preliva v dele poslovanja, ki vas res zanimajo: v vaš mesečni račun za gostovanje, v to, kako hitro lahko vsem dostavite novo funkcijo, kaj lahko obljubite živčnemu poslovnemu kupcu in koliko škode lahko povzroči en sam hrošč.

Ko v dobro zgrajenem multi-tenant izdelku popravite hrošča ali izdate funkcijo, jo vsaka stranka dobi naenkrat, iz ene posodobitve. V svetu single-tenant bi to spremembo uvajali v petdeset ločenih namestitev, od katerih je vsaka morda zdaj že nekoliko drugačna. Ena je torkovo popoldne. Druga je projekt. Pomnožite to z leti posodobitev in vidite, zakaj SaaS panoga sloni na multi-tenancyju.

Druga plat je, da deljenje infrastrukture zvišuje vložek pri ločevanju. V stanovanjski stavbi lahko okvara vodovoda prizadene več kot eno stanovanje. V multi-tenant programski opremi napaka pri tem, kako najemnike ohranjate ločene, ne moti le ene stranke — lahko razkrije podatke vseh naenkrat. To ni razlog za izogibanje multi-tenancyju. To je razlog, da ga zgradite pravilno, z nekom, ki je to že počel.

Trije načini ohranjanja najemnikov ločenih

Ko se razvijalci prepirajo o multi-tenancyju, se običajno prepirajo o tem, kako ločeni naj bodo podatki vsakega najemnika. Obstajajo trije pogosti pristopi in se nahajajo na drsni lestvici od »največje deljenje, najnižji strošek« do »največja ločitev, najvišji strošek«. Ni vam treba izbrati samim — bi pa morali razumeti kompromis, ki ga vaš razvijalec sklepa v vašem imenu.

1. Skupna baza, skupne tabele

Podatki vseh živijo v isti bazi, v istih tabelah, s skrito oznako — »tenant ID« — ki označuje, katere vrstice komu pripadajo. Programska oprema je odgovorna, da vedno filtrira po tej oznaki, tako da stranka A vedno vidi le vrstice stranke A. To je najcenejši in najbolj razširljiv model, tisti, ki ga uporablja večina zgodnjih SaaS izdelkov. Kavelj: ločitev živi v kodi, zato je en sam pozabljen filter način, kako podatki uhajajo. Zahteva skrbno, disciplinirano inženirstvo.

2. Skupna baza, ločeni predeli

Ena baza podatkov, a vsak najemnik dobi svoj ograjeni razdelek znotraj nje (razvijalci jih imenujejo »sheme«). Močnejša ločitev kot pri prvem modelu, še vedno razumno učinkovita, in lažje je, denimo, čisto izvoziti ali izbrisati podatke ene stranke. Kompromis je več premikajočih se delov za upravljanje, ko zrastete na stotine in tisoče najemnikov.

3. Ločena baza za vsakega najemnika

Vsaka stranka dobi svojo namensko bazo podatkov — najbliže temu, da ji daste zasebno hišo, ob tem pa še vedno deli aplikacijo. To je najmočnejša izolacija in najlažja zgodba za poslovnega kupca, ki je pozoren na varnost. Je tudi najdražja za obratovanje in upravljanje, zato je običajno pridržana za stranke visoke vrednosti, regulirane panoge ali izdelke, kjer bi bila zamenjava podatkov katastrofalna.

Del, ki ga ne smete zgrešiti: izolacija

Če obstaja eno mesto, kamor je vredno usmeriti svojo skrb, je tukaj. Izolacija najemnikov je jamstvo, da stranka A nikoli, pod nobenimi pogoji, ne more videti, urejati ali celo zaznati obstoja podatkov stranke B. Sliši se očitno. Je tudi najpogostejši vir resnih hroščev v multi-tenant izdelkih, saj je odpoved tiha — vse je videti v redu vse do dne, ko nekdo odpre poročilo in v njem zagleda stranke tujca.

Razlog, zakaj se to dogaja, je strukturen. Pri najcenejšem modelu si mora vsaka posamezna zahteva do baze zapomniti, da filtrira po najemniku. Naredite to pravilno desettisočkrat in enkrat narobe, in imate uhajanje. Zato se izkušene ekipe ne zanašajo na to, da si bodo razvijalci zapomnili — izolacijo vgradijo v temelj, tako da pozaba postane nemogoča in ne le malo verjetna. Ni vam treba razumeti, kako to počnejo. Treba je vprašati, ali to počnejo.

Obstaja tudi tišji sorodnik tega problema: »hrupni sosed«. Ker si najemniki delijo infrastrukturo, lahko ena stranka, ki počne nekaj zahtevnega — ogromen uvoz, podivjano poročilo — upočasni sistem za vse druge, prav tako kot lahko eno stanovanje z odprtimi vsemi pipami sesuje vodni tlak po vsej stavbi. Dobra multi-tenant zasnova to predvidi z omejitvami in pravično delitvijo. Vredno je vprašati, zlasti če pričakujete nekaj zelo velikih strank.

Kdaj je single-tenant dejansko prava izbira

Multi-tenancy je privzeta izbira za SaaS, a ni vera. Obstajajo pošteni razlogi, da stranki daste lastno ločeno kopijo, in dober svetovalec vam bo povedal, kdaj ste naleteli na takega, namesto da bi vse na silo tlačil v skupni model.

• Stranka v regulirani panogi — zdravstvo, finance, državna uprava — katere pravila skladnosti dejansko zahtevajo, da njeni podatki živijo nekje dokazljivo ločeno.
• Ena velika stranka, ki plačuje dovolj, da se namenska postavitev splača, in ki želi globoko prilagoditev, za katero ne želite, da bi pronicala v izkušnjo vseh drugih.
• Podatki tako občutljivi, da bi strošek uhajanja med najemniki uničil poslovanje, zaradi česar se največja izolacija splača kljub dodatnemu strošku.
• Zahteva po obratovanju on-premise, kjer mora programska oprema teči znotraj strankinih lastnih zidov, ne v vašem oblaku.

Opazite vzorec: single-tenant je izjema, po kateri namerno posežete, običajno za določeno stranko visoke vrednosti, ne privzeta izbira, na kateri gradite celotno poslovanje. Če razvijalec za vaš standardni izdelek od prvega dne predlaga single-tenant, ga prosite, naj vam pojasni zakaj — to običajno pomeni precej višje stroške obratovanja in počasnejše posodobitve, vi pa želite, da je to izbira, ne nesreča.

Vprašanja, ki si jih je treba zastaviti, preden kdorkoli napiše kodo

Ni vam treba zasnovati arhitekture. Treba se je prepričati, da je oseba, ki jo snuje, premislila prave stvari. Tukaj je kratek seznam, za katerega bi želel, da ga netehnični ustanovitelj prinese na ta prvi pogovor — natisnite ga, vprašajte, opazujte, kako samozavestno se nanj odgovarja.

1. 1
   Kako boste podatke najemnikov ohranjali ločene?

   Poslušate strukturni odgovor — sistem to uveljavlja — ne »previdni bomo«. To je tisto, o čemer se ne pogaja.
2. 2
   Kateri model uporabljamo in zakaj?

   Skupne tabele, ločeni predeli ali baza za vsakega najemnika. Ni napačnega odgovora, mora pa obstajati razlog, ki ustreza vašim strankam in proračunu.
3. 3
   Ali lahko veliki stranki pozneje ponudimo namensko izolacijo?

   Tudi če začnete povsem deljeno, naj zasnova pusti prostor, da eni veliki ali regulirani stranki daste močnejšo ločitev brez predelave.
4. 4
   Kaj se zgodi, ko ena stranka postane ogromna?

   Kako sistem prepreči, da bi en zahteven najemnik upočasnil vse druge? Želite slišati, da so bili scenariji hrupnega soseda upoštevani.
5. 5
   Kako čisto izvozimo ali izbrišemo podatke ene stranke?

   Stranke odhajajo, zakon o varstvu zasebnosti pa zahteva, da njihove podatke na zahtevo odstranite. To naj bo preprosta, dobro razumljena operacija, ne panika.

Ne ocenjujete tehnične podrobnosti odgovorov. Preverjate, da nobeno od teh vprašanj ne pristane kot presenečenje. Ekipa, ki je multi-tenant programsko opremo že gradila, bo imela na vseh pet jasne, skoraj zdolgočasene odgovore. Obotavljanje pri prvem ali tretjem je signal, da upočasnite in pobrskate globlje.

Kratek, življenjski primer

K nam je prišel ustanovitelj z delujočim prototipom orodja za naročanje terminov, namenjenega majhnim klinikam. Imel je že tri plačujoče stranke — in tih problem. Da bi hitro prišel na trg, je prvi razvijalec vsaki kliniki dal svojo ločeno kopijo aplikacije. Tri stranke, tri namestitve, tri rahlo različne različice, ker je vsaka spotoma zaprosila za majhno prilagoditev.

Pri treh je delovalo čudovito. Ustanoviteljeva nočna mora je bila misel na trideset. Vsak popravek hrošča je pomenil prijavo na tri mesta. Vsaka nova funkcija je pomenila tri uvedbe in tri stvari za preizkus. Nova klinika je za ročno postavitev vzela skoraj cel teden. Model, ki jih je pripeljal do zagona, je bil zdaj tisto, kar je omejevalo njihovo rast — točno tisti problem temelja, o katerem govori celoten ta članek.

Nismo vsega izpulili v dramatičnem prepisovanju. Jedro smo na novo zgradili na skupnem multi-tenant temelju z izolacijo, uveljavljeno na ravni sistema, prilagoditve posameznih klinik smo ohranili kot nastavljive nastavitve namesto ločenih kodnih baz in tri obstoječe klinike preselili eno za drugo, vzporedno, tako da nihče ni imel strašnega dne preklopa. Uvajanje nove klinike je iz tedna ročnega dela prešlo v samopostrežno registracijo. Nove funkcije zdaj dosežejo vsako stranko iz ene same izdaje.

Številke so tu ponazoritvene, ne obljuba — vsak izdelek je drugačen — a oblika je tipična: predelava je stala pravi denar in nekaj mesecev, povrnila pa se je že v okviru prve peščice novih strank, ki so jih nenadoma lahko uvedli, ne da bi mignili s prstom. Nauk, ki ga je ustanovitelj odnesel, je bil cenejši: če bi na začetku zastavili pet vprašanj, ne bi bilo ničesar za predelati.

Pogosta vprašanja