Tenancy models to consider for a multitenant solution (Modeller för innehavare att överväga för en lösning för flera innehavare)

Det finns många olika sätt att utforma en lösning som ska vara multitenant. Det här beslutet handlar huvudsakligen om huruvida och hur du delar resurser mellan dina klienter. Intuitivt kanske du vill undvika att dela resurser, men det här blir snabbt dyrt när verksamheten skalas och när du börjar använda fler och fler klienter.

Det är bra att tänka på de olika modellerna för flera klientorganisationen genom att först förstå hur du definierar klienter för din specifika organisation, vilka affärsfaktorer du har och hur du planerar att skala din lösning. På den här sidan ger vi vägledning till tekniska beslutsfattare om de modeller för innehavare som du kan överväga och deras kompromisser.

Definiera en klientorganisation

Först måste du definiera en klientorganisation för din organisation. Fundera över vem din kund är. Med andra ord, vilka tillhandahåller du dina tjänster till? Det finns två vanliga modeller:

• Business-to-business (B2B). Om dina kunder är andra organisationer kommer du förmodligen att betrakta dina klienter som dessa kunder. Överväg dock om dina kunder kan ha avdelningar (team eller avdelningar) eller om de har en närvaro i flera länder. Du kan behöva överväga att ha en enda kundkarta till flera klienter om det finns olika krav för dessa undergrupper. På samma sätt kanske en kund vill underhålla två instanser av din tjänst, så att de kan hålla utvecklings- och produktionsmiljöer åtskilda från varandra. I allmänhet har en enda klient flera användare. Till exempel är alla dina kunders anställda användare inom samma klientorganisation.
• Företag till konsument (B2C). Om kunderna är konsumenter är det ofta mer komplicerat att relatera kunder, klienter och användare. I vissa fall kan varje konsument vara sin egen klientorganisation. Men fundera över om din lösning kan användas av familjer, grupper av vänner, vänner, vänner, associationer eller andra grupperingar som kan behöva komma åt och hantera sina data tillsammans. En musikströmningstjänst kan till exempel stödja både enskilda användare och familjer, och den kan hantera var och en av dessa kontotyper på olika sätt, när det gäller att dela upp dem i klientorganisation.

Din definition av klientorganisation påverkar några av de saker som du behöver tänka på eller betona när du skapar din lösning. Tänk dig till exempel följande olika typer av klienter:

• Om dina klienter är enskilda personer eller familjer kan du behöva vara särskilt bekymrad över hur du hanterar personuppgifter och lagar om datasuveränitet inom varje jurisdiktion som du hanterar.
• Om dina klienter är företag kan du behöva tänka på kundernas krav för regelefterlevnad, isolering av deras data och se till att du uppfyller ett angivet servicenivåmål (SLO), till exempel drifttid eller tjänsttillgänglighet.

Hur bestämmer du vilken modell som ska användas?

Att välja en innehavares modell är inte bara ett tekniskt beslut. Det är också ett kommersiellt beslut som du måste fatta. Du måste tänka på frågor som följande:

• Vilka är dina affärsmål?
• Kommer dina kunder att acceptera alla former av flera innehavare? Hur skulle varje modell för flera innehavare påverka dina efterlevnadskrav eller kundens efterlevnadskrav?
• Kommer en lösning för en enskild klient att skalas efter dina framtida tillväxtambitioner?
• Hur stort är driftteamet och hur mycket av din infrastrukturhantering kan du automatisera?
• Förväntar sig dina kunder att du uppfyller serviceavtal (SLA) eller har du servicenivåavtal som du vill ha?

Om du förväntar dig att ditt företag ska skalas ut till ett stort antal kunder är det mycket viktigt att distribuera delad infrastruktur. Annars måste du underhålla en stor och ständigt växande vagnpark med instanser. Det är troligt att det inte går att distribuera enskilda Azure-resurser för varje kund, såvida du inte etablerar och använder en dedikerad prenumeration per klientorganisation. När du delar samma Azure-prenumeration mellan flera klienter kan kvoter och begränsningar för Azure-resurser börja gälla och driftskostnaderna för att distribuera och konfigurera om dessa resurser blir högre hos varje ny kund.

