Modelli di determinazione dei prezzi per una soluzione multi-tenant

Un buon modello di determinazione dei prezzi garantisce che rimanga redditizio man mano che il numero di tenant aumenta e man mano che si aggiungono nuove funzionalità. Una considerazione importante quando si sviluppa una soluzione multi-tenant commerciale è come progettare modelli di determinazione prezzi per il prodotto. In questa pagina vengono fornite indicazioni per i decision maker tecnici sui modelli di determinazione dei prezzi che è possibile prendere in considerazione e sui compromessi coinvolti.

Quando si determina il modello di determinazione dei prezzi per il prodotto, è necessario bilanciare il valore restituito (ROV) per i clienti con il costo delle merci vendute (COGS) per recapitare il servizio. L'offerta di modelli commerciali più flessibili (per una soluzione) potrebbe aumentare il ROV per i clienti, ma potrebbe anche aumentare la complessità architetturale e commerciale della soluzione (e quindi aumentare anche il COGS).

Di seguito sono riportate alcune considerazioni importanti da tenere in considerazione quando si sviluppano modelli di determinazione dei prezzi per una soluzione:

• Il COGS sarà più alto del profitto ottenuto dalla soluzione?
• CogS può cambiare nel tempo, in base alla crescita degli utenti o ai cambiamenti nei modelli di utilizzo?
• Quanto è difficile misurare e registrare le informazioni necessarie per gestire il modello di determinazione prezzi? Ad esempio, se si prevede di fatturare i clienti in base al numero di chiamate API effettuate, è stato identificato come misurare le chiamate API effettuate da ogni cliente?
• La redditività dipende dalla garanzia che i clienti usino la soluzione in modo limitato?
• Se un cliente utilizza eccessivamente la soluzione, significa che non sei più redditizio?

Esistono alcuni fattori chiave che influenzano la redditività:

• Modelli di prezzi dei servizi di Azure. I modelli di determinazione dei prezzi dei servizi di Azure o di terze parti che costituiscono la soluzione possono influire sui modelli redditizi.
• Modelli di utilizzo dei servizi. Gli utenti possono dover accedere alla soluzione solo durante le ore lavorative o possono avere solo una piccola percentuale di utenti con volumi elevati. È possibile ridurre cogS riducendo la capacità inutilizzata quando l'utilizzo è basso?
• Archiviazione crescita. La maggior parte delle soluzioni accumula i dati nel tempo. Più dati implicano un costo più elevato per archiviarlo e proteggerlo, riducendo la redditività per tenant. È possibile impostare le quote di archiviazione o applicare un periodo di conservazione dei dati?
• Isolamento dei tenant. Il modello di tenancy usato influisce sul livello di isolamento tra i tenant. Se si condividono le risorse, è necessario considerare in che modo i tenant potrebbero usare o abusare del servizio? In che modo il livello di isolamento del tenant influisce su COGS e sulle prestazioni per tutti? Alcuni modelli di prezzi non sono redditizi senza controlli aggiuntivi relativi all'allocazione delle risorse. Ad esempio, potrebbe essere necessario implementare la limitazione dei servizi per rendere sostenibile un modello tariffario a tariffa fissa.
• Ciclo di vita del tenant. Ad esempio, le soluzioni con tassi elevati di varianza dei clienti o servizi che richiedono un maggiore impegno di onboarding possono subire una riduzione della redditività, specialmente se vengono addebitati prezzi usando un modello basato sul consumo.
• Requisiti del livello di servizio. I tenant che richiedono livelli di servizio più elevati possono significare che la soluzione non è più redditizia. È fondamentale chiarire le aspettative a livello di servizio dei clienti e gli eventuali obblighi previsti, in modo da poter pianificare i modelli di determinazione dei prezzi di conseguenza.

Modelli di determinazione dei prezzi comuni

