Cenové modely pro víceklientských řešení

Dobrý cenový model zajišťuje, že zůstanete ziskový, jak roste počet tenantů a jak přidáváte nové funkce. Důležitým aspektem při vývoji komerčního multitenantového řešení je návrh cenových modelů pro váš produkt. Na této stránce poskytujeme pokyny pro pracovníky s technickými rozhodovacími rozhodnutími o cenových modelech, které můžete zvážit, a související kompromisy.

Při určování cenového modelu pro váš produkt je potřeba vyvážit návratnost hodnoty (ROV) pro vaše zákazníky s náklady na prodané zboží (COGS) k dodání služby. Nabídka flexibilnějších komerčních modelů (pro řešení) může zvýšit ROV pro zákazníky, ale může také zvýšit architekturu a komerční složitost řešení (a tím také zvýšit vaše COGS).

Některé důležité aspekty, které byste měli vzít v úvahu při vývoji cenových modelů pro řešení, jsou následující:

• Bude COGS vyšší než zisk, který z řešení získáte?
• Může se COGS v průběhu času měnit na základě růstu uživatelů nebo změn ve vzorech použití?
• Jak obtížné je měřit a zaznamenávat informace potřebné k provozování cenového modelu? Pokud například plánujete fakturovat zákazníky na základě počtu volání rozhraní API, které provádějí, zjistili jste, jak měříte volání rozhraní API prováděných jednotlivými zákazníky?
• Závisí vaše ziskovost na tom, aby zákazníci používali vaše řešení omezeným způsobem?
• Pokud zákazník řešení přepíná, znamená to, že už nejste ziskoví?

Existují některé klíčové faktory, které ovlivňují vaši ziskovost:

• Cenové modely služeb Azure Cenové modely služeb Azure nebo třetích stran, které tvoří vaše řešení, můžou ovlivnit, které modely jsou ziskové.
• Vzory využití služeb Uživatelé můžou mít přístup k vašemu řešení jenom během pracovní doby nebo můžou mít jenom malé procento uživatelů s velkým objemem. Můžete snížit kapacitu COGS snížením nevyužité kapacity, když je vaše využití nízké?
• Růst úložiště. Většina řešení shromažďuje data v průběhu času. Více dat znamená vyšší náklady na ukládání a ochranu, což snižuje ziskovost na tenanta. Můžete nastavit kvóty úložiště nebo vynutit dobu uchovávání dat?
• Izolace tenanta. Model tenantů , který používáte, ovlivňuje úroveň izolace, kterou máte mezi tenanty. Pokud sdílíte své prostředky, musíte zvážit, jak můžou tenanti službu nadměrně využívat nebo zneužívat? Jak bude úroveň izolace tenanta ovlivňovat vaše coGS a výkon pro všechny? Některé cenové modely nejsou ziskové bez dalších kontrol kolem přidělování prostředků. Například možná budete muset implementovat omezování služeb, aby byl cenový model s plochou sazbou udržitelný.
• Životní cyklus tenanta Například řešení s vysokou četností změn zákazníků nebo službami, které vyžadují větší úsilí při onboardingu, můžou mít nižší ziskovost – zejména pokud se cena používá pomocí modelu založeného na spotřebě.
• Požadavky na úroveň služeb. Tenanti, kteří vyžadují vyšší úroveň služeb, můžou znamenat, že vaše řešení už není ziskové. Je důležité, abyste jasně vybrali očekávání na úrovni služeb vašich zákazníků a všechny závazky, které máte, abyste mohli podle toho plánovat cenové modely.

Běžné cenové modely

Existuje mnoho běžných cenových modelů, které se často používají u víceklientských řešení. Každý z těchto cenových modelů má přidružené komerční výhody a rizika a vyžaduje další aspekty architektury. Je důležité pochopit rozdíly mezi těmito cenovými modely, abyste měli jistotu, že vaše řešení zůstane ziskové při vývoji.

Poznámka:

Pro řešení můžete nabídnout více modelů nebo kombinovat modely dohromady. Můžete například poskytnout model pro jednotlivé uživatele pro zákazníky, kteří mají poměrně stabilní uživatelská čísla, a můžete také nabídnout model spotřeby pro zákazníky, kteří mají proměnlivé vzory využití.

