Di Frederick Chong e Gianpaolo Carraro

In questo documento viene presentata una panoramica del modello SaaS (Software-as-a-Service) per la distribuzione di software come servizio. Viene inoltre offerta una descrizione generale dell’architettura di un’applicazione SaaS e vengono esaminati vantaggi e problemi dello sviluppo e dell’offerta di soluzioni SaaS (26 pagine stampate).

Per ulteriori riferimenti, è disponibile un ARCast (in inglese)

Introduzione

Software come servizio. L’argomento è di grande attualità. Le pubblicazioni informatiche sono gremite di articoli in cui il software come servizio (SaaS, Software as a Service) viene descritto come una rivoluzione verso nuovi orizzonti. Tutti sanno, o pensano di sapere, grossomodo di cosa si tratti e quanto si diffonderà. In pochi affermerebbero però di poterne dare una definizione esatta e ancora meno saprebbero realizzarlo.

Ma se il modello SaaS rappresenta davvero una promessa per il futuro della distribuzione delle applicazioni, perché non ci sono informazioni che ne facilitino la realizzazione?

Con buona probabilità, il modello SaaS è destinato ad avere un impatto profondo sul mondo del software, perché il software come servizio cambierà il modo in cui le persone creano, vendono, acquistano e utilizzano il software. Perché questo accada è tuttavia necessario che i produttori di software dispongano di risorse e informazioni che consentano realmente lo sviluppo di applicazioni SaaS.

Questo è il primo di una serie di documenti Microsoft dedicati a demistificare il modello SaaS e a costituire una guida pratica concreta per la creazione di applicazioni SaaS. In questo documento viene presentata una panoramica del modello SaaS e dei vantaggi e delle difficoltà che può incontrare chi desideri fornirlo. Questi argomenti verranno trattati in maggior dettaglio in documenti successivi.

In questo documento verrà innanzitutto descritto che cos’è esattamente il software come servizio e quali novità presenta ai fornitori che desiderino adottarlo rispetto al software tradizionale (sviluppato internamente). Verrà quindi esaminato il modello di business SaaS, per valutare quanto possa essere proficuo nel mondo reale.

Poiché questo è un documento architetturale, la sezione più ampia è dedicata all’architettura di un’applicazione SaaS. Verrà presentato un modello di maturità a quattro livelli che spiega e pone in prospettiva alcuni attributi fondamentali del modello SaaS: configurabilità, efficienza multi-tenant e scalabilità. Verranno esaminati i componenti di un’architettura SaaS generale, per poi analizzare in maggior dettaglio un problema tipico dell’architetto SaaS, ovvero la predisposizione di un meccanismo per l’estensione del modello dati di un’applicazione multi-tenant.

Verranno infine illustrati alcuni aspetti operativi relativi al supporto delle applicazioni SaaS dopo il deployment.

Che cosa si intende per “software come servizio”?

L’esatta definizione di software come servizio (SaaS, Software as a Service) è ancora oggi controversa e, con buona probabilità, persone diverse darebbero definizioni diverse. La maggior parte degli esperti potrà tuttavia convenire su alcuni aspetti fondamentali che distinguono il software SaaS dal software pacchettizzato tradizionale, da un lato, e da un semplice sito Web, dall’altro. Nella sua forma più semplice, la definizione di software come servizio potrebbe essere:

“software distribuito come servizio in hosting a cui si accede tramite Internet”.

Vale la pena di soffermarsi un attimo a considerare le implicazioni di questa definizione. Non indica un’architettura specifica, non fa riferimento a tecnologie o protocolli specifici, non individua un’utenza aziendale o consumer e non prevede l’adozione di modelli di business specifici. In base a questa definizione, le caratteristiche distintive principali del software come servizio sono l’ubicazione del codice applicativo e la modalità di deployment e di accesso.

Si tratta di una definizione semplicistica? In effetti, sì. Più avanti verranno illustrati altri attributi che definiscono e caratterizzano un’applicazione SaaS matura e ben costruita.

Stando a questa definizione, possono essere classificati come SaaS numerosi servizi e applicazioni che non ci si aspetterebbe di trovare in questa categoria. Si consideri ad esempio un servizio di posta elettronica Web come Microsoft Hotmail. Benché Hotmail non salti immediatamente alla mente quando si pensa al modello SaaS, risponde a tutti i criteri di base: un fornitore ospita tutta la logica e i dati del programma e offre agli utenti finali l’accesso a tali dati tramite Internet, mediante un’interfaccia utente Web.

Passando dal generale allo specifico, è possibile dividere il software come servizio in due categorie principali:

• Servizi line-of-business, rivolti alle aziende e alle organizzazioni di tutte le dimensioni. I servizi line-of-business sono spesso soluzioni aziendali personalizzate su larga scala mirate ad assistere processi aziendali come contabilità, gestione della supply chain e relazioni con i clienti. Questi servizi vengono solitamente venduti ai clienti sotto forma di abbonamento.

• Servizi consumer, rivolti al pubblico. I servizi consumer vengono talvolta venduti sotto forma di abbonamento, altre volte vengono invece forniti gratuitamente e finanziati tramite pubblicità.

In questo documento vengono analizzati i problemi aziendali e di architettura che emergono nello sviluppo di applicazioni line-of-business e i concetti e gli esempi proposti si riferiscono a tale contesto. I problemi dell’estendibilità e della personalizzazione multi-tenant, dell’isolamento e della scalabilità dei dati si presentano tuttavia anche in ambito consumer, dove generalmente possono essere risolti più facilmente. Pertanto, la lettura di questo documento può risultare utile anche agli sviluppatori di soluzioni SaaS consumer.

Riflessioni sul software come servizio

Per passare dall’offerta di software sviluppato internamente all’offerta di software come servizio, i fornitori devono concepire in modo nuovo tre elementi intercorrelati: il modello di business, l’architettura dell’applicazione e la struttura operativa (vedere la figura 1).

Figura 1. Aree in cui i fornitori di software devono pensare in modo nuovo

Nelle tre sezioni seguenti verrà esaminata in maggior dettaglio ognuna di queste aree, con particolare riguardo all’architettura dell’applicazione.

Modifica del modello di business

La modifica del modello di business può riguardare una o più delle seguenti aree:

• Passaggio della “proprietà” del software dal cliente a un provider esterno.

• Riallocazione della responsabilità della gestione e dell’infrastruttura tecnologica. L’hardware e i servizi professionali passano infatti dal cliente al provider.

• Riduzione del costo della fornitura dei servizi software, per effetto della specializzazione e dell’economia di scala.

• Acquisizione di una clientela di aziende minori, attraverso la riduzione del costo minimo a cui il software può essere venduto.

Per beneficiare dei vantaggi del modello SaaS è necessario un nuovo modo di pensare sia del provider che del cliente e spetta al provider agevolare il cliente in questa transizione.

Chi “possiede” il software?

La maggior parte del software viene ancora venduto come è avvenuto per decenni. Il cliente acquista una licenza di utilizzo e installa il software su hardware di proprietà o comunque sottoposto al proprio controllo, mentre il fornitore offre il supporto previsto dai termini della licenza o del contratto di assistenza. In un contesto limpido e regolare la nozione di “licenza” può apparire un tecnicismo: dal punto di vista legale, il cliente acquista solo il diritto all’utilizzo di una copia del software, ma in termini pratici è come se diventasse “proprietario” del software e potrà utilizzarlo tutte le volte che lo desidera e per tutto il tempo che vorrà.

