Multi-tenancy forklart uten sjargong: en guide for gründere

På et tidspunkt mens du bygger et programvareprodukt, vil en utvikler si ordet "multi-tenant" til deg, studere ansiktet ditt og anta at du forsto. Du nikket sannsynligvis. Det gjør de fleste gründere. Men dette er en av de tidlige beslutningene som stille setter taket for hvor raskt du kan vokse, hvor billig du kan drive og hvor galt det kan gå hvis en kunde noen gang ser data som ikke er deres. Det fortjener ti minutter av oppmerksomheten din nå, for det er svært dyrt å gå tilbake til senere.

Jeg har sittet overfor mange ikke-tekniske gründere — folk med en skarp idé for et SaaS-produkt og ingen særlig interesse for databaser. Den gode nyheten er at du ikke trenger å lære å kode for å ta denne beslutningen godt. Du trenger en klar mental modell og en kort liste med spørsmål. Det er det denne guiden er. Ingen moteord, ingen arkitekturdiagrammer du aldri ser på igjen, bare det utvikleren din skulle ønske du forsto før den første linjen med kode.

Hvis du tar med deg én idé herfra, la det være denne: multi-tenancy er ikke en funksjon du legger til senere. Det er et fundament. Du kan male om et hus, men du kan ikke enkelt endre hva det står på når veggene først er reist.

Hva "multi-tenant" faktisk betyr

Se for deg en boligblokk. Hver beboer har sin egen leilighet — sin egen nøkkel, sine egne møbler, sin egen inngangsdør. Men de deler alle den samme strukturen: fundamentet, rørene, taket, heisen. Utleieren vedlikeholder én bygning, ikke femti separate hus, og det er det som gjør husleien overkommelig. Multi-tenant-programvare fungerer akkurat slik. Én applikasjon betjener mange kunder — "tenants" — og hver enkelt opplever den som sitt eget private rom, selv om de alle kjører på det samme delte systemet under.

Den motsatte tilnærmingen er single-tenant: hver kunde får sin egen separate kopi av programvaren, som å bygge et helt nytt frittstående hus til hver enkelt. Mer privat, mer tilpassbart — og dramatisk dyrere å bygge, drifte og oppdatere, for nå vedlikeholder du femti hus i stedet for én bygning.

Nesten alle produktene du bruker til daglig, er multi-tenant. E-posten din, regnskapsverktøyet ditt, bookingsystemet ditt, CRM-et salgsteamet ditt lever i. Du og tusen andre selskaper deler den samme underliggende programvaren, og ingen av dere ser noen gang de andre. Den usynligheten — den rene atskillelsen — er hele kunsten i multi-tenancy.

Hvorfor denne beslutningen berører hele virksomheten din

Det er fristende å plassere dette i båsen "teknisk detalj som utvikleren min håndterer". Men modellen du velger, brer seg rett inn i de delene av virksomheten du faktisk bryr deg om: den månedlige hostingregningen din, hvor raskt du kan levere en ny funksjon til alle, hva du kan love en nervøs bedriftskunde, og hvor mye skade en enkelt feil kan gjøre.

Når du fikser en feil eller slipper en funksjon i et godt bygd multi-tenant-produkt, får hver kunde den på én gang, fra én enkelt oppdatering. I en single-tenant-verden ville du rulle ut den endringen til femti separate installasjoner, som hver kan være litt forskjellige nå. Det ene er en tirsdag ettermiddag. Det andre er et prosjekt. Gang det med år med oppdateringer, og du ser hvorfor SaaS-bransjen går på multi-tenancy.

Baksiden er at deling av infrastruktur hever innsatsen på atskillelsen. I en boligblokk kan en rørlekkasje ramme mer enn én leilighet. I multi-tenant-programvare er en feil i hvordan du holder tenants atskilt ikke bare til bry for én kunde — den kan eksponere alles data på én gang. Dette er ikke en grunn til å unngå multi-tenancy. Det er grunnen til å bygge det skikkelig, med noen som har gjort det før.

De tre måtene å holde tenants atskilt på

