Separare
Granița pe care o păstrează baza de date, nu codul
Fiecare CRM pretinde că este multi-tenant. Pretenderea este ieftină; ceea ce contează este care strat susține linia. Dacă răspunsul este „aplicația noastră adaugă întotdeauna filtrul corect”, atunci garanția este doar la fel de bună ca cel mai puțin odihnit dezvoltator care a scris vreodată o interogare.
iKonekt a fost multi-tenant încă de la prima sa migrare, nu adaptat ulterior, ceea ce sună a laudă și este de fapt o mărturisire: adaptarea ulterioară este aproape imposibil de făcut convingător, iar toți cei care au încercat au o poveste.
Separarea trăiește în baza de date. Fiecare dintre cele douăzeci și șase de tabele poartă tenantul căruia îi aparține, iar politica care verifică acest lucru rulează la fiecare citire și la fiecare scriere, complet sub aplicație. O interogare care uită granița nu returnează clienții altuia. Nu returnează nimic.
Securitate la nivel de rând, forțată
Nu o convenție, nu o regulă de code review. Baza de date refuză. Șaptezeci și două de politici, scrise una câte una, nu generate — pentru că o politică generată este o politică pe care nimeni nu a citit-o.
Chei compuse
O înregistrare copil face referire la tenantul său și la părintele său împreună, ca pereche. Un identificator rătăcit de la compania greșită nu se rezolvă — pur și simplu nu este o referință validă.
Niciun tenant implicit, niciodată
O cerere fără scop nu devine discret o cerere pentru tenantul zero. Aruncă o eroare înainte să ajungă la baza de date. Nu există un mod „unscoped” pe care să uitați să-l dezactivați.
Eroarea care nu și-a putea anunța prezența
În timp ce se lucra la partea de multi-tenant, majoritatea greșelilor au fost zgomotoase. Dați două companii cu același domeniu de client și baza de date obiectează imediat, cu un cod de eroare și o urmă de stivă; o reparați înainte de prânz.
Una nu a obiectat. O tabelă de suprascrieri editabile de prompturi era cheiată doar după tipul promptului — nu după tip și tenant. O a doua companie care își edita propria copie ar fi suprascris discret copia primei companii, prin SQL perfect valid, fără eroare, fără avertisment și fără niciun test care să eșueze. A fost descoperită citind fiecare index unic rămas după schimbarea unei chei, unul câte unul, din suspiciunea că cele zgomotoase au avut companie.
O menționăm pentru că este forma onestă a acestei munci. Separarea nu este o funcționalitate pe care o activați; este un obicei de a citi părțile plictisitoare ale schemei, presupunând că ceva de acolo nu vă este de acord.
Testele, pentru record: 942 la număr, rulate pe o bază de date reconstruită de la zero la fiecare modificare. Nu sunt acolo pentru a dovedi că designul este ingenios. Sunt acolo pentru că modul de eșec al acestui design anume este tăcut, iar eșecurile tăcute au nevoie de cineva care să strige în numele lor.
Ce îi aduce separarea unei persoane obișnuite
- Un grup poate gestiona mai multe companii dintr-o singură instalare, iar un vânzător dintr-una nu va vedea niciodată un client al alteia — nu prin politică, prin construcție.
- Un program de parteneri, un set de prompturi, o revendicare asupra unui client: totul delimitat per companie, astfel încât configurația unui tenant să nu poată deveni a tuturor.
- O cerere de ștergere este onorată în interiorul unei granițe, nu într-o grămadă partajată, iar acest lucru face posibil răspunsul onest.
- Și nimeni nu trebuie să-și amintească nimic din toate acestea. Acesta este scopul — o garanție care depinde de a fi amintită nu este o garanție.
Încă un rând care nu este despre baze de date
Fiecare serviciu frate din familie își păstrează propria acreditare denumită. Nimic nu vorbește cu una partajată, deci niciun serviciu nu poate acționa accidental ca altul — o mică disciplină născută direct din faptul că am avut cândva un token partajat și nu ne-a plăcut.
Este același instinct ca regula bazei de date. Faceți lucrul greșit imposibil, nu doar descurajat, și vă veți petrece atenția pe clienți în loc de pe vigilență.
- 126 de tabeleFiecare își poartă tenantul, cu verificarea forțată activă.
- 272 de politiciScrise individual, astfel încât fiecare a fost citită de o persoană.
- 3942 de testeÎmpotriva unei baze de date reconstruite de la zero, la fiecare modificare.
- 40 entități impliciteO cerere fără un scope nu ajunge niciodată la date.
Măsurat pe versiunea live
„Aplicația noastră filtrează întotdeauna după firmă.”
În propoziția aceea, „întotdeauna” face multă muncă.
Mutați granița în jos, în baza de date, și o clauză WHERE uitată nu returnează nimic în loc să returneze clienții altcuiva. Un ecran gol este un eșec mai bun decât o prezentare stânjenitoare.
Pentru grupurile care administrează mai multe mărci →