Ceny založené na spotřebě

Model consumption se někdy označuje jako průběžné platby nebo průběžné platby. S rostoucím využitím služby se vaše výnosy zvyšují:

Při měření spotřeby můžete zvážit jednoduché faktory, například množství dat přidaných do řešení. Alternativně můžete zvážit kombinaci atributů použití společně. Modely consumption nabízejí mnoho výhod, ale jejich implementace ve víceklientských řešeních může být obtížná.

Výhody: Z pohledu vašich zákazníků existuje minimální počáteční investice, které jsou potřeba k použití vašeho řešení, aby tento model byl pro vstup nízký. Z pohledu operátora služeb se náklady na hostování a správu zvyšují s tím, jak se zvýší využití zákazníků a vaše výnosy. Díky tomuto zvýšení může být vysoce škálovatelný cenový model. Cenové modely spotřeby fungují zvlášť dobře, pokud jsou také služby Azure používané v řešení založené na spotřebě.

Složitost a provozní náklady: Modely spotřeby spoléhají na přesné měření využití a rozdělení tohoto využití podle tenanta. To může být náročné, zejména v řešení s mnoha distribuovanými komponentami. Potřebujete uchovávat podrobné záznamy o spotřebě pro fakturaci a auditování a také poskytovat způsoby, jak zákazníkům získat přístup k datům o jejich spotřebě.

Rizika: Ceny spotřeby můžou motivovat zákazníky ke snížení jejich využití systému, aby snížily náklady. Modely spotřeby navíc vedou k nepředvídatelným datovým proudům výnosů. Můžete to zmírnit tím, že nabídnete rezervace kapacity, kdy zákazníci platí za určitou úroveň spotřeby předem. Jako poskytovatel služeb můžete tyto výnosy využít k investici do vylepšení řešení, ke snížení provozních nákladů nebo ke zvýšení návratnosti hodnoty přidáním funkcí.

Poznámka:

Implementace a podpora rezervací kapacity může zvýšit složitost fakturačních procesů v rámci vaší aplikace. Možná budete také muset zvážit, jak zákazníci získávají refundace nebo si vyměňují rezervace kapacity a tyto procesy můžou také přidávat obchodní a provozní problémy.

Ceny pro jednotlivé uživatele

Cenový model pro jednotlivé uživatele zahrnuje účtování zákazníků na základě počtu lidí, kteří používají vaši službu, jak je znázorněno v následujícím diagramu.

Cenové modely pro jednotlivé uživatele jsou velmi běžné, protože jejich jednoduchost se implementuje ve víceklientských řešeních. Jsou však přidruženy k několika komerčním rizikům.

Výhody: Když účtujete zákazníky za každého uživatele, můžete snadno vypočítat a předpovědět svůj datový proud výnosů. Kromě toho za předpokladu, že pro každého uživatele máte poměrně konzistentní vzory využití, pak se výnosy zvyšují stejným tempem jako přechod na služby, takže se jedná o škálovatelný model.

Složitost a provozní náklady: Modely pro jednotlivé uživatele jsou obvykle snadno implementované. V některých situacích ale potřebujete měřit spotřebu jednotlivých uživatelů, což vám může pomoct zajistit, aby COGS pro jednoho uživatele zůstal ziskový. Měřením spotřeby a jeho přidružením ke konkrétnímu uživateli můžete zvýšit provozní složitost vašeho řešení.

Rizika: Různé vzorce spotřeby uživatelů můžou vést ke snížení ziskovosti. Například těžké uživatele řešení můžou být nákladnější, aby mohli obsluhovat než light uživatelé. Skutečné vrácení hodnoty (ROV) pro řešení se navíc neprojeví skutečným počtem zakoupených uživatelských licencí.

Ceny jednotlivých uživatelů

Tento model se podobá cenám pro jednotlivé uživatele, ale místo toho, aby zákazník vyžadoval počáteční závazek u počtu očekávaných uživatelů, se zákazníkovi účtuje pouze za uživatele, kteří se k řešení skutečně přihlásí a používají ho za určité období (jak je znázorněno v následujícím diagramu).

Můžete to změřit v jakémkoli období, které dává smysl. Měsíční období jsou běžná a tato metrika se často zaznamenává jako měsíční aktivní uživatelé nebo MAU.