Esistono molti modelli di prezzi comuni che vengono spesso usati con soluzioni multi-tenant. Ognuno di questi modelli di prezzi presenta vantaggi e rischi commerciali associati e richiede considerazioni aggiuntive sull'architettura. È importante comprendere le differenze tra questi modelli di determinazione dei prezzi, in modo da garantire che la soluzione rimanga redditizia man mano che si evolve.

Nota

È possibile offrire più modelli per una soluzione o combinare i modelli. Ad esempio, è possibile fornire un modello per utente per i clienti con numeri utente abbastanza stabili ed è anche possibile offrire un modello di consumo per i clienti che hanno modelli di utilizzo fluttuanti.

prezzi a consumo

Un modello a consumo viene talvolta definito con pagamento in base al consumo o pagamento in base al consumo. Man mano che aumenta l'uso del servizio, i ricavi aumentano:

Quando si misura l'utilizzo, è possibile considerare fattori semplici, ad esempio la quantità di dati da aggiungere alla soluzione. In alternativa, è possibile considerare una combinazione di attributi di utilizzo insieme. I modelli a consumo offrono molti vantaggi, ma possono essere difficili da implementare in una soluzione multi-tenant.

Vantaggi: dal punto di vista dei clienti, è necessario un investimento iniziale minimo necessario per usare la soluzione, in modo che questo modello abbia una barriera bassa per l'ingresso. Dal punto di vista dell'operatore del servizio, i costi di hosting e gestione aumentano con l'aumento dell'utilizzo dei clienti e dei ricavi. Questo aumento può rendere un modello di determinazione prezzi altamente scalabile. I modelli di determinazione dei prezzi a consumo funzionano particolarmente bene quando anche i servizi di Azure usati nella soluzione sono basati sul consumo.

Complessità e costi operativi: i modelli a consumo si basano su misurazioni accurate dell'utilizzo e sulla suddivisione di questo utilizzo per tenant. Ciò può risultare complesso, soprattutto in una soluzione con molti componenti distribuiti. È necessario mantenere i record di consumo dettagliati per la fatturazione e il controllo, nonché fornire metodi per i clienti per ottenere l'accesso ai dati di consumo.

Rischi: i prezzi a consumo possono motivare i clienti a ridurre l'utilizzo del sistema, al fine di ridurre i costi. Inoltre, i modelli di consumo generano flussi di ricavi imprevedibili. È possibile attenuare questo problema offrendo prenotazioni di capacità, in cui i clienti pagano per un certo livello di consumo iniziale. L'utente, in qualità di provider di servizi, può usare questi ricavi per investire in miglioramenti nella soluzione, per ridurre il costo operativo o per aumentare il rendimento sul valore aggiungendo funzionalità.

Nota

L'implementazione e il supporto delle prenotazioni di capacità possono aumentare la complessità dei processi di fatturazione all'interno dell'applicazione. Potrebbe anche essere necessario considerare il modo in cui i clienti ottengono rimborsi o scambiano le prenotazioni di capacità e questi processi possono anche aggiungere problemi commerciali e operativi.

Prezzi per utente

Un modello di determinazione prezzi per utente prevede l'addebito dei clienti in base al numero di persone che usano il servizio, come illustrato nel diagramma seguente.

I modelli di prezzi per utente sono molto comuni, a causa della loro semplicità di implementazione in una soluzione multi-tenant. Tuttavia, sono associati a diversi rischi commerciali.

Vantaggi: quando si fatturano i clienti per ogni utente, è facile calcolare e prevedere il flusso dei ricavi. Inoltre, supponendo di avere modelli di utilizzo abbastanza coerenti per ogni utente, i ricavi aumentano allo stesso tasso di adozione del servizio, rendendo questo modello scalabile.

Complessità e costi operativi: i modelli per utente tendono a essere facili da implementare. Tuttavia, in alcune situazioni, è necessario misurare il consumo per utente, che consente di garantire che COGS per un singolo utente rimanga redditizio. Misurando il consumo e associandolo a un determinato utente, è possibile aumentare la complessità operativa della soluzione.

