Modelli di titolarità per un'app multi-tenant

Sentiamo frequentemente parlare dell'importanza di creare un'applicazione multi-tenant, specialmente nel contesto dello sviluppo di un'applicazione Software come Servizio (SaaS).

C'è un po' di confusione sul concetto di "app multi-tenant" e sui vari modelli utilizzati per svilupparne una. In questo articolo, abbiamo esaminato più da vicino questi termini in modo più pratico.

Comprendere i diversi modelli di titolarità da un punto di vista tecnico#

Architettura single-tenant#

L'architettura single-tenant è un modello di software o di cloud computing in cui ogni cliente o tenant ha un'istanza dedicata di un'applicazione o servizio. Se guardiamo all'origine del modello di business B2B, parte dal presupposto che ogni istanza del software serva solo un cliente o un'organizzazione.

Caratteristiche#

• Isolamento: Ogni cliente o tenant opera in un ambiente isolato con risorse, database e configurazioni dedicate.
• Personalizzazione: Le architetture single-tenant spesso consentono una maggiore personalizzazione e flessibilità per soddisfare esigenze specifiche del cliente.
• Sicurezza: Sicurezza e privacy dei dati migliorate, poiché i dati del cliente non sono mescolati con quelli di altri tenant.
• Scalabilità: La scalabilità delle risorse e della capacità può essere più semplice, poiché l'istanza di ciascun tenant può essere regolata indipendentemente.
• Manutenzione: Manutenzione e aggiornamenti indipendenti, poiché le modifiche apportate all'ambiente di un tenant non influenzano gli altri.
• Costo: In genere costi di infrastruttura e operativi più elevati a causa della necessità di mantenere istanze separate per ciascun tenant.

Esempi#

• Hosting dedicato: I fornitori di servizi di hosting web tradizionali offrono architetture single-tenant, in cui ogni cliente ottiene le proprie risorse, database o configurazioni.
• Software on-premise: Alcune applicazioni software a livello aziendale, come i sistemi di gestione delle relazioni con i clienti (CRM) o i sistemi di gestione delle risorse umane (HRMS), offrono opzioni di distribuzione single-tenant per le organizzazioni con requisiti stringenti di sicurezza dei dati e personalizzazione.
• SaaS con livelli premium: In alcune offerte di Software come Servizio (SaaS), i livelli premium o enterprise forniscono opzioni single-tenant per i clienti che richiedono sicurezza, conformità o personalizzazione avanzate.

L'architettura single-tenant è comunemente utilizzata in scenari in cui la conformità è fondamentale o necessarie esigenze di sicurezza personalizzate. Ad esempio, settori come la finanza, la sanità e il governo, che hanno requisiti normativi rigorosi, spesso preferiscono soluzioni single-tenant per garantire la conformità.

Tuttavia, è importante notare che le architetture single-tenant possono essere più dispendiose in termini di risorse e complesse da gestire rispetto alle architetture multi-tenant, poiché ogni istanza del cliente richiede la propria infrastruttura e manutenzione. Di conseguenza, possono essere più adatte per applicazioni con clienti meno numerosi ma più grandi o dove personalizzazione e isolamento sono critici.

Architettura multi-tenant#

Multi-tenancy software è un'architettura software in cui una sola istanza di software gira su un server e serve più tenant. I sistemi progettati in questo modo sono "condivisi" (piuttosto che "dedicati" o "isolati"). Un tenant è un gruppo di utenti che condividono l'accesso comune con privilegi specifici all'istanza software. Con un'architettura multi-tenant, un'applicazione software è progettata per fornire a ogni tenant una quota dedicata dell'istanza, inclusi i suoi dati, configurazione, gestione utenti, funzionalità individuale del tenant e proprietà non funzionali. -- Wikipedia

Caratteristiche#

• Risorse condivise: Più tenant condividono la stessa infrastruttura, inclusi server, database e risorse di rete, per ottimizzare l'utilizzo delle risorse.
• Isolamento: I dati e le configurazioni dei tenant sono logicamente segregati, garantendo privacy e sicurezza dei dati.
• Economie di scala: La multi-tenancy può essere conveniente poiché l'overhead è distribuito tra più utenti, riducendo i costi operativi e infrastrutturali.
• Scalabilità: L'architettura può scalare orizzontalmente o verticalmente per accogliere un numero crescente di tenant e utenti.
• Manutenzione: Gli aggiornamenti e la manutenzione sono semplificati, poiché i cambiamenti si applicano uniformemente a tutti i tenant, semplificando la gestione.
• Personalizzazione: Anche se è possibile una certa personalizzazione, è in genere più limitata rispetto alle architetture single-tenant per mantenere la coerenza a livello di sistema.

Esempi#