Výhody: Z pohledu vašich zákazníků tento model vyžaduje nízkou investici a riziko, protože dochází k minimálnímu plýtvání; nevyužité licence se neúčtují. To je obzvláště atraktivní, když marketing řešení nebo růst řešení pro větší podnikové zákazníky. Z vašeho pohledu jako vlastník služby se váš ROV přesněji odráží na zákazníka podle počtu měsíčních aktivních uživatelů.

Složitost a provozní náklady: Modely uživatelů na aktivní můžou vyžadovat zaznamenání skutečného využití a jeho zpřístupnění zákazníkovi v rámci faktury. Měření spotřeby jednotlivých uživatelů pomáhá zajistit zachování ziskovosti u COGS pro jednoho uživatele, ale opět vyžaduje další práci k měření spotřeby pro každého uživatele.

Rizika: Podobně jako u cen jednotlivých uživatelů existuje riziko, že různé vzorce spotřeby jednotlivých uživatelů můžou ovlivnit vaši ziskovost. V porovnání s cenami jednotlivých uživatelů mají modely uživatelů méně předvídatelný datový proud výnosů. Kromě toho diskontní ceny neposkytují užitečný způsob, jak podnítit růst.

Ceny za jednotku

V mnoha systémech není počet uživatelů prvkem, který má největší vliv na celkové COGS. Například v řešeních orientovaných na zařízení, označovaných také jako internet věcí nebo IoT, má počet zařízení často největší dopad na COGS. V těchto systémech se dá použít cenový model pro jednotlivé jednotky, kde definujete, co je jednotka , například zařízení. Podívejte se na následující diagram.

Některá řešení mají navíc vysoce proměnlivé vzory použití, kdy malý počet uživatelů má nepřiměřený dopad na COGS. Například v řešení, které se prodává maloobchodním prodejcům s cihlami a maltami, může být vhodný cenový model pro jednotlivé prodejny.

Výhody: V systémech, kde jednotliví uživatelé nemají významný vliv na COGS, je lepší způsob, jak znázorňovat realitu škálování systému a výsledný dopad na COGS. Může také zlepšit sladění se skutečnými vzory využití pro zákazníka. U mnoha řešení IoT, kde každé zařízení generuje předvídatelné a konstantní množství spotřeby, může to být efektivní model pro škálování růstu vašeho řešení.

Složitost a provozní náklady: Obecně se snadno implementují ceny na jednotku a mají poměrně nízké provozní náklady. Provozní náklady ale můžou být vyšší, pokud potřebujete rozlišovat a sledovat využití podle jednotlivých jednotek, jako jsou zařízení nebo maloobchodní prodejny. Měření spotřeby na jednotku vám pomůže zajistit zachování ziskovosti, protože můžete určit COGS pro jednu jednotku.

Rizika: Rizika cenového modelu na jednotku jsou podobná cenovým modelům pro jednotlivé uživatele. Různé vzorce spotřeby podle některých jednotek můžou znamenat snížení ziskovosti, například pokud jsou některá zařízení nebo obchody mnohem těžší než ostatní uživatelé řešení.

Ceny založené na funkcích a službách

Můžete se rozhodnout nabídnout své řešení s různými úrovněmi funkčnosti v různých cenových bodech. Můžete například poskytnout dvě měsíční ploché sazby nebo ceny za jednotku, jednu jako základní nabídku s dostupnou podmnožinou funkcí a druhou představuje komplexní sadu funkcí vašeho řešení. Podívejte se na následující diagram.

Tento model může také nabízet různé smlouvy o úrovni služeb pro různé úrovně. Například úroveň Basic může nabízet 99,9% dostupnost, zatímco úroveň Premium může nabízet 99,99 %. Vyšší smlouvu o úrovni služeb (SLA) je možné implementovat pomocí služeb a funkcí, které umožňují vyšší cíle dostupnosti.

I když tento model může být komerčně přínosný, vyžaduje vyspělé technické postupy, které dobře dělají. Při pečlivém zvážení může být tento model velmi efektivní.

Výhody: Ceny založené na funkcích jsou pro zákazníky často atraktivní, protože můžou vybrat úroveň na základě sady funkcí nebo úrovně služeb, kterou potřebují. Poskytuje také jasnou cestu k prodeji zákazníků s dalšími funkcemi nebo vyšší odolností pro ty, kteří ji vyžadují.

