Multi-tenancy förklarat utan jargong: en guide för grundare

Någon gång när du bygger en mjukvaruprodukt kommer en utvecklare att säga ordet "multi-tenant" till dig, betrakta ditt ansikte och anta att du förstod. Du nickade förmodligen. De flesta grundare gör det. Men det här är ett av de där tidiga besluten som tyst sätter taket för hur snabbt du kan växa, hur billigt du kan driva och hur illa det kan gå om en kund någonsin ser data som inte är deras. Det förtjänar tio minuter av din uppmärksamhet nu, eftersom det är mycket dyrt att återbesöka senare.

Jag har suttit mittemot många icke-tekniska grundare — människor med en skarp idé för en SaaS-produkt och inget särskilt intresse för databaser. Den goda nyheten är att du inte behöver lära dig koda för att fatta det här beslutet väl. Du behöver en tydlig tankemodell och en kort lista med frågor. Det är vad den här guiden är. Inga modeord, inga arkitekturdiagram du aldrig kommer att titta på igen, bara det din utvecklare önskar att du förstod innan den första kodraden.

Om du tar med dig en idé härifrån, låt det bli denna: multi-tenancy är inte en funktion du lägger till senare. Det är en grund. Du kan måla om ett hus, men du kan inte enkelt ändra vad det står på när väggarna väl är uppe.

Vad "multi-tenant" faktiskt betyder

Föreställ dig ett flerfamiljshus. Varje hyresgäst har sin egen lägenhet — sin egen nyckel, sina egna möbler, sin egen ytterdörr. Men de delar alla samma struktur: grunden, rörsystemet, taket, hissen. Hyresvärden underhåller en byggnad, inte femtio separata hus, och det är det som gör hyran överkomlig. Multi-tenant-mjukvara fungerar precis så här. En applikation betjänar många kunder — "tenants" — och var och en upplever den som sitt eget privata utrymme, även om de alla körs på samma delade system under ytan.

Det motsatta tillvägagångssättet är single-tenant: varje kund får sin egen separata kopia av mjukvaran, som att bygga ett helt nytt fristående hus för var och en. Mer privat, mer anpassningsbart — och dramatiskt dyrare att bygga, driva och uppdatera, eftersom du nu underhåller femtio hus istället för en byggnad.

Nästan varje produkt du använder dagligen är multi-tenant. Din e-post, ditt bokföringsverktyg, ditt bokningssystem, CRM:et som ditt säljteam lever i. Du och tusen andra företag delar samma underliggande mjukvara, och ingen av er ser någonsin de andra. Den osynligheten — den rena separationen — är hela konsten med multi-tenancy.

Varför det här beslutet påverkar hela ditt företag

Det är frestande att kategorisera detta som "en teknisk detalj som min utvecklare hanterar". Men modellen du väljer får direkta ringar på vattnet i de delar av verksamheten du verkligen bryr dig om: din månatliga hostingfaktura, hur snabbt du kan leverera en ny funktion till alla, vad du kan lova en nervös företagsköpare och hur mycket skada en enda bugg kan göra.

När du fixar en bugg eller släpper en funktion i en välbyggd multi-tenant-produkt får varje kund den på en gång, från en enda uppdatering. I en single-tenant-värld skulle du rulla ut den ändringen till femtio separata installationer, var och en som kanske är lite annorlunda vid det här laget. Det ena är en tisdagseftermiddag. Det andra är ett projekt. Multiplicera det över år av uppdateringar och du ser varför SaaS-branschen körs på multi-tenancy.

Baksidan är att delning av infrastruktur höjer insatsen på separationen. I ett flerfamiljshus kan ett rörfel påverka mer än en lägenhet. I multi-tenant-mjukvara orsakar ett misstag i hur du håller tenants isär inte bara besvär för en kund — det kan exponera allas data på en gång. Det är inte ett skäl att undvika multi-tenancy. Det är skälet att bygga den ordentligt, med någon som har gjort det förut.

De tre sätten att hålla tenants isär