• SaaS basato su cloud: La maggior parte delle applicazioni Software come Servizio (SaaS), come Google Workspace e Salesforce, utilizza la multi-tenancy per servire più organizzazioni o utenti su una piattaforma condivisa.
• Hosting condiviso: Nei servizi di hosting web, i servizi di hosting condiviso ospitano più siti web sullo stesso server, ciascuno appartenente a un cliente o un'organizzazione diversi.
• Servizi cloud pubblici: I fornitori di cloud pubblico, come AWS e Azure, usano la multi-tenancy per servire clienti diversi con risorse virtualizzate isolate all'interno di data center condivisi.
• Soluzioni infrastrutturali a livello aziendale: Come un cluster Kubernetes condiviso utilizzato da più unità aziendali all'interno di un'organizzazione.

Ridefinire le app multi-tenant nel mondo reale#

Abbiamo fornito definizioni da una prospettiva architetturale, rendendo facile distinguere tra design multi-tenant e single-tenant. Tuttavia, questo si avvicina più alla definizione tecnica. Se usiamo queste definizioni nel nostro ambiente di sviluppo reale quando progettiamo modelli di titolarità, questo modo di pensare presuppone che un'app multi-tenant debba avere un'infrastruttura puramente condivisa e multi-tenant.

Tuttavia, le esigenze aziendali e di prodotto variano molto e hanno numerosi requisiti caso per caso, quindi non esiste una soluzione adatta a tutti.

Immagina uno scenario in cui un tenant sta utilizzando risorse da un'infrastruttura condivisa, ma a causa di esigenze aziendali specifiche, richiede che una o due parti del sistema siano esclusivamente dedicate a loro. Queste parti dedicate potrebbero essere il database, le istanze o una combinazione di altri componenti, tutto mentre condividono l'infrastruttura complessiva. Qui entra in gioco l'architettura mixed-tenant.

Nello sviluppo pratico di prodotti SaaS, è comune incontrare uno scenario in cui un prodotto è progettato principalmente con un modello di multi-tenancy generico. Tuttavia, alcuni aspetti dell'architettura o delle risorse possono essere orientati verso un approccio "single-tenancy".

AWS ha utilizzato il seguente caso come esempio per comunicare questo concetto: la multi-tenancy è un concetto ampio, ed è caso per caso combinare e scegliere la strategia giusta per definire ciò che si vuole ottenere con le risorse condivise e l'isolamento dei dati.

In altre parole, a volte le persone continuano a chiamare questo modello “multi-tenancy”, quindi nella definizione più ampia di multi-tenancy, non implica che ogni componente di una soluzione sia condiviso. Piuttosto, implica che almeno alcuni componenti di una soluzione siano riutilizzati tra più tenant.

Comprendere questo termine in modo ampio può aiutarti a capire meglio le esigenze dei tuoi clienti e da dove provengono.

Piuttosto che fissarsi su un singolo modello architetturale, la multi-tenancy riflette la praticità dell'architettura di un prodotto SaaS nel mondo reale. Quando ci riferiamo a un'app multi-tenant, non implica necessariamente che l'app aderisca a un unico modello architetturale; potrebbe utilizzare varie strategie di titolarità, indicando che almeno alcuni dei suoi componenti sono condivisi.

Considerazioni chiave per determinare la tua strategia di modello di titolarità#

Ecco la domanda, come posso proporre la strategia di titolarità per il mio prodotto? Ecco alcune domande importanti a cui pensare:

• Quali sono i tuoi obiettivi aziendali?
• Una soluzione single-tenant può supportare i tuoi piani di crescita futura?
• Quanto è grande il tuo team operativo e quanto della gestione dell'infrastruttura può essere automatizzato? Ti importa dell'agilità e dell'efficienza dei costi?
• I tuoi clienti sono a loro agio con diverse opzioni di multi-tenancy?
• Come influisce ciascuna opzione sulla conformità, sia tua che dei tuoi clienti?
• Sei previsto per rispettare gli accordi sul livello di servizio (SLA) o puntare a specifici obiettivi di livello di servizio (SLO)?
• Hai considerato sicurezza, costo, prestazioni, affidabilità e capacità di risposta alle esigenze individuali dei tenant nel loro complesso?

Ricorda che non esiste una rigida divisione nel tuo prodotto in cui devi optare per un modello esclusivamente multi-tenant o solo single-tenant. La tua decisione dovrebbe basarsi su come dividi i componenti architetturali del tuo prodotto e i livelli specifici di isolamento richiesti dai tuoi clienti o attività. Puoi quindi applicare diversi approcci di conseguenza.

Prossimamente#

Abbiamo parlato della "nuova" definizione di un'app multi-tenant, tuttavia, come affrontare l'isolamento dei tenant, le identità e come determinare se le tue identità devono essere isolate o meno? Cosa significa per le identità essere "isolate"?

La confusione sorge spesso quando si affrontano situazioni in cui un singolo utente reale ha due identità diverse. È appropriato etichettare questa situazione come - “identità isolate”?

Affronteremo queste domande nella nostra prossima serie di articoli. Resta sintonizzato!