Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Ridefinire la multi-tenancy
I termini multi-tenancy e SaaS sono spesso strettamente collegati. In alcuni casi, le organizzazioni descrivono SaaS e multi-tenancy come la stessa cosa. Sebbene ciò possa sembrare naturale, equiparare SaaS e multi-tenancy tende a indurre i team ad adottare una visione puramente tecnica del SaaS quando, in realtà, SaaS è più un modello di business che una strategia di architettura.
Per comprendere meglio questo concetto, iniziamo con la visione classica della multi-tenancy. In questa visione puramente incentrata sull'infrastruttura, la multi-tenancy viene utilizzata per descrivere come le risorse vengono condivise dai tenant per promuovere l'agilità e l'efficienza dei costi.
Supponiamo, ad esempio, di avere un microservizio o un'istanza Amazon Elastic Compute Cloud
La sfida di questa definizione è che collega troppo direttamente la nozione tecnica di multi-tenancy al SaaS. Si presume che la caratteristica distintiva del SaaS sia che deve disporre di un'infrastruttura condivisa e multi-tenant. Questa visione del SaaS inizia a crollare quando esaminiamo i vari modi in cui il SaaS viene realizzato in ambienti diversi.
Il diagramma seguente fornisce una panoramica di un sistema SaaS che illustra alcune delle sfide che dobbiamo affrontare nella definizione della multi-tenancy.
Qui vedrai il modello SaaS classico descritto in precedenza, con una serie di servizi applicativi circondati da servizi condivisi che ti consentono di gestire e gestire i tuoi inquilini collettivamente.
La novità sono i microservizi che abbiamo incluso. Il diagramma include tre microservizi di esempio: prodotto, ordine e catalogo. Se osservi attentamente il modello di locazione di ciascuno di questi servizi, noterai che tutti utilizzano modelli di locazione leggermente diversi.
SaaS e multi-tenancy
Il servizio di prodotto condivide tutte le sue risorse (elaborazione e archiviazione) con tutti gli inquilini. Ciò è in linea con la definizione classica di multi-tenancy. Tuttavia, se dai un'occhiata al servizio ordini, noterai che ha un'elaborazione condivisa, ma uno spazio di archiviazione separato per ogni tenant.
Il servizio di catalogo aggiunge un'altra variante in cui l'elaborazione è separata per ogni tenant (una distribuzione di microservizi separata per ogni tenant), ma condivide lo storage per tutti i tenant.
Variazioni di questo tipo sono comuni negli ambienti SaaS. Vicini rumorosi, modelli su più livelli, esigenze di isolamento: questi sono solo alcuni dei motivi per cui potresti condividere o isolare in modo selettivo parti della tua soluzione SaaS.
Date queste variazioni e molte altre possibilità, diventa sempre più difficile capire come utilizzare il termine multi-tenant per caratterizzare questo ambiente. Nel complesso, per quanto riguarda il cliente, si tratta di un ambiente multi-tenant. Tuttavia, se utilizziamo la definizione più tecnica, alcune parti di questo ambiente sono multi-tenant e altre no.
Ecco perché diventa necessario abbandonare l'uso del termine multi-tenant per caratterizzare gli ambienti SaaS. Possiamo invece parlare di come viene implementata la multi-tenancy all'interno dell'applicazione, ma evita di utilizzarla per caratterizzare una soluzione come SaaS. Se si intende utilizzare il termine multi-tenant, ha più senso utilizzarlo per descrivere l'intero ambiente SaaS come multi-tenant, sapendo che alcune parti dell'architettura possono essere condivise e altre no. Nel complesso, continuate a utilizzare e gestire questo ambiente in un modello multi-tenant.
Il caso estremo
Per evidenziare meglio questo concetto di locazione, diamo un'occhiata a un modello SaaS con inquilini che condividono zero risorse. Il diagramma seguente fornisce un esempio di ambiente SaaS utilizzato da alcuni provider SaaS.
Pila per inquilino
In questo diagramma, vedrai che abbiamo ancora il nostro ambiente comune intorno a questi inquilini. Tuttavia, ogni tenant viene distribuito con una raccolta di risorse dedicata. In questo modello nulla è condiviso dagli inquilini.
Questo esempio mette in discussione cosa significa essere multi-tenant. Si tratta di un ambiente multi-tenant anche se nessuna delle risorse è condivisa? Gli inquilini che utilizzano questo sistema hanno le stesse aspettative che si avrebbero nei confronti di un ambiente SaaS con risorse condivise. In effetti, potrebbero non essere consapevoli di come le loro risorse vengono distribuite sotto il cofano dell'ambiente SaaS.
Anche se questi inquilini utilizzano un'infrastruttura isolata, sono comunque gestiti e gestiti collettivamente. Condividono un'esperienza unificata di onboarding, identità, metriche, fatturazione e operatività. Inoltre, quando viene rilasciata una nuova versione, questa viene distribuita a tutti gli inquilini. Affinché ciò funzioni, non è possibile consentire la personalizzazione una tantum per i singoli inquilini.
Questo esempio estremo fornisce un buon modello per testare il concetto di SaaS multi-tenant. Sebbene possa non realizzare tutte le efficienze dell'infrastruttura condivisa, si tratta di un ambiente SaaS multi-tenant completamente valido. Per alcuni clienti, il loro dominio può imporre che alcuni o tutti i clienti utilizzino questo modello. Ciò non significa che non siano SaaS. Se utilizzano questi servizi condivisi e tutti i tenant utilizzano la stessa versione, ciò è comunque conforme ai principi fondamentali del SaaS.
Dati questi parametri e questa definizione più ampia di SaaS, è possibile notare la necessità di evolvere l'uso del termine multi-tenant. Ha più senso fare riferimento a qualsiasi sistema SaaS gestito e gestito collettivamente come multi-tenant. Quindi, puoi rimandare a una terminologia più granulare per descrivere come le risorse vengono condivise o dedicate all'interno dell'implementazione di una soluzione SaaS.