När utvecklare bråkar om multi-tenancy bråkar de oftast om hur separat varje tenants data ska vara. Det finns tre vanliga tillvägagångssätt, och de ligger på en glidande skala från "maximal delning, lägst kostnad" till "maximal separation, högst kostnad". Du behöver inte välja en själv — men du bör förstå avvägningen din utvecklare gör å dina vägnar.

1. Delad databas, delade tabeller

Allas data lever i samma databas, i samma tabeller, med en dold etikett — ett "tenant-ID" — som markerar vilka rader som tillhör vem. Mjukvaran ansvarar för att alltid filtrera efter den etiketten, så att kund A bara någonsin ser kund A:s rader. Det här är den billigaste och mest skalbara modellen, den som de flesta tidiga SaaS-produkter använder. Haken: separationen lever i koden, så ett enda missat filter är hur data läcker. Det kräver noggrann, disciplinerad ingenjörskonst.

2. Delad databas, separata fack

En databas, men varje tenant får sin egen avskilda sektion inuti den (utvecklare kallar dessa "scheman"). Starkare separation än den första modellen, fortfarande rimligt effektiv, och enklare att till exempel exportera eller radera en kunds data rent. Avvägningen är fler rörliga delar att hantera när du växer till hundratals och tusentals tenants.

3. En separat databas per tenant

Varje kund får sin egen dedikerade databas — det närmaste du kommer att ge dem ett privat hus medan du fortfarande delar applikationen. Det här är den starkaste isoleringen och den enklaste berättelsen att berätta för en säkerhetsmedveten företagsköpare. Det är också det dyraste att driva och förvalta, så det tenderar att reserveras för högvärdiga kunder, reglerade branscher eller produkter där en datasammanblandning skulle vara katastrofal.

Delen du inte får ha fel på: isolering

Om det finns ett ställe att lägga din oro på, är det här. Tenantisolering är garantin att kund A aldrig, under några omständigheter, kan se, redigera eller ens ana existensen av kund B:s data. Det låter självklart. Det är också den enskilt vanligaste källan till allvarliga buggar i multi-tenant-produkter, eftersom felet är tyst — allt ser bra ut ända fram till den dag någon öppnar en rapport och ser en främlings kunder i den.

Anledningen till att detta händer är strukturell. I den billigaste modellen måste varje enskild databasförfrågan komma ihåg att filtrera efter tenant. Få det rätt tiotusen gånger och fel en gång, och du har en läcka. Därför förlitar sig erfarna team inte på att utvecklare kommer ihåg — de bygger in isoleringen i grunden, så att glömma blir omöjligt snarare än bara osannolikt. Du behöver inte förstå hur de gör det. Du behöver fråga om de gör det.

Det finns också en tystare kusin till det här problemet: den "stökiga grannen". Eftersom tenants delar infrastruktur kan en kund som gör något tungt — en gigantisk import, en skenande rapport — sakta ner systemet för alla andra, på samma sätt som en lägenhet med alla kranar igång kan sänka vattentrycket i hela byggnaden. Bra multi-tenant-design planerar för detta med gränser och rättvis delning. Det är värt att fråga om, särskilt om du förväntar dig några mycket stora kunder.

När single-tenant faktiskt är rätt val

Multi-tenancy är standard för SaaS, men det är ingen religion. Det finns ärliga skäl att ge en kund sin egen separata kopia, och en bra rådgivare berättar för dig när du har träffat på ett sådant istället för att tvinga in allt i den delade modellen.

• En kund i en reglerad bransch — vård, finans, offentlig sektor — vars efterlevnadsregler i praktiken kräver att deras data lever någonstans bevisbart separat.
• En enda stor kund som betalar tillräckligt för att en dedikerad uppsättning är värd det, och som vill ha djup anpassning du inte vill ska läcka in i allas andras upplevelse.
• Data så känslig att kostnaden för en läcka mellan tenants skulle avsluta verksamheten, vilket gör maximal isolering värd den extra kostnaden.
• Ett on-premise-krav, där mjukvaran måste köras innanför kundens egna väggar snarare än i ditt moln.