Rischi: i diversi modelli di consumo degli utenti possono comportare una riduzione della redditività. Ad esempio, gli utenti pesanti della soluzione potrebbero costare di più per servire rispetto agli utenti leggeri. Inoltre, il rendimento effettivo sul valore (ROV) per la soluzione non si riflette sul numero effettivo di licenze utente acquistate.

Prezzi per utente attivo

Questo modello è simile ai prezzi per utente, ma invece di richiedere un impegno iniziale del cliente sul numero di utenti previsti, il cliente viene addebitato solo per gli utenti che accedono e usano effettivamente la soluzione in un periodo (come illustrato nel diagramma seguente).

È possibile misurare questo in qualsiasi periodo abbia senso. I periodi mensili sono comuni e questa metrica viene spesso registrata come utenti attivi mensili o MAU.

Vantaggi: dal punto di vista dei clienti, questo modello richiede un basso investimento e un rischio, perché ci sono rifiuti minimi; le licenze inutilizzate non sono fatturabili. Ciò rende particolarmente interessante quando si marketing la soluzione o si aumenta la soluzione per i clienti aziendali più grandi. Dal punto di vista del proprietario del servizio, il tuo ROV si riflette in modo più accurato sul cliente in base al numero di utenti attivi mensili.

Complessità e costi operativi: i modelli utente attivi richiedono di registrare l'utilizzo effettivo e di renderlo disponibile a un cliente come parte della fattura. La misurazione del consumo per utente consente di garantire che la redditività venga mantenuta con COGS per un singolo utente, ma anche in questo caso richiede un lavoro aggiuntivo per misurare il consumo per ogni utente.

Rischi: analogamente ai prezzi per utente, esiste un rischio che i diversi modelli di consumo dei singoli utenti possano influire sulla redditività. Rispetto ai prezzi per utente, i modelli utente attivi hanno un flusso di ricavi meno prevedibile. Inoltre, i prezzi di sconto non forniscono un modo utile per stimolare la crescita.

Prezzi per unità

In molti sistemi, il numero di utenti non è l'elemento che ha il massimo effetto sul COGS complessivo. Ad esempio, nelle soluzioni orientate ai dispositivi, dette anche Internet delle cose o IoT, il numero di dispositivi ha spesso il maggiore impatto su COGS. In questi sistemi è possibile usare un modello di determinazione prezzi per unità, in cui si definisce l'unità, ad esempio un dispositivo. Vedere il diagramma seguente.

Inoltre, alcune soluzioni hanno modelli di utilizzo altamente variabili, in cui un numero ridotto di utenti ha un impatto sproporzionato su COGS. Ad esempio, in una soluzione venduta ai rivenditori di mattoni e malta, un modello di prezzi per negozio potrebbe essere appropriato.

Vantaggi: nei sistemi in cui i singoli utenti non hanno un effetto significativo su COGS, i prezzi per unità rappresentano un modo migliore per rappresentare la realtà del modo in cui il sistema viene ridimensionato e l'impatto risultante su COGS. Può anche migliorare l'allineamento ai modelli effettivi di utilizzo per un cliente. Per molte soluzioni IoT, in cui ogni dispositivo genera un consumo prevedibile e costante, può essere un modello efficace per ridimensionare la crescita della soluzione.

Complessità e costi operativi: in genere, i prezzi per unità sono facili da implementare e hanno un costo operativo piuttosto basso. Tuttavia, il costo operativo può diventare più elevato se è necessario distinguere e tenere traccia dell'utilizzo in base a singole unità, ad esempio dispositivi o punti vendita al dettaglio. La misurazione del consumo per unità consente di garantire che la redditività venga mantenuta, poiché è possibile determinare cogS per una singola unità.

Rischi: i rischi di un modello di determinazione prezzi per unità sono simili ai prezzi per utente. Modelli di consumo diversi per alcune unità possono significare una riduzione della redditività, ad esempio se alcuni dispositivi o negozi sono utenti molto più pesanti della soluzione rispetto ad altri.