Složitost a provozní náklady: Cenové modely založené na funkcích můžou být složité k implementaci, protože vyžadují, aby vaše řešení vědělo o funkcích dostupných na jednotlivých cenových úrovních. Přepínače funkcí můžou být efektivním způsobem, jak poskytnout přístup k určitým podmnožinám funkcí, ale to vyžaduje průběžnou údržbu. Přepínače funkcí také zvyšují režijní náklady, aby zajistily vysokou kvalitu, protože bude k dispozici více cest kódu k testování. Povolení vyšších cílů dostupnosti služeb v některých úrovních může vyžadovat další složitost architektury, aby se zajistila správná sada infrastruktury pro každou úroveň a tento proces může zvýšit provozní náklady na řešení.

Rizika: Cenové modely založené na funkcích můžou být složité a matoucí, pokud existuje příliš mnoho úrovní nebo možností. Režie spojená s dynamickým přepínáním funkcí navíc může zpomalit rychlost, s jakou dodáváte další funkce.

Ceny Freemium

Můžete se rozhodnout nabídnout bezplatnou úroveň služby se základními funkcemi a bez záruk na úrovni služeb. Pak můžete nabídnout samostatnou placenou úroveň s dalšími funkcemi a formální smlouvou o úrovni služeb (jak je znázorněno na následujícím diagramu).

Bezplatná úroveň může být nabízena také jako časově omezená zkušební verze a během zkušební verze můžou mít vaši zákazníci k dispozici plnou nebo omezenou funkčnost. To se označuje jako model freemium, což je efektivní rozšíření cenového modelu založeného na funkcích.

Výhody: Je velmi snadné nabízet řešení, když je zdarma.

Složitost a provozní náklady: Všechny složitosti a provozní náklady se vztahují na cenový model založený na funkcích. Musíte ale také zvážit provozní náklady spojené se správou bezplatných tenantů. Možná budete muset zajistit, aby zastaralí nebo odebraní tenanti měli jasnou zásadu uchovávání informací, zejména pro bezplatné tenanty. Při povýšení tenanta na placenou úroveň možná budete muset přesunout tenanta mezi službami Azure, abyste získali vyšší smlouvy SLA. Při přechodu na placenou úroveň bude také důležité zachovat data a konfiguraci tenanta.

Rizika: Musíte zajistit, abyste pro tenanty zadali dostatečně vysokou úroveň ROV, abyste mohli zvážit přechod na placenou úroveň. Kromě toho je potřeba náklady na poskytování vašeho řešení zákazníkům na úrovni Free pokrýt ziskovou marží od těch, kteří jsou na placených úrovních.

Náklady na ceny prodaného zboží

Můžete zvolit cenu řešení tak, aby každý tenant platil pouze náklady na provoz jejich podílu na službách Azure bez přidané ziskové marže. Tento model – označovaný také jako předávání nákladů nebo cen – se někdy používá pro víceklientských řešení, která nemají být ziskovým centrem.

Náklady na model prodaného zboží jsou vhodné pro interně orientované multitenantní řešení. Každá organizační jednotka odpovídá tenantovi a náklady na prostředky Azure je potřeba rozdělit mezi ně. Může být také vhodné, pokud jsou výnosy odvozené z prodeje jiných produktů a služeb, které spotřebovávají nebo rozšiřují víceklientských řešení.

Výhody: Vzhledem k tomu, že tento model nezahrnuje žádnou přidanou marži pro zisk, budou náklady na tenanty nižší.

Složitost a provozní náklady: Podobně jako u modelu spotřeby závisí náklady na ceny prodaného zboží na přesné měření využití a rozdělení tohoto využití podle tenanta. Sledování spotřeby může být náročné, zejména v řešení s mnoha distribuovanými komponentami. Potřebujete uchovávat podrobné záznamy o spotřebě pro fakturaci a auditování a také poskytovat způsoby, jak zákazníkům získat přístup k datům o jejich spotřebě.

V případě interně víceklientských řešení můžou tenanti přijímat přibližné odhady nákladů a mít uvolněnější požadavky na audit fakturace. Tyto uvolněné požadavky snižují složitost a náklady na provoz vašeho řešení.

