Multi-tenancy forklaret uden jargon: en guide for stiftere

På et tidspunkt i opbygningen af et softwareprodukt vil en udvikler sige ordet "multi-tenant" til dig, betragte dit ansigt og antage, at du forstod. Du nikkede sandsynligvis. Det gør de fleste stiftere. Men det er en af de tidlige beslutninger, der stille sætter loftet for, hvor hurtigt du kan vokse, hvor billigt du kan drive, og hvor galt det kan gå, hvis en kunde nogensinde ser data, der ikke er deres. Det fortjener ti minutter af din opmærksomhed nu, for det er meget dyrt at vende tilbage til senere.

Jeg har siddet over for mange ikke-tekniske stiftere — folk med en skarp idé til et SaaS-produkt og ingen særlig interesse for databaser. Den gode nyhed er, at du ikke behøver lære at kode for at træffe denne beslutning godt. Du har brug for en klar mental model og en kort liste med spørgsmål. Det er, hvad denne guide er. Ingen modeord, ingen arkitekturdiagrammer, du aldrig kigger på igen, bare det, din udvikler ønsker, du forstod inden den første linje kode.

Hvis du tager én idé med dig herfra, så lad det være denne: multi-tenancy er ikke en funktion, du tilføjer senere. Det er et fundament. Du kan male et hus om, men du kan ikke nemt ændre, hvad det står på, når væggene først er rejst.

Hvad "multi-tenant" faktisk betyder

Forestil dig en etageejendom. Hver beboer har sin egen lejlighed — sin egen nøgle, sine egne møbler, sin egen hoveddør. Men de deler alle den samme struktur: fundamentet, vandrørene, taget, elevatoren. Udlejeren vedligeholder én bygning, ikke halvtreds separate huse, og det er det, der gør huslejen overkommelig. Multi-tenant-software fungerer præcis sådan. Én applikation betjener mange kunder — "tenants" — og hver enkelt oplever den som sit eget private rum, selvom de alle kører på det samme delte system nedenunder.

Den modsatte tilgang er single-tenant: hver kunde får sin egen separate kopi af softwaren, som at bygge et helt nyt fritliggende hus til hver enkelt. Mere privat, mere tilpasseligt — og dramatisk dyrere at bygge, drive og opdatere, for nu vedligeholder du halvtreds huse i stedet for én bygning.

Næsten alle de produkter, du bruger til daglig, er multi-tenant. Din e-mail, dit regnskabsværktøj, dit bookingsystem, det CRM, dit salgsteam lever i. Du og tusind andre virksomheder deler den samme underliggende software, og ingen af jer ser nogensinde de andre. Den usynlighed — den rene adskillelse — er hele kunsten i multi-tenancy.

Hvorfor denne beslutning rører hele din forretning

Det er fristende at sætte det i kassen "teknisk detalje, min udvikler håndterer". Men den model, du vælger, breder sig direkte ind i de dele af forretningen, du faktisk interesserer dig for: din månedlige hostingregning, hvor hurtigt du kan levere en ny funktion til alle, hvad du kan love en nervøs erhvervskunde, og hvor meget skade en enkelt fejl kan gøre.

Når du retter en fejl eller udgiver en funktion i et velbygget multi-tenant-produkt, får hver kunde den på én gang, fra en enkelt opdatering. I en single-tenant-verden ville du udrulle den ændring til halvtreds separate installationer, som hver især måske er en smule forskellige nu. Det ene er en tirsdag eftermiddag. Det andet er et projekt. Gang det med år af opdateringer, og du forstår, hvorfor SaaS-branchen kører på multi-tenancy.

Bagsiden er, at deling af infrastruktur øger indsatsen på adskillelsen. I en etageejendom kan en vandskade ramme mere end én lejlighed. I multi-tenant-software er en fejl i, hvordan du holder tenants adskilt, ikke kun til besvær for én kunde — den kan blotlægge alles data på én gang. Det er ikke en grund til at undgå multi-tenancy. Det er grunden til at bygge det ordentligt, med nogen, der har gjort det før.

De tre måder at holde tenants adskilt på

