Esistono molti modi diversi per progettare e creare soluzioni multi-tenant in Azure. A un estremo, è possibile condividere ogni risorsa nella soluzione tra tutti i tenant. In altri casi, è possibile distribuire risorse isolate per ogni tenant. Potrebbe sembrare semplice distribuire risorse separate per ogni tenant e può funzionare per un numero ridotto di tenant. Tuttavia, in genere non offre un'efficacia dei costi e può diventare difficile gestire le risorse. Esistono anche diversi approcci che si adattano a questi estremi e hanno tutti compromessi come scalabilità, isolamento, efficienza dei costi, prestazioni, complessità di implementazione e gestibilità.
In questa sezione vengono illustrate le principali categorie di servizi di Azure che comprendono una soluzione, tra cui calcolo, archiviazionee dati, rete, distribuzione, identità, messaggistica, intelligenza artificiale e Machine Learning e IoT. Per ogni categoria vengono descritti i modelli chiave e gli approcci che è possibile considerare quando si progetta una soluzione multi-tenant e alcuni antipattern da evitare.
Modello degli stamp di distribuzione
Il modello Deployment Stamps viene spesso usato nelle soluzioni multi-tenant. Implica la distribuzione di un'infrastruttura dedicata per un tenant o per un gruppo di tenant. Un singolo timbro può contenere più tenant o può essere dedicato a un singolo tenant.
Quando si usano indicatori a tenant singolo, il modello Deployment Stamps tende a essere semplice da implementare, perché ogni stamp è probabilmente inconsapevole di qualsiasi altro, quindi non è necessario integrare logica o funzionalità multi-tenancy nel livello dell'applicazione. Quando ogni tenant ha un proprio timbro dedicato, questo modello fornisce il massimo grado di isolamento e attenua il problema Noisy Neighbor.When each tenant has their own dedicated stamp, this pattern provides the highest degree of isolation, and it mitigate the Noisy Neighbor problem. Offre anche la possibilità di configurare o personalizzare i tenant in base ai propri requisiti, ad esempio per trovarsi in un'area geopolitica specifica o per avere requisiti specifici di disponibilità elevata.
Quando si usano timbri multi-tenant, è necessario considerare altri modelli per gestire la multi-tenancy all'interno del timbro e il problema Noisy Neighbor potrebbe comunque essere applicato. Tuttavia, usando il modello Deployment Stamps, è possibile continuare a ridimensionare man mano che la soluzione cresce.
Il problema principale con il modello Deployment Stamps, quando viene usato per gestire un singolo tenant, tende a essere il costo dell'infrastruttura. Quando si usano indicatori a tenant singolo, ogni stamp deve avere un proprio set separato di infrastruttura, che non è condiviso con altri tenant. È anche necessario assicurarsi che le risorse distribuite per un timbro siano sufficienti per soddisfare il carico massimo per il carico di lavoro del tenant. Assicurarsi che il modello di determinazione prezzi compensi il costo della distribuzione per l'infrastruttura del tenant.
I timbri a tenant singolo spesso funzionano correttamente quando si dispone di un numero ridotto di tenant. Man mano che aumenta il numero di tenant, è possibile, ma sempre più difficile gestire una flotta di francobolli (vedere questo case study come esempio). È anche possibile applicare il modello Stamp di distribuzione per creare una flotta di francobolli multi-tenant, che possono offrire vantaggi per la condivisione delle risorse e dei costi.
Per implementare il modello Deployment Stamps, è importante usare approcci di distribuzione automatizzati. A seconda della strategia di distribuzione, è possibile valutare la possibilità di gestire i timbri all'interno delle pipeline di distribuzione usando un'infrastruttura dichiarativa come codice, ad esempio Bicep, modelli arm o modelli Terraform. In alternativa, è possibile prendere in considerazione la creazione di codice personalizzato per distribuire e gestire ogni stamp, ad esempio usando Gli SDK di Azure.
Destinatari
Gli articoli di questa sezione sono destinati a essere utili per architetti di soluzioni e sviluppatori di applicazioni multi-tenant, inclusi fornitori di software indipendenti (ISV) e startup che sviluppano soluzioni SaaS. Gran parte delle indicazioni contenute in questa sezione è generica e si applica a più servizi di Azure all'interno di una categoria.
Passaggi successivi
È consigliabile esaminare gli approcci per l'organizzazione delle risorse in una soluzione multi-tenant prima di esaminare le indicazioni sulle categorie specifiche di servizi di Azure.