Rizika: Náklady na ceny prodaného zboží mohou motivovat vaše tenanty ke snížení jejich využití systému, aby snížily náklady. Vzhledem k tomu, že se tento model používá pro aplikace, které nejsou zisková centra, nemusí to být problém.

Ceny s plochou sazbou

V tomto modelu účtujete tenantovi plochou sazbu za přístup k vašemu řešení po danou dobu. Stejné ceny platí bez ohledu na to, kolik služby používají, počtu uživatelů, počtu zařízení, která se připojují, nebo jakékoli jiné metriky. Podívejte se na následující diagram.

Jedná se o nejjednodušší model implementace a pochopení zákazníků a často ho požadují podnikoví zákazníci. Pokud ale potřebujete dál přidávat nové funkce nebo pokud se spotřeba tenanta zvýší bez dalších výnosů, může se snadno stát nedostupnou.

Výhody: Ceny s plochou sazbou se dají snadno prodávat a zákazníkům se dají snadno pochopit a vytvořit rozpočet.

Složitost a provozní náklady: Cenové modely s plochou sazbou se dají snadno implementovat, protože zákazníci fakturace nevyžadují žádné měření ani sledování spotřeby. I když to není nezbytné, doporučujeme měřit spotřebu jednotlivých tenantů, abyste měli jistotu, že měříte COGS přesně a abyste zajistili zachování ziskovosti.

Rizika: Pokud máte tenanty, kteří vaše řešení silně využívají, je pro tento cenový model snadné stát se neužitečným.

Ceny slev

Jakmile definujete cenový model, můžete se rozhodnout implementovat komerční strategie pro incentivizaci růstu prostřednictvím cen slev. Ceny slev se dají použít s cenovými modely consumption, per-user a per-unit.

Poznámka:

Ceny slev obvykle nevyžadují aspekty architektury nad rámec přidání podpory pro složitější strukturu fakturace. Úplná diskuze o komerčních výhodách slev je nad rámec tohoto dokumentu.

Mezi běžné cenové vzory slev patří:

• Pevné ceny. Pro každého uživatele, jednotku nebo množství spotřeby máte stejné náklady bez ohledu na to, kolik je zakoupeno nebo spotřebováno. Toto je nejjednodušší přístup. Zákazníci, kteří využívají velké využití vašeho řešení, ale můžou mít pocit, že by měli těžit z úspor z rozsahu získáním slevy.
• Digresivní ceny. Když zákazníci nakupují nebo spotřebovávají více jednotek, snížíte náklady na jednotku. To je komerčně atraktivní pro zákazníky.
• Krokování cen. Snížíte náklady na jednotku, protože zákazníci si kupují více. Provedete to ale v krocích změn na základě předdefinovaných rozsahů množství. Můžete například účtovat vyšší cenu za prvních 100 uživatelů, pak nižší cenu za 101. až 200. uživatele a potom znovu nižší cenu. To může být zisknější.

Následující diagram znázorňuje tyto cenové vzory.

Slevy za neprodukční prostředí

V mnoha případech zákazníci vyžadují přístup k neprodukčnímu prostředí, které můžou použít k testování, trénování nebo vytváření vlastní interní dokumentace. Neprodukční prostředí obvykle mají nižší požadavky na spotřebu a náklady na provoz. Mimoprodukční prostředí například často nejsou předmětem smluv o úrovni služeb (SLA) a limity sazeb můžou být nastaveny na nižší hodnoty. Můžete také zvážit agresivnější automatické škálování služeb Azure.

Zákazníci také často očekávají, že neprodukční prostředí budou výrazně levnější než jejich produkční prostředí. Existuje několik alternativ, které by mohly být vhodné, pokud poskytujete neprodukční prostředí:

• Nabízí úroveň Freemium, jako jste už možná udělali pro placené zákazníky. Měli byste ho pečlivě monitorovat, protože některé organizace můžou vytvářet mnoho testovacích a trénovacích prostředí, která budou využívat další prostředky pro provoz.

  Poznámka:

  Časově omezené zkušební verze využívající úrovně Freemium nejsou obvykle vhodné pro testovací a trénovací prostředí. Zákazníci obvykle potřebují, aby jejich neprodukční prostředí byla k dispozici po celou dobu životnosti produkční služby.

