Condividi tramite

Considerazioni sul ciclo di vita del tenant nelle soluzioni multi-tenant

Quando si progetta un'architettura multi-tenant, è necessario tenere conto di ogni fase del ciclo di vita di un tenant. Questo articolo fornisce indicazioni per i decision maker tecnici sulle considerazioni importanti per ogni fase.

Tenant di prova

Molti clienti richiedono o richiedono versioni di valutazione prima di eseguire il commit per l'acquisto di una soluzione SaaS (Software as a Service).

Le prove introducono le considerazioni uniche seguenti:

  • Requisiti del servizio: Decidere se le versioni di valutazione devono soddisfare gli stessi requisiti di sicurezza, prestazioni e livello di servizio dei dati per i clienti completi.

  • Infrastruttura: Determinare se ospitare tenant di prova nella stessa infrastruttura dei clienti effettivi o utilizzare un'infrastruttura dedicata.

  • Migrazione: Pianificare la migrazione dei dati da un tenant di valutazione a un tenant a pagamento se un cliente acquista il servizio dopo una versione di valutazione.

  • Processo di richiesta: Definire chi può richiedere una versione di valutazione, come impedire l'uso improprio della soluzione e se automatizzare la creazione della versione di valutazione o coinvolgere il team.

  • Limiti: Impostare limiti appropriati per i clienti della versione di valutazione, ad esempio limiti di tempo, restrizioni delle funzionalità o limiti di prestazioni.

In alcune situazioni, un modello di determinazione prezzi gratuito con funzionalità limitate può fungere da alternativa alla fornitura di versioni di valutazione.

Accogliere nuovi inquilini

Quando si esegue l'onboarding di un nuovo tenant, considerare i fattori seguenti:

  • Processo: Decidere se rendere l'onboarding un processo self-service, automatizzato o manuale.

  • Residenza dei dati: Determinare se il tenant ha requisiti specifici per la residenza dei dati, ad esempio la conformità alle normative sulla sovranità dei dati.

  • Conformità: Identificare gli standard di conformità che il tenant deve soddisfare. Questi standard possono includere Payment Card Industry Data Security Standard (PCI DSS) o Heath Insurance Portability and Accountability Act (HIPAA).

  • Ripristino di emergenza: Verificare se il tenant ha requisiti di ripristino di emergenza specifici, ad esempio un obiettivo del tempo di ripristino (RTO) o un obiettivo del punto di ripristino (RPO). Determinare se queste garanzie differiscono da quelle fornite ad altri tenant.

  • Informazione: Definire le informazioni necessarie per eseguire l'onboarding completo del tenant. Ad esempio, potrebbe essere necessario il nome legale dell'organizzazione o il logo della società, incluse le dimensioni e il formato del file.

  • Fatturazione: Determinare se la piattaforma offre opzioni di determinazione dei prezzi e modelli di fatturazione diversi.

  • Ambienti: Identificare se il tenant richiede ambienti di preproduzione. Chiarire se l'ambiente deve essere sempre disponibile o può essere attivato su richiesta.

Dopo aver eseguito l'onboarding dei tenant, passano a uno stato operativo normale. Tuttavia, gli eventi importanti del ciclo di vita possono verificarsi durante questo stato.

Aggiornare l'infrastruttura dei tenant

Considera come applicare gli aggiornamenti all'infrastruttura dei tenant. Tenant diversi potrebbero ricevere aggiornamenti in momenti diversi.

Per altre informazioni, vedere Considerazioni per l'aggiornamento di una soluzione multi-tenant.

Scalare l'infrastruttura dei tenant

Determinare se i tenant riscontrano modelli aziendali stagionali o altre fluttuazioni nei consumi per la vostra soluzione.

Ad esempio, se si fornisce una soluzione ai rivenditori, è possibile prevedere picchi di traffico durante determinati periodi dell'anno in alcune aree geografiche, mentre altri periodi rimangono silenziosi. Valutare se questa stagionalità influisce sul modo in cui si progetta e si ridimensiona la soluzione. Tenere presente i problemi dei vicini rumorosi, in cui un aumento improvviso del carico da un sottoinsieme di clienti degrada le prestazioni per gli altri.

