När du överväger en arkitektur för flera klientorganisationer finns det flera beslut du behöver fatta och element som du behöver tänka på.
I en arkitektur med flera klienter delar du en del av eller alla dina resurser mellan klientorganisationer. Den här processen innebär att en arkitektur med flera klientorganisationer kan ge dig kostnad och driftseffektivitet. Multitenancy medför dock komplexitet. Du måste ställa dig själv följande frågor:
- Hur definierar du vad en klientorganisation är för din specifika lösning? Motsvarar en klientorganisation en kund, en användare eller en grupp användare som ett team eller en familj?
- Hur distribuerar du infrastrukturen för att stödja flera klientorganisationer och hur mycket isolering kommer du att ha mellan klientorganisationer?
- Vilka kommersiella prismodeller kommer din lösning att erbjuda och hur kommer dina prismodeller att påverka dina krav för flera klientorganisationer?
- Vilken tjänstnivå behöver du tillhandahålla dina klienter, över dimensioner som prestanda, återhämtning, säkerhet och efterlevnadskrav som datahemvist?
- Hur planerar du att utveckla din verksamhet eller lösning? Kommer den att skalas till det antal klienter du förväntar dig?
- Har någon av dina klienter ovanliga eller särskilda krav? Behöver din största kund till exempel högre prestanda eller starkare garantier än andra?
- Hur ska du övervaka, hantera, automatisera, skala och styra din Azure-miljö och hur påverkar flera klientorganisationer din hanteringsstrategi?
- Vilka komponenter i lösningen hanterar registrering och hantering av klientorganisationer och hur ska dessa komponenter utformas?
Oavsett arkitektur är det viktigt att du har en tydlig förståelse för dina kunders eller klientorganisationers krav. Om du har gjort försäljningsåtaganden till kunder, eller om du har avtalsförpliktelser eller efterlevnadskrav att uppfylla, måste du veta vilka dessa krav är när du utformar din lösning. Men på samma sätt kan dina kunder ha implicita förväntningar på hur saker och ting ska fungera, eller hur du ska bete dig, vilket kan påverka hur du utformar en lösning med flera klientorganisationer.
Anta till exempel att du skapar en lösning med flera klientorganisationer som du säljer till företag inom finansbranschen. Dina kunder har mycket strikta säkerhetskrav och du måste ange en omfattande lista över alla domännamn som din lösning använder, så att de kan lägga till den i brandväggens tillåtna lista. Det här kravet påverkar de Azure-tjänster som du använder och den isoleringsnivå som du måste tillhandahålla mellan dina klienter. De kräver också att deras lösning har en minsta återhämtningsnivå. Det kan finnas många liknande förväntningar, både explicita och implicita, som du behöver tänka på i hela lösningen.
I det här avsnittet beskriver vi några av de överväganden som du bör tänka på, vilka krav du bör få fram och några av de kompromisser du behöver göra när du planerar en arkitektur för flera klienter.
Målgrupp
Artiklarna i det här avsnittet är särskilt relevanta för tekniska beslutsfattare, som chief technology officers (CTOs) och arkitekter samt produktchefer. Målgruppen omfattar även oberoende programvaruleverantörer (ISV:er) och nystartade företag som utvecklar SaaS-lösningar. Dessutom bör alla som arbetar med arkitekturer med flera klientorganisationer känna till dessa principer och kompromisser.
Nästa steg
Överväg olika innehavarmodeller för din lösning.