Approfondiremo il concetto di "multi-tenancy" e condivideremo le nostre intuizioni su come lo percepiamo.
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.
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.
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.
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
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.
Ecco la domanda, come posso proporre la strategia di titolarità per il mio prodotto? Ecco alcune domande importanti a cui pensare:
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.
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!