Considerazioni sul ciclo di vita del tenant in una soluzione multi-tenant

  • Articolo

Quando si considera un'architettura multi-tenant, è importante considerare tutte le diverse fasi del ciclo di vita di un tenant. In questa pagina vengono fornite indicazioni per i decision maker tecnici sulle fasi del ciclo di vita e sulle considerazioni importanti per ogni fase.

Tenant di valutazione

Quando si compila una soluzione SaaS, tenere presente che molti clienti richiedono o richiedono versioni di valutazione prima di eseguire il commit per acquistare una soluzione.

Le prove portano le seguenti considerazioni uniche:

  • Requisiti del servizio: le versioni di valutazione devono essere soggette agli stessi requisiti di sicurezza, prestazioni e livello di servizio dei dati per i clienti completi?
  • Infrastruttura: è consigliabile usare la stessa infrastruttura per i tenant di valutazione dei clienti completi o disporre di un'infrastruttura dedicata per i tenant di valutazione?
  • Migrazione: se i clienti acquistano il servizio dopo una versione di valutazione, come eseguiranno la migrazione dei dati dai tenant di valutazione nei tenant a pagamento?
  • Processo di richiesta: esistono limiti per chi può richiedere una versione di valutazione? Come si può prevenire l'abuso della soluzione? È possibile creare automaticamente tenant di valutazione o coinvolgere il team in ogni richiesta?
  • Limiti: quali limiti si vogliono o devono essere applicati ai clienti della versione di valutazione, ad esempio limiti di tempo, restrizioni delle funzionalità o limitazioni relative alle prestazioni?

In alcune situazioni, un modello di prezzi freemium può essere un'alternativa alla fornitura di versioni di valutazione.

Eseguire l'onboarding di nuovi tenant

Quando si esegue l'onboarding di un nuovo tenant, considerare le domande seguenti:

  • Processo: l'onboarding sarà un processo self-service, automatizzato o manuale?
  • Residenza dei dati: il tenant ha requisiti specifici per la residenza dei dati? Ad esempio, esistono normative sulla sovranità dei dati in vigore?
  • Conformità: il tenant deve soddisfare eventuali standard di conformità(ad esempio PCI DSS, HIPAA e così via)?
  • Ripristino di emergenza: il tenant ha requisiti specifici per il ripristino di emergenza, ad esempio un obiettivo del tempo di ripristino (RTO) o un obiettivo del punto di ripristino (RPO)? Queste sono diverse dalle garanzie fornite ad altri tenant?
  • Informazioni: quali informazioni sono necessarie per poter eseguire l'onboarding completo del tenant? Ad esempio, è necessario conoscere il nome legale dell'organizzazione? Hai bisogno del logo aziendale per personalizzare l'applicazione e, in tal caso, quali dimensioni e formato del file ti servono?
  • Fatturazione: la piattaforma offre diverse opzioni di determinazione dei prezzi e modelli di fatturazione?
  • Ambienti: il tenant richiede ambienti di pre-produzione? E ci sono aspettative sulla disponibilità per tale ambiente? È temporaneo (su richiesta) o sempre disponibile?

Dopo l'onboarding dei tenant, passano a uno stato "aziendale come al solito". Tuttavia, esistono ancora diversi eventi importanti del ciclo di vita che possono verificarsi, anche quando si trovano in questo stato.

Aggiornare l'infrastruttura dei tenant

È necessario considerare come applicare gli aggiornamenti all'infrastruttura dei tenant. Diversi tenant potrebbero avere aggiornamenti applicati in momenti diversi.

Vedere Aggiornamenti per altre considerazioni sull'aggiornamento delle distribuzioni dei tenant.

Ridimensionare l'infrastruttura dei tenant

Valutare se i tenant potrebbero avere modelli di business stagionali o modificare in caso contrario il livello di consumo per la soluzione.

