Che cosa è la multi-tenancy?

Significa avere un’applicazione che si comporta come se fosse totalmente dedicata a un cliente quando in realtà ne serve molti in parallelo utilizzando lo stesso codice. Alcune considerazioni da fare quando si desidera architettare un’applicazione Software as a service (SaaS) multi-tenant.

In questo spazio (Techne – Con parole mie) i protagonisti della tecnologia raccontano e si raccontano, portando alla luce la miscela virtuosa di tecnica ed esperienza al servizio delle esigenze dell’utenza. Parlano sulla base della conoscenza, evitando di fare riferimento alla propria produzione, bensì portando il discorso su un piano generale e fruibile da tutti.

Ai tempi del modello Asp (application service provisioning), una delle principali sfide che le aziende si trovavano a dover affrontare era il problema della scalabilità. Per ogni nuovo cliente che veniva aggiunto, era spesso necessario disporre di una versione totalmente nuova di interfaccia utente, business logic e regole di business, oltre all’esigenza di avere un database completamente diverso. Queste problematiche rendevano difficile il modello di business associato alle applicazioni Asp, perché non c’era modo per l’hosting provider di trarre vantaggio da reali economie di scala. Ed è anche il motivo per cui molti dei primi Asp hosting provider oggi non esistono più.

Tuttavia, il software come servizio (SaaS) si è evoluto dai giorni del modello Asp. Uno degli elementi chiave è stato proprio quello legato alle economie di scala che spesso viene affrontato con il concetto di multi-tenancy, è cioè disporre di un’applicazione che si comporta come se fosse totalmente dedicata a un cliente quando in realtà ne serve molti in parallelo utilizzando lo stesso codice. Questo principio si basa sul concetto one-to-many, piuttosto che sul modello one-to-one utilizzato in applicazioni premise-based pacchettizzate tradizionali.

I vantaggi assicurati dalle architetture multi-tenant sono duplici: l’infrastruttura sottostante è condivisa dando luogo a notevoli economie di scala con una ripartizione ottimale del carico. E, poiché gli elevati costi di sviluppo di infrastrutture e applicazioni sono condivisi, questa applicazione “enterprise-grade” può essere resa disponibile anche alle aziende più piccole. Un’architettura multi-tenant è progettata per consentire la messa a punto di configurazioni specifiche per ogni utente per quanto concerne l’interfaccia (branding), le regole e i processi di business, e i layer data model. Tutto ciò deve essere possibile senza modificare il codice perché lo stesso codice viene condiviso tra tutti i ‘tenutari’, trasformando così la personalizzazione del software in configurazione dello stesso.

Per trarre vantaggio da reali economie di scala con il modello SaaS è necessario essere in grado di fare tutto questo in un ambiente one-to-many. Tuttavia, in base alla nostra esperienza con i fornitori SaaS, l’elemento di contenzioso risiede nell’area del database. Mantenere i dati di ciascuna azienda al sicuro è assolutamente fondamentale ma, in molte circostanze, il cliente vuole di più e chiede che i propri dati vengano archiviati fisicamente su un database diverso o partizionato.

Ed è qui dove si decide se si supporta il concetto di multi-tenancy.

Quando si architetta un’applicazione SaaS multi-tenant è necessario considerare:

Separazione dell’interfaccia dalla business logic, consentendone la personalizzazione.

Supporto di regole, flussi di lavoro e altre configurazioni di ciascuna azienda attraverso aggiornamenti, pur disponendo di una singola istanza di tale business logic.

Soddisfazione delle esigenze operative di ciascuna azienda.

Se appropriato, prevedere processi di elaborazione batch in grado di soddisfare diverse aziende con un unico job stream.

Supporto di aziende internazionali così come di un’unica geografia che contiene numerose organizzazioni.

Ma il trucco sta nel database.

Recentemente si è parlato molto del concetto di modelli hybrid-tenancy.

È fondamentale che un fornitore di soluzioni SaaS presti molta attenzione all’aspetto della base dati.

E ci sono tre definizioni di modelli a database ibrido a cui conformarsi:

1) il modello single tenant, cioè un database separato per ciascun cliente;

2) il database multi-tenant, cioè con un database condiviso e schemi identici;

3) il database multi-tenant condiviso, cioè ogni cliente ha uno schema personalizzato.

(*)Director of Software as a Service di Progress Software

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome