Мултитенантност без жаргона: ръководство за основатели

В някакъв момент от изграждането на софтуерен продукт разработчик ще ви каже думата „мултитенантен“, ще погледне лицето ви и ще приеме, че сте разбрали. Вероятно сте кимнали. Повечето основатели го правят. Но това е едно от онези ранни решения, които тихомълком определят тавана на това колко бързо можете да растете, колко евтино можете да работите и колко зле могат да се развият нещата, ако някой клиент някога види данни, които не са негови. Заслужава си десет минути внимание сега, защото е много скъпо да се връщате към него по-късно.

Срещал съм се с много нетехнически основатели — хора с остра идея за SaaS продукт и без особен интерес към базите данни. Добрата новина е, че не е нужно да се учите да програмирате, за да вземете това решение добре. Нужен ви е ясен мисловен модел и кратък списък с въпроси. Точно това е настоящото ръководство. Без модни думи, без архитектурни диаграми, които никога повече няма да погледнете — само това, което разработчикът ви иска да разбирате преди първия ред код.

Ако вземете една идея от тук, нека бъде тази: мултитенантността не е функция, която добавяте по-късно. Тя е основа. Можете да пребоядисате къщата, но не можете лесно да смените това, върху което стои, след като стените вече са вдигнати.

Какво всъщност означава „мултитенантен“

Представете си жилищна сграда. Всеки наемател има свой собствен апартамент — свой ключ, свои мебели, своя входна врата. Но всички споделят една и съща структура: основата, водопровода, покрива, асансьора. Собственикът поддържа една сграда, а не петдесет отделни къщи, и точно това прави наема достъпен. Мултитенантният софтуер работи точно по този начин. Едно приложение обслужва много клиенти — „наематели“ — и всеки от тях го преживява като свое лично пространство, въпреки че всички работят върху една и съща споделена система отдолу.

Противоположният подход е единичен наемател: всеки клиент получава свое отделно копие на софтуера, все едно строите чисто нова самостоятелна къща за всеки от тях. По-лично, по-персонализируемо — и драматично по-скъпо за изграждане, поддръжка и обновяване, защото вече поддържате петдесет къщи вместо една сграда.

Почти всеки продукт, който използвате ежедневно, е мултитенантен. Имейлът ви, счетоводният ви инструмент, системата ви за резервации, CRM-ът, в който живее екипът ви по продажби. Вие и хиляда други компании споделяте един и същ базов софтуер и никой от вас никога не вижда останалите. Тази невидимост — това чисто разделение — е цялото изкуство на мултитенантността.

Защо това решение засяга целия ви бизнес

Изкушаващо е да го причислите към „технически детайл, с който се занимава разработчикът ми“. Но моделът, който изберете, се отразява директно на частите от бизнеса, които наистина ви интересуват: месечната ви сметка за хостинг, колко бързо можете да доставите нова функция на всички, какво можете да обещаете на нервен корпоративен купувач и колко щети може да нанесе един-единствен бъг.

Когато поправите бъг или пуснете функция в добре изграден мултитенантен продукт, всеки клиент я получава наведнъж, от едно обновяване. В свят с единичен наемател бихте разгръщали тази промяна към петдесет отделни инсталации, всяка от които вече може да е малко по-различна. Едното е вторник следобед. Другото е проект. Умножете това през години обновявания и ще разберете защо SaaS индустрията се крепи на мултитенантността.

Обратната страна е, че споделянето на инфраструктура повишава залога върху разделението. В жилищна сграда повреда във водопровода може да засегне повече от един апартамент. В мултитенантния софтуер грешка в начина, по който държите наемателите разделени, не просто причинява неудобство на един клиент — тя може да изложи данните на всички наведнъж. Това не е причина да избягвате мултитенантността. Това е причината да я изградите правилно, с някой, който вече го е правил.

Трите начина да държите наемателите разделени

Когато разработчиците спорят за мултитенантността, обикновено спорят за това колко разделени трябва да са данните на всеки наемател. Има три често срещани подхода и те се нареждат по плъзгаща се скала от „максимално споделяне, най-нисък разход“ до „максимално разделение, най-висок разход“. Не е нужно сами да избирате, но трябва да разбирате компромиса, който разработчикът ви прави от ваше име.

1. Споделена база данни, споделени таблици

Данните на всички живеят в една и съща база данни, в едни и същи таблици, със скрит етикет — „ID на наемател“ — който отбелязва кои редове на кого принадлежат. Софтуерът отговаря винаги да филтрира по този етикет, така че клиент А вижда само редовете на клиент А. Това е най-евтиният и най-мащабируем модел, който повечето ранни SaaS продукти използват. Уловката: разделението живее в кода, така че един пропуснат филтър е начинът, по който изтичат данни. Изисква внимателно, дисциплинирано инженерство.

2. Споделена база данни, отделни отделения

Една база данни, но всеки наемател получава свое заградено отделение в нея (разработчиците ги наричат „схеми“). По-силно разделение от първия модел, все още сравнително ефективно, и по-лесно е например да се изнесат или изтрият чисто данните на един клиент. Компромисът е повече подвижни части за управление, докато растете до стотици и хиляди наематели.

3. Отделна база данни за всеки наемател

Всеки клиент получава своя специална база данни — най-близкото до това да му дадете частна къща, докато все още споделяте приложението. Това е най-силната изолация и най-лесната история за разказване на корпоративен купувач, загрижен за сигурността. Това е и най-скъпото за поддръжка и експлоатация, така че обикновено се запазва за високостойностни клиенти, регулирани индустрии или продукти, при които смесване на данни би било катастрофално.

Частта, която не можете да сбъркате: изолацията

Ако има едно място, на което да изразходвате тревогата си, то е тук. Изолацията на наемателите е гаранцията, че клиент А никога, при никакви обстоятелства, не може да види, редактира или дори да усети съществуването на данните на клиент Б. Звучи очевидно. То е и най-честият източник на сериозни бъгове в мултитенантните продукти, защото провалът е тих — всичко изглежда наред чак до деня, в който някой отвори справка и види чужди клиенти в нея.

Причината това да се случва е структурна. В най-евтиния модел всяка заявка към базата данни трябва да помни да филтрира по наемател. Уцелете я десет хиляди пъти и сбъркате веднъж и имате изтичане. Затова опитните екипи не разчитат разработчиците да помнят — те вграждат изолацията в основата, така че забравянето да стане невъзможно, а не просто малко вероятно. Не е нужно да разбирате как го правят. Нужно е да попитате дали го правят.

Има и по-тих роднина на този проблем: „шумният съсед“. Тъй като наемателите споделят инфраструктура, един клиент, който прави нещо тежко — гигантски импорт, неуправляема справка — може да забави системата за всички останали, по същия начин, по който един апартамент, пуснал всички кранове, може да свали налягането на водата в цялата сграда. Доброто мултитенантно проектиране планира за това с ограничения и справедливо споделяне. Заслужава си да попитате, особено ако очаквате няколко много големи клиента.

Кога единичният наемател наистина е правилният избор

Мултитенантността е по подразбиране за SaaS, но не е религия. Има честни причини да дадете на клиент собствено отделно копие и добрият съветник ще ви каже, когато сте попаднали на такава, вместо да вкарва всичко насила в споделения модел.

• Клиент в регулирана индустрия — здравеопазване, финанси, държавна администрация — чиито правила за съответствие на практика изискват данните му да живеят някъде доказуемо отделно.
• Един голям клиент, плащащ достатъчно, че специална настройка да си струва, и който иска дълбока персонализация, която не желаете да изтича в преживяването на всички останали.
• Данни толкова чувствителни, че цената на изтичане между наематели би сложила край на бизнеса, което прави максималната изолация заслужаваща допълнителния разход.
• Изискване за on-premise, при което софтуерът трябва да работи в собствените стени на клиента, а не във вашия облак.

Забележете модела: единичният наемател е изключението, към което посягате съзнателно, обикновено за конкретен високостойностен клиент, а не настройката по подразбиране, върху която градите целия бизнес. Ако разработчик предложи единичен наемател за стандартния ви продукт от първия ден, помолете го да ви обясни защо — обикновено това означава много по-висок експлоатационен разход и по-бавни обновявания, и искате това да бъде избор, а не случайност.

Въпросите, които да зададете, преди някой да напише код

Не е нужно да проектирате архитектурата. Нужно е да се уверите, че човекът, който я проектира, е помислил за правилните неща. Ето краткия списък, който бих искал един нетехнически основател да донесе на онзи първи разговор — отпечатайте го, задайте го, наблюдавайте колко уверено получавате отговор.

1. 1
   Как ще държите данните на наемателите разделени?

   Слушате за структурен отговор — системата го налага — а не „ще внимаваме“. Това е въпросът, по който няма пазарлък.
2. 2
   Кой модел използваме и защо?

   Споделени таблици, отделни отделения или база данни на наемател. Няма грешен отговор, но трябва да има причина, която пасва на клиентите и бюджета ви.
3. 3
   Можем ли да предложим специална изолация на голям клиент по-късно?

   Дори да започнете напълно споделено, проектът трябва да оставя място да дадете на един голям или регулиран клиент по-силно разделение без преработка.
4. 4
   Какво се случва, когато един клиент стане огромен?

   Как системата спира един тежък наемател да забавя всички останали? Искате да чуете, че сценариите с шумния съсед са били обмислени.
5. 5
   Как чисто изнасяме или изтриваме данните на един клиент?

   Клиентите си тръгват, а законът за поверителност изисква да премахвате данните им при поискване. Това трябва да е проста, добре разбрана операция, а не паника.

Не оценявате техническия детайл на отговорите. Проверявате дали нито един от тези въпроси не идва като изненада. Екип, който е изграждал мултитенантен софтуер преди, ще има ясни, почти отегчени отговори и на петте. Колебание по първия или третия е сигналът да забавите и да разровите по-дълбоко.

Кратък пример, оформен от реалността

Един основател дойде при нас с работещ прототип на инструмент за планиране, насочен към малки клиники. Той вече имаше трима плащащи клиенти — и един тих проблем. За да излезе бързо на пазара, първият разработчик беше дал на всяка клиника свое отделно копие на приложението. Трима клиенти, три инсталации, три леко различни версии, защото всяка беше поискала по някоя малка промяна по пътя.

Работеше прекрасно при три. Кошмарът на основателя беше мисълта за тридесет. Всяка поправка на бъг означаваше влизане на три места. Всяка нова функция означаваше три разгръщания и три неща за тестване. Нова клиника отнемаше близо седмица за ръчна настройка. Моделът, който ги изведе на пазара, сега беше това, което ограничаваше растежа им — точно проблемът с основата, за който е цялата тази статия.

Не изтръгнахме всичко в драматично пренаписване. Преизградихме ядрото върху споделена мултитенантна основа с изолация, наложена на системно ниво, запазихме персонализациите за всяка клиника като конфигурируеми настройки, а не отделни кодови бази, и мигрирахме трите съществуващи клиники една по една, паралелно, така че никой да няма страшен ден на превключване. Включването на нова клиника премина от седмица ръчна работа към самообслужваща се регистрация. Новите функции сега достигат до всеки клиент от едно пускане.

Числата тук са илюстративни, не обещание — всеки продукт е различен — но формата е типична: преработката струваше реални пари и няколко месеца и се изплати в рамките на първите няколко нови клиента, които изведнъж можеха да включват без да мръднат пръст. Поуката, която основателят извлече, беше по-евтината: ако бяха задали петте въпроса в началото, нямаше да има какво да преработват.

Често задавани въпроси