Best Practices per lo sviluppo di applicazioni Multi-Tenant su Windows Azure
Iniziamo con una precisazione importante: il multi-tenant è un concetto slegato dal Cloud Computing essendo entrambi aspetti complementari delle architetture applicative!
Infatti la progettazione multi-tenant è un modello architetturale dove ogni singola istanza applicativa è in grado di fornire servizi a più tenants (clienti) sfruttando diverse opzioni di condivisione delle risorse (da shared nothing a shared Everything, dove nel mezzo esistono molte varianti/opzioni) mentre il Cloud Computing rappresenta un modello di utilizzo dell’IT, dall’infrastruttura alle applicazioni, tramite servizi. Da notare che il multi-tenant è in netta contrapposizione rispetto al concetto di multi-instance dove ogni cliente/organizzazione ha delle istanze separate proprie di risorse computazionali, di storage,ecc...
Il Cloud Computing, e nel nostro caso Windows Azure Platform, è un ottimo facilitatore per il multi-tenant ma ricordiamoci che optare per una soluzione multi-tenant significa innanzitutto avere chiaro gli aspetti di business e in secondo luogo conoscere le tecnologie!! Infatti, dalla mia esperienza maturata in questi ultimi anni lavorando con ISV e software house, posso riassumere in 4 macro-step il processo di porting di applicazioni dall’ on-premises verso Windows Azure:
- Business Strategy: Analisi ed evoluzione del proprio Business Model (vendere subscriptions, non licenze, gestire il service delivery insieme ad un business partner-il vendor-, garantire ai propri clienti gli SLA,…).
- Multi-instance: Migrazione da on-premises a Cloud in architettura multi-instance dove ogni cliente a cui verrà venduta la soluzione avrà a disposizione un set di risorse di Azure a lui dedicate.
- Business Optimization: Analisi verticale del mercato in realazione alle opzioni offerte dal modello multi-tenant. Analisi sull’impatto del ROI rispetto al modello Multi-instance. Analisi economica…
- Multi-Tenanty: Evoluzione da architettura multi-instance a multi-tenant.
Da notare che per questioni molto diverse tra loro (sensibilità dei propri clienti, reali vincoli legali, esperienze nello sviluppo, ecc) il punto 3 può portare ad una scelta ponderata a NON adottare il modello multi-tenant! E qui ritorniamo al punto iniziale: Il multi-tenant è un concetto slegato dal Cloud Computing. Infatti, per chi ha un po’ di esperienza alle spalle questo modello probabilmente ricorderà, in vari tratti, alcuni esercizi fatti quasi 10 anni fa quando ancora non si parlava di Cloud o SaaS ma più semplicemente di ASP (Application Service Providers)
. Anche allora, pensando al modello ASP non tutte le soluzioni potevano avere una architettura multi-tenant. Ovviamente, se interessa, approfondirò questo processo in un post dedicato…
Sempre il punto 3 porta con se almeno un paio di benefici economici: l’ammortizzamento tra più clienti di attività condivise (es: patch management, security fix, ecc…) e l’ammortizzamento tra più clienti delle funzioni di base dei sistemi operativi.
Per chi supera indenne il punto 3 può approfondire alcuni aspetti (non tutti) della progettazione multi-tenant scaricando il progetto di esempio chiamato CloudNinja. Tutta la documentazione (Design Document, Setup Guide, Sample Walkthrough) e il codice sorgente li potete trovare a questo link: https://cloudninja.codeplex.com/.
Sarà quindi possibile analizzare come affrontare al meglio alcuni aspetti importanti come il Metering, l’ Automated Scaling, il Federated Identity ed infine il Provisioning dei tenants.
L’esempio fornito comprende l’uso delle seguenti tecnologie:
- Windows Azure Platform (SDK 1.4 refresh)
- Compute
- Storage
- SQL Azure
- AppFabric Caching
- AppFabric Access Control
- Entity Framework 4.1 (EF)
- ASP.NET MVC 3
- Task Parallel Library (TPL)
- Windows Identity Foundation (WIF)
- LINQ
Buona lettura