Om du däremot förväntar dig att din verksamhet bara kommer att ha ett fåtal kunder kan det vara värt att överväga att ha resurser för en enskild klientorganisation som är dedikerade till varje kund. På samma sätt kan en infrastruktur för en enskild klient vara lämplig om kundernas isoleringskrav är höga.

Logiska och fysiska klienter

Därefter måste du bestämma vad en klientorganisation innebär för din specifika lösning och om du ska skilja mellan logiska och fysiska klienter.

Tänk dig till exempel en musikströmningstjänst. Till en början kan du skapa en lösning som enkelt kan hantera tusentals (eller till och med tiotusentals) användare. När du fortsätter att växa kanske du behöver duplicera din lösning eller några av dess komponenter för att kunna skala efter dina nya kundbehov. Det innebär att du måste ta reda på hur du tilldelar specifika kunder till specifika instanser av din lösning. Du kan göra detta slumpmässigt eller geografiskt, eller genom att fylla i en enda instans och sedan spilla över till en annan. Men du behöver förmodligen ha en post för vilka kunder du har och vilken infrastruktur deras data och program är tillgängliga på, så att du kan dirigera trafiken till rätt infrastruktur. I det här exemplet kan du representera varje användare som en separat logisk klientorganisation och sedan mappa användarna till fysiska klienter som representerar de olika instanser som du har distribuerat. Du har en en-till-många-mappning mellan logiska och fysiska klienter och du kan flytta logiska klienter mellan fysiska klienter efter eget gottfinnande.

Tänk dig däremot ett företag som skapar molnprogramvara för juridiska företag. Dina kunder kan behöva en egen dedikerad infrastruktur för att upprätthålla sina efterlevnadsstandarder. Därför måste du vara beredd på att distribuera och hantera många olika instanser av din lösning direkt från början. I det här exemplet är en logisk och fysisk klient samma sak.

En viktig skillnad mellan logiska och fysiska klienter är hur isolering tillämpas. När flera logiska klienter delar en enda uppsättning infrastruktur förlitar du dig vanligtvis på programkoden och en klient-ID i en databas för att hålla varje klientorganisations data åtskilda. När du har fysiska klienter har de sin egen infrastruktur, så det kan vara mindre viktigt att koden är medveten om att den fungerar i en miljö med flera klienter.

Ibland visas fysiska klienter som kallas distributioner,superklientereller stämplar. I resten av det här dokumentet använder vi termerna distributioner och fysiska distributionerför att undvika förvirring mellan logiska och fysiska klienter.

När du får en begäran om en specifik logisk klientorganisation måste du mappa den till den fysiska distributionen som innehåller klientens data, som du ser nedan:

Isolering av klientorganisation

En av de största övervägandena när du designar en arkitektur med flera klienter är den isoleringsnivå som varje klient behöver. Isolering kan innebära olika saker:

• Ha en enda uppsättning delad infrastruktur, med separata instanser av ditt program och separata databaser för varje klientorganisation.
• Dela några vanliga resurser, samtidigt som andra resurser är separata för varje klientorganisation.
• Förvara data i en separat fysisk infrastruktur. I molnet kan detta kräva separata Azure-resurser för varje klientorganisation, eller till och med innebära att en separat fysisk infrastruktur distribueras med hjälp av dedikerade värdar.

I stället för att tänka på isolering som en diskret egenskap bör du tänka på isolering som en continuum. Du kan distribuera komponenter i din arkitektur som är mer eller mindre isolerade än andra komponenter i samma arkitektur, beroende på dina krav. Följande diagram visar en continuum av isolering:

Isoleringsnivån påverkar många aspekter av din arkitektur, inklusive följande:

• Säkerhet. Om du delar infrastruktur mellan flera klienter måste du vara särskilt noga med att inte komma åt data från en klientorganisation när du returnerar svar till en annan. Du behöver en stark grund för din identitetsstrategi och du måste överväga både klient- och användaridentitet i din auktoriseringsprocess.
• Kostnad. Delad infrastruktur kan användas av flera klienter, så det är billigare.
• Prestanda. Om du delar infrastruktur kan systemets prestanda påverkas när fler kunder använder den, eftersom resurserna kan förbrukas snabbare.
• Tillförlitlighet. Om du använder en enda uppsättning delad infrastruktur kan ett problem med en klientorganisations komponenter resultera i ett avbrott för alla.
• Svarstider för enskilda klienters behov. När du distribuerar infrastruktur som är dedikerad till en klientorganisation kan du justera konfigurationen för resurserna för den specifika klientorganisationens krav. Du kan till och med överväga detta i din prismodell, där du gör det möjligt för kunder att betala mer för isolerade distributioner.

