Quando si considera un'architettura multi-tenant, sono necessarie diverse decisioni da prendere e elementi da considerare.
In un'architettura multi-tenant si condividono alcune o tutte le risorse tra i tenant. Questo processo significa che un'architettura multi-tenant può offrire efficienza in termini di costi e operazioni. Tuttavia, il multi-tenancy comporta alcune complessità, ad esempio:
- Come si definisce qual è il tenant , per la soluzione specifica? Un tenant corrisponde a un cliente, a un utente o a un gruppo di utenti (ad esempio un team)?
- Come si distribuirà l'infrastruttura per supportare il multi-tenancy e che livello di isolamento si avrà tra i tenant?
- Quali modelli di prezzi commerciali offrono la soluzione e come i modelli di prezzi influiscono sui requisiti di multitenancy?
- Quale livello di servizio deve essere garantito ai tenant? Prendere in considerazione i requisiti relativi a prestazioni, resilienza, sicurezza e conformità, ad esempio la residenza dei dati.
- Come si prevede di far crescere l'azienda o la soluzione e, in questo caso, il numero di tenant previsti verrà ridimensionato?
- Uno dei tenant presenta requisiti insoliti o speciali? Ad esempio, il cliente più grande necessita di prestazioni più elevate o garanzie più solide rispetto agli altri?
- In che modo è possibile monitorare, gestire, automatizzare, ridimensionare e governare l'ambiente di Azure e qual è l'impatto sul multi-tenancy?
- Quali componenti della soluzione gestiscono l'onboarding e la gestione del tenant e come è necessario progettare questi componenti?
Requisiti
Indipendentemente dall'architettura, è essenziale avere una chiara comprensione dei requisiti dei clienti o dei tenant. Se si sono presi impegni di vendita per i clienti o se si hanno obblighi contrattuali o requisiti di conformità per soddisfare, è necessario conoscere quali requisiti sono quando si progetta la soluzione. Tuttavia, i clienti potrebbero avere aspettative implicite su come funzionare le cose o su come si dovrebbe comportare, che potrebbe influire sul modo in cui si progetta una soluzione multi-tenant.
Ad esempio, si supponga di creare una soluzione multi-tenant che si vende alle aziende nel settore dei servizi finanziari. I clienti hanno requisiti di sicurezza molto rigorosi e devono fornire un elenco completo di ogni nome di dominio usato dalla soluzione, in modo che possano aggiungerli all'elenco di autorizzazioni del firewall. Questo requisito influisce sui servizi di Azure usati e sul livello di isolamento che è necessario fornire tra i tenant. Richiedono inoltre che la loro soluzione abbia un livello minimo di resilienza. Potrebbero esserci molte aspettative simili, esplicite e implicite, che è necessario prendere in considerazione nell'intera soluzione.
In questa sezione vengono descritte le considerazioni da fornire, i requisiti che è consigliabile assegnare e alcuni dei compromessi necessari per pianificare un'architettura multi-tenant.
Destinatari
Gli articoli di questa sezione sono particolarmente rilevanti per i responsabili tecnici, ad esempio i responsabili della tecnologia (CTOs) e gli architetti, nonché i responsabili dei prodotti. Il pubblico include anche fornitori di software indipendenti (ISV) e startup che sviluppano soluzioni SaaS. Inoltre, chiunque funzioni con architetture multi-tenant deve avere familiarità con questi principi e compromessi.
Passaggi successivi
Prendere in considerazione diversi modelli di tenancy per la soluzione.