• Nabízí testovací nebo trénovací úroveň služby s nižšími limity využití. Dostupnost této úrovně můžete omezit na zákazníky, kteří mají existujícího placeného tenanta.
• Nabídněte zvýhodněné uživatele, aktivního uživatele nebo ceny za jednotku pro neprodukční tenanty s nižší nebo žádnou smlouvou o úrovni služeb.
• V případě tenantů, kteří používají ceny s plochou sazbou, se můžou vyjednávat neprodukční prostředí jako součást smlouvy.

Poznámka:

Ceny založené na funkcích obvykle nejsou dobrou volbou pro neprodukční prostředí, pokud nejsou nabízené funkce stejné jako funkce nabízené v produkčním prostředí. Důvodem je to, že tenanti obvykle chtějí testovat a poskytovat trénování všech stejných funkcí, které jsou pro ně k dispozici v produkčním prostředí.

Nepoužitelné cenové modely

Neužitečný cenový model stojí za poskytování služby více než výnosy, které získáte. Můžete například účtovat plochou sazbu za tenanta bez jakýchkoli omezení pro vaši službu, ale pak byste službu sestavili s prostředky Azure založenými na spotřebě a bez limitů využití pro jednotlivé tenanty. V takové situaci můžete být ohroženi tím, že tenanti nadlimitují vaši službu, a proto je pro ně nedostupné.

Obecně se chcete vyhnout nerefitovatelným cenovými modely. Existují ale situace, kdy se můžete rozhodnout pro přechod na neužitečný cenový model, včetně:

• Nabízí se bezplatná služba, která umožňuje růst.
• Další streamy výnosů poskytují služby nebo doplňkové funkce.
• Hostování konkrétního tenanta poskytuje další komerční hodnotu, jako je jejich použití jako ukotvený tenant na novém trhu.

V případě, že neúmyslně vytvoříte neužitečný cenový model, existují některé způsoby, jak zmírnit rizika spojená s nimi, včetně:

• Omezte používání služby prostřednictvím limitů využití.
• Vyžaduje využití rezervací kapacity.
• Požádejte tenanta o přechod na vyšší funkci nebo úroveň služby.

Rizikové cenové modely

Při implementaci cenového modelu pro řešení budete obvykle muset předpokládat, jak se bude používat. Pokud se tyto předpoklady projeví jako nesprávné nebo se vzory využití v průběhu času změní, může se cenový model stát nedostupným. Cenové modely, které jsou ohroženy tím, že se stanou neužitečnými, se označují jako rizikové cenové modely. Pokud například přijmete cenový model, který očekává, že uživatelé sami omezí množství, které používají vaše řešení, možná jste implementovali rizikový cenový model.

Většina řešení SaaS bude pravidelně přidávat nové funkce. Tím se zvýší ROV uživatelům, což může také vést k nárůstu množství použitého řešení. To by mohlo vést k tomu, že řešení, které se stane neužitečným, pokud použití nových funkcí řídí využití, ale cenový model to nefaktoruje.

Pokud například do svého řešení zavedete novou funkci nahrávání videa, která používá prostředek založený na spotřebě a využití této funkce je vyšší, než se čekalo, zvažte kombinaci limitů využití a cen na úrovni služeb.

Limity využití

Limity využití umožňují omezit využití vaší služby, aby se zabránilo tomu, že se cenové modely stanou neužitečnými, nebo zabránit tomu, aby jeden tenant spotřebovává nepřiměřeně velkou kapacitu vaší služby. To může být zvlášť důležité ve víceklientských službách, kde může mít jeden tenant vliv na prostředí jiných tenantů prostřednictvím příliš náročných prostředků.

Poznámka:

Je důležité, aby vaši zákazníci věděli, že používáte limity využití. Pokud implementujete limity využití bez toho, aby o limitu věděli vaši zákazníci, bude výsledkem nespokojení zákazníků. To znamená, že je důležité předem identifikovat a naplánovat limity využití. Cílem by mělo být naplánování limitu a následné sdělení limitů zákazníkům před tím, než se stanou nezbytnými.

