Monikäyttäjyys ilman jargonia: perustajan opas

Jossain vaiheessa ohjelmistotuotetta rakennettaessa kehittäjä sanoo sinulle sanan "monitenanttinen", katsoo ilmettäsi ja olettaa, että ymmärsit. Luultavasti nyökkäsit. Useimmat perustajat tekevät niin. Mutta tämä on yksi niistä varhaisista päätöksistä, jotka hiljaa määräävät katon sille, kuinka nopeasti voit kasvaa, kuinka edullisesti voit pyörittää toimintaa ja kuinka pahasti asiat voivat mennä pieleen, jos asiakas joskus näkee dataa, joka ei ole hänen. Se ansaitsee kymmenen minuuttia huomiotasi nyt, koska siihen on hyvin kallista palata myöhemmin.

Olen istunut monen ei-teknisen perustajan kanssa — ihmisten, joilla on terävä idea SaaS-tuotteesta eikä mitään erityistä kiinnostusta tietokantoihin. Hyvä uutinen on, ettei sinun tarvitse opetella ohjelmoimaan tehdäksesi tämän päätöksen hyvin. Tarvitset selkeän ajatusmallin ja lyhyen listan kysymyksiä. Juuri sitä tämä opas on. Ei muotisanoja, ei arkkitehtuurikaavioita, joita et koskaan enää katso, vain se, mitä kehittäjäsi toivoisi sinun ymmärtävän ennen ensimmäistä koodiriviä.

Jos otat tästä yhden ajatuksen mukaasi, olkoon se tämä: monikäyttäjyys ei ole ominaisuus, jonka lisäät myöhemmin. Se on perustus. Talon voi maalata uudelleen, mutta sen perustaa ei voi helposti vaihtaa, kun seinät on jo pystytetty.

Mitä "monitenanttinen" oikeasti tarkoittaa

Kuvittele kerrostalo. Jokaisella asukkaalla on oma asuntonsa — oma avain, omat huonekalut, oma ulko-ovi. Mutta he kaikki jakavat saman rakenteen: perustuksen, putkiston, katon, hissin. Isännöitsijä ylläpitää yhtä rakennusta, ei viittäkymmentä erillistä taloa, ja juuri se pitää vuokran kohtuullisena. Monitenanttinen ohjelmisto toimii täsmälleen näin. Yksi sovellus palvelee monia asiakkaita — "tenantteja" — ja jokainen kokee sen omana yksityisenä tilanaan, vaikka kaikki pyörivät saman jaetun järjestelmän päällä.

Vastakkainen lähestymistapa on yksitenanttinen: jokainen asiakas saa oman erillisen kopionsa ohjelmistosta, kuin rakentaisi jokaiselle aivan uuden omakotitalon. Yksityisempi, paremmin muokattavissa — ja dramaattisesti kalliimpi rakentaa, pyörittää ja päivittää, koska nyt ylläpidät viittäkymmentä taloa yhden rakennuksen sijaan.

Lähes jokainen päivittäin käyttämäsi tuote on monitenanttinen. Sähköpostisi, kirjanpito-ohjelmasi, varausjärjestelmäsi, CRM, jossa myyntitiimisi elää. Sinä ja tuhat muuta yritystä jaatte saman taustaohjelmiston, eikä kukaan teistä koskaan näe toisiaan. Tuo näkymättömyys — tuo siisti erottelu — on koko monikäyttäjyyden taito.

Miksi tämä päätös koskettaa koko liiketoimintaasi

On houkuttelevaa luokitella tämä "tekniseksi yksityiskohdaksi, jonka kehittäjäni hoitaa". Mutta valitsemasi malli heijastuu suoraan niihin liiketoiminnan osiin, joista todella välität: kuukausittaiseen hosting-laskuusi, kuinka nopeasti voit toimittaa uuden ominaisuuden kaikille, mitä voit luvata hermostuneelle yritysostajalle ja kuinka paljon vahinkoa yksi ainoa bugi voi aiheuttaa.