Dal momento che il modello di software come prodotto domina il mercato, l’idea di software come servizio può apparire quasi aliena: anziché “possedere” integralmente un software importante, si propone ai clienti di pagare una sottoscrizione per un software che viene eseguito sui server di qualcun altro e che non sarà più disponibile quando si smette di rinnovare la sottoscrizione. Per questa ragione è fondamentale che il potenziale cliente comprenda che il passaggio dal modello tradizionale al modello SaaS prospetta vantaggi diretti e ben quantificabili.

Trasferimento delle responsabilità IT

In un’organizzazione tipica il budget destinato al settore IT viene speso in tre aree principali:

• Software - Programmi e dati che l’organizzazione utilizza per le elaborazioni informatiche.

• Hardware - Computer desktop, server, componenti di rete e dispositivi mobili che consentono l’accesso al software.

• Servizi professionali - Persone e organizzazioni che assicurano la continuità dell’efficienza del sistema, ovvero personale di supporto tecnico, consulenti e fornitori.

Di queste tre aree, quella del software è la più direttamente coinvolta nella gestione delle informazioni, obiettivo finale di ogni organizzazione IT. L’hardware e i servizi professionali, per quanto componenti vitali dell’ambiente IT, possono essere considerati mezzi per il conseguimento di un fine, in quanto consentono al software di produrre il risultato finale desiderato, ovvero la gestione efficiente delle informazioni. Per dirla in altre parole, qualsiasi organizzazione acquisirebbe volentieri funzionalità software aggiuntive che non richiedano l’acquisto di nuovo hardware, mentre nessuna acquisterebbe nuovo hardware senza che vi sia l’esigenza di adottare un nuovo software.

In un ambiente IT in cui viene utilizzato software eseguito in sede, la maggior parte del budget viene solitamente spesa per l’hardware e per i servizi professionali, mentre solo una parte marginale viene investita nel software (vedere la figura 2).

Figura 2. Budget tipico di un ambiente basato su software sviluppato internamente

In questo modello il budget destinato al software viene speso principalmente per copie con licenza di software aziendale confezionato e di software line-of-business personalizzato. Il budget per l’hardware viene speso per i computer portatili e desktop da fornire agli utenti, per i server che contengono dati e applicazioni e per la componentistica di rete. Il budget per i servizi professionali viene destinato al personale di supporto, affinché provveda alla distribuzione e al supporto del software e dell’hardware, nonché ai consulenti e alle risorse di sviluppo che facilitano la progettazione e la creazione di sistemi personalizzati.

Nota Le proporzioni illustrate in questi diagrammi hanno scopo esclusivamente indicativo, non intendono promuovere una particolare ripartizione e un ambiente reale può differire significativamente da quanto indicato.

In un’organizzazione basata principalmente sul modello SaaS, la ripartizione del budget IT si presenta in modo molto diverso (vedere la figura 3).

Figura 3. Budget tipico di un ambiente SaaS

In questo modello il fornitore SaaS ospita le applicazioni critiche e i relativi dati in server centrali dislocati presso la propria sede e supporta l’hardware e il software con personale dedicato. In tal modo l’organizzazione del cliente viene sollevata dalla responsabilità di supportare il software ospitato e di acquistare e gestire l’hardware server relativo. Inoltre, le applicazioni distribuite via Web o tramite Smart Client gravano molto meno sui computer desktop rispetto a quanto avviene con le applicazioni tradizionali installate localmente. In tal modo il cliente può estendere in modo significativo il ciclo di vita della tecnologia desktop. Il risultato finale è che una parte molto più grande del budget IT può essere destinata al software, in genere sotto forma di quota di sottoscrizione ai provider SaaS.

Vantaggi dell’economia di scala

Il risultato emerso può apparire illusorio. Dopo tutto, i fornitori SaaS dovranno destinare una percentuale delle quote di sottoscrizione ricevute per il “software” al pagamento dell’hardware e dei servizi professionali a proprio carico. La risposta è nell’economia di scala. Un fornitore SaaS con x clienti che sottoscrivono un unico servizio software centralizzato può servire tutti i clienti in un ambiente consolidato. Ad esempio, un’applicazione SaaS line-of-business installata in una farm con bilanciamento del carico su cinque server può supportare 50 clienti di medie dimensioni, per cui ogni cliente sarà responsabile di un decimo del costo di un server. L’installazione locale di un’applicazione analoga richiederebbe per ogni cliente un intero server, ma nei casi in cui si desideri assicurare bilanciamento del carico e disponibilità elevata può essere necessario adottare anche più server per ogni cliente. Quanto illustrato permette un notevole risparmio potenziale rispetto al modello tradizionale e, per le applicazioni SaaS progettate in funzione della massima scalabilità, il costo operativo per cliente continuerà a scendere man mano che si aggiungono nuovi clienti. Il provider che si allinea a questa tendenza svilupperà il multi-tenancy come competenza primaria, accrescendo così la qualità della propria offerta a costi inferiori. In tal modo, anche tenendo conto dei costi sostenuti dai fornitori SaaS per l’hardware e i servizi professionali, i clienti possono ancora ottenere maggiori funzionalità software per lo stesso budget IT (vedere la figura 4).

Figura 4. Budget tipico di un ambiente SaaS, tenendo conto dei costi dell’hardware e dei servizi professionali

Accesso al mercato delle aziende minori

Con l’articolo “La Coda Lunga” pubblicato sul numero di Wired Magazine di ottobre 2004 (http://www.wired.com/wired/archive/12.10/tail.html), l’autore Chris Anderson illustrava il concetto di “Long Tail” spiegando la ragione per cui i rivenditori online, come Amazon.com, accolgono fondamentalmente la domanda che i rivenditori tradizionali non possono soddisfare in modo economicamente conveniente (vedere la figura 5).

Figura 5. La “coda lunga”

In categorie merceologiche come libri o CD, la domanda tende a concentrarsi su una fascia ristretta di articoli. In questo tipo di scenario, vengono pubblicati ogni anno migliaia di libri, CD e DVD, ma solo poche decine di titoli si eleva al rango di bestseller. Il resto langue in una sorta di “coda lunga”, costituita dal gran numero di pubblicazioni minori a contenuto specialistico che, nella migliore delle ipotesi, venderanno al massimo qualche migliaio di copie.

I rivenditori tradizionali si concentrano sulla vendita degli articoli più popolari, perché non possono tenere in magazzino copie di ciascuno dei tre milioni di libri, CD e DVD in pubblicazione. I rivenditori online, invece, non hanno problemi di spazio sugli scaffali. Inviando la merce ai clienti direttamente da enormi depositi sparsi per il mondo, possono pubblicizzare e vendere con la stessa facilità sia il titolo più popolare che quello al milionesimo posto in classifica. L’accesso a questa lunga coda di vendite minori si traduce in un enorme profitto.

Un grande negozio tradizionale di libri può esporre sui propri scaffali circa 130.000 titoli diversi. Tuttavia secondo Anderson la maggior parte delle vendite di libri di Amazon.com riguarda titoli non compresi tra i primi 130.000. In altre parole, la maggior parte dei libri venduti da Amazon.com non sarebbe mai stata proposta in una libreria tradizionale.

I fornitori di soluzioni software line-of-business complesse si confrontano con una curva di mercato simile (vedere la figura 6).

Figura 6. Curva del mercato dei fornitori di software line-of-business

Diversamente dai pacchetti software confezionati, più semplici, il software line-of-business viene frequentemente personalizzato in base alle specifiche esigenze del cliente, talvolta viene installato e assistito in sede dai team di servizio del fornitore e in molti casi richiede hardware server dedicato e personale di supporto per la gestione. Il costo di questi servizi dedicati incide sul prezzo minimo a cui il fornitore può vendere il software. Questo tipo di software viene pertanto rivolto prevalentemente alle aziende abbastanza grandi da poter sostenere il costo di tale grado di servizio personalizzato. Per ogni grande azienda che acquista una soluzione line-of-business, vi sono però decine di aziende più piccole che potrebbero beneficiare di una soluzione simile, ma che non possono affrontarne la spesa.

Figura 7. Nuovi mercati aperti dal minor costo del software SaaS

Con il taglio delle spese di manutenzione e grazie all’economia di scala resa possibile dalla combinazione e dalla centralizzazione dell’hardware e dei servizi rivolti ai clienti, i fornitori di software SaaS possono offrire soluzioni a costi molto contenuti rispetto ai fornitori di software tradizionali, non solo in termini monetari, ma anche in termini di snellimento dell’infrastruttura IT dei clienti. L’adozione del modello SaaS consente pertanto l’accesso esclusivo a una fascia di clienti potenziali completamente nuova, finora irraggiungibile dai fornitori di software tradizionali perché non economicamente conveniente (vedere la figura 7).

Per acquisire con efficacia i nuovi clienti minori, i fornitori abituati a un processo di vendita basato sul contatto personale e sul rapporto fornitore-cliente devono cambiare ancora una volta prospettiva. Con i prezzi più contenuti resi possibili dall’adozione del modello SaaS, la maggior parte dei fornitori non potrà offrire servizi personalizzati a una base di clienti molto più ampia di quella attuale. La vendita di software SaaS è comparabile alla vendita di suonerie per telefoni portatili o di musica scaricabile: il cliente deve poter visitare il sito Web del fornitore, sottoscrivere il servizio, pagare con carta di credito, personalizzare il servizio e iniziare a utilizzarlo, il tutto senza intervento umano da parte del fornitore. Questo non significa che si debba rinunciare all’approccio personale dedicato ai clienti più grandi aventi esigenze specifiche. Se però si progetta l’automazione dei processi di vendita, marketing, fornitura e personalizzazione sin dalla pianificazione iniziale, si potrà offrire l’approccio automatizzato come una possibile scelta e si otterrà come fortunato effetto collaterale la semplificazione del lavoro che il proprio personale di supporto deve svolgere per eseguire le stesse attività per conto di un cliente.

Architettura dell’applicazione

La definizione sopra citata di software come servizio è: “software distribuito come servizio in hosting a cui si accede tramite Internet”. A seconda di come si definiscano parole come software e accesso, questa definizione può tuttavia includere una serie fin troppo ampia di significati. Dal punto di vista di un architetto di applicazioni, questa definizione certo non chiarisce cosa renda un’applicazione SaaS effettivamente funzionante, ovvero quale sia la differenza tra un’applicazione SaaS efficace e una non efficace. L’abbinamento tra un’applicazione line-of-business basata su codice scritto dieci anni fa e un front end HTML di fortuna può ricadere sotto la definizione generale di software come servizio, ma con buona probabilità presenterebbe problemi di scalabilità e non risulterebbe economicamente vantaggioso. Per individuare quella che potrebbe essere definita un’applicazione SaaS matura, è pertanto necessario introdurre alcuni criteri aggiuntivi.

I tre attributi di un’architettura multi-tenant a istanza singola

Dal punto di vista di un architetto di applicazioni, vi sono tre differenze principali tra un’applicazione SaaS ben progettata e una meno valida. Un’applicazione SaaS ben progettata è scalabile, assicura un’efficienza multi-tenant ed è configurabile.

Rendere scalabile un’applicazione significa aumentare la concorrenza massima e utilizzare le risorse applicative in modo più efficiente, ad esempio ottimizzando la durata dei blocchi, ricorrendo all’assenza di stato, condividendo risorse comuni come thread e connessioni di rete, memorizzando dati di riferimento nella cache e dividendo i database di grandi dimensioni in più parti.

Il multi-tenancy è la novità più significativa per gli architetti abituati a progettare applicazioni single-tenant isolate. Quando ad esempio un utente di un’azienda accede alle informazioni relative ai propri clienti utilizzando un servizio di applicazione CRM, è possibile che l’istanza di applicazione a cui si connette stia già servendo decine, se non centinaia, di utenti di altre aziende, tutti ignari l’uno dell’altro. È pertanto necessario che l’architettura preveda la massima condivisione delle risorse tra i diversi utenti e il necessario isolamento tra i dati di ciascuno.

Naturalmente, se una singola istanza di applicazione in esecuzione su un singolo server deve accogliere utenti di diverse aziende contemporaneamente, non è possibile limitarsi a implementare codice personalizzato per rispondere alle esigenze di un utente specifico, perché ogni modifica impatterebbe anche su tutti gli altri utenti. Anziché accedere a una versione personalizzata dell’applicazione in senso tradizionale, ogni cliente utilizzerà metadati per configurare il funzionamento e l’aspetto della stessa applicazione. L’architetto SaaS dovrà curare che la configurazione delle applicazioni risulti semplice per tutti i clienti e non implichi ulteriori costi operativi o di sviluppo.

Il modello di maturità del software come servizio

La definizione di SaaS include adesso anche gli attributi importanti che caratterizzano un’applicazione SaaS matura. La maturità può essere anche parziale. Un’applicazione può soddisfare i requisiti aziendali posti come obiettivo anche se possiede solo uno o due di questi attributi. In tal caso l’architetto dell’applicazione può scegliere di non implementare gli altri attributi per non aumentare i costi senza motivo.

In termini generali, la maturità di un’applicazione SaaS può essere espressa utilizzando un modello con quattro livelli distinti. Ogni livello si distingue dal precedente per l’aggiunta di uno dei tre attributi sopra elencati.

Figura 8. Modello di maturità SaaS a quattro livelli

Livello I: istanze ad hoc/personalizzate

Il primo livello di maturità è simile al modello di distribuzione software tradizionale ASP (Application Service Provider), risalente agli anni ‘90. A questo livello, ogni cliente dispone di una propria versione personalizzata dell’applicazione ospitata ed esegue una propria istanza dell’applicazione sui server host. Dal punto di vista dell’architettura, il software con questo livello di maturità è molto simile al software line-of-business venduto in modo tradizionale, perché diversi client di un’organizzazione si connettono a una stessa istanza in esecuzione sul server, ma tale istanza è completamente indipendente da tutte le altre istanze o processi che l’host esegue per conto degli altri clienti.

Le applicazioni client-server tradizionali possono essere di norma adattate al primo livello di maturità del modello SaaS con interventi di sviluppo relativamente contenuti e senza riorganizzare da capo l’architettura dell’intero sistema. Benché questo livello offra solo alcuni dei vantaggi di una soluzione SaaS completamente matura, già consente ai fornitori di ridurre i costi attraverso il consolidamento dell’hardware server e dell’amministrazione.

Livello II: istanze configurabili

Al secondo livello di maturità il fornitore ospita un’istanza distinta dell’applicazione per ogni cliente (o tenant). Mentre al primo livello ogni istanza viene personalizzata singolarmente per il tenant, a questo livello tutte le istanze utilizzano la stessa implementazione del codice e le diverse esigenze dei clienti vengono soddisfatte tramite opzioni di configurazione dettagliate che consentono al cliente di modificare l’aspetto e il funzionamento dell’applicazione. Pur essendo identiche a livello di codice, le diverse istanze restano completamente isolate le une dalle altre.

L’adozione di un’unica base di codice per tutti i clienti di un fornitore consente di ridurre drasticamente i requisiti di servizio di un’applicazione SaaS, perché ogni modifica apportata alla base di codice può essere facilmente estesa a tutti i clienti contemporaneamente. In tal modo non è più necessario provvedere all’aggiornamento o all’installazione integrata di singole istanze personalizzate. Tuttavia, se un’applicazione tradizionale è stata progettata per la personalizzazione individuale e non per la configurazione tramite metadati, l’adattamento dell’applicazione al secondo livello di maturità del modello SaaS può richiedere una modifica architetturale più consistente rispetto a quella necessaria per l’adattamento al primo livello.

Come per il primo livello, anche per il secondo livello di maturità il fornitore deve predisporre hardware e spazio di archiviazione sufficienti a supportare un numero potenzialmente alto di istanze di applicazione in esecuzione contemporanea.

Livello III: istanze configurabili e multi-tenant efficiente

Al terzo livello di maturità il fornitore esegue una singola istanza per tutti i clienti e assicura la possibilità di configurare l’aspetto e le funzionalità dell’applicazione tramite metadati. I criteri di autorizzazione e di protezione assicurano che i dati di ogni utente siano separati da quelli degli altri utenti e dalla prospettiva dell’utente nulla indica che l’istanza dell’applicazione è condivisa con altri tenant.

Con questo approccio non è più necessario che il server del fornitore disponga di spazio sufficiente a contenere un numero di istanze equivalente al numero di clienti. Le risorse di elaborazione vengono utilizzate in modo molto più efficiente rispetto al secondo livello e i costi vengono ridotti di conseguenza. Uno svantaggio significativo di questo approccio è che la scalabilità dell’applicazione è limitata. A meno che non si ricorra al partizionamento per gestire le prestazioni del database, l’applicazione può essere scalata solo spostandola su un server più potente (scalabilità verticale), fino a quando la riduzione dei ricavi non renda impossibile aggiungere ulteriore potenza in termini economicamente convenienti.

Livello IV: istanze scalabili e configurabili e multi-tenant efficiente

Al quarto e ultimo livello di maturità il fornitore ospita una farm di istanze identiche con bilanciamento del carico e assicura ai clienti l’isolamento dei dati e la possibilità di configurare l’aspetto e le funzionalità dell’applicazione tramite metadati. Tale sistema SaaS può essere scalato fino a soddisfare un numero arbitrario di clienti, perché il numero di server e istanze in esecuzione nel back end può essere aumentato o ridotto in base alla domanda e senza modificare l’architettura dell’applicazione, mentre gli aggiornamenti e le correzioni possono essere estesi contemporaneamente a centinaia di tenant.

Scelta di un modello di maturità

Qual è il modello di maturità più adatto alla propria applicazione? Il quarto livello potrebbe sembrare il migliore in assoluto, per qualsiasi applicazione SaaS, ma non è sempre così. Può essere più utile pensare alla maturità SaaS come a una linea continua che unisce isolamento di dati e codice da un lato e condivisione di dati e codice dall’altro (vedere la figura 9).

Figura 9. Maturità SaaS vista come una linea continua

Dove collocare la propria applicazione su questa linea continua dipende dal tipo di azienda, dall’architettura, dalle esigenze operative e dalle considerazioni sui clienti. Come si potrà vedere anche da questa semplice spiegazione, tutte queste considerazioni sono in qualche modo correlate.

• Modello di business - Ha senso un approccio isolato in termini finanziari? Rinunciare ai vantaggi economici e di gestione tipici dell’approccio condiviso significa offrire la propria applicazione a costi più alti. In alcuni casi questa scelta può essere tuttavia giustificata dalla necessità di soddisfare esigenze diverse. I clienti possono inoltre mostrare una resistenza di origine culturale o legale a un modello architetturale in cui più tenant condividono l’accesso alla stessa applicazione, anche se si dimostra loro che questo non comporta alcun rischio per i dati riservati. In ultima analisi è ovviamente necessario adottare un modello di business che consenta di creare un’applicazione redditizia, indipendentemente dal livello di maturità scelto.

• Modello architetturale - È possibile realizzare l’applicazione in modo che possa essere eseguita in una sola istanza logica? Se si pensa di realizzare un sistema di distribuzione tramite Internet adattando un’applicazione desktop o client-server tradizionale, si tenderà a rilevare che quest’ultima è fondamentalmente incompatibile con l’approccio a istanza singola basato su metadati e probabilmente si concluderà che l’investimento da sostenere per la sua trasformazione in un’applicazione SaaS completamente matura non è economicamente conveniente. Se invece si sta progettando e realizzando da zero un’applicazione di rete nativa, sarà molto più facile optare per l’approccio a istanza singola.

• Modello operativo - È possibile garantire il rispetto del contratto di servizio (SLA) senza ricorrere all’isolamento? Esaminare attentamente gli obblighi previsti dai contratti di servizio sottoscritti con i clienti, con particolare attenzione alle clausole relative ai tempi di inattività, alle opzioni di supporto e al ripristino d’emergenza e determinare se tali obblighi possono essere soddisfatti con un’architettura applicativa in cui più clienti non correlati condividono l’accesso a una stessa istanza di applicazione.

Architettura generale

Dal punto di vista dell’architettura, le applicazioni SaaS sono molto simili alle altre applicazioni create sui principi della progettazione orientata ai servizi (vedere la figura 10).

Figura 10. Architettura di un’applicazione SaaS

La maggior parte dei componenti illustrati nella figura 10 dovrebbe essere già familiare agli architetti di applicazioni. I servizi di elaborazione espongono interfacce che possono essere richiamate dagli Smart Client e/o dal livello di presentazione Web ed avviano un flusso di lavoro sincrono o una transazione di lungo termine che richiamerà altri servizi aziendali che interagiscono con i rispettivi archivi dati per leggere e scrivere i dati aziendali. I servizi di protezione sono responsabili del controllo degli accessi ai servizi software per il back-end e gli utenti finali.

La differenza di maggior rilievo consiste nell’aggiunta di servizi di metadati, responsabili della gestione della configurazione dell’applicazione per i singoli tenant. I servizi e gli Smart Client interagiscono con i servizi di metadati per recuperare informazioni che descrivono le configurazioni e le estensioni specifiche di ogni tenant.

Servizi di metadati

In un’applicazione SaaS matura i servizi di metadati costituiscono per i clienti il mezzo principale per personalizzare e configurare l’applicazione in base alle proprie esigenze. Gli utenti possono di norma modificare la configurazione in quattro aree principali:

• Interfaccia utente e branding - I clienti spesso apprezzano la possibilità di modificare l’interfaccia utente per aggiungervi i tratti distintivi dell’azienda e per questo le applicazioni SaaS offrono in genere funzionalità che consentono ai clienti di modificare elementi quali grafica, colori, tipi di carattere e così via.

• Flusso di lavoro e regole di business - Per raggiungere un’ampia gamma di potenziali clienti, un’applicazione aziendale critica SaaS deve poter accomodare flussi di lavoro diversi. Un cliente di un’applicazione di fatturazione può ad esempio richiedere che ogni fattura venga approvata da un responsabile. Un secondo cliente può richiedere che ogni fattura venga approvata da due responsabili in sequenza. Un terzo può richiedere che ogni fattura venga approvata da due responsabili, che possono però lavorare in parallelo. Quando appropriato, è consigliabile dare ai clienti la possibilità di configurare il flusso di lavoro dell’applicazione al fine di allinearlo ai processi aziendali.

• Estensione del modello dati - Per molte applicazioni SaaS guidate dai dati, un modello dati rigido è semplicemente inadeguato a soddisfare tutti. Anche nell’utilizzo di applicazioni relativamente semplici mirate allo svolgimento di una sola attività specifica, i clienti possono lamentarsi delle restrizioni imposte da un set di dati e tabelle non modificabile. Un modello dati estendibile prevede che l’applicazione possa essere adattata alle esigenze dei clienti e non viceversa. Più avanti in questo documento verrà illustrato come definire l’architettura di un modello dati estendibile.

• Controllo accessi - La creazione degli account per i diversi utenti e l’assegnazione dei diritti di accesso alle diverse risorse e funzionalità vengono solitamente affidate ai clienti. I diritti e le restrizioni di accesso vengono tracciati mediante l’utilizzo di criteri di protezione che devono poter essere configurati dai diversi tenant.

Per offrire ai clienti la possibilità di configurare il software in base alle proprie esigenze, queste opzioni sono organizzate in unità di configurazione gerarchiche, ciascuna delle quali contiene opzioni relative a ognuna delle quattro aree sopra elencate. Ogni cliente può configurare liberamente un ambito di primo livello ed eventualmente creare uno o più sottoambiti in una gerarchia arbitraria. Una strategia di relazioni determina se e come i nodi figlio debbano ereditare o sovrascrivere le impostazioni di configurazione dei nodi padre.

Un cliente tipico che acquista per la propria azienda l’accesso a un’applicazione può ad esempio disporre di diverse business unit, tutte conformi a determinati standard aziendali, ma con esigenze diverse e tali da rendere necessaria la configurazione autonoma di alcuni aspetti dell’applicazione. All’interno di ogni business unit possono esserci, a loro volta, gruppi organizzativi con esigenze di configurazione specifiche. Per ognuna di queste unità organizzative, il cliente può stabilire un ambito che assicura al gruppo l’accesso alle opzioni di configurazione e la possibilità di impostarle o modificarle.

Diversamente dalle applicazioni line-of-business tradizionali, configurate dal fornitore, è molto più probabile che le applicazioni SaaS vengano configurate direttamente dai clienti. La progettazione dell’interfaccia di configurazione richiede pertanto la stessa cura posta nella progettazione dell’interfaccia visualizzata dagli utenti finali. L’ideale sarebbe che gli utenti potessero configurare l’applicazione tramite una procedura guidata o tramite schermate semplici e intuitive che contengano tutte le opzioni disponibili, ma senza sovraffollamenti e con una distinzione chiara tra quelle che possono essere modificate o meno all’interno di un certo ambito.

Servizi di protezione

Il tema della protezione, già importante di per sé in qualsiasi contesto software, per la natura del modello SaaS diventa un imperativo per i clienti e una priorità assoluta per gli architetti. Attenendosi ad alcune linee guida basilari è possibile garantire ai tenant la riservatezza dei propri dati.

Autenticazione

Di norma il provider SaaS affida ai tenant la responsabilità di creare e gestire i propri account utente, in un processo definito amministrazione delegata. Con l’amministrazione delegata, il cliente crea gli account utente e il fornitore li autentica. Per implementare il modello dell’amministrazione delegata, i progettisti SaaS ricorrono a due modalità principali di gestione dell’autenticazione: un sistema di autenticazione centralizzato o un sistema di autenticazione decentralizzato. La scelta del progettista avrà un impatto sulla complessità dell’architettura e sull’esperienza degli utenti finali e va fatta tenendo conto delle considerazioni del modello aziendale sulle esigenze dell’applicazione, dei clienti e degli utenti finali.

In un sistema di autenticazione centralizzato il provider gestisce un unico database centrale degli account utente per tutti i tenant dell’applicazione. Gli amministratori di ogni tenant possono creare, gestire ed eliminare gli account utente del proprio tenant. Quando un utente si connette all’applicazione, fornisce le proprie credenziali. L’applicazione le autentica confrontandole con i record contenuti nell’elenco centrale ed eventualmente concede l’accesso all’utente (vedere la figura 11).

Figura 11. Sistema di autenticazione centralizzato

Questo approccio richiede un’infrastruttura di autenticazione relativamente semplice che può essere progettata e implementata con una certa facilità e non richiede modifiche all’infrastruttura utente del tenant. Uno svantaggio importante di questo approccio è che un sistema di autenticazione centralizzato rende molto più difficile l’implementazione del Single Sign-On, in cui l’applicazione accetta le credenziali che l’utente finale ha già immesso durante l’accesso alla rete aziendale. Senza il Single Sign-On, ogni volta che gli utenti accedono all’applicazione verrà visualizzata una noiosa richiesta di credenziali che dovrà essere compilata manualmente.

In un sistema di autenticazione decentralizzato il tenant distribuisce un servizio federativo che si interfaccia con il proprio servizio directory degli utenti. Quando un utente finale tenta di accedere all’applicazione, il servizio federativo autentica l’utente localmente ed emette un token di protezione. Questo viene accettato dal sistema di autenticazione del provider SaaS e l’utente può accedere all’applicazione (vedere la figura 12).

Figura 12. Sistema di autenticazione decentralizzato

È un approccio ideale quando è importante utilizzare il Single Sign-On, perché l’autenticazione viene gestita in modo trasparente e non impone all’utente la memorizzazione e l’immissione di un set di credenziali specifico. L’approccio decentralizzato è tuttavia molto più complesso di quello centralizzato e un’applicazione SaaS con migliaia di clienti richiederebbe relazioni di trust individuali con i servizi federativi di ciascun tenant.

In molti casi il provider SaaS tenderà ad adottare una soluzione ibrida, in cui ricorre all’approccio centralizzato per autenticare e gestire gli utenti dei tenant più piccoli e all’approccio federativo per le aziende di dimensioni maggiori che desiderano sfruttare i vantaggi del Single Sign-On e sono disposte a pagarne il prezzo.

Autorizzazione

Di norma l’accesso alle risorse e alle funzioni aziendali delle applicazioni SaaS viene gestito tramite ruoli mappati alle specifiche funzioni professionali definite all’interno di un’organizzazione. A ogni ruolo vengono assegnate una o più autorizzazioni che consentono agli utenti di quel ruolo di svolgere azioni in conformità con le regole di business applicabili (vedere la figura 13).

Figura 13. Controllo accessi

I ruoli vengono gestiti all’interno dell’applicazione SaaS stessa. Possono contenere account utente individuali o gruppi di utenti. Agli account utente individuali e ai gruppi è possibile assegnare più ruoli, in base alle necessità.

A seconda dei ruoli a cui è assegnato, un determinato utente dispone di una o più autorizzazioni a svolgere operazioni o azioni specifiche. Tali azioni sono solitamente mappate direttamente a importanti funzioni aziendali o alla gestione dell’applicazione stessa. Un’applicazione per gli acquisti potrebbe ad esempio includere autorizzazioni per la creazione, l’invio, l’approvazione e il rifiuto di ordini di acquisto. Un’applicazione per agenti ipotecari potrebbe invece includere autorizzazioni per il controllo del credito di un cliente e la concessione di un prestito e così via. La stessa autorizzazione può essere assegnata a uno o più ruoli, in base alle necessità, e a ogni utente verrà riconosciuto l’insieme delle autorizzazioni assegnate a tutti i ruoli a cui appartiene.

L’utilizzo delle regole di business consente di controllare l’accesso alle azioni e alle risorse di un’applicazione in modo più dettagliato di quanto permesso dalle autorizzazioni. Le regole di business introducono la necessità di soddisfare alcune condizioni prima che l’accesso possa essere concesso. È ad esempio possibile utilizzare una regola di business che consente a un utente di trasferire fondi tra conti diversi solo durante le ore di ufficio, a meno che la somma trasferita non sia inferiore a un determinato importo.

Il controllo accessi viene gestito a livello di ambito. Ogni ambito eredita ruoli, autorizzazioni e regole di business da tutti gli ambiti padre, in base alla strategia di relazioni, e può modificarli, aggiungerne altri o eliminarli, in base alle necessità. Si consideri ad esempio un cliente con sede negli Stati Uniti e filiale a Toronto, in Canada. L’ambito radice include un ruolo denominato Amministratore indennità, che dispone di diverse autorizzazioni inerenti la gestione delle indennità dei lavoratori, compresa l’amministrazione del programma di accantonamento pensionistico 401(k) dell’azienda. Poiché i piani pensione 401(k) sono contemplati solo nella normativa fiscale statunitense, in Canada non vengono utilizzati. Per la filiale canadese viene quindi creato un ambito figlio che eredita il ruolo Amministratore indennità e le relative autorizzazioni, ma non eredita l’autorizzazione a modificare i versamenti per il piano 401(k). In sostituzione il cliente aggiunge un’autorizzazione che consente al ruolo di modificare i versamenti per il piano di accantonamento pensionistico registrato RRSP (Registered Retirement Savings Plan), l’equivalente canadese del 401(k) statunitense.

Figura 14. Esempio di confronto tra autorizzazioni dell’ambito radice e dell’ambito figlio

L’ideale è che l’applicazione includa un set predefinito di ruoli, autorizzazioni e regole di business che ogni tenant possa modificare ed estendere in autonomia tramite un’interfaccia utente funzionale e intuitiva.

Approfondimento: il modello dati multi-tenant

Fin qui è stata esaminata l’architettura generale delle applicazioni. Ora verrà approfondito un aspetto particolare, ovvero quello della creazione di un modello dati che possa essere esteso dai clienti in un ambiente multi-tenant. L’intento non è quello di studiare tutti i dettagli del processo di estensione del modello dati, ma di rendere l’idea delle problematiche architetturali da tenere presenti nella progettazione delle applicazioni SaaS.

Nel progettare l’applicazione verrà certo inclusa una configurazione di database standard, con tabelle, campi, query e relazioni predefinite, adeguate allo scopo della soluzione. Organizzazioni diverse presentano però esigenze diverse, che non possono essere soddisfatte da un modello dati predefinito rigido e non estendibile. Un cliente di un sistema SaaS per il controllo dei processi potrebbe ad esempio voler archiviare con ogni record una stringa contenente un codice di classificazione generato esternamente per assicurare la piena integrazione tra il sistema e gli altri processi. Un altro cliente potrebbe non aver bisogno di un campo contenente una stringa di classificazione, ma potrebbe voler memorizzare un intero che rappresenta l’ID di categoria. Fatta eccezione per pochi casi particolari, sarà quindi necessario sviluppare e implementare un metodo che consenta ai clienti di estendere il modello dati predefinito in base alle proprie esigenze senza compromettere il modello dati utilizzato dagli altri clienti. Per la soluzione di questo problema verranno considerati tre approcci generali: database dedicati per ogni tenant, un database condiviso con un set di estensioni fisso e un database condiviso con estensioni personalizzate.

Database dedicati per ogni tenant

Il primo approccio prevede che a ogni tenant venga assegnato un database dedicato, che può essere esteso dal tenant in base alle proprie esigenze.

Con questo approccio viene creato un nuovo database predefinito standard durante il processo di acquisizione di ogni nuovo tenant e il servizio di metadati tiene traccia di quale database è assegnato a ogni tenant. Dopo la creazione del nuovo database, il tenant può modificarlo liberamente, nei limiti fissati dall’interfaccia utente e dalla logica di programma dell’applicazione. Potenzialmente può creare nuovi campi, nuove query e anche nuove tabelle e relazioni.

Se il fattore costo può essere trascurato, questo è l’unico approccio da prendere in considerazione, perché è quello più facilmente realizzabile e offre ai clienti la massima libertà di estensione del modello dati predefinito. Clienti di settori come quelli bancario e medico possono inoltre avere l’esigenza del massimo isolamento dei dati e potrebbero non prendere neanche in considerazione un’applicazione che non offra ad ogni cliente un database dedicato. Lo svantaggio di questo approccio risiede nella possibilità di supportare solo un numero limitato di database per ogni server. Pertanto il costo dell’infrastruttura sarà più alto e tenderà a crescere più rapidamente.

Database condiviso e set di estensioni fisso

Il secondo approccio prevede la creazione di un unico database condiviso da tutti i tenant che include un numero predefinito di campi personalizzati che i tenant possono attivare e utilizzare nel modo desiderato (vedere la figura 15).

Figura 15. Campi personalizzati in un database condiviso

Nella figura 15 i record dei diversi clienti vengono tutti memorizzati in un’unica tabella. Un campo TenantID associa ogni record al relativo tenant. Oltre al set di campi standard, vengono forniti alcuni campi personalizzati. Ogni cliente può decidere come utilizzare tali campi e come raccogliere i relativi dati.

I campi possono essere tipizzati e quindi sottoposti a tutte le funzionalità di controllo e convalida dell’input previste dall’applicazione e dal database. In alternativa è possibile non tipizzare i campi per consentire ai clienti di archiviarvi qualsiasi tipo di dati. I clienti possono facoltativamente fornire una propria logica di convalida dell’input per evitare che gli utenti immettano involontariamente dati non validi.

Il database condiviso comporta un costo di erogazione dei servizi di gran lunga inferiore rispetto a quello dell’approccio isolato, perché consente a un singolo motore di database di supportare un numero di clienti più ampio prima che si renda necessario un partizionamento. Lo svantaggio maggiore di questo approccio sta nel fatto che l’estendibilità del modello dati è limitata al numero di campi personalizzati predisposti. La scelta di questo numero richiede un’attenta valutazione delle esigenze potenziali dei clienti. Se i campi sono pochi, i clienti non potranno utilizzare l’applicazione in modo efficace, se invece sono troppi si avrà un inutile spreco di spazio e un database pieno di campi inutilizzati.

Database condiviso ed estensioni personalizzate

Il terzo approccio prevede la creazione di un unico database condiviso e consente ai clienti di estendere il modello dati in modo arbitrario per archiviarvi, ad esempio, dati personalizzati quali coppie nome-valore in tabelle separate (vedere la figura 16).

Figura 16. Dati personalizzati archiviati in una tabella di estensione separata

In questo caso a ogni record per il quale un cliente definisce dati personalizzati viene assegnato un ID univoco collegato a una o più righe memorizzate in una tabella di estensione separata. Per ogni riga di questa tabella viene memorizzata una coppia nome-valore. Ogni cliente può creare un numero indefinito di coppie nome–valore, in base alle proprie esigenze. Quando l’applicazione recupera un record del cliente, esegue una ricerca nella tabella dati personalizzata, seleziona tutte le righe corrispondenti all’ID del record e le restituisce come normali campi dati. Naturalmente i campi della tabella personalizzata non possono essere tipizzati, perché dovranno contenere dati diversi per i diversi clienti. Per aggirare questa limitazione è possibile aggiungere una terza colonna contenente un identificatore del tipo di dati, in modo che sia possibile eseguire il cast dei dati recuperati al tipo appropriato.

Questo approccio consente l’estensione arbitraria del modello dati pur conservando i vantaggi economici dell’utilizzo di un database condiviso. Lo svantaggio principale risiede nella maggiore complessità delle funzioni di database, ad esempio per le ricerche, l’indicizzazione, le query e l’aggiornamento dei record. Questo è l’approccio più indicato quando si prevede che i clienti avranno bisogno di un elevato grado di flessibilità nell’estensione del modello dati predefinito, ma non richiederanno l’isolamento dei dati.

Nello sviluppo di un modello dati estendibile è necessario tenere presente che ogni estensione implementata da un cliente richiederà una corrispondente estensione della logica di business (affinché l’applicazione possa utilizzare i dati personalizzati) e della logica di presentazione (affinché gli utenti possano immettere i dati personalizzati come input e riceverli come output). L’interfaccia di configurazione presentata al cliente dovrebbe quindi offrire meccanismi per l’aggiornamento, possibilmente integrato, di tutti e tre gli elementi. In un prossimo documento verrà illustrato come offrire meccanismi che consentano a ogni cliente di estendere la logica di business e l’interfaccia utente.

Scalabilità

Il software aziendale su larga scala è destinato ad essere utilizzato da migliaia di persone contemporaneamente. Chi ha esperienza nello sviluppo di applicazioni aziendali di questo tipo ha imparato a conoscere in prima persona le problematiche correlate alla creazione di un’architettura scalabile. Per un’applicazione SaaS, la scalabilità è ancora più importante: sarà infatti necessario supportare la base di utenti media di un singolo cliente moltiplicato per il numero totale di clienti. Agli ISV abituati a realizzare software aziendali da eseguire in sede, supportare questo tipo di base di utenti sembrerà come passare da un campionato minore al campionato di serie A: le regole possono essere familiari, ma la partita viene giocata a un livello completamente diverso. Anziché con un’applicazione aziendale business-critical distribuita su larga scala, si confronteranno con la creazione di un sistema scalato su Internet, che deve offrire supporto attivo a una base di utenti potenzialmente destinata a contare milioni di unità.

Scalabilità dell’applicazione

Non sempre si avrà l’onere e la fortuna di supportare tanti utenti quanti ne conta Hotmail, ma i problemi di scalabilità resteranno più o meno gli stessi.

Le applicazioni possono essere scalate verticalmente (passando l’applicazione su un server più grande e potente) o orizzontalmente (eseguendo l’applicazione su più server). L’adeguamento verticale, soluzione familiare adottata da chiunque abbia sostituito un vecchio computer con uno nuovo, è spesso la scelta migliore per le piccole applicazioni che non servono un numero di utenti molto elevato. In ambito SaaS, tuttavia, il modo migliore per aggiungere capacità al sistema è quasi sempre l’adeguamento orizzontale, come descritto nel modello di maturità SaaS. Un’applicazione SaaS ben progettata può essere scalata orizzontalmente su un numero arbitrario di server, ognuno dei quali esegue una o più istanze identiche dell’applicazione. Di seguito vengono illustrate le linee guida per la progettazione di un’applicazione che possa essere “scalata orizzontalmente” senza difficoltà.

• Progettare l’applicazione in modo che possa essere eseguita senza stato, con tutti i dati necessari sugli utenti e sulle sessioni archiviati sul lato client o in un archivio distribuito accessibile da tutte le istanze dell’applicazione. Assenza di stato significa che tutte le transazioni possono essere gestite da un’istanza così come da qualsiasi altra e un utente può avviare transazioni con decine di istanze diverse nella stessa sessione senza neanche saperlo.

• Progettare l’applicazione in modo che le operazioni di I/O possano essere eseguite in modo asincrono, così che l’applicazione possa svolgere altri lavori nell’attesa del completamento dell’input e dell’output.

• Condividere le risorse come thread, connessioni di rete e connessioni di database. Questo consente di utilizzare al meglio le risorse di elaborazione e facilita la previsione del peso che graverà su di esse.

• Scrivere le operazioni di database in modo da assicurare la massima concorrenza e il minore numero di blocchi esclusivi. Quando si eseguono operazioni di sola lettura, ad esempio, non bloccare i record.

Questo è ovviamente solo un modo estremamente sintetico di esaminare il tema dell’implementazione di un’architettura scalabile. Sull’argomento è stato scritto ben più di un volume. Per ulteriori riferimenti, vedere Risorse su prestazioni e scalabilità pubblicato da Microsoft Patterns & Practices.

Scalabilità dei dati

Man mano che le dimensioni dei database crescono per l’aumentare del numero degli utenti, il tempo impiegato per svolgere operazioni come query e ricerche si allunga. Le applicazioni SaaS, che spesso utilizzano gli stessi database per servire migliaia di clienti, sono particolarmente suscettibili di questo tipo di decadimento delle prestazioni ed è quindi importante prevedere un piano di crescita adeguato.

Un modo piuttosto semplice di scalare un database consiste nel partizionarlo, dividendo i dati in “pezzi” più piccoli allo scopo di migliorare l’efficienza di query e aggiornamenti. Per determinare il modo migliore di partizionare i dati, è opportuno considerare lo sviluppo di una strategia di partizionamento. Se ad esempio un’applicazione ha clienti in tutto il mondo, una strategia di partizionamento geografico potrebbe essere appropriata, così da porre i dati dei clienti europei in una partizione, i dati dei clienti asiatici in un’altra e così via.

Nella maggior parte delle situazioni è probabile che la dimensione del database continui a crescere. È quindi importante implementare anche una strategia di ripartizionamento dinamico, per assicurare che i dati già partizionati possano essere partizionati ulteriormente, in modo da mantenere elevate le prestazioni e la metrica di scala.

Struttura operative

Il terzo cambiamento importante nel modo di pensare deve riguardare la struttura operativa dell’applicazione, ovvero la distribuzione dell’applicazione ai clienti e il modo di mantenerla disponibile ed efficiente a costi contenuti. Per molti ISV, che non hanno mai eseguito un datacenter per i propri clienti, questo può risultare l’aspetto meno familiare del modello SaaS. I provider SaaS non solo devono essere esperti nella creazione e nella promozione del software, ma devono anche imparare a farlo funzionare e a gestirlo.

Risorse come Microsoft Operations Framework (MOF) offrono una grande quantità di indicazioni su come mantenere un sistema affidabile, disponibile, supportabile e gestibile. Oltre alle problematiche operative comunemente affrontate da MOF, il modello SaaS ne presenta altre specifiche.

Servizi condivisi

Chi ha maturato esperienze nella presenza aziendale sul Web dovrebbe avere già una certa familiarità con le basi dell’hosting Web e dei servizi middleware. Di norma un’organizzazione ospita un sito internamente oppure contratta con un provider esterno la condivisione di uno spazio per l’attrezzatura o l’hosting completo, comprensivo di hardware, archiviazione e larghezza di banda. Il servizio di hosting è responsabile della disponibilità del sito, ma di solito non è altrettanto responsabile del funzionamento e della gestione del sito.

La fornitura di software come servizio introduce un nuovo elemento da considerare quando si pensa all’hosting (vedere la figura 17). A seconda del proprio piano aziendale può essere necessario adottare un sistema di misurazione e addebito per:

• Tenere traccia dell’attività del cliente e addebitare il tempo di utilizzo del servizio o l’impiego delle risorse.

• Negare o limitare l’accesso in certe ore del giorno o in base ad altri criteri.

• Monitorare l’accessibilità e le prestazioni del sito per verificare la conformità ai contratti di servizio.

• Eseguire altre funzioni per assicurare ai clienti un’esperienza fluida che risponda alle aspettative o le superi.

L’insieme dei sistemi utilizzati per lo svolgimento di queste funzioni è definito servizi condivisi.

Figura 17. Livello dei servizi condivisi per l’hosting SaaS

I servizi condivisi possono essere ulteriormente classificati in due sottocategorie:

• Servizi di supporto operativo (OSS, Operational Support Services) - Per la gestione di problematiche operative quali l’attivazione degli account, la fornitura, la garanzia del servizio, l’utilizzo e la misurazione.

• Servizi di supporto aziendale (BSS, Business Support Services) - Per il supporto degli addebiti (fatturazione, tariffazione, tassazione e incasso) e la gestione dei clienti (immissione ordini, self service per i clienti, assistenza clienti, ticket di assistenza e Customer Relationship Management).

Come per l’hosting Web tradizionale, sarà necessario decidere se creare il livello dei servizi condivisi e provvedere all’hosting dell’applicazione in autonomia o se affidare questi aspetti a un’azienda di hosting esterna, nota come provider SaaS. I provider SaaS offrono un set di servizi condivisi per gestire le problematiche operative e aziendali sopra descritte.

Monitoraggio

Gli SLA sottoscritti con i clienti quantificano gli standard operativi a cui bisogna attenersi. Gli SLA sono contratti legalmente vincolanti e disattenderli può comportare pesanti conseguenze economiche e di immagine. Monitorare costantemente l’architettura dell’applicazione è pertanto vitale per individuare immediatamente eventuali problemi e correggerli prima che si traducano in una interruzione del servizio o nel decadimento delle prestazioni.

Monitoraggio della disponibilità

La disponibilità elevata dovrebbe essere una delle massime priorità di ogni fornitore SaaS. Un guasto di un solo server o di un solo datacenter potrebbe provocare gravi perdite di dati o di produttività per un’ampia percentuale di clienti, se non per tutti. Per gli ISV che si avvicinano al modello SaaS con un bagaglio di esperienze nello sviluppo di software desktop o client-server tradizionale, il requisito della disponibilità elevata imposto da un modello di applicazione basato sulla rete potrebbe sollevare nuove difficoltà. È consigliabile includere nell’applicazione il supporto per tecniche di base, quali il monitoraggio di heartbeat e i meccanismi di avviso, e porre particolare attenzione ai potenziali collegamenti deboli, come una connessione a un database posto in un sito remoto non controllabile direttamente.

Le soluzioni tecniche, come gli avvisi, sono ovviamente solo una parte di un processo più ampio volto ad assicurare la disponibilità elevata. Assicurarsi che il centro operativo sia pronto a mettere in atto i correttivi necessari in caso di guasto del sistema.

Per una panoramica dei problemi correlati alla disponibilità elevata, vedere “Funzioni SMF (Service Management Function): disponibilità” su Microsoft TechNet.

Monitoraggio delle prestazioni

I clienti si aspettano di ricevere un livello di prestazioni accettabile. In certi casi questa aspettativa verrà resa esplicita dagli SLA che ci si impegna a rispettare nel contratto con il cliente. A prescindere dagli SLA, se i clienti trovano che l’applicazione non risponde o è troppo lenta, probabilmente cesseranno le proprie sottoscrizioni o non le rinnoveranno. I clienti contrariati potranno inoltre esprimere il proprio dissenso su siti Web e nelle pagine delle pubblicazioni del settore, contribuendo così a compromettere la reputazione dell’applicazione. Al contrario, un’applicazione veloce e flessibile che soddisfa le esigenze degli utenti verrà apprezzata dai clienti e, nel caso in cui questi abbiano utilizzato in passato un pacchetto software tradizione meno veloce, saranno favorevolmente impressionati dal modello SaaS in generale.

Per assicurare prestazioni elevate, quando possibile includere sempre il supporto dei contatori delle prestazioni direttamente nell’applicazione. Definire soglie di allarme sui contatori delle prestazioni che controllano, ad esempio, l’utilizzo della CPU e il tempo di risposta dell’applicazione e utilizzare gli avvisi per notificare al personale appropriato gli eventuali eventi di gestione.

Stabilire la soglia minima delle prestazioni è solitamente l’operazione più difficile. Dopo aver stabilito la soglia minima, sarà molto più facile rilevare un funzionamento anomalo e individuarne l’origine.

Conclusioni

C’è ancora tanto da scrivere per ognuno degli argomenti trattati in questo documento, ma la panoramica illustrata dovrebbe rendere un’idea dei concetti fondamentali del modello SaaS e dei vantaggi che questo può offrire al fornitore e ai clienti. SaaS rappresenta un nuovo paradigma nella distribuzione del software, un modello di architettura basato sui principi del multi-tenant efficiente, della massima scalabilità e della configurabilità tramite metadati e mirato a diffondere software di buona qualità a costi contenuti per clienti potenziali e preesistenti. L’attuazione di questi principi può facilitare la trasformazione necessaria per l’accesso al mercato delle aziende minori, non raggiungibili con il modello di distribuzione tradizionale.

Per ulteriori informazioni, vedere Architettura dati multi-tenant.