Din lösningsarkitektur kan påverka vilka alternativ du har tillgängliga för isolering. Låt oss till exempel tänka på ett exempel på en lösningsarkitektur med tre nivåer:

• Nivån för användargränssnittet kan vara en delad webbapp för flera innehavare och alla klienter har åtkomst till ett enda värdnamn.
• Mellannivån kan vara ett delat programlager med delade meddelandeköer.
• Datanivån kan vara isolerade databaser, tabeller eller blobcontainrar.

Du kan blanda och matcha olika isoleringsnivåer på varje nivå. Ditt beslut om vad som delas och vad som är isolerat baseras på många överväganden, inklusive kostnad, komplexitet, dina kunders krav och antalet resurser som du kan distribuera innan du når Azure-kvoter och -gränser.

Vanliga modeller för innehavare

När du har fastställt dina krav kan du utvärdera dem mot några vanliga modeller och mönster för innehavare.

Automatiserade distributioner för en enskild klient

I en automatiserad distributionsmodell för en enskild klient distribuerar du en dedikerad uppsättning infrastruktur för varje klientorganisation, som du ser i det här exemplet:

Ditt program ansvarar för att initiera och samordna distributionen av varje klientorganisations resurser. Lösningar som bygger på den här modellen använder vanligtvis infrastruktur som kod (IaC) eller Azure Resource Manager API:er. Du kan använda den här metoden när du behöver etablera helt separata infrastrukturer för var och en av dina kunder. Överväg distributionsstämpelmönstret när du planerar distributionen.

Fördelar: En viktig fördel med den här metoden är att data för varje klient är isolerade, vilket minskar risken för oavsiktligt läckage. Detta kan vara viktigt för vissa kunder med höga kostnader för regelefterlevnad. Dessutom är det osannolikt att klienter påverkar varandras systemprestanda, som ibland kallas för problem med störningar på grannen. Uppdateringar och ändringar kan distribueras progressivt över klientorganisationen, vilket minskar sannolikheten för ett systemomfattande avbrott.

Risker: Din kostnadseffektivitet är låg eftersom du inte delar infrastruktur mellan dina klienter. Om en enskild klientorganisation kräver en viss infrastrukturkostnad är det troligt att 100 klienter kräver 100 gånger den kostnaden, i utgifter. Dessutom är löpande underhåll (t.ex. tillämpning av ny konfiguration eller programuppdateringar) sannolikt tidskrävande. Överväg att automatisera dina operativa processer och överväg att tillämpa ändringar progressivt i dina miljöer. Du bör också överväga andra åtgärder för korsdistribution, till exempel rapportering och analys i hela din egendom. På samma sätt bör du planera för hur du kan köra frågor mot och manipulera data över flera distributioner.

Distributioner för flera olika program i samma installation

I motsatt extremfall kan du överväga en distribution för flera olika etenant-program, där alla komponenter delas. Du har bara en uppsättning infrastruktur att distribuera och underhålla, och alla klienter använder den, som du ser i följande diagram:

Fördelar: Den här modellen är attraktiv på grund av den lägre kostnaden för att driva en lösning med delade komponenter. Även om du behöver distribuera resurser på högre nivåer eller SKU:er är det fortfarande ofta så att den totala distributionskostnaden är lägre än en uppsättning resurser för en enskild klientorganisation. Om en användare eller klient behöver flytta sina data till en annan logisk klientorganisation behöver du inte migrera data mellan två separata distributioner.

Risker:

• Var noga med att se till att du separerar data för varje klientorganisation och inte läcker data mellan klienterna. Du kan behöva hantera horisontell partitionering av dina data själv. Dessutom kan du behöva bekymra dig om de effekter som enskilda klienter kan ha på det övergripande systemet. Om till exempel en enda stor klient försöker utföra en tung fråga eller åtgärd, kommer det att påverka andra klienter?

• Fastställ hur du spårar och associerar dina Azure-kostnader till klienterom detta är viktigt för dig. Underhåll kan vara enklare med en enda distribution eftersom du bara behöver uppdatera en uppsättning resurser. Men det är också ofta mer riskabelt, eftersom ändringar kan påverka hela kundbasen.