Kun korjaat bugin tai julkaiset ominaisuuden hyvin rakennetussa monitenanttisessa tuotteessa, jokainen asiakas saa sen kerralla, yhdellä päivityksellä. Yksitenanttisessa maailmassa jakaisit muutoksen viiteenkymmeneen erilliseen asennukseen, joista jokainen saattaa olla nyt hieman erilainen. Toinen on tiistai-iltapäivä. Toinen on projekti. Kerro tämä vuosien päivityksillä, niin näet, miksi SaaS-ala pyörii monikäyttäjyydellä.

Kääntöpuoli on, että infrastruktuurin jakaminen nostaa erottelun panoksia. Kerrostalossa putkivuoto voi vaikuttaa useampaan kuin yhteen asuntoon. Monitenanttisessa ohjelmistossa virhe tavassa, jolla pidät tenantit erillään, ei vain haittaa yhtä asiakasta — se voi paljastaa kaikkien datan kerralla. Tämä ei ole syy välttää monikäyttäjyyttä. Se on syy rakentaa se kunnolla, jonkun kanssa, joka on tehnyt sen ennenkin.

Kolme tapaa pitää tenantit erillään

Kun kehittäjät kiistelevät monikäyttäjyydestä, he yleensä kiistelevät siitä, kuinka erillistä kunkin tenantin datan tulisi olla. On kolme yleistä lähestymistapaa, ja ne asettuvat liukuvalle asteikolle "maksimaalinen jakaminen, alhaisin kustannus" -kohdasta "maksimaalinen erottelu, korkein kustannus" -kohtaan. Sinun ei tarvitse valita itse, mutta sinun tulisi ymmärtää kompromissi, jonka kehittäjäsi tekee puolestasi.

1. Jaettu tietokanta, jaetut taulut

Kaikkien data elää samassa tietokannassa, samoissa tauluissa, piilotetulla merkinnällä — "tenant-tunnuksella" — joka osoittaa, mitkä rivit kuuluvat kenelle. Ohjelmiston vastuulla on aina suodattaa tämän merkinnän mukaan, jotta asiakas A näkee vain asiakkaan A rivit. Tämä on edullisin ja parhaiten skaalautuva malli, jota useimmat varhaiset SaaS-tuotteet käyttävät. Koukku: erottelu elää koodissa, joten yksi unohtunut suodatin on tapa, jolla data vuotaa. Se vaatii huolellista, kurinalaista insinöörityötä.

2. Jaettu tietokanta, erilliset lokerot

Yksi tietokanta, mutta jokainen tenant saa oman muuratun osionsa sen sisällä (kehittäjät kutsuvat näitä "skeemoiksi"). Vahvempi erottelu kuin ensimmäisessä mallissa, yhä kohtuullisen tehokas, ja helpompi vaikkapa viedä tai poistaa yhden asiakkaan data siististi. Kompromissi on enemmän liikkuvia osia hallittavana, kun kasvat satoihin ja tuhansiin tenantteihin.

3. Erillinen tietokanta jokaiselle tenantille

Jokainen asiakas saa oman omistetun tietokantansa — lähimpänä yksityisen talon antamista hänelle samalla, kun yhä jaatte sovelluksen. Tämä on vahvin eristys ja helpoin tarina kerrottavaksi turvallisuustietoiselle yritysostajalle. Se on myös kallein pyörittää ja ylläpitää, joten se varataan yleensä arvokkaille asiakkaille, säännellyille toimialoille tai tuotteille, joissa datan sekoittuminen olisi katastrofaalista.

Osa, jota et voi tehdä väärin: eristys

Jos on yksi paikka, johon huolesi kannattaa käyttää, se on tässä. Tenanttien eristys on takuu siitä, että asiakas A ei koskaan, missään olosuhteissa, voi nähdä, muokata tai edes aistia asiakkaan B datan olemassaoloa. Se kuulostaa itsestäänselvältä. Se on myös yksittäinen yleisin vakavien bugien lähde monitenanttisissa tuotteissa, koska epäonnistuminen on hiljainen — kaikki näyttää hyvältä aina siihen päivään asti, jolloin joku avaa raportin ja näkee siinä vieraan asiakkaita.