Når utviklere krangler om multi-tenancy, krangler de som regel om hvor atskilt hver tenants data skal være. Det finnes tre vanlige tilnærminger, og de ligger på en glidende skala fra "maksimal deling, lavest kostnad" til "maksimal atskillelse, høyest kostnad". Du trenger ikke velge en selv — men du bør forstå avveiningen utvikleren din gjør på dine vegne.

1. Delt database, delte tabeller

Alles data lever i den samme databasen, i de samme tabellene, med en skjult merkelapp — en "tenant-ID" — som markerer hvilke rader som tilhører hvem. Programvaren har ansvaret for alltid å filtrere etter den merkelappen, slik at kunde A bare noen gang ser kunde A sine rader. Dette er den billigste og mest skalerbare modellen, den de fleste tidlige SaaS-produkter bruker. Haken: atskillelsen lever i koden, så ett enkelt oversett filter er hvordan data lekker. Det krever nøye, disiplinert ingeniørarbeid.

2. Delt database, separate rom

Én database, men hver tenant får sin egen avskjermede seksjon inni den (utviklere kaller disse "skjemaer"). Sterkere atskillelse enn den første modellen, fortsatt rimelig effektiv, og enklere å for eksempel eksportere eller slette én kundes data rent. Avveiningen er flere bevegelige deler å håndtere etter hvert som du vokser til hundrevis og tusenvis av tenants.

3. En separat database per tenant

Hver kunde får sin egen dedikerte database — det nærmeste du kommer å gi dem et privat hus mens du fortsatt deler applikasjonen. Dette er den sterkeste isoleringen og den enkleste historien å fortelle en sikkerhetsbevisst bedriftskunde. Det er også det dyreste å drifte og betjene, så det pleier å være forbeholdt kunder av høy verdi, regulerte bransjer eller produkter der en datasammenblanding ville vært katastrofal.

Delen du ikke kan gjøre feil: isolering

Hvis det er ett sted å bruke bekymringen din, er det her. Tenant-isolering er garantien for at kunde A aldri, under noen omstendigheter, kan se, redigere eller engang ane eksistensen av kunde B sine data. Det høres opplagt ut. Det er også den enkeltstående vanligste kilden til alvorlige feil i multi-tenant-produkter, fordi svikten er taus — alt ser fint ut helt frem til den dagen noen åpner en rapport og ser en fremmeds kunder i den.

Grunnen til at dette skjer, er strukturell. I den billigste modellen må hver eneste databaseforespørsel huske å filtrere etter tenant. Få det riktig ti tusen ganger og feil én gang, og du har en lekkasje. Derfor stoler erfarne team ikke på at utviklere husker — de bygger isoleringen inn i fundamentet, slik at det å glemme blir umulig snarere enn bare usannsynlig. Du trenger ikke forstå hvordan de gjør det. Du må spørre om de gjør det.

Det finnes også en stillere fetter av dette problemet: den "støyende naboen". Fordi tenants deler infrastruktur, kan én kunde som gjør noe tungt — en kjempeimport, en løpsk rapport — gjøre systemet tregt for alle andre, på samme måte som én leilighet med alle kraner i gang kan senke vanntrykket i hele bygningen. God multi-tenant-design planlegger for dette med grenser og rettferdig deling. Det er verdt å spørre om, særlig hvis du forventer noen få svært store kunder.

Når single-tenant faktisk er det riktige valget

Multi-tenancy er standarden for SaaS, men det er ikke en religion. Det finnes ærlige grunner til å gi en kunde sin egen separate kopi, og en god rådgiver forteller deg når du har truffet en slik, i stedet for å tvinge alt inn i den delte modellen.

• En kunde i en regulert bransje — helse, finans, offentlig sektor — hvis etterlevelsesregler i praksis krever at dataene deres lever et sted som påviselig er atskilt.
• En enkelt stor kunde som betaler nok til at et dedikert oppsett er verdt det, og som vil ha dyp tilpasning du ikke vil skal lekke inn i alle andres opplevelse.
• Data så sensitive at kostnaden ved en lekkasje på tvers av tenants ville avsluttet virksomheten, noe som gjør maksimal isolering verdt den ekstra utgiften.
• Et on-premise-krav, der programvaren må kjøre innenfor kundens egne vegger snarere enn i din sky.