• Skalning kan också vara en faktor att tänka på. Det är mer troligt att du når gränserna för Azure-resursskalning när du har en delad uppsättning infrastruktur. Om du till exempel använder ett lagringskonto som en del av din lösning kan antalet begäranden till det lagringskontot nå gränsen för vad lagringskontot kan hantera när skalan ökar. För att undvika att nå en resurskvotgräns kan du överväga att distribuera flera instanser av dina resurser (till exempel flera AKS-kluster eller lagringskonton), eller så kan du även överväga att distribuera dina klienter över resurser som du har distribuerat till flera Azure-prenumerationer.

• Det finns troligen en gräns för hur långt du kan skala en enskild distribution, och kostnaderna för att göra det kan öka icke-linjärt. Om du till exempel har en enda delad databas kan du, när du kör i mycket hög skala, få slut på dataflödet och behöva betala mer för ett ökat dataflöde för att hålla dig till din efterfrågan.

Lodrätt partitionerade distributioner

Du behöver inte vara i extremfallen av dessa skalor. I stället kan du överväga att partitionera klienterna lodrätt, med följande steg:

• Använd en kombination av distributioner för en enda klient och flera klienter. Du kan till exempel ha de flesta av dina kunders data- och programnivåer i infrastrukturer med flera klientorganisation, men du kan distribuera en enda klientinfrastruktur för kunder som behöver högre prestanda eller dataisolering.
• Distribuera flera instanser av din lösning geografiskt och fäst varje klientorganisation på en specifik distribution. Detta är särskilt effektivt när du har klienter i olika geografiska områden.

Här är ett exempel som illustrerar en delad distribution för vissa klienter och en distribution för en enskild klientorganisation för en annan:

Fördelar: Eftersom du fortfarande delar infrastruktur kan du fortfarande få några av kostnadsfördelarna med att ha delade distributioner för flera i samma installation. Du kan distribuera billigare, delade resurser för vissa kunder, till exempel de som provar din tjänst med en utvärderingsversion. Du kan till och med fakturera kunderna ett högre pris för en distribution för en enskild klientorganisation, vilket ger en del av dina kostnader igen.

Risker: Din kodbas kommer troligen att behöva utformas för att stödja distributioner för både flera klienter och en enskild klientorganisation. Om du planerar att tillåta migrering mellan infrastrukturer måste du överväga hur du migrerar kunder från en distribution för flera innehavare till en egen distribution för en enskild klientorganisation. Du måste också ha en tydlig förståelse för vilka av dina logiska klienter som finns på vilka uppsättningar av fysisk infrastruktur, så att du kan kommunicera information om systemproblem eller uppgraderingar till relevanta kunder.

Vågrätt partitionerade distributioner

Du kan också överväga horisontell partitionering av dina distributioner. Det innebär att du har vissa delade komponenter, samtidigt som du underhåller andra komponenter med distributioner för en enskild klientorganisation. Du kan till exempel skapa en enda programnivå och sedan distribuera enskilda databaser för varje klientorganisation, som du ser i den här bilden:

Fördelar: Horisontellt partitionerade distributioner kan hjälpa dig att minska störningar om du har upptäckt att den största delen av belastningen på systemet beror på specifika komponenter som du kan distribuera separat för varje klientorganisation. Dina databaser kan till exempel absorbera det mesta av systemets belastning eftersom frågebelastningen är hög. Om en enskild klient skickar ett stort antal begäranden till din lösning kan prestanda för en databas påverkas negativt, men andra klientdatabaser (och delade komponenter, t.ex. programnivån) påverkas inte.

Risker: Med en vågrätt partitionerad distribution måste du fortfarande överväga den automatiserade distributionen och hanteringen av dina komponenter, särskilt de komponenter som används av en enda klientorganisation.

Testa din isoleringsmodell

Oavsett vilken isoleringsmodell du väljer kontrollerar du att din lösning testas för att verifiera att en klientorganisations data inte av misstag läcks till en annan och att eventuella störningar i grannen är godtagbara. Överväg att använda Azure Chaos Studio för att avsiktligt introducera fel som simulerar verkliga avbrott och kontrollera återhämtningsförmågan för din lösning även när komponenterna inte fungerar.

Nästa steg

Överväg livscykeln för dina klienter.