Syy tähän on rakenteellinen. Edullisimmassa mallissa jokaisen yksittäisen tietokantapyynnön on muistettava suodattaa tenantin mukaan. Tee se oikein kymmenentuhatta kertaa ja väärin kerran, niin sinulla on vuoto. Siksi kokeneet tiimit eivät luota siihen, että kehittäjät muistavat — he rakentavat eristyksen perustukseen, jotta unohtamisesta tulee mahdotonta eikä vain epätodennäköistä. Sinun ei tarvitse ymmärtää, miten he tekevät sen. Sinun tarvitsee kysyä, tekevätkö he sen.

On myös tämän ongelman hiljaisempi serkku: "meluisa naapuri". Koska tenantit jakavat infrastruktuurin, yksi asiakas, joka tekee jotain raskasta — jättimäisen tuonnin, hallitsemattoman raportin — voi hidastaa järjestelmää kaikille muille, samalla tavalla kuin yksi asunto, jossa kaikki hanat ovat auki, voi pudottaa vedenpaineen koko rakennuksessa. Hyvä monitenanttinen suunnittelu varautuu tähän rajoituksilla ja reilulla jakamisella. Se kannattaa kysyä, varsinkin jos odotat muutamia hyvin suuria asiakkaita.

Milloin yksitenanttinen on oikeasti oikea valinta

Monikäyttäjyys on SaaS:n oletus, mutta se ei ole uskonto. On rehellisiä syitä antaa asiakkaalle oma erillinen kopionsa, ja hyvä neuvonantaja kertoo sinulle, kun olet osunut sellaiseen, sen sijaan että pakottaisi kaiken jaettuun malliin.

• Asiakas säännellyllä toimialalla — terveydenhuolto, rahoitus, julkishallinto — jonka vaatimustenmukaisuussäännöt käytännössä vaativat, että hänen datansa elää jossain todistettavasti erillään.
• Yksi suuri asiakas, joka maksaa tarpeeksi, jotta omistettu kokoonpano on sen arvoinen, ja joka haluaa syvää muokkausta, jonka et halua vuotavan kaikkien muiden kokemukseen.
• Data niin arkaluonteista, että tenanttien välisen vuodon hinta lopettaisi liiketoiminnan, mikä tekee maksimaalisesta eristyksestä lisäkustannuksen arvoisen.
• On-premise-vaatimus, jossa ohjelmiston on pyörittävä asiakkaan omien seinien sisällä eikä sinun pilvessäsi.

Huomaa kaava: yksitenanttinen on poikkeus, johon tartut harkiten, yleensä tietyn arvokkaan asiakkaan vuoksi, ei oletus, jonka päälle rakennat koko liiketoiminnan. Jos kehittäjä ehdottaa yksitenanttista vakiotuotteellesi ensimmäisestä päivästä, pyydä häntä käymään läpi miksi — se tarkoittaa yleensä paljon korkeampaa pyörityskustannusta ja hitaampia päivityksiä, ja haluat sen olevan valinta, ei vahinko.

Kysymykset, jotka kannattaa esittää ennen kuin kukaan kirjoittaa koodia

Sinun ei tarvitse suunnitella arkkitehtuuria. Sinun tarvitsee varmistaa, että sen suunnitteleva henkilö on ajatellut oikeita asioita. Tässä on lyhyt lista, jonka haluaisin ei-teknisen perustajan tuovan tuohon ensitapaamiseen — tulosta se, esitä se, tarkkaile kuinka itsevarmasti siihen vastataan.

1. 1
   Miten pidätte tenanttien datan erillään?

   Kuuntelet rakenteellista vastausta — järjestelmä pakottaa sen — etkä "olemme huolellisia". Tämä on se, josta ei tingitä.
2. 2
   Mitä mallia käytämme ja miksi?

   Jaetut taulut, erilliset lokerot vai tietokanta per tenant. Väärää vastausta ei ole, mutta syyn pitäisi sopia asiakkaisiisi ja budjettiisi.