Når udviklere skændes om multi-tenancy, skændes de som regel om, hvor adskilt hver tenants data skal være. Der er tre almindelige tilgange, og de ligger på en glidende skala fra "maksimal deling, laveste omkostning" til "maksimal adskillelse, højeste omkostning". Du behøver ikke selv vælge en — men du bør forstå den afvejning, din udvikler træffer på dine vegne.

1. Delt database, delte tabeller

Alles data lever i den samme database, i de samme tabeller, med et skjult mærke — et "tenant-ID" — der angiver, hvilke rækker der tilhører hvem. Softwaren har ansvaret for altid at filtrere efter det mærke, så kunde A kun nogensinde ser kunde A's rækker. Dette er den billigste og mest skalerbare model, den de fleste tidlige SaaS-produkter bruger. Hagen: adskillelsen lever i koden, så et enkelt overset filter er, hvordan data lækker. Det kræver omhyggelig, disciplineret ingeniørarbejde.

2. Delt database, separate rum

Én database, men hver tenant får sin egen afskærmede sektion inde i den (udviklere kalder disse "skemaer"). Stærkere adskillelse end den første model, stadig rimeligt effektiv, og lettere at, lad os sige, eksportere eller slette én kundes data rent. Afvejningen er flere bevægelige dele at håndtere, efterhånden som du vokser til hundreder og tusinder af tenants.

3. En separat database per tenant

Hver kunde får sin egen dedikerede database — det nærmeste du kommer på at give dem et privat hus, mens du stadig deler applikationen. Dette er den stærkeste isolering og den letteste historie at fortælle en sikkerhedsbevidst erhvervskunde. Det er også det dyreste at drive og betjene, så det plejer at være forbeholdt kunder af høj værdi, regulerede brancher eller produkter, hvor en datasammenblanding ville være katastrofal.

Den del, du ikke må få forkert: isolering

Hvis der er ét sted at bruge din bekymring, er det her. Tenant-isolering er garantien for, at kunde A aldrig, under nogen omstændigheder, kan se, redigere eller bare fornemme eksistensen af kunde B's data. Det lyder indlysende. Det er også den enkeltstående mest almindelige kilde til alvorlige fejl i multi-tenant-produkter, fordi svigtet er tavst — alt ser fint ud lige indtil den dag, nogen åbner en rapport og ser en fremmeds kunder i den.

Grunden til, at dette sker, er strukturel. I den billigste model skal hver eneste databaseforespørgsel huske at filtrere efter tenant. Få det rigtigt ti tusind gange og forkert én gang, og du har en lækage. Derfor stoler erfarne teams ikke på, at udviklere husker — de bygger isoleringen ind i fundamentet, så det at glemme bliver umuligt frem for blot usandsynligt. Du behøver ikke forstå, hvordan de gør det. Du skal spørge, om de gør det.

Der er også en stillere fætter til dette problem: den "støjende nabo". Fordi tenants deler infrastruktur, kan én kunde, der gør noget tungt — en kæmpe import, en løbsk rapport — gøre systemet langsomt for alle andre, på samme måde som én lejlighed med alle haner kørende kan sænke vandtrykket i hele bygningen. Godt multi-tenant-design planlægger for dette med grænser og fair deling. Det er værd at spørge om, især hvis du forventer nogle få meget store kunder.

Hvornår single-tenant faktisk er det rigtige valg

Multi-tenancy er standard for SaaS, men det er ikke en religion. Der er ærlige grunde til at give en kunde sin egen separate kopi, og en god rådgiver fortæller dig, når du er stødt på en sådan, i stedet for at tvinge alt ind i den delte model.

• En kunde i en reguleret branche — sundhed, finans, det offentlige — hvis compliance-regler i praksis kræver, at deres data lever et sted, der beviseligt er adskilt.
• En enkelt stor kunde, der betaler nok til, at en dedikeret opsætning er det værd, og som ønsker dyb tilpasning, du ikke vil have til at sive ind i alle andres oplevelse.
• Data så følsomme, at omkostningen ved en lækage på tværs af tenants ville lukke forretningen, hvilket gør maksimal isolering den ekstra udgift værd.
• Et on-premise-krav, hvor softwaren skal køre inden for kundens egne mure frem for i din sky.