Ad esempio, se si fornisce una soluzione ai rivenditori, ci si potrebbe aspettare che determinati periodi dell'anno saranno particolarmente occupati in alcune aree geografiche e tranquilla in altri momenti. Valutare se questa stagionalità influisce sul modo in cui si progetta e si ridimensiona la soluzione. Tenere presente il modo in cui la stagionalità potrebbe influire sui problemi dei vicini rumorosi, ad esempio quando un subset di tenant riscontra un aumento improvviso e imprevisto del carico che riduce le prestazioni di altri tenant. È possibile prendere in considerazione l'applicazione di mitigazioni, che possono includere il ridimensionamento dell'infrastruttura dei singoli tenant, lo spostamento dei tenant tra le distribuzioni e il provisioning di un livello di capacità sufficiente per gestire picchi e picchi di traffico.

Spostare i tenant tra un'infrastruttura e l'altro

Potrebbe essere necessario spostare i tenant tra l'infrastruttura per diversi motivi, ad esempio:

  • Ribilanciamento: si segue un approccio partizionato verticalmente per eseguire il mapping dei tenant all'infrastruttura ed è necessario spostare un tenant in una distribuzione diversa per ribilanciare il carico.
  • Aggiornamenti: un tenant aggiorna lo SKU o il piano tariffario e devono essere spostati in una distribuzione dedicata a tenant singolo con isolamento più elevato da altri tenant.
  • Migrazioni: un tenant richiede che i dati vengano spostati in un archivio dati dedicato.
  • Spostamenti di aree: un tenant richiede che i dati vengano spostati in una nuova area geografica. Questo requisito può verificarsi durante l'acquisizione di un'azienda o quando cambiano le leggi o le situazioni geopolitiche.

Si consideri come spostare i dati dei tenant e come reindirizzare le richieste al nuovo set di infrastruttura che ospita l'istanza. È anche consigliabile valutare se lo spostamento di un tenant potrebbe comportare tempi di inattività e assicurarsi che i tenant siano completamente consapevoli del rischio.

Unire e dividere i tenant

È allettante pensare ai tenant o ai clienti come entità statiche e immutabili. Tuttavia, in realtà, questo spesso non è vero. Ad esempio:

  • 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 consumer, 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 gestione delle operazioni di unione e suddivisione. Si consideri, ad esempio, un'applicazione di fotografia consumer creata per consentire alle famiglie di condividere foto l'una con l'altra. Le foto sono di proprietà dei singoli membri della famiglia che li hanno contribuito, o dalla famiglia nel suo complesso? Se gli utenti lasciano la famiglia, è necessario rimuovere o rimanere nel set di dati della famiglia? Se gli utenti si uniscono a un'altra famiglia, le loro vecchie foto dovrebbero spostarsi con loro?

Offboarding dei tenant

È anche inevitabile che i tenant debbano essere occasionalmente rimossi dalla soluzione. In una soluzione multi-tenant, vengono illustrate alcune considerazioni importanti, tra cui:

  • Periodo di conservazione: per quanto tempo è necessario mantenere i dati dei clienti? Sono previsti requisiti legali per eliminare definitivamente i dati, dopo un determinato periodo di tempo?
  • Reonboarding: è consigliabile offrire ai clienti la possibilità di eseguire di nuovo ilboarding? I dati saranno ancora disponibili se si ricongiunteranno entro il periodo di conservazione dei dati?
  • Ribilanciamento: se si esegue l'infrastruttura condivisa, è necessario ribilanciare l'allocazione dei tenant all'infrastruttura?

Disattivare e riattivare i tenant

In alcune situazioni potrebbe essere necessario disattivare o riattivare l'account di un cliente. Ad esempio:

  • Il cliente ha richiesto la disattivazione. In un sistema consumer, un cliente potrebbe scegliere di annullare la sottoscrizione.
  • Il cliente non può essere fatturato ed è necessario disattivare la sottoscrizione.

La disattivazione è separata dall'offboarding in quanto è destinata a essere uno stato temporaneo. Tuttavia, dopo un periodo di tempo, è possibile scegliere di disattivare un tenant disattivato.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Altri contributori:

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

Passaggi successivi

Prendere in considerazione i modelli di determinazione prezzi che verranno usati per la soluzione.