Prezzi basati sulle funzionalità e sul livello di servizio

È possibile scegliere di offrire la soluzione con diversi livelli di funzionalità in punti di prezzo diversi. Ad esempio, è possibile fornire due prezzi fissi mensili o per unità, uno è un'offerta di base con un subset di funzionalità disponibili e l'altra che presenta il set completo delle funzionalità della soluzione. Vedere il diagramma seguente.

Questo modello può anche offrire contratti di servizio diversi per livelli diversi. Ad esempio, il livello Basic può offrire un tempo di attività del 99,9%, mentre un livello Premium può offrire il 99,99%. È possibile implementare un contratto di servizio superiore usando servizi e funzionalità che consentono obiettivi di disponibilità più elevati.

Anche se questo modello può essere commercialmente vantaggioso, richiede procedure di progettazione mature per fare bene. Con un'attenta considerazione, questo modello può essere molto efficace.

Vantaggi: i prezzi basati sulle funzionalità sono spesso interessanti per i clienti, poiché possono selezionare un livello in base al set di funzionalità o al livello di servizio di cui hanno bisogno. Offre anche un percorso chiaro per l'upselling dei clienti con funzionalità aggiuntive o maggiore resilienza per coloro che lo richiedono.

Complessità e costi operativi: i modelli di determinazione prezzi basati sulle funzionalità possono essere complessi da implementare, perché richiedono che la soluzione sia consapevole delle funzionalità disponibili a ogni livello di prezzo. Gli interruttori di funzionalità possono essere un modo efficace per fornire l'accesso a determinati subset di funzionalità, ma ciò richiede una manutenzione continuativa. Inoltre, gli interruttori delle funzionalità aumentano il sovraccarico per garantire una qualità elevata, perché saranno disponibili più percorsi di codice da testare. L'abilitazione di destinazioni di disponibilità del servizio più elevate in alcuni livelli può richiedere complessità dell'architettura aggiuntive, per garantire che il set corretto di infrastruttura venga usato per ogni livello e questo processo può aumentare il costo operativo della soluzione.

Rischi: i modelli di determinazione prezzi basati sulle funzionalità possono diventare complicati e confusi, se sono presenti troppi livelli o opzioni. Inoltre, il sovraccarico dovuto all'attivazione dinamica delle funzionalità può rallentare la velocità con cui si offrono funzionalità aggiuntive.

Prezzi di Freemium

È possibile scegliere di offrire un livello gratuito del servizio, con funzionalità di base e senza garanzie a livello di servizio. È quindi possibile offrire un livello a pagamento separato, con funzionalità aggiuntive e un contratto di servizio formale (come illustrato nel diagramma seguente).

Il livello gratuito può anche essere offerto come versione di valutazione limitata a tempo e durante la versione di valutazione i clienti potrebbero avere funzionalità complete o limitate. Si tratta di un modello freemium, che è in effetti un'estensione del modello di determinazione prezzi basato sulle funzionalità.

Vantaggi: è molto facile commercializzare una soluzione quando è gratuita.

Complessità e costo operativo: tutte le problematiche relative alla complessità e ai costi operativi si applicano al modello di determinazione prezzi basato sulle funzionalità. Tuttavia, è necessario considerare anche il costo operativo necessario per la gestione dei tenant gratuiti. Potrebbe essere necessario assicurarsi che i tenant non aggiornati siano inattivi o rimossi ed è necessario disporre di criteri di conservazione chiari, in particolare per i tenant gratuiti. Quando si promuove un tenant a un livello a pagamento, potrebbe essere necessario spostare il tenant tra i servizi di Azure per ottenere contratti di servizio più elevati. Sarà anche importante conservare i dati e la configurazione del tenant quando si passa a un livello a pagamento.