Læg mærke til mønstret: single-tenant er undtagelsen, du bevidst griber til, som regel for en specifik kunde af høj værdi, ikke standarden, du bygger hele forretningen på. Hvis en udvikler foreslår single-tenant til dit standardprodukt fra dag ét, så bed dem gennemgå hvorfor — det betyder som regel en meget højere driftsomkostning og langsommere opdateringer, og du vil have, at det er et valg, ikke et uheld.

Spørgsmålene at stille, før nogen skriver kode

Du behøver ikke designe arkitekturen. Du skal sikre dig, at den person, der gør det, har tænkt over de rigtige ting. Her er den korte liste, jeg ville ønske, en ikke-teknisk stifter tog med til den første samtale — print den, stil den, og hold øje med, hvor selvsikkert den besvares.

1. 1
   Hvordan vil I holde tenants data adskilt?

   Du lytter efter et strukturelt svar — systemet håndhæver det — ikke "vi vil være omhyggelige". Dette er den, der ikke kan forhandles.
2. 2
   Hvilken model bruger vi, og hvorfor?

   Delte tabeller, separate rum eller database-per-tenant. Der er intet forkert svar, men der bør være en grund, der passer til dine kunder og dit budget.
3. 3
   Kan vi tilbyde dedikeret isolering til en stor kunde senere?

   Selv hvis du starter helt delt, bør designet levne plads til at give én stor eller reguleret kunde stærkere adskillelse uden en ombygning.
4. 4
   Hvad sker der, når én kunde bliver enorm?

   Hvordan forhindrer systemet en tung tenant i at gøre alle andre langsomme? Du vil høre, at scenarier med støjende naboer er blevet overvejet.
5. 5
   Hvordan eksporterer eller sletter vi én kundes data rent?

   Kunder forlader, og databeskyttelsesloven kræver, at du fjerner deres data på anmodning. Dette bør være en simpel, velforstået operation, ikke en panik.

Du bedømmer ikke den tekniske detalje i svarene. Du tjekker, at ingen af disse spørgsmål lander som en overraskelse. Et team, der har bygget multi-tenant-software før, har skarpe, næsten kedede svar på alle fem. Tøven ved det første eller tredje er signalet til at sætte farten ned og grave i det.

Et kort, virkelighedsnært eksempel

En stifter kom til os med en fungerende prototype af et planlægningsværktøj rettet mod små klinikker. Det havde allerede tre betalende kunder — og et stille problem. For hurtigt at komme på markedet havde den første udvikler givet hver klinik sin egen separate kopi af appen. Tre kunder, tre installationer, tre let forskellige versioner, fordi hver havde bedt om en lille justering undervejs.

Det fungerede smukt ved tre. Stifterens mareridt var tanken om tredive. Hver fejlrettelse betød at logge ind tre steder. Hver ny funktion betød tre udrulninger og tre ting at teste. En ny klinik tog det meste af en uge at sætte op i hånden. Modellen, der bragte dem til lancering, var nu det, der satte loft over deres vækst — præcis det fundamentproblem, hele denne artikel handler om.

Vi rev ikke alt ud i en dramatisk omskrivning. Vi byggede kernen om på et delt multi-tenant-fundament med isolering håndhævet på systemniveau, beholdt de klinikspecifikke tilpasninger som konfigurerbare indstillinger frem for separate kodebaser, og migrerede de tre eksisterende klinikker én ad gangen, parallelt, så ingen havde en skræmmende omstillingsdag. At onboarde en ny klinik gik fra en uges manuelt arbejde til en selvbetjent tilmelding. Nye funktioner når nu hver kunde fra en enkelt udgivelse.

Tallene her er illustrative, ikke et løfte — hvert produkt er forskelligt — men formen er typisk: ombygningen kostede rigtige penge og et par måneder, og den betalte sig selv inden for de første håndfulde nye kunder, de pludselig kunne onboarde uden at løfte en finger. Den lære, stifteren tog med sig, var den billigere: hvis de havde stillet de fem spørgsmål i starten, ville der ikke have været noget at bygge om.

Almindelige spørgsmål