Valutare la possibilità di applicare le mitigazioni seguenti:

  • Ridimensionare l'infrastruttura dei singoli clienti.

  • Spostare i tenant tra le distribuzioni.

  • Prevedere un livello di capacità sufficiente per gestire picchi e cali nel traffico.

Spostare i tenant tra un'infrastruttura e l'altro

Potrebbe essere necessario spostare i tenant tra l'infrastruttura per diversi motivi. Considerare gli scenari seguenti:

  • Riequilibrio: Si segue un approccio partizionato verticalmente per la mappatura dei tenant all'infrastruttura e occorre spostare un tenant in una distribuzione diversa per ribilanciare il carico.

  • Aggiornamenti: Un tenant aggiorna lo SKU o il piano tariffario e deve passare a una distribuzione dedicata a tenant singolo con isolamento più elevato da altri tenant.

  • Migrazioni: Un tenant richiede di spostare i dati in un archivio dati dedicato.

  • Spostamenti dell'area: Un tenant richiede che i dati si trovino in un'area geografica diversa. Questo requisito può verificarsi durante l'acquisizione di una società o a causa di cambiamenti in condizioni legali o geopolitiche.

Si consideri come spostare i dati dei tenant e come reindirizzare le richieste al nuovo set di infrastruttura che ospita l'istanza. Valutare anche se lo spostamento di un tenant potrebbe comportare tempi di inattività e assicurarsi che i tenant comprendano appieno il rischio.

Unire e dividere gli inquilini

È facile presupporre che i tenant o i clienti rimangano statici, ma in realtà cambiano spesso. Considerare gli scenari seguenti:

  • Negli scenari aziendali, le aziende potrebbero essere acquisite o unite, incluse le aziende che si trovano in aree geografiche diverse.

  • Negli scenari aziendali, le aziende potrebbero suddividere o dismettere.

  • Negli scenari dei consumatori, i singoli utenti potrebbero unirsi o lasciare le famiglie.

Valutare se è necessario fornire funzionalità per gestire l'unione e la separazione dei dati, delle identità utente e delle risorse. Considerare anche il modo in cui la proprietà dei dati influisce sulla modalità di gestione delle operazioni di unione e suddivisione.

Ad esempio, in un'app di condivisione di foto destinata alle famiglie, determinare se le immagini appartengono a singoli contribuenti o alla famiglia nel suo insieme. Se un utente lascia la famiglia, valutare se rimuovere i dati o mantenerli nel set di dati della famiglia. Se un utente si unisce a un'altra famiglia, determinare se le vecchie foto si spostano con loro.

Rimozione degli utenti

A volte è necessario rimuovere i tenant dalla soluzione. In una soluzione multitenant, l'offboarding introduce le seguenti considerazioni importanti:

  • Periodo di conservazione: Determinare per quanto tempo mantenere i dati dei clienti. Identificare eventuali requisiti legali che impongono la distruzione dei dati dopo un periodo specifico.

  • Reonboarding: Decidere se supportare il reonboarding. Chiarire se i dati del tenant rimangono disponibili durante il periodo di conservazione.

  • Riequilibrio: Se si gestisce un'infrastruttura condivisa, valutare se è necessario riequilibrare le allocazioni degli utenti dopo l'offboarding.

Disattivare e riattivare gli inquilini

Potrebbe essere necessario disattivare o riattivare l'account di un cliente. Si considerino gli esempi seguenti:

  • Un cliente richiede la disattivazione. In un sistema consumer, un cliente potrebbe scegliere di annullare la sottoscrizione.

  • Non è possibile fatturare un cliente ed è necessario disattivare la sottoscrizione.

La disattivazione è diversa dall'offboarding perché è destinata a essere uno stato provvisorio. Tuttavia, dopo un periodo di tempo, è possibile scegliere di disattivare un tenant disattivato.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Altri collaboratori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.