3. 3
   Voimmeko tarjota omistetun eristyksen isolle asiakkaalle myöhemmin?

   Vaikka aloitatkin täysin jaettuna, suunnittelun pitäisi jättää tilaa antaa yhdelle suurelle tai säännellylle asiakkaalle vahvempi erottelu ilman uudelleenrakentamista.
4. 4
   Mitä tapahtuu, kun yksi asiakas kasvaa valtavaksi?

   Miten järjestelmä estää yhtä raskasta tenanttia hidastamasta kaikkia muita? Haluat kuulla, että meluisan naapurin skenaariot on otettu huomioon.
5. 5
   Miten viemme tai poistamme yhden asiakkaan datan siististi?

   Asiakkaat lähtevät, ja tietosuojalaki vaatii poistamaan heidän datansa pyynnöstä. Tämän pitäisi olla yksinkertainen, hyvin ymmärretty toimenpide, ei paniikki.

Et arvostele vastausten teknistä yksityiskohtaa. Tarkistat, ettei mikään näistä kysymyksistä tule yllätyksenä. Tiimi, joka on rakentanut monitenanttista ohjelmistoa aiemmin, antaa täsmälliset, lähes pitkästyneet vastaukset kaikkiin viiteen. Epäröinti ensimmäisessä tai kolmannessa on merkki hidastaa ja kaivautua syvemmälle.

Lyhyt, todenmukainen esimerkki

Perustaja tuli luoksemme toimivan prototyypin kanssa ajanvaraustyökalusta, joka oli suunnattu pienille klinikoille. Sillä oli jo kolme maksavaa asiakasta — ja hiljainen ongelma. Päästäkseen nopeasti markkinoille ensimmäinen kehittäjä oli antanut jokaiselle klinikalle oman erillisen kopionsa sovelluksesta. Kolme asiakasta, kolme asennusta, kolme hieman erilaista versiota, koska jokainen oli pyytänyt pientä muutosta matkan varrella.

Se toimi kauniisti kolmella. Perustajan painajainen oli ajatus kolmestakymmenestä. Jokainen bugikorjaus tarkoitti kirjautumista kolmeen paikkaan. Jokainen uusi ominaisuus tarkoitti kolmea käyttöönottoa ja kolmea testattavaa asiaa. Uuden klinikan pystyttäminen käsin vei lähes viikon. Malli, joka vei heidät lanseeraukseen, oli nyt se, joka kattoi heidän kasvunsa — juuri se perustusongelma, josta koko tämä artikkeli kertoo.

Emme repineet kaikkea irti dramaattisessa uudelleenkirjoituksessa. Rakensimme ytimen uudelleen jaetun monitenanttisen perustuksen päälle eristys järjestelmätasolla pakotettuna, pidimme klinikkakohtaiset mukautukset konfiguroitavina asetuksina erillisten koodikantojen sijaan ja migroimme kolme olemassa olevaa klinikkaa yksi kerrallaan, rinnakkain, jottei kenelläkään olisi pelottavaa vaihtopäivää. Uuden klinikan käyttöönotto muuttui viikon käsityöstä itsepalveluna tapahtuvaksi rekisteröitymiseksi. Uudet ominaisuudet tavoittavat nyt jokaisen asiakkaan yhdestä julkaisusta.

Tässä esitetyt luvut ovat havainnollistavia, eivät lupaus — jokainen tuote on erilainen — mutta muoto on tyypillinen: uudelleenrakentaminen maksoi oikeaa rahaa ja pari kuukautta, ja se maksoi itsensä takaisin ensimmäisten muutaman uuden asiakkaan myötä, jotka he yhtäkkiä saattoivat ottaa käyttöön sormeakaan nostamatta. Oppi, jonka perustaja sai, oli se edullisempi: jos he olisivat esittäneet ne viisi kysymystä alussa, ei olisi ollut mitään uudelleenrakennettavaa.

Yleisiä kysymyksiä