Arkitektura multi-tenant për SaaS: si ta zgjedhësh modelin e duhur para se ta ndërtosh MVP-në

Nëse po ndërton një produkt SaaS për më shumë se një klient, një vendim i marrë në javët e para do të ndikojë në kostot, sigurinë dhe aftësinë tënde për t’u zgjeruar për vite me radhë: si i ndan të dhënat e një klienti nga ato të tjetrit. Ky është vendimi për arkitekturën multi-tenant të SaaS, dhe është shumë më e lirë ta marrësh me vetëdije sesa ta rregullosh pasi të kesh njëzet klientët e parë.

Ky udhëzues është për themelues, pronarë produktesh dhe drejtues teknikë që planifikojnë një MVP SaaS. Shpjegon tre modelet kryesore, kompromiset që kanë rëndësi vërtet dhe një zgjedhje fillestare të arsyeshme. Një arkitekturë multi-tenant e mirë nuk ka të bëjë me teknologji të ndërlikuar, por me zgjedhjen e nivelit të duhur të izolimit për klientët e tu.

Çfarë do të thotë “multi-tenant”

Një tenant është një organizatë klient që përdor produktin tënd: një klinikë, një kompani logjistike, një grup restorantesh. Në një sistem multi-tenant, shumë tenantë ndajnë të njëjtin aplikacion që po funksionon. Në një sistem single-tenant, çdo tenant ka kopjen e vet të aplikacionit, databazën e vet, ose të dyja.

Shumica e produkteve SaaS qëndrojnë diku mes këtyre skajeve. Pyetja e dobishme nuk është “multi-tenant apo jo?”, por “cilat shtresa i ndajmë dhe cilat i izolojmë?”. Shtresat e zakonshme janë serverat e aplikacionit, databaza dhe ruajtja e skedarëve.

Tre modelet e arkitekturës multi-tenant

Ofruesit e cloud-it si AWS i përshkruajnë si modelet silo, pool dhe bridge. Ja si duken në praktikë.

1. Databazë e përbashkët, skemë e përbashkët (pool)

Të gjithë tenantët jetojnë në të njëjtat tabela dhe çdo rresht ka një tenant_id. Aplikacioni filtron me të në çdo kërkesë.

• Të mirat: më e lira për t’u mbajtur, më e thjeshta për publikim, një migrim përditëson të gjithë, analitikë e lehtë mes tenantëve për ekipin tënd.
• Të këqijat: një filtër i harruar mund të nxjerrë të dhëna nga një klient te tjetri; një tenant i rëndë mund t’i ngadalësojë të gjithë (problemi i “fqinjit zhurmëmadh”); kopja rezervë dhe rikthimi për një tenant të vetëm janë të vështira.

2. Databazë e përbashkët, skemë e veçantë për tenant (bridge)

Çdo tenant merr skemën e vet brenda një databaze. Izolimi është më i fortë se me skemë të përbashkët, por migrimet duhet të ekzekutohen një herë për secilin tenant, dhe kjo bëhet e ngadaltë dhe e rrezikshme kur ke qindra tenantë.

3. Databazë ose instalim i veçantë për tenant (silo)

Çdo tenant ka databazën e vet, dhe nganjëherë edhe instancën e vet të aplikacionit.

• Të mirat: izolimi më i fortë, kopje rezervë e thjeshtë për tenant, e lehtë të premtosh vendndodhjen e të dhënave, një tenant i rëndë nuk i dëmton të tjerët. Klientët e mëdhenj shpesh e kërkojnë këtë.
• Të këqijat: kostoja më e lartë e infrastrukturës, regjistrim më i ngadaltë nëse krijimi nuk automatizohet, dhe çdo version duhet shpërndarë në shumë mjedise.

Krahasimi me një shikim

Si të zgjedhësh: pesë pyetje për t’u përgjigjur fillimisht

1. Kush është klienti yt? Qindra biznese të vogla të çojnë te skema e përbashkët. Pak banka, spitale apo institucione publike të çojnë te databaza të izoluara.
2. Çfarë detyrimesh ligjore dhe vendndodhjeje të dhënash ke? Nëse një kontratë mund të kërkojë që të dhënat e klientit të qëndrojnë në një rajon të caktuar, planifikoje që tani. Rregullorja e BE-së (GDPR) e bën të rëndësishme të dish saktësisht ku ndodhen të dhënat personale të çdo tenanti dhe si fshihen.
3. Sa e pabarabartë do të jetë përdorimi? Nëse një tenant mund të jetë pesëdhjetë herë më i madh se mesatarja, të duhet një rrugë për ta kaluar në burime të veta.
4. Si do të faturosh? Planet për përdorues, sipas përdorimit apo me çmim fiks kërkojnë matje për çdo tenant. Ndërtoje këtë që nga dita e parë.
5. Sa kapacitet operativ ke? Modelet silo janë të fuqishme, por kërkojnë automatizim. Një ekip i vogël pa të do të mbytet në mjedise.

Arkitektura multi-tenant e arsyeshme për shumicën e MVP-ve

