Multi-tenancy explicat fără jargon: ghidul fondatorului

La un moment dat în construirea unui produs software, un dezvoltator vă va spune cuvântul „multi-tenant”, vă va privi fața și va presupune că ați înțeles. Probabil ați dat din cap. Majoritatea fondatorilor o fac. Dar aceasta este una dintre acele decizii timpurii care stabilesc în tăcere plafonul pentru cât de repede puteți crește, cât de ieftin puteți funcționa și cât de rău pot merge lucrurile dacă un client ajunge vreodată să vadă date care nu îi aparțin. Merită zece minute din atenția dumneavoastră acum, pentru că este foarte costisitor de revizuit mai târziu.

Am stat față în față cu mulți fondatori non-tehnici — oameni cu o idee ascuțită pentru un produs SaaS și fără vreun interes deosebit pentru baze de date. Vestea bună este că nu trebuie să învățați să programați pentru a lua bine această decizie. Aveți nevoie de un model mental clar și de o listă scurtă de întrebări. Exact asta este acest ghid. Fără cuvinte la modă, fără diagrame de arhitectură la care nu vă veți mai uita niciodată, doar lucrul pe care dezvoltatorul și-ar dori să-l înțelegeți înainte de prima linie de cod.

Dacă rețineți o singură idee, fie aceasta: multi-tenancy nu este o funcție pe care o adăugați mai târziu. Este o fundație. Puteți rezugrăvi o casă, dar nu puteți schimba ușor pe ce stă odată ce zidurile sunt ridicate.

Ce înseamnă cu adevărat „multi-tenant”

Imaginați-vă un bloc de apartamente. Fiecare locatar are propriul apartament — propria cheie, propriul mobilier, propria ușă. Dar toți împart aceeași structură: fundația, instalațiile sanitare, acoperișul, liftul. Proprietarul întreține o singură clădire, nu cincizeci de case separate, iar asta face chiria accesibilă. Software-ul multi-tenant funcționează exact așa. O singură aplicație deservește mulți clienți — „tenanți” — și fiecare o trăiește ca pe propriul spațiu privat, deși toți rulează pe același sistem partajat de dedesubt.

Abordarea opusă este single-tenant: fiecare client primește propria copie separată a software-ului, ca și cum ați construi o casă nouă, separată, pentru fiecare. Mai privat, mai personalizabil — și dramatic mai scump de construit, de rulat și de actualizat, pentru că acum întrețineți cincizeci de case în loc de o singură clădire.

Aproape fiecare produs pe care îl folosiți zilnic este multi-tenant. E-mailul, instrumentul de contabilitate, sistemul de rezervări, CRM-ul în care trăiește echipa de vânzări. Dumneavoastră și alte o mie de companii împărțiți același software de bază și niciunul nu îl vede vreodată pe celălalt. Această invizibilitate — această separare curată — este toată arta multi-tenancy-ului.

De ce această decizie atinge întreaga afacere

Este tentant să clasați asta la „detaliu tehnic de care se ocupă dezvoltatorul meu”. Dar modelul pe care îl alegeți se propagă direct în părțile afacerii de care vă pasă cu adevărat: factura lunară de găzduire, cât de repede puteți livra o funcție nouă tuturor, ce îi puteți promite unui cumpărător corporativ neliniștit și câtă pagubă poate face o singură eroare.

Când reparați o eroare sau lansați o funcție într-un produs multi-tenant bine construit, fiecare client o primește deodată, dintr-o singură actualizare. Într-o lume single-tenant, ați derula acea schimbare către cincizeci de instalări separate, fiecare poate ușor diferită până acum. Una este o după-amiază de marți. Cealaltă este un proiect. Înmulțiți asta cu ani de actualizări și veți vedea de ce industria SaaS se sprijină pe multi-tenancy.

Reversul medaliei este că partajarea infrastructurii ridică miza pe separare. Într-un bloc, o defecțiune la instalații poate afecta mai mult de un apartament. În software-ul multi-tenant, o greșeală în modul în care țineți tenanții despărțiți nu doar incomodează un client — poate expune datele tuturor deodată. Acesta nu este un motiv să evitați multi-tenancy. Este motivul să-l construiți cum trebuie, cu cineva care a mai făcut-o.

Cele trei moduri de a ține tenanții despărțiți