Rischi: è necessario assicurarsi di fornire un ROV sufficientemente elevato per i tenant per valutare la possibilità di passare a un livello a pagamento. Inoltre, il costo di fornire la soluzione ai clienti nel livello gratuito deve essere coperto dal margine di profitto di coloro che sono su livelli a pagamento.

Costo delle merci vendute prezzi

È possibile scegliere di prezzi per la soluzione in modo che ogni tenant paghi solo il costo di gestione della quota dei servizi di Azure, senza alcun margine di profitto aggiunto. Questo modello, detto anche pass-through cost o pricing , viene talvolta usato per soluzioni multi-tenant che non sono destinate a essere un centro di profitto.

Il costo del modello venduto di beni è ideale per le soluzioni multi-tenant internamente. Ogni unità organizzativa corrisponde a un tenant e i costi delle risorse di Azure devono essere distribuiti tra di essi. Può anche essere appropriato se i ricavi derivano dalle vendite di altri prodotti e servizi che utilizzano o aumentano la soluzione multi-tenant.

Vantaggi: poiché questo modello non include alcun margine aggiuntivo per il profitto, il costo per i tenant sarà inferiore.

Complessità e costo operativo: analogamente al modello di consumo, il costo dei prezzi venduti delle merci si basa su misurazioni accurate dell'utilizzo e sulla suddivisione dell'utilizzo per tenant. Il rilevamento dell'utilizzo può essere complesso, soprattutto in una soluzione con molti componenti distribuiti. È necessario mantenere i record di consumo dettagliati per la fatturazione e il controllo, nonché fornire metodi per i clienti per ottenere l'accesso ai dati di consumo.

Per le soluzioni multi-tenant rivolte internamente, i tenant possono accettare stime approssimative dei costi e avere requisiti di controllo della fatturazione più rilassati. Questi requisiti rilassati riducono la complessità e il costo della gestione della soluzione.

Rischi: il costo dei prezzi venduti di beni può motivare i tenant a ridurre l'utilizzo del sistema, al fine di ridurre i costi. Tuttavia, poiché questo modello viene usato per le applicazioni che non sono centri di profitto, questo potrebbe non essere un problema.

Prezzi a tariffa fissa

In questo modello viene addebitata una tariffa fissa a un tenant per l'accesso alla soluzione per un determinato periodo di tempo. Lo stesso prezzo si applica indipendentemente dalla quantità di servizio usata, dal numero di utenti, dal numero di dispositivi che si connettono o da qualsiasi altra metrica. Vedere il diagramma seguente.

Si tratta del modello più semplice da implementare e per consentire ai clienti di comprendere e spesso richiesto dai clienti aziendali. Tuttavia, può diventare facilmente poco professionale se è necessario continuare ad aggiungere nuove funzionalità o se il consumo di tenant aumenta senza ricavi aggiuntivi.

Vantaggi: i prezzi a tariffa fissa sono facili da vendere ed è facile per i clienti comprendere e budget.

Complessità e costi operativi: i modelli di determinazione prezzi a tariffa fissa possono essere facili da implementare perché i clienti di fatturazione non richiedono alcun consumo di misurazione o monitoraggio. Tuttavia, anche se non è essenziale, è consigliabile misurare il consumo per tenant per assicurarsi di misurare in modo accurato COGS e garantire che la redditività venga mantenuta.

Rischi: se si dispone di tenant che usano pesantemente la soluzione, è facile che questo modello di prezzi diventi poco professionale.

Prezzi degli sconti

Dopo aver definito il modello di determinazione dei prezzi, è possibile scegliere di implementare strategie commerciali per stimolare la crescita tramite i prezzi degli sconti. I prezzi degli sconti possono essere usati con modelli di prezzi a consumo, per utente e per unità.

Nota

I prezzi degli sconti non richiedono in genere considerazioni sull'architettura, oltre all'aggiunta del supporto per una struttura di fatturazione più complessa. Una discussione completa sui vantaggi commerciali dello sconto esula dall'ambito di questo documento.

