Quando si prende in considerazione un'architettura multi-tenant, è necessario prendere diverse decisioni ed elementi da prendere in considerazione.
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, la multi-tenancy introduce complessità. È necessario porsi le domande seguenti:
- Come si definisce cos'è un tenant per la soluzione specifica? Un tenant corrisponde a un cliente, a un utente o a un gruppo di utenti come un team o una famiglia?
- 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 offriranno la soluzione e in che modo i modelli tariffari influiscono sui requisiti di multi-tenancy?
- Quale livello di servizio è necessario fornire ai tenant, tra dimensioni quali prestazioni, resilienza, sicurezza e requisiti di conformità, ad esempio la residenza dei dati?
- Come si intende far crescere l'azienda o la soluzione? Verrà ridimensionata in base al numero di tenant previsti?
- 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?
- Come monitorare, gestire, automatizzare, ridimensionare e gestire l'ambiente di Azure e come influisce la multi-tenancy sulla strategia di gestione?
- Quali componenti della soluzione gestiscono l'onboarding e la gestione dei tenant e come devono essere progettati questi componenti?
Indipendentemente dall'architettura, è essenziale avere una chiara comprensione dei requisiti dei clienti o dei tenant. Se si sono assunti impegni di vendita per i clienti o se si hanno obblighi contrattuali o requisiti di conformità da soddisfare, è necessario conoscere quali requisiti sono quando si progetta la soluzione. Ma allo stesso modo, i clienti potrebbero avere aspettative implicite su come funzionano le cose o su come si dovrebbe comportare, che potrebbero influire sul modo in cui si progetta una soluzione multi-tenant.
Si supponga, ad esempio, 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 aggiungerlo all'elenco di elementi consentiti del firewall. Questo requisito influisce sui servizi di Azure usati e sul livello di isolamento che è necessario fornire tra i tenant. Richiedono anche che la 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 alcune considerazioni da considerare, i requisiti da considerare e alcuni dei compromessi da apportare quando si pianifica un'architettura multi-tenant.
Destinatari
Gli articoli in questa sezione sono particolarmente rilevanti per i decision maker tecnici, come i responsabili della tecnologia (CTOs) e architetti, nonché i product manager. Il pubblico include anche fornitori di software indipendenti (ISV) e startup che sviluppano soluzioni SaaS. Inoltre, chiunque lavori con architetture multi-tenant dovrebbe avere familiarità con questi principi e compromessi.
Passaggi successivi
Prendere in considerazione modelli di tenancy diversi per la soluzione.