Când dezvoltatorii se ceartă despre multi-tenancy, de obicei se ceartă despre cât de separate ar trebui să fie datele fiecărui tenant. Există trei abordări comune, iar ele stau pe o scară glisantă, de la „partajare maximă, cost minim” la „separare maximă, cost maxim”. Nu trebuie să alegeți una singur — dar ar trebui să înțelegeți compromisul pe care dezvoltatorul îl face în numele dumneavoastră.

1. Bază de date partajată, tabele partajate

Datele tuturor trăiesc în aceeași bază de date, în aceleași tabele, cu o etichetă ascunsă — un „tenant ID” — care marchează ce rânduri aparțin cui. Software-ul este responsabil să filtreze mereu după acea etichetă, astfel încât clientul A să vadă doar rândurile lui A. Acesta este modelul cel mai ieftin și cel mai scalabil, cel folosit de majoritatea produselor SaaS la început. Capcana: separarea trăiește în cod, deci un singur filtru omis este modul în care se scurg datele. Cere inginerie atentă și disciplinată.

2. Bază de date partajată, compartimente separate

O singură bază de date, dar fiecare tenant primește propria secțiune îngrădită în interiorul ei (dezvoltatorii le numesc „scheme”). Separare mai puternică decât primul model, încă rezonabil de eficientă și mai ușor de, să zicem, exportat sau șters datele unui client în mod curat. Compromisul: mai multe piese mobile de gestionat pe măsură ce creșteți spre sute și mii de tenanți.

3. O bază de date separată per tenant

Fiecare client primește propria bază de date dedicată — lucrul cel mai apropiat de a-i da o casă privată, păstrând totodată aplicația partajată. Aceasta este cea mai puternică izolare și cea mai ușoară poveste de spus unui cumpărător corporativ preocupat de securitate. Este și cea mai scumpă de rulat și de operat, așa că tinde să fie rezervată clienților de mare valoare, industriilor reglementate sau produselor în care o încurcătură de date ar fi catastrofală.

Partea pe care nu o puteți greși: izolarea

Dacă există un singur loc unde să vă cheltuiți grija, aici este. Izolarea tenantului este garanția că clientul A nu poate niciodată, sub nicio circumstanță, să vadă, să modifice sau măcar să simtă existența datelor clientului B. Sună evident. Este totodată cea mai frecventă sursă unică de erori grave în produsele multi-tenant, pentru că eșecul este tăcut — totul arată bine până în ziua în care cineva deschide un raport și vede în el clienții unui străin.

Motivul pentru care se întâmplă este structural. În modelul cel mai ieftin, fiecare cerere către baza de date trebuie să-și amintească să filtreze după tenant. Faceți-o corect de zece mii de ori și greșit o dată și aveți o scurgere. De aceea echipele cu experiență nu se bazează pe faptul că dezvoltatorii își amintesc — construiesc izolarea în fundație, astfel încât uitarea devine imposibilă, nu doar improbabilă. Nu trebuie să înțelegeți cum o fac. Trebuie să întrebați dacă o fac.

Mai există și o rudă mai discretă a acestei probleme: „vecinul gălăgios”. Pentru că tenanții împart infrastructura, un client care face ceva greu — un import uriaș, un raport scăpat de sub control — poate încetini sistemul pentru toți ceilalți, la fel cum un apartament cu toate robinetele deschise poate scădea presiunea apei în toată clădirea. Designul multi-tenant bun planifică asta cu limite și partajare echitabilă. Merită întrebat, mai ales dacă vă așteptați la câțiva clienți foarte mari.

Când single-tenant este de fapt alegerea corectă

Multi-tenancy este implicit pentru SaaS, dar nu este o religie. Există motive oneste să-i dați unui client propria copie separată, iar un consultant bun vă va spune când ați nimerit unul, în loc să forțeze totul în modelul partajat.

• Un client dintr-o industrie reglementată — sănătate, finanțe, administrație — ale cărui reguli de conformitate cer efectiv ca datele lui să stea undeva demonstrabil separat.
• Un singur client mare care plătește suficient cât să merite o configurare dedicată și care vrea o personalizare profundă pe care nu o vreți scursă în experiența tuturor.
• Date atât de sensibile încât costul unei scurgeri între tenanți ar pune capăt afacerii, ceea ce face izolarea maximă să merite cheltuiala suplimentară.
• O cerință on-premise, în care software-ul trebuie să ruleze în interiorul zidurilor proprii ale clientului, nu în cloud-ul dumneavoastră.

