Esistono molti modi diversi per progettare e creare soluzioni multi-tenant in Azure. Ad un estremo, è possibile condividere ogni risorsa nella soluzione tra tutti i tenant. All'altra estremità, è 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'efficienza dei costi e può diventare difficile gestire le risorse. Esistono anche diversi approcci che rientrano tra questi estremi e richiedono tutti compromessi tra scalabilità, isolamento, efficienza dei costi, prestazioni, complessità di implementazione e gestibilità.
In questa sezione vengono illustrate le categorie principali di servizi di Azure che comprendono una soluzione, tra cui calcolo, archiviazione e 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 prendere in considerazione quando si progetta una soluzione multi-tenant e alcuni antipattern per 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 potrebbe servire più tenant o potrebbe 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 non è a conoscenza di qualsiasi altro, quindi non è necessario integrare alcuna 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 riduce il problema Noisy Neighbor. 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 di disponibilità elevata specifici.
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 ancora essere applicato. Tuttavia, usando il modello Stamp di distribuzione, è possibile continuare a ridimensionare man mano che la soluzione cresce.
Il problema principale con lo schema Deployment Stamps, quando viene usato per servire un singolo tenant, tende a essere il costo dell'infrastruttura. Ogni stamp deve avere un proprio set separato di infrastruttura e l'infrastruttura non viene condivisa con altri tenant. È anche necessario assicurarsi che le risorse distribuite per un timbro siano sufficienti per soddisfare il carico di lavoro massimo per il carico di lavoro del tenant. Assicurarsi che il modello di determinazione prezzi scosti il costo della distribuzione per l'infrastruttura del tenant.
I timbri a tenant singolo spesso funzionano bene 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 timbri a tenant singolo (vedere questo case study come esempio). È anche possibile applicare il modello Stamp di distribuzione per creare timbri 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 prendere in considerazione la gestione dei timbri all'interno delle pipeline di distribuzione usando un'infrastruttura dichiarativa come codice, ad esempio file Bicep 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 leader 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 su categorie specifiche di servizi di Azure.