Legg merke til mønsteret: single-tenant er unntaket du bevisst griper til, som regel for en bestemt kunde av høy verdi, ikke standarden du bygger hele virksomheten på. Hvis en utvikler foreslår single-tenant for standardproduktet ditt fra dag én, be dem gå gjennom hvorfor — det betyr som regel en mye høyere driftskostnad og tregere oppdateringer, og du vil at det skal være et valg, ikke et uhell.

Spørsmålene du bør stille før noen skriver kode

Du trenger ikke designe arkitekturen. Du må sørge for at personen som gjør det, har tenkt på de riktige tingene. Her er den korte listen jeg skulle ønske en ikke-teknisk gründer tok med til den første samtalen — skriv den ut, still den, og følg med på hvor selvsikkert den blir besvart.

1. 1
   Hvordan skal dere holde tenants data atskilt?

   Du lytter etter et strukturelt svar — systemet håndhever det — ikke "vi skal være forsiktige". Dette er den ikke-forhandlingsbare.
2. 2
   Hvilken modell bruker vi, og hvorfor?

   Delte tabeller, separate rom eller database-per-tenant. Det finnes ikke noe galt svar, men det bør finnes en grunn som passer kundene og budsjettet ditt.
3. 3
   Kan vi tilby dedikert isolering til en stor kunde senere?

   Selv om du starter helt delt, bør designet la det være rom til å gi én stor eller regulert kunde sterkere atskillelse uten en ombygging.
4. 4
   Hva skjer når én kunde blir enorm?

   Hvordan hindrer systemet en tung tenant i å gjøre alle andre trege? Du vil høre at scenarier med støyende naboer er blitt vurdert.
5. 5
   Hvordan eksporterer eller sletter vi én kundes data rent?

   Kunder forlater, og personvernloven krever at du fjerner dataene deres på forespørsel. Dette bør være en enkel, velforstått operasjon, ikke en panikk.

Du karaktersetter ikke den tekniske detaljen i svarene. Du sjekker at ingen av disse spørsmålene lander som en overraskelse. Et team som har bygd multi-tenant-programvare før, har skarpe, nesten lei seg svar på alle fem. Nøling på det første eller tredje er signalet om å roe ned og grave i det.

Et kort, virkelighetsnært eksempel

En gründer kom til oss med en fungerende prototype av et planleggingsverktøy rettet mot små klinikker. Det hadde allerede tre betalende kunder — og et stille problem. For å komme raskt på markedet hadde den første utvikleren gitt hver klinikk sin egen separate kopi av appen. Tre kunder, tre installasjoner, tre litt forskjellige versjoner, fordi hver hadde bedt om en liten justering underveis.

Det fungerte vakkert ved tre. Gründerens mareritt var tanken på tretti. Hver feilretting betydde å logge inn tre steder. Hver ny funksjon betydde tre utrullinger og tre ting å teste. En ny klinikk tok mesteparten av en uke å sette opp for hånd. Modellen som tok dem til lansering, var nå det som satte tak på veksten deres — akkurat det fundamentproblemet hele denne artikkelen handler om.

Vi rev ikke ut alt i en dramatisk omskriving. Vi bygde kjernen om på et delt multi-tenant-fundament med isolering håndhevet på systemnivå, beholdt de klinikkspesifikke tilpasningene som konfigurerbare innstillinger snarere enn separate kodebaser, og migrerte de tre eksisterende klinikkene én om gangen, parallelt, slik at ingen fikk en skummel omleggingsdag. Å onboarde en ny klinikk gikk fra en uke med manuelt arbeid til en selvbetjent registrering. Nye funksjoner når nå hver kunde fra én enkelt utgivelse.

Tallene her er illustrerende, ikke et løfte — hvert produkt er forskjellig — men formen er typisk: ombyggingen kostet ekte penger og et par måneder, og den betalte seg selv innen de første håndfullene av nye kunder de plutselig kunne onboarde uten å løfte en finger. Lærdommen gründeren tok med seg, var den billigere: hvis de hadde stilt de fem spørsmålene i starten, hadde det ikke vært noe å bygge om.

Vanlige spørsmål