Observați tiparul: single-tenant este excepția la care recurgeți deliberat, de obicei pentru un client anume de mare valoare, nu valoarea implicită pe care construiți toată afacerea. Dacă un dezvoltator propune single-tenant pentru produsul dumneavoastră standard din prima zi, cereți-i să vă explice de ce — de obicei înseamnă un cost de rulare mult mai mare și actualizări mai lente, iar dumneavoastră vreți ca asta să fie o alegere, nu un accident.

Întrebările de pus înainte ca cineva să scrie cod

Nu trebuie să proiectați arhitectura. Trebuie să vă asigurați că persoana care o face s-a gândit la lucrurile potrivite. Iată lista scurtă pe care aș vrea ca un fondator non-tehnic să o aducă la acea primă discuție — tipăriți-o, puneți întrebările și urmăriți cu câtă siguranță vi se răspunde.

1. 1
   Cum veți ține datele tenanților separate?

   Ascultați după un răspuns structural — sistemul îl impune — nu „vom fi atenți”. Aceasta este cea de nenegociat.
2. 2
   Ce model folosim și de ce?

   Tabele partajate, compartimente separate sau bază de date per tenant. Nu există răspuns greșit, dar ar trebui să existe un motiv care se potrivește clienților și bugetului dumneavoastră.
3. 3
   Putem oferi izolare dedicată unui client mare mai târziu?

   Chiar dacă începeți complet partajat, designul ar trebui să lase loc pentru a-i da unui client mare sau reglementat o separare mai puternică fără o reconstrucție.
4. 4
   Ce se întâmplă când un client devine uriaș?

   Cum împiedică sistemul un tenant greu să încetinească pe toți ceilalți? Vreți să auziți că scenariile cu vecinul gălăgios au fost luate în calcul.
5. 5
   Cum exportăm sau ștergem curat datele unui client?

   Clienții pleacă, iar legea privind confidențialitatea cere să le eliminați datele la cerere. Aceasta ar trebui să fie o operațiune simplă, bine înțeleasă, nu o panică.

Nu notați detaliul tehnic al răspunsurilor. Verificați ca niciuna dintre aceste întrebări să nu cadă ca o surpriză. O echipă care a mai construit software multi-tenant va avea răspunsuri clare, aproape plictisite, la toate cinci. Ezitarea la prima sau a treia este semnalul să încetiniți și să săpați mai adânc.

Un exemplu scurt, cu formă reală

Un fondator a venit la noi cu un prototip funcțional pentru un instrument de programări destinat clinicilor mici. Avea deja trei clienți plătitori — și o problemă tăcută. Ca să ajungă rapid pe piață, primul dezvoltator dăduse fiecărei clinici propria copie separată a aplicației. Trei clienți, trei instalări, trei versiuni ușor diferite, pentru că fiecare ceruse câte o mică modificare pe parcurs.

Funcționa minunat la trei. Coșmarul fondatorului era gândul la treizeci. Fiecare reparare de eroare însemna autentificare în trei locuri. Fiecare funcție nouă însemna trei implementări și trei lucruri de testat. O clinică nouă lua aproape o săptămână de configurat manual. Modelul care îi adusese la lansare era acum lucrul care le plafona creșterea — exact problema fundației despre care vorbește tot acest articol.

Nu am smuls totul într-o rescriere dramatică. Am reconstruit nucleul pe o fundație multi-tenant partajată, cu izolarea impusă la nivel de sistem, am păstrat personalizările per clinică drept setări configurabile în loc de coduri-sursă separate și am migrat cele trei clinici existente una câte una, în paralel, ca nimeni să nu aibă o zi înfricoșătoare de comutare. Integrarea unei clinici noi a trecut de la o săptămână de muncă manuală la o înscriere autoservire. Funcțiile noi ajung acum la fiecare client dintr-o singură lansare.

Cifrele de aici sunt ilustrative, nu o promisiune — fiecare produs este diferit — dar forma este tipică: reconstrucția a costat bani reali și câteva luni și s-a amortizat în primii câțiva clienți noi pe care îi puteau dintr-odată integra fără să ridice un deget. Lecția pe care fondatorul a luat-o cu el a fost cea mai ieftină: dacă ar fi pus cele cinci întrebări de la început, nu ar fi avut nimic de reconstruit.

Întrebări frecvente