I modelli di prezzi di sconto comuni includono:

• Prezzi fissi. Si ha lo stesso costo per ogni utente, unità o quantità di consumo, indipendentemente dalla quantità acquistata o utilizzata. Questo è l'approccio più semplice. Tuttavia, i clienti che fanno un uso pesante della soluzione possono sentirsi come se avessero dovuto trarre vantaggio dalle economie di scala ottenendo uno sconto.
• Prezzi in uscita. Man mano che i clienti acquistano o consumano più unità, si riduce il costo per unità. Questo è più attraente per i clienti.
• Prezzi dei passaggi. Si riduce il costo per unità, man mano che i clienti acquistano di più. A tale scopo, tuttavia, si modificano i passaggi, in base a intervalli predefiniti di quantità. Ad esempio, è possibile addebitare un prezzo più alto per i primi 100 utenti, quindi un prezzo inferiore per il 101 e il 200° utente, quindi un prezzo più basso dopo questo. Questo può essere più redditizio.

Il diagramma seguente illustra questi modelli di determinazione dei prezzi.

Sconti per ambienti non di produzione

In molti casi, i clienti richiedono l'accesso a un ambiente non di produzione che possono usare per il test, il training o per la creazione della propria documentazione interna. Gli ambienti non di produzione hanno in genere requisiti e costi di consumo inferiori da gestire. Ad esempio, gli ambienti non di produzione spesso non sono soggetti a contratti di servizio e i limiti di frequenza potrebbero essere impostati a valori inferiori. È anche possibile prendere in considerazione una scalabilità automatica più aggressiva nei servizi di Azure.

Allo stesso modo, i clienti spesso si aspettano che gli ambienti non di produzione siano notevolmente più economici rispetto agli ambienti di produzione. Esistono diverse alternative che potrebbero essere appropriate quando si forniscono ambienti non di produzione:

• Offrire un livello freemium, come si potrebbe già fare per i clienti a pagamento. Questa operazione deve essere monitorata attentamente, perché alcune organizzazioni potrebbero creare molti ambienti di test e training, che utilizzeranno risorse aggiuntive per funzionare.

  Nota

  Le versioni di valutazione limitate a tempo che usano livelli freemium non sono in genere adatte per ambienti di test e training. I clienti hanno in genere bisogno che gli ambienti non di produzione siano disponibili per la durata del servizio di produzione.

• Offrire un livello di test o training del servizio, con limiti di utilizzo inferiori. È possibile scegliere di limitare la disponibilità di questo livello ai clienti che dispongono di un tenant a pagamento esistente.
• Offrire un prezzo scontato per utente, per utente attivo o per unità per tenant non di produzione, con un contratto di servizio inferiore o nessun contratto di servizio.
• Per i tenant che usano prezzi a tariffa fissa, gli ambienti non di produzione potrebbero essere negoziati come parte dell'accordo.

Nota

I prezzi basati sulle funzionalità non sono in genere un'opzione valida per gli ambienti non di produzione, a meno che le funzionalità offerte non siano le stesse offerte dall'ambiente di produzione. Ciò è dovuto al fatto che i tenant vogliono in genere testare e fornire training su tutte le stesse funzionalità disponibili per loro nell'ambiente di produzione.

Modelli di determinazione prezzi non aggiornabili

Un modello tariffario non redditizio costa più per fornire il servizio rispetto ai ricavi guadagnati. Ad esempio, è possibile addebitare una tariffa fissa per tenant senza limiti per il servizio, ma si creerà il servizio con risorse di Azure basate sul consumo e senza limiti di utilizzo per tenant. In questa situazione, è possibile che i tenant sovrasfruttino il servizio e, di conseguenza, renderli inutilizzabili per gestirli.

In genere, è consigliabile evitare modelli di determinazione prezzi non aggiornabili. Tuttavia, esistono situazioni in cui è possibile scegliere di adottare un modello di determinazione prezzi non aggiornabile, tra cui:

• Viene offerto un servizio gratuito per consentire la crescita.
• I flussi di ricavi aggiuntivi vengono forniti da servizi o funzionalità aggiuntive.
• L'hosting di un tenant specifico fornisce un altro valore commerciale, ad esempio usarli come tenant di ancoraggio in un nuovo mercato.

Nel caso in cui si crei inavvertitamente un modello di determinazione prezzi non aggiornabile, esistono alcuni modi per attenuare i rischi associati, tra cui:

• Limitare l'uso del servizio tramite limiti di utilizzo.
• Richiedere l'uso delle prenotazioni di capacità.
• Richiedere il passaggio del tenant a una funzionalità o a un livello di servizio superiore.

Modelli di prezzi rischiosi

Quando si implementa un modello di determinazione prezzi per una soluzione, in genere è necessario fare ipotesi su come verrà usato. Se questi presupposti risultano non corretti o i modelli di utilizzo cambiano nel tempo, il modello di determinazione prezzi potrebbe non essere più redditizio. I modelli di determinazione dei prezzi a rischio di diventare non redditizi sono noti come modelli di determinazione dei prezzi rischiosi. Ad esempio, se si adotta un modello di determinazione prezzi che prevede che gli utenti limitino automaticamente la quantità di utilizzo della soluzione, è possibile che sia stato implementato un modello di determinazione dei prezzi rischioso.

La maggior parte delle soluzioni SaaS aggiungerà regolarmente nuove funzionalità. Questo aumenta il ROV agli utenti, che possono anche portare ad aumenti nella quantità usata dalla soluzione. Ciò potrebbe comportare una soluzione che diventa poco professionale, se l'uso di nuove funzionalità determina l'utilizzo, ma il modello di determinazione prezzi non tiene conto di questo aspetto.

Ad esempio, se si introduce una nuova funzionalità di caricamento video nella soluzione, che usa una risorsa basata sul consumo e l'assorbimento dell'utente della funzionalità è superiore al previsto, prendere in considerazione una combinazione di limiti di utilizzo e funzionalità e prezzi a livello di servizio.

Limiti di utilizzo

I limiti di utilizzo consentono di limitare l'utilizzo del servizio per evitare che i modelli di determinazione dei prezzi diventino inutili o impedire a un singolo tenant di utilizzare una quantità sproporzionata della capacità del servizio. Ciò può essere particolarmente importante nei servizi multi-tenant, in cui un singolo tenant può influire sull'esperienza di altri tenant consumando eccessivamente le risorse.

Nota

È importante rendere i clienti consapevoli dell'applicazione dei limiti di utilizzo. Se si implementano limiti di utilizzo senza che i clienti siano consapevoli del limite, ciò comporterà l'insoddisfazione dei clienti. Ciò significa che è importante identificare e pianificare i limiti di utilizzo in anticipo. L'obiettivo deve essere quello di pianificare il limite e di comunicare i limiti ai clienti prima che diventino necessari.

I limiti di utilizzo vengono spesso usati in combinazione con le funzionalità e i prezzi a livello di servizio, per offrire una quantità di utilizzo più elevata a livelli più elevati. I limiti vengono comunemente usati anche per proteggere i componenti di base che causano colli di bottiglia o problemi di prestazioni del sistema, se vengono utilizzati eccessivamente.

Limiti di richieste inviate al bot

Un modo comune per applicare un limite di utilizzo consiste nell'aggiungere limiti di frequenza alle API o a funzioni dell'applicazione specifiche. Questa operazione è nota anche come limitazione. I limiti di frequenza impediscono l'overuse continuo. Vengono spesso usati per limitare il numero di chiamate a un'API, in un periodo di tempo definito. Ad esempio, un'API può essere chiamata solo 20 volte al minuto e restituirà un errore HTTP 429, se viene chiamato più frequentemente di questo.

