Mäta förbrukningen för varje klientorganisation
Som lösningsleverantör är det viktigt att mäta förbrukningen för varje klient i din multitenant-lösning. Genom att mäta förbrukningen för varje klientorganisation kan du se till att kostnaden för sålda varor (KSV) för att leverera tjänsten till varje klientorganisation är lönsamma. På den här sidan ger vi vägledning till tekniska beslutsfattare om vikten av att mäta förbrukning, och de metoder som du kan överväga för att mäta en klients förbrukning samt de kompromisser som ingår.
Det finns två huvudsakliga problem som driver behovet av att mäta varje klientorganisations förbrukning:
- Du måste mäta den faktiska kostnaden för varje klientorganisation. Detta är viktigt för att övervaka lösningens lönsamhet för varje klientorganisation.
- Du måste fastställa hur mycket klientorganisationen ska debiteras när du använder förbrukningsbaserad prissättning.
Det kan dock vara svårt att mäta de faktiska resurser som används av en klientorganisation i en lösning för flera innehavare. De flesta tjänster som kan användas som en del av en lösning för flera klienter skiljer eller delar inte automatiskt upp användningen, baserat på vad du definierar en klientorganisation som ska vara. Tänk dig till exempel en tjänst som lagrar data för alla dina klienter i en enda relationsdatabas. Det är svårt att avgöra exakt hur mycket utrymme varje klientorganisation använder för relationsdatabasen, antingen vad gäller lagring eller beräkningskapacitet som krävs för att bearbeta frågor och begäranden.
För en lösning för en enskild klientorganisation kan du däremot använda Azure Cost Management i Azure Portal för att få en fullständig kostnadsuppdelning för alla Azure-resurser som används av den klientorganisationen.
När du står inför dessa utmaningar är det därför viktigt att överväga hur du mäter förbrukning.
Anteckning
I vissa fall är det kommersiellt acceptabelt att ta en förlust när tjänsten levereras till en klient, till exempel när du går in på en ny marknad eller region. Det här är ett kommersiellt val. Även i dessa situationer är det fortfarande en bra idé att mäta förbrukningen för varje klientorganisation, så att du kan planera för framtiden.
Vägledande förbrukningsmått
Moderna program (som skapats för molnet) består vanligtvis av många olika tjänster, var och en med olika förbrukningsmått. Ett lagringskonto mäter till exempel förbrukning baserat på mängden lagrade data, de data som överförs och antalet transaktioner. Men Azure App Service mäts med mängden beräkningsresurser som allokeras över tid. Om du har en lösning som innehåller ett lagringskonto och App Service-resurser kan det vara mycket svårt att kombinera alla dessa mått för att beräkna den faktiska KSV:n (kostnaden för sålda varor). Ofta är det enklare att använda ett enda indikativt mått för att representera förbrukning i lösningen.
Om du till exempel har en lösning för flera användare som delar en enda relationsdatabas kan du fastställa att lagrade data är ett bra exempel på förbrukningsmått.
Anteckning
Även om du använder den mängd data som lagras av en klientorganisation som en indikation på förbrukningsmåttet kanske det inte är en verklig representation av förbrukningen för varje klientorganisation. Om en viss klientorganisation till exempel gör många fler läsningar eller kör mer rapportering från lösningen, men den inte skriver så mycket data, kan den använda mycket mer beräkning än vad lagringskraven skulle indikera.
Ibland är det viktigt att mäta och granska den faktiska förbrukningen i klientorganisationen för att avgöra om de antaganden som du gör om dina vägledande mått är korrekta.
Transaktionsmått
Ett annat sätt att mäta förbrukning är att identifiera en nyckeltransaktion som är representativ för lösningens COGS. I en lösning för dokumenthantering kan det till exempel vara antalet dokument som skapats. Detta kan vara användbart om det finns en kärnfunktion eller funktion i ett system som är transaktionellt och om det är enkelt att mäta.
Den här metoden är vanligtvis enkel och kostnadseffektiv att implementera, eftersom det vanligtvis bara finns en enda punkt i ditt program som behöver registrera antalet transaktioner som sker.
Mått per begäran
I lösningar som främst är API-baserade kan det vara bra att använda ett förbrukningsmått som baseras på antalet API-begäranden som görs till lösningen. Detta kan ofta vara ganska enkelt att implementera, men det kräver att du använder API:er som primärt gränssnitt för systemet. Det blir en ökad driftskostnader för att implementera ett mått per begäran, särskilt för tjänster med hög volym, på grund av behovet av att registrera användning av begäran (för gransknings- och faktureringsändamål).
Anteckning
Användarriktade lösningar som består av en ensidesapplikation (SPA) eller ett mobilprogram som använder API:erna kanske inte passar bra för måttet per begäran. Det beror på att slutanvändaren inte har så stor förståelse för relationen mellan användningen av programmet och användningen av API:er. Ditt program kan vara trafikigt (det gör många API-begäranden) eller chunky (det gör för få API-begäranden) och användaren märker ingen skillnad.
Varning
Se till att du lagrar mått för förfrågningar i ett tillförlitligt datalager som har utformats för detta ändamål. Även om Azure Application Insights kan spåra begäranden och även spåra klientorganisations-ID:n (med hjälp av egenskaper ),är Application Insights inte utformat för att lagra varje telemetri. Den tar bort data som en del av dess samplingsbeteende. För fakturerings- och mätningsändamål väljer du ett datalager som ger dig en hög noggrannhetsnivå.
Uppskatta förbrukning
När du mäter förbrukningen för en klient kan det vara enklare att ange en uppskattning av förbrukningen för klienten i stället för att försöka beräkna den exakta mängden förbrukning. För en lösning för flera klienter som betjänar tusentals klienter i en enda distribution är det till exempel rimligt att göra en uppskattning av att kostnaden för att betjäna klientorganisationen bara är en procentandel av kostnaden för Azure-resurserna.
Du kan överväga att uppskatta cogs för en klientorganisation i följande fall:
- Du använder inte förbrukningsbaserad prissättning.
- Användningsmönster och kostnader för varje klientorganisation är liknande, oavsett storlek.
- Varje klientorganisation förbrukar en låg procentandel (till exempel < 2 %) av de övergripande resurserna i distributionen.
- Kostnaden per klientorganisation är låg.
Du kan också välja att uppskatta förbrukningen i kombination med indikativa förbrukningsmått,transaktionsmått eller mått per begäran. För ett program som främst hanterar dokument ger till exempel den procentandel av den totala lagringen som används av en klientorganisation, för att lagra dess dokument, en tillräckligt nära representation av den faktiska cogs-lagringen. Detta kan vara en användbar metod när det är svårt att mäta COGS eller när det skulle lägga till för mycket komplexitet i programmet.
Debitera dina kostnader
I vissa lösningar kan du helt enkelt debitera kunderna cogs för deras klientresurser. Du kan till exempel använda Azure-resurstaggar för att allokera fakturerbara Azure-resurser till klienter. Du kan sedan fastställa kostnaden för varje klientorganisation för den uppsättning resurser som är dedikerade till dem, plus en marginal för vinst och drift.
Anteckning
Vissa Azure-tjänster stöder inte taggar. För dessa tjänster måste du tillskriva kostnaderna till en klientorganisation, baserat på resursnamn, resursgrupp eller prenumeration.
Azure Cost Analysis kan användas för att analysera Azure-resurskostnader för en enskild klientorganisation som använder taggar, resursgrupper eller prenumerationer för att attributa kostnader.
Detta blir dock mycket komplext i de flesta moderna lösningar för flera klienter, på grund av utmaningen att korrekt fastställa exakt cogs för att betjäna en enda klientorganisation. Den här metoden bör endast övervägas för mycket enkla lösningar, lösningar som har resursdistributioner för en enskild klientorganisation eller anpassade klientspecifika tilläggsfunktioner i en större lösning.
Vissa Azure-tjänster innehåller funktioner som tillåter andra metoder för kostnadsattribut i en miljö med flera användare. Till exempel stöder Azure Kubernetes Service fleranodpooler , där varje klientorganisation tilldelas en nodpool med nodpooltaggar ,som används för att attributet kostnader.
Nästa steg
Överväg den uppdateringsdistributionsmodell som du ska använda.