Lägg märke till mönstret: single-tenant är undantaget du griper till medvetet, oftast för en specifik högvärdig kund, inte standarden du bygger hela verksamheten på. Om en utvecklare föreslår single-tenant för din standardprodukt från dag ett, be dem gå igenom varför — det betyder oftast en mycket högre driftskostnad och långsammare uppdateringar, och du vill att det ska vara ett val, inte en olyckshändelse.

Frågorna att ställa innan någon skriver kod

Du behöver inte designa arkitekturen. Du behöver se till att personen som gör det har tänkt på rätt saker. Här är den korta listan jag skulle vilja att en icke-teknisk grundare tar med till det första samtalet — skriv ut den, ställ den, observera hur självsäkert den besvaras.

1. 1
   Hur kommer ni att hålla tenants data åtskild?

   Du lyssnar efter ett strukturellt svar — systemet upprätthåller det — inte "vi ska vara försiktiga". Det här är den icke förhandlingsbara.
2. 2
   Vilken modell använder vi, och varför?

   Delade tabeller, separata fack eller databas-per-tenant. Det finns inget fel svar, men det bör finnas ett skäl som passar dina kunder och din budget.
3. 3
   Kan vi erbjuda dedikerad isolering till en stor kund senare?

   Även om du börjar helt delad bör designen lämna utrymme att ge en stor eller reglerad kund starkare separation utan en ombyggnad.
4. 4
   Vad händer när en kund blir enorm?

   Hur hindrar systemet en tung tenant från att sakta ner alla andra? Du vill höra att scenarier med stökiga grannar har övervägts.
5. 5
   Hur exporterar eller raderar vi en kunds data rent?

   Kunder lämnar, och integritetslagen kräver att du tar bort deras data på begäran. Det här bör vara en enkel, väl förstådd operation, inte en panik.

Du betygsätter inte den tekniska detaljen i svaren. Du kontrollerar att ingen av dessa frågor kommer som en överraskning. Ett team som har byggt multi-tenant-mjukvara förut har skarpa, nästan uttråkade svar på alla fem. Tvekan på den första eller tredje är signalen att sakta ner och gräva i.

Ett kort, verklighetsformat exempel

En grundare kom till oss med en fungerande prototyp för ett bokningsverktyg riktat mot små kliniker. Det hade redan tre betalande kunder — och ett tyst problem. För att snabbt komma ut på marknaden hade den första utvecklaren gett varje klinik sin egen separata kopia av appen. Tre kunder, tre installationer, tre lätt olika versioner, eftersom var och en hade bett om en liten justering längs vägen.

Det fungerade vackert vid tre. Grundarens mardröm var tanken på trettio. Varje buggfix innebar att logga in på tre ställen. Varje ny funktion innebar tre driftsättningar och tre saker att testa. En ny klinik tog större delen av en vecka att sätta upp för hand. Modellen som tog dem till lansering var nu det som satte tak för deras tillväxt — exakt det grundproblem som hela den här artikeln handlar om.

Vi rev inte ut allt i en dramatisk omskrivning. Vi byggde om kärnan på en delad multi-tenant-grund med isolering upprätthållen på systemnivå, behöll de klinikspecifika anpassningarna som konfigurerbara inställningar snarare än separata kodbaser, och migrerade de tre befintliga klinikerna en i taget, parallellt, så att ingen fick en skrämmande omställningsdag. Att introducera en ny klinik gick från en vecka av manuellt arbete till en självbetjäningsregistrering. Nya funktioner når nu varje kund från en enda release.

Siffrorna här är illustrativa, inte ett löfte — varje produkt är olik — men formen är typisk: ombyggnaden kostade riktiga pengar och ett par månader, och den betalade sig själv inom de första handfull nya kunder de plötsligt kunde introducera utan att lyfta ett finger. Lärdomen grundaren tog med sig var den billigare: om de hade ställt de fem frågorna i början hade det inte funnits något att bygga om.

Vanliga frågor