Det finns många sätt att tänka på hur du arbetar med klienter i din lösning. Ditt val av metod beror mycket på om och hur du delar resurser mellan dina klienter. Intuitivt kanske du vill undvika att dela resurser , men den metoden blir snabbt dyr när ditt företag skalar och du registrerar fler klienter.
När du tänker på de olika modellerna för flera klientorganisationer är det bra att först ta hänsyn till hur du definierar klientorganisationer för din organisation, vad dina affärsdrivande faktorer är och hur du planerar att skala din lösning. Den här artikeln innehåller vägledning som hjälper tekniska beslutsfattare att utvärdera innehavarmodellerna och deras kompromisser.
Definiera en klientorganisation
Först måste du definiera en klientorganisation för din organisation. Överväg vem din kund är. Med andra ord, vem tillhandahåller du dina tjänster till? Det finns två vanliga modeller:
- Verksamhet till företag (B2B). Om dina kunder är andra organisationer kommer du sannolikt att mappa dina klienter till dessa kunder. Tänk dock på om dina kunder har avdelningar (team eller avdelningar) och om de har närvaro i flera länder/regioner. Du kan behöva mappa en enskild kund 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 sina utvecklings- och produktionsmiljöer åtskilda från varandra. I allmänhet har en enskild klientorganisation flera användare. Till exempel är alla kundens anställda användare i en enda klientorganisation.
- Företag till konsument (B2C). Om dina kunder är konsumenter är det ofta mer komplicerat att relatera kunder, klienter och användare. I vissa scenarier kan varje konsument vara en separat klientorganisation. Tänk dock på om din lösning kan användas av familjer, grupper av vänner, klubbar, föreningar eller andra grupper som kan behöva komma åt och hantera sina data tillsammans. En musikströmningstjänst kan till exempel ha stöd för både enskilda användare och familjer, och den kan behandla var och en av dessa kontotyper på olika sätt när den separerar dem i klientorganisationer.
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 till exempel på de här typerna av klienter:
- Om dina klienter är enskilda personer eller familjer kan du behöva vara särskilt bekymrad över hur du hanterar personuppgifter och om lagar om datasuveränitet inom varje jurisdiktion som du tjänar.
- Om dina klienter är företag kan du behöva vara medveten om kundernas krav på regelefterlevnad, isolering av deras data och säkerställa 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 innehavarmodell är inte bara ett tekniskt beslut. Det är också ett kommersiellt beslut. Du måste tänka på sådana här frågor:
- Vilka är dina affärsmål?
- Kommer dina kunder att acceptera alla former av multitenancy? Hur påverkar varje multitenancy-modell dina efterlevnadskrav eller kundernas efterlevnadskrav?
- Kommer en lösning med en enda klientorganisation att skalas efter dina framtida tillväxtambitioner?
- Hur stor är driftteamet och hur mycket av din infrastrukturhantering kan du automatisera?
- Förväntar dina kunder att du uppfyller serviceavtal eller har du serviceavtal som du strävar efter?
Om du förväntar dig att ditt företag ska skalas till ett stort antal kunder är det viktigt att distribuera delad infrastruktur. Annars måste du underhålla en stor och växande flotta med resursinstanser. Att distribuera enskilda Azure-resurser för varje kund är sannolikt ohållbart, såvida du inte etablerar och använder en dedikerad prenumeration för varje klientorganisation. När du delar samma Azure-prenumeration mellan flera klienter kan Azure-resurskvoter och -gränser börja gälla och driftskostnaderna för att distribuera och konfigurera om dessa resurser ökar för varje ny kund.
Om du däremot förväntar dig att ditt företag bara har ett fåtal kunder kanske du vill överväga att använda resurser med en enda klientorganisation som är dedikerade till varje kund. Om dina kunders isoleringskrav är höga kan en infrastrukturmetod för en enda klientorganisation vara lämplig även om det är dyrare.
Klientorganisationer och distributioner
Därefter måste du avgöra vad klientorganisationen innebär för din specifika lösning och om du ska skilja mellan logiska klienter och distributioner.
Överväg 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 kan du dock upptäcka att du behöver duplicera din lösning eller några av dess komponenter för att kunna skala till ny kundefterfrågan. Det innebär att du måste bestämma hur du tilldelar specifika kunder till specifika instanser av din lösning. Du kan tilldela kunder slumpmässigt, geografiskt eller genom att fylla i en enda instans och sedan starta en annan (lagerplatsförpackning). Men du behöver förmodligen underhålla en post för dina kunder och vilken infrastruktur deras data och program är tillgängliga på så att du kan dirigera deras trafik till rätt infrastruktur. I det här exemplet kan du representera varje kund som en separat klientorganisation och sedan mappa användarna till distributionen som innehåller deras data. Du har en en-till-många-mappning mellan klienter och distributioner, och du kan flytta klienter mellan distributioner efter eget gottfinnande.
Tänk dig däremot ett företag som skapar molnprogramvara för juridiska företag. Dina kunder kanske insisterar på att ha 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 från början. I det här exemplet innehåller en distribution alltid en enda klientorganisation och en klientorganisation mappas till sin egen dedikerade distribution.
En viktig skillnad mellan klientorganisationer och distributioner är hur isolering framtvingas. När flera klienter delar en enskild distribution (en uppsättning infrastruktur) förlitar du dig vanligtvis på programkoden och en klientidentifierare som finns i en databas för att hålla varje klientorganisations data åtskilda. När du har klienter med egna dedikerade distributioner har de en egen infrastruktur, så det kan vara mindre viktigt att koden är medveten om att den körs i en miljö med flera klienter.
Distributioner kallas ibland supertenanter eller stämplar.
När du får en begäran om en specifik klientorganisation måste du mappa den till den distribution som innehåller klientorganisationens data, som du ser här:
Mer information finns i Mappa begäranden till klientorganisationer.
Isolering av klientorganisation
En av de största övervägandena i utformningen av en arkitektur med flera klienter är den isoleringsnivå som varje klientorganisation behöver. Isolering kan betyda olika saker:
- Har en enda delad infrastruktur, med separata instanser av ditt program och separata databaser för varje klientorganisation.
- Dela några vanliga resurser, men håll andra resurser åtskilda för varje klientorganisation.
- Lagra data på en separat fysisk infrastruktur. I molnet kan den här konfigurationen kräva separata Azure-resurser för varje klientorganisation. I extrema situationer kan det till och med innebära att du distribuerar en separat fysisk infrastruktur 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å att det är på ett kontinuum. 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 ett kontinuum 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 bli lidande när fler kunder använder den, eftersom resurserna kan förbrukas snabbare. Prestandaproblem kan förvärras av klienter med ovanliga användningsmönster.
- Tillförlitlighet. Om du använder en enda uppsättning delad infrastruktur kan ett problem med en komponent leda till ett avbrott för alla dina klienter.
- Svarstider för enskilda klientorganisationers behov. När du distribuerar infrastruktur som är dedikerad till en klient kan du kanske anpassa konfigurationen för resurserna till den specifika klientorganisationens krav. Du kan till och med överväga den här funktionen i din prismodell, så att kunderna kan betala mer för isolerade distributioner.
Din lösningsarkitektur kan påverka dina tillgängliga alternativ för isolering. Tänk dig till exempel en lösningsarkitektur med tre nivåer:
- Användargränssnittsnivån kan vara en delad webbapp med flera klienter som 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 överväga att använda olika isoleringsnivåer på varje nivå. Du bör basera ditt beslut på vad som delas och vad som är isolerat på många överväganden, inklusive kostnader, komplexitet, kundernas krav och antalet resurser som du kan distribuera innan du når Azure-kvoter och gränser.
Vanliga innehavarmodeller
När du har upprättat dina krav utvärderar du dem mot några vanliga innehavarmodeller och motsvarande distributionsmönster.
Automatiserade distributioner med en enda klientorganisation
I en automatiserad distributionsmodell för en enda 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. Vanligtvis använder lösningar som använder den här modellen infrastruktur som kod (IaC) eller Azure Resource Manager-API:er i stor utsträckning. 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 att använda mönstret Distributionsstämplar när du planerar distributionen.
Fördelar: En viktig fördel med den här metoden är att data för varje klientorganisation är isolerade, vilket minskar risken för oavsiktligt läckage. Det här skyddet kan vara viktigt för vissa kunder som har höga regelefterlevnadskostnader. Dessutom är det osannolikt att klientorganisationer påverkar varandras systemprestanda, ett problem som ibland kallas det bullriga grannproblemet. Uppdateringar och ändringar kan distribueras progressivt mellan klienter, vilket minskar sannolikheten för ett systemomfattande avbrott.
Risker: Om du använder den här metoden är kostnadseffektiviteten låg eftersom du inte delar infrastruktur mellan dina klienter. Om en enskild klientorganisation kräver en viss infrastrukturkostnad kräver 100 klienter förmodligen 100 gånger den kostnaden. Dessutom är pågående underhåll (som att tillämpa ny konfiguration eller programuppdateringar) förmodligen 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 flera distributioner, till exempel rapportering och analys i hela din flotta. På samma sätt bör du planera för hur du kan fråga och manipulera data i flera distributioner.
Fullständigt multitenantdistributioner
I motsatt extremitet kan du överväga en helt multitenant distribution, där alla komponenter delas. Du har bara en uppsättning infrastruktur att distribuera och underhålla, och alla klienter använder den, enligt följande diagram:
Fördelar: Den här modellen är attraktiv eftersom det är billigare att använda en lösning med delade komponenter än att använda enskilda resurser för varje klientorganisation. Även om du behöver distribuera högre nivåer eller SKU:er för resurser för att ta hänsyn till den ökade belastningen är den totala distributionskostnaden ofta fortfarande lägre än kostnaden för en uppsättning resurser med en enda klientorganisation. Om en användare eller klientorganisation behöver flytta sina data till en annan klientorganisation kanske du kan uppdatera klientidentifierare och nycklar, och du kanske inte behöver migrera data mellan två separata distributioner.
Risker:
Se till att separera data för varje klientorganisation och inte läcka data mellan klientorganisationer. Du kan behöva hantera horisontell partitioneringsdata. Dessutom kan du behöva oroa dig för vilka effekter enskilda klienter kan ha på det övergripande systemet. Om till exempel en stor klient försöker utföra en tung fråga eller åtgärd kan det påverka andra klienter.
Fastställ hur du spårar och associerar dina Azure-kostnader med klienter, om det ä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.
Du kan också behöva överväga skalning. Det är mer troligt att du når azure-resursskalningsgränser när du har en delad uppsättning infrastruktur. Om du till exempel använder ett lagringskonto som en del av din lösning, när din skala ökar, kan antalet begäranden till lagringskontot nå gränsen för vad lagringskontot kan hantera. För att undvika att nå en resurskvotgräns kan du överväga att distribuera en pool med flera instanser av dina resurser (till exempel flera AKS-kluster eller lagringskonton). Du kan till och med överväga att distribuera dina klienter mellan resurser som du distribuerar till flera Azure-prenumerationer.
Det finns förmodligen 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 uttömma dess dataflöde och behöva betala mer för ökat dataflöde för att hålla jämna steg med din efterfrågan.
Vertikalt partitionerade distributioner
Du behöver inte välja någon av ytterligheterna i dessa skalor. I stället kan du överväga att partitionera klientorganisationer vertikalt genom att använda den här metoden:
- Använd en kombination av distributioner med en enda klientorganisation och flera klienter. Du kan till exempel ha de flesta av dina kunders data- och programnivåer på infrastrukturer med flera klienter, men distribuera infrastrukturer med en enda klientorganisation för kunder som behöver högre prestanda eller dataisolering.
- Distribuera flera instanser av din lösning geografiskt och mappa varje klientorganisation till en specifik distribution. Den här metoden är särskilt effektiv 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 med en enda klientorganisation för en annan:
Fördelar: Eftersom du fortfarande delar en del av infrastrukturen kan du få några av kostnadsfördelarna med att använda delade distributioner med flera klientorganisationer. Du kan distribuera billigare delade resurser för vissa kunder, till exempel kunder som utvärderar din tjänst med en utvärderingsversion. Du kan till och med fakturera kunderna en högre avgift för att använda en distribution med en enda klientorganisation, vilket hjälper dig att återställa en del av dina kostnader.
Risker: Din kodbas måste utformas för att stödja både distributioner med flera klienter och en klientorganisation. Om du planerar att tillåta migrering mellan distributioner måste du överväga hur du migrerar kunder från en distribution med flera klienter till en egen distribution med en enda klientorganisation. Du behöver också veta vilka av dina klienter som finns i varje distribution, så att du kan kommunicera information om systemproblem eller uppgraderingar till relevanta kunder.
Horisontellt partitionerade distributioner
Du kan också överväga att horisontellt partitionera dina distributioner. I en horisontell distribution har du vissa delade komponenter men underhåller andra komponenter med distributioner med en enda klientorganisation. Du kan till exempel skapa en enda programnivå och sedan distribuera enskilda databaser för varje klientorganisation, som du ser i det här diagrammet:
Fördelar: Horisontellt partitionerade distributioner kan hjälpa dig att undvika ett problem med bullriga grannar: om du upptäcker att den största delen av belastningen på systemet orsakas av specifika komponenter kan du distribuera separata komponenter för varje klientorganisation. Dina databaser kan till exempel absorbera det mesta av systemets belastning, eftersom frågebelastningen är hög. Om en enskild klientorganisation skickar ett stort antal begäranden till din lösning kan prestandan för en databas påverkas negativt, men andra klientdatabaser (och delade komponenter, till exempel programnivån) påverkas inte.
Risker: Med en horisontellt partitionerad distribution behöver du fortfarande överväga automatisk distribution och hantering av dina komponenter, särskilt de komponenter som används av en enda klientorganisation.
Testa din isoleringsmodell
Oavsett vilken isoleringsmodell du väljer bör du testa din lösning för att kontrollera att en klientorganisations data inte oavsiktligt har läckt ut till en annan och att eventuella störningar i granneffekterna är acceptabla. Överväg att använda Azure Chaos Studio för att avsiktligt införa fel som simulerar verkliga avbrott och verifiera lösningens återhämtning även när komponenterna inte fungerar.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- John Downs | Huvudprogramtekniker
Övriga medarbetare:
- Chad Kittel | Huvudprogramtekniker
- Paolo Salvatori | Huvudkundtekniker, FastTrack för Azure
- Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.
Nästa steg
Överväg livscykeln för dina klienter