Limity využití se často používají v kombinaci s cenami na úrovni funkcí a služeb, aby se zajistilo vyšší využití na vyšších úrovních. Limity se také běžně používají k ochraně základních komponent, které způsobí kritické body systému nebo problémy s výkonem, pokud jsou nadměrně spotřebované.

Omezení přenosové rychlosti

Běžným způsobem, jak použít limit využití, je přidat omezení rychlosti pro rozhraní API nebo konkrétní aplikační funkce. Označuje se také jako omezování. Omezení rychlosti brání nepřetržitému nadměrnému využití. Často se používají k omezení počtu volání rozhraní API v definovaném časovém období. Například rozhraní API může být volána pouze 20krát za minutu a pokud se volá častěji, vrátí chybu HTTP 429.

Mezi situace, kdy se často používá omezování rychlosti, patří:

• ROZHRANÍ REST API.
• Asynchronní úlohy.
• Úkoly, které nejsou citlivé na čas
• Akce, které mají vysoké náklady na provedení
• Generování sestav

Implementace omezování rychlosti může zvýšit složitost řešení, ale služby, jako je Azure API Management, to zjednoduší použitím zásad omezení rychlosti.

Životní cyklus cenového modelu

Stejně jako jakákoli jiná část vašeho řešení mají cenové modely životní cyklus. S tím, jak se vaše aplikace v průběhu času vyvíjí, budete možná muset změnit cenové modely. To může být řízeno změnou potřeb zákazníků, komerčních požadavků nebo změn funkcí v rámci vaší aplikace. Mezi běžné změny životního cyklu cen patří:

• Přidání zcela nového cenového modelu Například přidání cenového modelu spotřeby do řešení, které aktuálně nabízí model s plochou sazbou.
• Vyřazení existujícího cenového modelu
• Přidání úrovně do existujícího cenového modelu
• Vyřazení úrovně v existujícím cenovém modelu
• Změna limitů využití u funkce v cenovém modelu
• Přidání nebo odebrání funkcí z cenového modelu na úrovni služeb
• Změna z komerčního modelu B2C (business-to-consumer) na obchodní model B2B (business-to-business). Tato změna pak vyžaduje nové cenové struktury pro vaše firemní zákazníky.

Obvykle je složité implementovat a spravovat mnoho různých cenových modelů najednou. Je také matoucí pro vaše zákazníky. Proto je lepší implementovat pouze jeden nebo dva modely s malým počtem vrstev. Díky tomu bude vaše řešení přístupnější a snadněji se spravuje.

Poznámka:

Cenové modely a fakturační funkce by se měly testovat, ideálně pomocí automatizovaného testování, stejně jako jakákoli jiná část vašeho systému. Čím složitější cenové modely, tím více se vyžaduje testování, a tak se zvýší náklady na vývoj a nové funkce.

Při změně cenových modelů je potřeba zvážit následující faktory:

• Budou tenanti chtít migrovat na nový model?
• Je pro tenanty snadné migrovat na nový model?
• Budou nové cenové modely vystavit vaši službu riziku? Odebíráte například limity četnosti, které aktuálně chrání důležité prostředky před nadměrným využitím?
• Mají tenanti jasnou cestu pro migraci na nový cenový model?
• Jak zabráníte tenantům v používání starších cenových modelů, abyste je mohli vyřadit?
• Je pravděpodobné, že tenanti obdrží šok na faktuře (negativní reakce na neočekávanou fakturu) při změně cenových modelů?
• Monitorujete výkon a využití svých služeb pro nové nebo změněné cenové modely, abyste mohli zajistit trvalou ziskovost?
• Dokážete jasně sdělit ROV pro nové cenové modely svým stávajícím tenantům?

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

• Daniel Scott-Raynsford | Partner Technology Strategist

Další přispěvatelé:

• Bohdan Cherchyk | Vedoucí zákaznický inženýr, FastTrack pro Azure
• John Downs | Hlavní zákaznický inženýr, FastTrack pro Azure
• Chad Kittel | Hlavní softwarový inženýr
• Paul Salvatori | Hlavní zákaznický inženýr, FastTrack pro Azure
• Vladimirskij Vladimirskij | Hlavní zákaznický inženýr, FastTrack pro Azure

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Zvažte způsob měření spotřeby podle tenantů ve vašem řešení.