Për shumicën e produkteve B2B në fazë fillestare, pika e duhur e nisjes është një databazë e përbashkët me skemë të përbashkët, së bashku me mbrojtje që e bëjnë të vështirë gabimin e “filtrit të harruar”:

• Zbatoje izolimin në databazë, jo vetëm në kod. Row-level security i PostgreSQL e lejon vetë databazën të refuzojë rreshtat e një tenanti tjetër, edhe nëse kodi harron një filtër.
• Bëje kontekstin e tenantit të detyrueshëm. Identifikoje tenantin një herë për çdo kërkesë (nga nënfaqja, tokeni ose sesioni) dhe kalo e në një shtresë të vetme të testuar, në vend që të mbështetesh te çdo zhvillues që ta mbajë mend.
• Testo për rrjedhje. Shto teste automatike që hyjnë si tenanti A dhe provojnë të lexojnë të dhënat e tenantit B në çdo endpoint.
• Mbaj një rrugë dalje. Dizajno identifikuesit dhe shtigjet e ruajtjes që një tenant të mund të kalohet më vonë në databazën e vet pa rishkruar produktin.

Kjo qasje “fillo me pool, kalo në silo kur duhet” e mban MVP-në të lirë dhe lë hapësirë për t’u ofruar klientëve të mëdhenj një nivel të izoluar më vonë, shpesh si plan premium.

Gabimet më të zakonshme

• Tenancy trajtohet si veçori e mëvonshme. Shtimi i kolonës së tenantit në një kod të pjekur prek çdo kërkesë, çelës cache-i, punë në sfond dhe shteg skedari.
• Harrohen vendet jo të dukshme. Cache-t, indekset e kërkimit, radhët, eksportet dhe shabllonet e email-it kanë nevojë për ndarje sipas tenantit.
• Kod i veçantë për klient. Degëzimi i kodit për klientë individualë duket i shpejtë dhe bëhet i pamirëmbajtshëm. Përdor konfigurime dhe feature flags.
• Pa vëzhgim sipas tenantit. Nëse nuk e di cili tenant shkaktoi një ngadalësim ose një rritje gabimesh, nuk mund ta mbështesësh dhe as ta faturosh siç duhet.

Çfarë do të thotë kjo për koston dhe afatin

Udhëzuesit publikë të kostos për SaaS ndryshojnë shumë, nga disa mijëra dollarë për një prototip të ngushtë deri në qindra mijëra për një platformë me shumë role, integrime, faturim dhe veçori AI. Diferenca vjen nga ndryshimi i fushëveprimit, jo sepse dikush gabon. Tenancy e ndikon këtë fushëveprim në tre mënyra: autentikimi dhe rolet për organizatë, faturimi dhe matja, dhe veglat e administrimit që i duhen ekipit tënd. Një vendim i qartë që në fillim heq një nga burimet më të mëdha të befasive në një ofertë. Për kontekst më të gjerë mbi kostot, shiko shkrimin tonë për portalet e klientëve, ku shpjegojmë fushëveprimin, sigurinë dhe faktorët e çmimit.

Pyetje të shpeshta

A është multi-tenant gjithmonë më i lirë se single-tenant?

Për klient, zakonisht po, sepse infrastruktura ndahet. Por kursimi mund të zhduket nëse më vonë duhet të shtosh izolim ose nëse disa tenantë të mëdhenj kërkojnë burime të dedikuara. Kostoja totale varet nga përbërja e klientëve.

A mund të nis me skemë të përbashkët dhe ta kaloj një klient në databazë të veçantë më vonë?

Po, nëse e planifikon. Mbajtja e identifikuesve të tenantit të qëndrueshëm nëpër tabela, skedarë dhe cache e bën nxjerrjen të mundur. Ta shtosh këtë në një produkt që nuk e ka menduar kurrë tenancy është shumë më e vështirë.

A ndikon multi-tenancy te certifikimet e sigurisë?

Ndikon në mënyrën si e dëshmon izolimin. Auditorët dhe klientët e mëdhenj zakonisht kërkojnë prova: kontrolle aksesi, teste, regjistrim dhe procedura të qarta fshirjeje të dhënash. Kontrollet në nivel databaze, si row-level security, e bëjnë më të lehtë dhënien e këtyre provave.

Sa tenantë duhen para se skema e përbashkët të bëhet problem?

Nuk ka një numër universal. Skemat e përbashkëta me indekse të mira shërbejnë numra shumë të mëdhenj tenantësh. Problemet vijnë zakonisht nga madhësitë e pabarabarta dhe kërkesat pa filtër, jo nga numri në vetvete.

Po planifikon një produkt SaaS?

Zgjedhja e modelit të tenancy është një nga vendimet që i kalojmë me themeluesit përpara se të shkruhet asnjë rresht kodi prodhimi. Nëse po peshon opsionet për produktin tënd, shiko shërbimin tonë ndërtim produkti SaaS (0→1), ose kontakto Shkulaku për të diskutuar idenë tënde me ekipin tonë dhe për të marrë një pamje të sinqertë të fushëveprimit, arkitekturës dhe afatit.