In alcune situazioni, in cui viene spesso usata la limitazione della frequenza, includere quanto segue:

• API REST.
• Attività asincrone.
• Attività che non sono sensibili al tempo.
• Azioni che comportano un costo elevato da eseguire.
• Generazione di report.

L'implementazione della limitazione della frequenza può aumentare la complessità della soluzione, ma i servizi come Azure Gestione API possono semplificare applicando i criteri di limite di velocità.

Ciclo di vita del modello tariffario

Come qualsiasi altra parte della soluzione, i modelli tariffari hanno un ciclo di vita. Man mano che l'applicazione si evolve nel tempo, potrebbe essere necessario modificare i modelli di determinazione prezzi. Ciò può essere determinato dalla modifica delle esigenze dei clienti, dei requisiti commerciali o delle modifiche alle funzionalità all'interno dell'applicazione. Di seguito sono riportate alcune modifiche comuni del ciclo di vita dei prezzi:

• Aggiunta di un modello di determinazione prezzi completamente nuovo. Ad esempio, l'aggiunta di un modello di determinazione prezzi a consumo a una soluzione che attualmente offre un modello a tariffa fissa.
• Ritiro di un modello di determinazione prezzi esistente.
• Aggiunta di un livello a un modello di determinazione prezzi esistente.
• Ritiro di un livello in un modello di determinazione prezzi esistente.
• Modifica dei limiti di utilizzo per una funzionalità in un modello di determinazione prezzi.
• Aggiunta o rimozione di funzionalità da un modello tariffario a livello di servizio e funzionalità.
• Passaggio da un modello commerciale business-to-consumer (B2C) a un modello commerciale business-to-business (B2B). Questa modifica richiede quindi nuove strutture tariffarie per i clienti aziendali.

In genere è complesso implementare e gestire molti modelli di determinazione prezzi diversi contemporaneamente. È anche confusa con i clienti. È quindi preferibile implementare solo uno o due modelli, con un numero ridotto di livelli. In questo modo la soluzione risulta più accessibile e più semplice da gestire.

Nota

I modelli di determinazione dei prezzi e le funzioni di fatturazione devono essere testati, idealmente usando test automatizzati, proprio come qualsiasi altra parte del sistema. Più complessi sono i modelli di determinazione dei prezzi, maggiore è il numero di test necessari e quindi il costo dello sviluppo e delle nuove funzionalità aumenterà.

Quando si modificano i modelli di determinazione dei prezzi, è necessario considerare i fattori seguenti:

• I tenant vogliono eseguire la migrazione al nuovo modello?
• È facile per i tenant eseguire la migrazione al nuovo modello?
• I nuovi modelli tariffari espongono il servizio a rischi? Ad esempio, si stanno rimuovendo i limiti di frequenza che attualmente proteggono le risorse critiche dall'uso eccessivo?
• I tenant hanno un percorso chiaro per la migrazione al nuovo modello di prezzi?
• In che modo si impedisce ai tenant di usare modelli di prezzi meno recenti, in modo da poterli ritirare?
• È probabile che i tenant ricevano uno shock della fattura (una reazione negativa a una fattura imprevista) al momento della modifica dei modelli di determinazione prezzi?
• Si monitorano le prestazioni e l'utilizzo dei servizi, per modelli di determinazione prezzi nuovi o modificati, in modo da garantire una redditività continua?
• È possibile comunicare chiaramente la versione ROV per i nuovi modelli di determinazione prezzi ai tenant esistenti?

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Daniel Scott-Raynsford | Partner Technology Strategist

Altri contributori:

• Bohdan Cherchyk | Senior Customer Engineer, FastTrack per Azure
• John Downs | Principal Customer Engineer, FastTrack per Azure
• Chad Kittel | Principal Software Engineer
• Paolo Salvatori | Principal Customer Engineer, FastTrack per Azure
• Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Valutare come misurare il consumo in base ai tenant nella soluzione.