deep-dive sulla scomposizione di un monolite in microservizi<\/a>, siamo pronti per addentrarci in un altro aspetto del modello SaaS: l\u2019approccio multi-tenant.<\/p>\nPerch\u00e9 \u00e8 cos\u00ec importante quando si parla di Software as a Services? E come implementarlo efficacemente?<\/p>\n
Introduzione<\/h2>\n Oggi sempre di pi\u00f9, pattern come quello SaaS sono fondamentali per determinare il successo di un prodotto.<\/p>\n
La semplice adozione di questo modello, per\u00f2, non \u00e8 abbastanza.<\/p>\n
Distribuire un prodotto pensato e progettato come mono-tenant secondo il SaaS Delivery Model \u00e8 uno degli errori pi\u00f9 comuni.<\/p>\n
Infatti, installare una copia del software per ogni cliente su un\u2019infrastruttura dedicata potrebbe tecnicamente funzionare, ma finirebbe per diventare presto insostenibile sia dal punto di vista gestionale, che finanziario.<\/p>\n
Costruire efficacemente una soluzione SaaS significa soprattutto garantire la customer satisfaction su qualsiasi scala.<\/p>\n
Per aumentare il profitto continuando a garantire, allo stesso tempo, la miglior user experience possibile \u00e8 necessario poter adattare potenza di calcolo e spesa al traffico effettivo e al numero reale degli utenti. Raggiungere questo scenario-tipo \u00e8 possibile sfruttando la condivisione dell\u2019infrastruttura tra tutti gli utenti.<\/p>\n
Mono-tenant VS multi-tenant: cosa cambia?<\/h2>\n Un software mono-tenant funziona come un client individuale. Per ciascun cliente esistono un database indipendente e una istanza del software dedicata. Ogni elemento \u00e8 dedicato esclusivamente ad un solo customer.<\/p>\n
Con un software multi-tenant, al contrario, l\u2019istanza del software in funzione su una piattaforma SaaS serve contemporaneamente tutti gli utenti. Ogni cliente si serve dello stesso software dell\u2019applicazione e attinge dallo stesso database. La condivisione resta comunque a livello infrastrutturale e non implica la condivisione dei dati del Tenant che restano isolati e invisibili agli altri Tenant.<\/p>\n
Perch\u00e9 optare per un modello multi-tenant<\/h2>\n Vediamo ora alcuni esempi di vantaggi di un approccio multi-tenant sull\u2019approccio mono-tenant:<\/p>\n
\nMaintenance e update: col modello multi-tenant la gestione degli aggiornamenti \u00e8 notevolmente semplificata. Aggiornando il software di base, gli utenti potranno disporre in automatico dell\u2019ultima versione.<\/li>\n Costi: dovendo mantenere una sola istanza dell\u2019infrastruttura, sar\u00e0 possibile contenere i costi e sfruttare al massimo i vantaggi derivanti da un\u2019economia di scala.<\/li>\n Scaling: scale up e scale down saranno automatici, immediati e perfettamente aderenti al traffico effettivo delle tue applicazioni.<\/li>\n<\/ul>\nCome migrare verso il modello Multi-tenant<\/h2>\n Prima di cominciare a modificare il codice applicativo, \u00e8 necessario assicurarsi di poter fare su di esso cambiamenti senza che l\u2019applicazione (o parte di essa) smetta di funzionare.<\/p>\n
Il primo passo, quindi, \u00e8 dotarsi di una suite di test; I test automatici vi aiuteranno a procedere in modo semplice e sicuro.<\/p>\n
Il secondo step consiste invece in una serie di valutazioni sulle attivit\u00e0 necessarie al re-engineering del data model dell\u2019applicazione. Solo dopo si potr\u00e0 procedere con le modifiche a data model e relativo codice dell\u2019applicazione.<\/p>\n
Passiamo ora al terzo step: la modifica del codice. Ecco Alcuni consigli:<\/p>\n
\nogni risorsa dovr\u00e0 mantenere una referenza con il cliente, utile per poter recuperare le giuste informazioni.<\/li>\n Creiamo un modello per storare le informazioni di ciascun cliente e poi linkiamo tutte le risorse a quel modello. Per evitare che i dati di ciascun cliente possano essere recuperate dagli altri clienti, \u00e8 consigliabile archiviare il customer ID all\u2019interno del token di autenticazione per filtrare i dati all\u2019interno delle API in modo sicuro.<\/li>\n Durante il processo di refactoring del data model, teniamo presente che, al crescere dei dati, la velocit\u00e0 di esecuzione delle query potrebbe diminuire in modo drastico. Per evitare questo \u00e8 consigliabile organizzare i dati utilizzando indici sulle colonne e partizioni.<\/li>\n utilizziamo table partition and column indexing. Un altro trucco consiste nell\u2019utilizzo di una cache per i dati che vengono richiesti in modo intensivo (es. database Key-Value NoSQL).<\/li>\n<\/ul>\nCome abbiamo descritto nel nostro blog post precedente<\/a>, se il nostro punto di partenza \u00e8 un\u2019applicazione monolitica, la prima cosa da fare per facilitare il lavoro \u00e8 scomporla in microservizi dividendo, per prima cosa, backend e frontend.<\/p>\nNella trasformazione in multi-tenant \u00e8 importante tenere a mente che, per poter scalare nel modo pi\u00f9 efficiente possibile, il layer applicativo dovrebbe seguire il paradigma Stateless.<\/p>\n
Cosa significa? Restate sintonizzati per scoprirlo: nel nostro prossimo articolo parleremo proprio di questo!<\/p>\n","protected":false},"excerpt":{"rendered":"
Bentornati nella nostra serie di articoli dedicata al tema SaaS Enablement. Dopo il nostro deep-dive sulla scomposizione di un monolite […]<\/p>\n","protected":false},"author":8,"featured_media":1103,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[481],"tags":[305],"yoast_head":"\n
SaaS Enablement: da mono-tenant a multi-tenant. - Proud2beCloud Blog<\/title>\n \n \n \n \n \n \n \n \n \n \n \n \n\t \n\t \n\t \n \n \n \n \n \n \n\t \n\t \n\t \n