Provoz více zákazníků na jedné platformě není jen způsob nasazení. Je to návrhové rozhodnutí, které určuje ekonomický model platformy — kdo za co platí, kolik zákazníků zvládne obsloužit jeden tým, jestli jde nového zákazníka spustit za minuty, nebo za měsíce — i inženýrské rozhodnutí, které rozhoduje o tom, jestli data každého zákazníka opravdu zůstanou tam, kam patří. Platforma stavěná pro více zákazníků od začátku dokáže obsloužit mnoho zákazníků s jedním provozním nákladem, dodat vylepšení všem najednou a doladit jednotlivá prostředí bez větvení kódu. Platforma, která tuhle schopnost dodělává dodatečně, vždycky někde protéká — náklady bobtnají, izolace dat má najednou výjimky, přehled provozovatele je až druhořadý a přání zákazníka po vlastním doladění se mění v inženýrský projekt. Provoz více zákazníků bereme jako architektonický základ a odráží se to v podobě každé funkce.
Prostředí je hlavní hranicí. Každý kus dat na platformě — každý záznam, každý uživatel, každá konfigurace, každá automatizace, každý soubor — patří konkrétnímu prostředí. Vrstva přístupu k datům tuto hranici vynucuje automaticky: dotaz vydaný v kontextu prostředí A nemůže vrátit data z prostředí B, ať vypadá jakkoli. Toto vynucení je na úrovni infrastruktury, ne dolepené v kódu jednotlivých funkcí, takže vývojáři funkcí nemusí pamatovat na to přidat do své logiky "WHERE tenant = ?" — hranice platí ještě dřív, než se jejich kód vůbec spustí.
Konfigurace pro každé prostředí zvlášť dělá z každého prostředí opravdu samostatnou implementaci. Typy, které prostředí používá, vlastnosti těchto typů, pohledy nad nimi, automatizace, které nad nimi běží, role určující přístup — to všechno patří danému prostředí. Jedno prostředí může mít propracovaný model vztahů se zákazníky; jiné prostředí na téže platformě model údržby zařízení; třetí model správy dárců pro neziskovku. Tatáž platforma obsluhuje všechna tři, protože konfigurace, která každé z nich dělá užitečným, žije uvnitř prostředí, ne v kódu platformy.
Sdílený kód, samostatná data je základní princip provozu. Je jeden kód, jedno nasazení, jeden provozní náklad — a na něm tolik samostatných zákaznických implementací, kolik jich provozovatel zřídí. Když vyjde vylepšení platformy, dorazí do všech prostředí najednou, protože se nasazuje jen jeden kód. Když si zákazník přeje odlišnou konfiguraci, řeší se to jako nastavení na úrovni prostředí, ne jako větev kódu, protože právě větvení kódu je to, čemu má architektura více zákazníků předcházet. Výsledkem je, že provozní tým obslouží mnoho zákazníků s úsilím, jaké by jednozákaznický provoz vynaložil na jediného.
Konzole provozovatele a správa prostředí jsou dvě oddělené vrstvy administrace. Správce prostředí spravuje své vlastní prostředí — uživatele, role, konfiguraci, data. Provozovatel platformy spravuje celý soubor prostředí — zřizování, rušení, sledování, nastavování limitů pro jednotlivá prostředí, řešení podpory napříč prostředími. Obě vrstvy jsou oddělené: správce prostředí má plnou pravomoc uvnitř svého prostředí a nulový výhled ven; provozovatel platformy má přehled napříč prostředími, ale běžně se dat jednotlivých prostředí nedotýká. Toto rozdělení pravomocí má význam jak pro bezpečnost — správci prostředí se nemohou navzájem omylem ovlivnit — tak pro škálování, protože konzole provozovatele umožní malému provoznímu týmu vidět celý soubor prostředí naráz.
Konzole provozovatele poskytuje ten centrální pohled. Prostředí jsou vypsaná s aktuálním stavem — velikost, míra aktivity, kondice, nastavené limity, poslední akce provozovatele. Problémy, které se týkají více prostředí, se ukazují centrálně, místo aby se dohledávaly v každém prostředí zvlášť. Akce platné napříč prostředími — globální změna konfigurace, oznámení o nasazení, audit celého souboru — se zadávají z jednoho místa. Pro realitu provozu mnoha prostředí naráz je právě tento centrální pohled tím, co provoz udrží zvládnutelný.
Limity pro jednotlivá prostředí umožňují provozovatelům ladit spotřebu zdrojů prostředí od prostředí. Kvóty úložiště, limity četnosti volání API, stropy počtu uživatelů, souběžnost úloh na pozadí — to vše lze nastavit pro každé prostředí zvlášť, takže velký firemní zákazník dostane vyšší limity než malý startup a prostředí, které se chová špatně, lze přiškrtit, aniž by to postihlo ostatní. Limity jsou deklarativní; platforma je vynucuje jednotně; prostředí vidí své nastavené limity ve svém chování bez jakéhokoli překvapení.
Úlohy na pozadí se znalostí prostředí běží automaticky se správným kontextem prostředí. Naplánované automatizace, naplánované reporty, naplánovaná údržba — všechno běží pro každé prostředí zvlášť, s jeho konfigurací, jeho daty, jeho rozvrhem. Úloha na pozadí spuštěná pro prostředí A se nikdy nedotkne dat prostředí B, protože úloha ví, pro které prostředí běží, a vrstva přístupu k datům podle toho hranici vynutí. Tak se naplánovaná práce škáluje přes celý soubor prostředí, aniž by bylo třeba udržovat plánovací infrastrukturu pro jednotlivá prostředí.
Zřízení prostředí je operace životního cyklu pro přidání nového zákazníka. Provozovatel vytvoří nové prostředí, zvolí výchozí konfiguraci — často opětovným importem exportu datového modelu ze vzorového prostředí — zřídí prvního správce a prostředí předá. Co dřív mohl být měsíc inženýrské práce na každého nového zákazníka, se mění na operaci na pár minut, protože export vzorového modelu a sdílené nasazení platformy zastanou všechny části, které by jinak vyžadovaly vlastní přípravu.
Zrušení prostředí řeší čistě druhý konec životního cyklu. Když zákazník odejde, jeho prostředí lze archivovat — a data zachovat po dobu, kterou určuje smlouva — nebo úplně vymazat a odstranit z platformy veškerou stopu po datech prostředí. Obě cesty jsou řízené operace, které respektují hranici izolace: žádná data ze zrušeného prostředí neuniknou do jiného a žádná data jiného prostředí se přitom nedotknou.
Vlastní vzhled a přizpůsobení pro každé prostředí stojí na tomto základu. Uživatelé každého prostředí vidí logo, barvy, písma a doménu své vlastní organizace; této vrstvě se podrobně věnuje článek o přizpůsobení pro zákazníka. Pro odlišnosti implementace nad rámec vzhledu — další typy, upravené pohledy, automatizace specifické pro dané prostředí — popisují, jak to v praxi funguje, tentýž článek o přizpůsobení a článek o importu dat a exportu modelu.
Pro provozovatele platformy, kteří zvažují, zda platforma unese jejich zákaznickou základnu, je provoz více zákazníků tou základní vlastností, která rozhoduje, jestli odpověď škáluje. Pro podnikové architekty, kteří zvažují, zda může jejich organizace na jednom nasazení hostit více oddělení nebo dceřiných společností, platí totéž. K okolním tématům: článek o přizpůsobení pro zákazníka rozebírá konfiguraci pro jednotlivá prostředí podrobněji, článek o rolích a oprávněních popisuje vrstvu autorizace uvnitř každého prostředí, článek o protokolu událostí popisuje auditní stopu, která běží pro každé prostředí zvlášť, a článek o importu dat a exportu modelu popisuje, jak se konfigurace přenáší mezi prostředími. Provoz více zákazníků je vlastnost, díky které je platforma ekonomicky udržitelná při jakékoli smysluplné velikosti; a izolace je to, co každému zákazníkovi dovoluje věřit, že jeho data zůstanou jen jeho.