In più script abbiamo parlato di Azure Cosmos Db, strumento tra i più importanti servizi offerti dalla piattaforma Azure, perché in ottica PaaS ci fornisce un database documentale, e non solo, geo distribuito dalle altissime prestazioni.

Il throughput è la variabile fondamentale che ci troviamo a dovere dimensionare per poter decidere quanto carico di lavoro il database può supportare e di conseguenza la velocità e il numero di richieste concorrenti che riusciamo a soddisfare. Questo numero, espresso in RU/s, è in funzione della dimensione del documento che andiamo a leggere e a scrivere, e del tipo di operazione effettuate. Trovare un numero non è facile, perché esso costituisce un costo fisso e non possiamo quindi permetterci né di esagerare né di sottodimensionare le capacità.

Inoltre, ci sono scenari in cui il carico di lavoro non è prevedibile, oppure ancora dove gli applicativi hanno lunghi periodi di inattività, oppure dove effettuiamo dei grossi carichi di lavoro temporanei per poi mantenere inutilizzato il database. In queste situazioni l'autoscale, introdotto recentemente, è la soluzione più adatta. In pratica diamo un tetto massimo di RU/s che il database può raggiungere e istantaneamente il limite si adatta per soddisfare tutte le richieste che arrivano.

Possiamo abilitare l'autoscale su container o database già presenti oppure in fase di creazione degli stessi, e in qualsiasi momento tornare al sistema manuale. Se throughput è distribuito per l'intero database, anche l'autoscale può essere applicato a più container. Nell'immagine seguente si vede il flag da abilitare.

Il tetto massimo è fondamentale per tenere sotto controllo i costi. E' facile essere tentati, infatti, a mettere un max RU/s molto alto, ma bisogna considerare che basta un picco di richiesta per far sì che un'intera ora che venga contabilizzata con le RU/s che sono state necessarie per quel picco. Abbiamo quindi un adattamento e un costo piuttosto aderente con dei limiti che vanno tenuti in considerazione. Va inoltre considerato che le RU/s, in caso di mancato utilizzo del database, non scendono comunque sotto le 400 RU/s, andando a costituire il costo minimo mensile.