Architetture di Cloud Computing

Corso di Laurea Magistrale in Ingegneria Informatica Corso di Ingegneria del A. A. 2013-2014 Architetture di Cloud Computing 1 Cloud computing

Sommario Principali requisiti richiesti dal cloud clomputing Strategie e soluzioni architetturali 2

Obiettivo Delineare diverse strategie architetturali che consentono di soddisfare i principali requisiti richiesti dal cloud computing: Scalabilità Disponibilità rilevando la mancanza di soluzioni standardizzate e una molteplicità di alternative; Viene caratterizzato il SaaS delineando dei modelli e sottolineando le proprietà rilevanti che impongono l utilizzo di opportune architetture. 3

Modelli proposti Architettura di cloud storage che sfrutta il paradigma P2P evidenziando un miglioramento della scalabilità e della fault-tolerance, importanti parametri di questa emergente tecnologia. Architetture dati evidenziando quali siano le diverse modalità di gestione dei database in ambito cloud e le relative proprietà. 4

Caratterizzazione del SaaS Il SaaS è un software sviluppato come servizio ospitato a cui si accede tramite Internet. Questa categoria di servizi viene invocata dai consumatori quando ne hanno necessità quindi i consumatori pagano tanto quanto usano i servizi. In un tipico scenario SaaS [55] si possono individuare tre ruoli: 5

Ruoli in uno scenario SaaS Ruoli SaaS customer, che è la persona o l azienda che vuole usare il software per realizzare un certo task e perciò si abbona a un applicazione SaaS. SaaS provider, che vende il software come un servizio e pertanto esegue (ospita) il software per il quale i clienti SaaS possono sottoscrivere l abbonamento. Saas application vendor, che si riferisce alle aziende che sviluppano le applicazioni che sono offerte come un servizio dai SaaS provider. I SaaS provider e i SaaS vendor possono essere le stesse company. 6

Esempio Salesforce offre la sua applicazione CRM come un servizio, agendo quindi sia come SaaS provider che come SaaS vendor. Inoltre Salesforce permette ad altre company di sviluppare applicazioni SaaS ed eseguirle sulla piattaforma Salesforce, agendo così SaaS provider che ospita le applicazioni di vendor terzi di applicazioni SaaS. 7

Modelli di distribuzione I Saas vendor introducono modelli di distribuzione SaaS per il proprio software: Si tratta di modelli in cui il software non è più acquistato ed eseguito dai clienti stessi sulla loro infrastruttura ma è eseguito sull infrastruttura IT (Information Technology) di una hosting company. Ciò comporta un cambiamento importante nel modo di pensare 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 gestito 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. 8

Meta-modello del SaaS Il consumatore invoca questa categoria di servizi attraverso il browser l applicazione invoca i servizi per soddisfare la funzionalità che è offerta dall applicazione software. Componenti costituenti l architettura di, un applicazione SaaS [10] Sono applicazioni sono molto simili alle altre create sui principi della progettazione orientata ai servizi: la differenza di maggior rilievo consiste nell aggiunta dei servizi di metadati, responsabili della gestione della configurazione dell applicazione per i singoli tenant 9

Modifiche consentite alla configurazione Gli utenti possono di norma modificare la configurazione in quattro aree principali: Interfaccia utente - 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 - 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. Controllo degli 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. 10

Configurabilità Per offrire ai clienti la possibilità di configurare il software in base alle proprie esigenze, le precedenti 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. 11

Configurabilità Diversamente dalle applicazioni di 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 possano 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. 12

Requisiti e caratteristiche di qualità di un applicazione Saas Dal punto di vista di un enterprise architect, 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 [10]. 13

Strategie per la Scalabilità Per rendere scalabile un applicazione occorre: aumentare la concorrenza massima utilizzare le risorse applicative in modo più efficiente ad esempio: ricorrendo all assenza di stato condividendo risorse comuni come thread e connessioni di rete memorizzando i dati di riferimento nella cache dividendo i database di grandi dimensioni in più parti. 14

Strategie per il multi-tenancy Il multi-tenancy è la novità più significativa per gli enterprise architect abituati a progettare applicazioni single-tenant isolate. Ad esempio: un utente di un azienda accede alle informazioni relative ai propri clienti utilizzando un servizio CRM, è possibile che l istanza dell 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. 15

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

Problemi con la scalabilità Nel cercare di riusare i servizi SaaS sorgono alcuni problemi tecnici legati alla garanzia di una scalabilità predefinita anche in corrispondenza di picchi o all elevata disponibilità dei servizi. 1. 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 moltiplicata per il numero totale di clienti. 2. Agli Indipendent Software Vendor (ISV), abituati a realizzare software aziendali da eseguire in sede, supportare questo tipo 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à. 17

Problemi con la scalabilità 3. La scalabilità dell applicazione richiede un equilibrata combinazione dei due distinti domini del software e dell hardware. Si possono fare grandi progressi e aumentare la scalabilità in uno di questi domini per poi vanificarli a causa degli errori commessi nell altro. Ad esempio, la creazione di una webfarm di server con bilanciamento del carico non fornirà alcun beneficio per un applicazione progettata per essere eseguita su un singolo computer; analogamente, progettare un applicazione a elevata scalabilità e distribuirla su computer connessi a una rete a bassa larghezza di banda non consentirà di gestire carichi elevati in modo efficiente quando l ingente traffico determina una saturazione della rete. 18

Disponibilità La disponibilità [56] elevata dovrebbe costituire 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 come i meccanismi di avviso, e porre attenzione ai potenziali collegamenti deboli, come una connessione a un database posto in un sito remoto non controllabile direttamente 19

Autenticazione e autorizzazione Insieme a questi rilevanti aspetti, anche altri requisiti vanno considerati in ambito SaaS come l autenticazione e l autorizzazione [10]: 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. Queste proprietà richieste dalle applicazioni SaaS necessitano dell adozione di appropriate architetture, nel seguito descritte, che permettano di affrontare tali problematiche. 20

Corso di Laurea Magistrale in Ingegneria Informatica Corso di Ingegneria del A. A. 2013-2014 Soluzioni architetturali per sicurezza disponibilità e scalabilità 21

Strategie architetturali per garantire della protezione dei servizi Di seguito vengono proposte delle strategie architetturali [10] che affrontano il problema della protezione dei servizi in ambito SaaS, specificando delle soluzioni relative alle problematiche di autenticazione e autorizzazione: 1. Sistema di autenticazione centralizzato 2. Sistema di autenticazione decentralizzato 3. Gestione degli accessi 22

Amministrazione delegata Mediante un processo definito amministrazione delegata [10] il provider SaaS affida ai tenant la responsabilità di creare e gestire i propri account utente: 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 [10]: sistema di autenticazione centralizzato 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. 23

Sistema di autenticazione centralizzato 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. 24

Architettura centralizzata Questo approccio richiede un infrastruttura di autenticazione relativamente semplice che può essere progettata e implementata con una certa facilità senza 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 la richiesta di credenziali che dovrà essere compilata manualmente 25

Sistema di autenticazione decentralizzato In un sistema di autenticazione decentralizzato: il tenant distribuisce un servizio federativo [65] 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 26

Architettura decentralizzata È un approccio ideale quando è importante utilizzare il Single Sign-On: non impone all utente l immissione di un set di credenziali specifico per ogni servizio SaaS cui accedere, sfruttando l autenticazione locale. Questo approccio è tuttavia molto più complesso di quello centralizzato 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 tra le due tecniche precedenti, ricorrendo 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. 27

Gestione degli accessi L accesso alle risorse e alle funzioni aziendali delle applicazioni SaaS viene gestito tramite dei ruoli [10] mappati sulle specifiche funzioni professionali definite all interno di un organizzazione ad ogni ruolo vengono assegnate una o più autorizzazioni che consentono agli utenti di quel ruolo di svolgere delle azioni in conformità con le regole di business applicabili. 28

Gestione degli accessi I ruoli vengono gestiti all interno dell applicazione SaaS stessa e possono contenere account utente individuali o gruppi di utenti (sia agli account utente individuali che ai gruppi è possibile assegnare più ruoli in base alle necessità 29

Ruoli e autorizzazioni 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 sulle importanti funzioni aziendali o sulla gestione dell applicazione stessa. Un applicazione per gli acquisti potrebbe, ad esempio, includere delle autorizzazioni per la creazione, l invio, l approvazione e il rifiuto di ordini di acquisto; un applicazione per agenti ipotecari potrebbe invece includere delle autorizzazioni per il controllo del credito di un cliente, per 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. 30

Regole di business e controllo degli accessi 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. E possibile, ad esempio, 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 degli 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à. 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. 31

Strategie per la disponibilità La disponibilità [56] è uno dei principali requisiti richiesti da un sistema cloud-based legato alla capacità di un servizio SaaS di fornire le sue funzionalità in maniera persistente, consentendo ai suoi consumatori di accedervi in ogni momento e ovunque. Diversamente dal software tradizionale, un servizio SaaS viene eseguito nell infrastruttura del provider, e i consumatori del servizio vi accedono attraverso Internet: in questo modo i consumatori del servizio non possono accedervi ogni volta che questo non è disponibile a causa di qualche evento come un network failure, un service middleware failure, o per altre problematiche che coinvolgono i vari componenti della piattaforma dei servizi. 32

Problemi di disponibilità In tali casi, i consumatori del servizio non possono in alcun modo rimediare al problema; l implicazione di tale problematica sui consumatori è pertanto molto rilevante e costituisce un aspetto critico da considerare. Un altra circostanza in cui la disponibilità viene meno (oltre ai possibili failure precedentemente indicati) si verifica quando i consumatori del servizio non possono essere online ma vogliono accedere al servizio che, ovviamente, non è disponibile nell intervallo di tempo in cui si è off-line. Per fornire una totale disponibilità dei servizi SaaS, occorre quindi escogitare una modalità alternativa per l utilizzo dei servizi stessi: in particolare, si possono individuare delle soluzioni sia dalla parte dei fornitori che dalla parte dei consumatori dei servizi. 33

Autonomic computing Le soluzioni dalla parte del fornitore sono principalmente legate alle possibilità di gestire in modo autonomo i potenziali fault: poiché i servizi da eseguire in modo continuativo non possono sempre essere gestiti dagli amministratori umani, può essere applicato il principio dell autonomic computing [66] nel contesto di un sistema cloud, così come di seguito schematizzato con un architettura [56] che permette di gestire il problema della disponibilità. 34

Architettura per garantire la disponibilità 35

Architettura per la disponibilità: Availability manager Il Fault Identifier monitora lo stato delle risorse gestite nel cloud e identifica gli eventuali fault confrontando lo stato monitorato con la descrizione del normale funzionamento. Il Cause Detector determina la causa più plausibile del fault consultando una base di conoscenza e dei log storici. L Actuator Determiner seleziona l attuatore (Actuator) più appropriato per rimediare ai fault le cui cause sono note. Le soluzioni applicabili dalla parte del consumatore dipendono in gran parte dal grado di adattabilità offerto dai fornitori del servizio in quanto i fornitori possono progettare e ingegnerizzare i tipi dei potenziali fault nei servizi; di seguito sono esaminate due efficaci soluzioni [56] relative all utilizzo di un Proxy e al download di una versione leggera dei servizi. 36

Architettura per la disponibilità: accesso Proxy-based Un Proxy può essere utilizzato per consentire ai consumatori di accedere ad un servizio SaaS in modo trasparente allo scopo di superare i problemi che potrebbero presentarsi quando questi accedono a tale servizio con lo spazio degli indirizzi fisici. Un accesso proxy-based fornisce un accesso trasparente al servizio SaaS disaccoppiando i consumatori del servizio dalla parte del fornitore del servizio: quando un nodo cloud per un certo servizio non è disponibile, uno smart proxy dalla parte del consumatore può notare il failure e accedere ad un altra istanza di tale servizio sullo stesso nodo (criterio di ridondanza). 37

Soluzioni per ottenere disponibilità del servizio Effettuare il download di una versione leggera dei servizi SaaS costituisce un altra soluzione per migliorare la disponibilità nel caso in cui i consumatori del servizio non possano utilizzare Internet: una semplice modalità è quella di installare i servizi SaaS dalla parte del consumatore anche se ciò sarebbe in contraddizione con le caratteristiche intrinseche del cloud computing. In questo caso sarebbe opportuno considerare la sincronizzazione tra l informazione offline e online legata alla sessione e i set dei dati: questa soluzione è applicabile concretamente solo se è disponibile una versione leggera dei servizi. 38

Strategie per la scalabilità La scalabilità [56] rappresenta la capacità di aumentare le risorse per ottenere un incremento (idealmente) lineare nelle performance del servizio La caratteristica principale di un applicazione scalabile è costituita dal fatto che un carico aggiuntivo richiede solamente risorse aggiuntive e non un estesa modifica dell applicazione stessa. Relativamente ai servizi SaaS, non è semplice garantire una scalabilità soddisfacente in quanto è difficile valutare il numero dei consumatori di un applicazione SaaS non essendo tale valore prefissato. Senza sapere questo numero, preparare le risorse necessarie per fornire i servizi SaaS diventa problematico. Essere scalabile quando un numero estremamente grande di consumatori prova a utilizzare gli stessi servizi SaaS è, quindi, un problema complesso: in effetti, non è semplice per i fornitori dei servizi garantire un livello predeterminato di scalabilità con una limitata quantità di risorse, considerando la dinamicità che caratterizza le richieste. 39

Determinazione della quantità di risorse Dal punto di vista dei consumatori, si ha un certo dinamismo caratterizzato dall aspetto dell on-demand mentre Dal punto di vista del provider, occorre determinare un quantitativo di risorse pre-fissato o comunque limitato. Di conseguenza, individuare la giusta quantità delle risorse nel contesto dei servizi SaaS diventa un aspetto critico da considerare, per cui occorre determinare delle opportune strategie. 40

Richiesta di servizio e allocazione Relazione tra la richiesta dinamica dei consumatori di un servizio e l entità delle allocazioni effettuate dal fornitore del servizio, indicando il range di scalabilità accettabile. L asse delle ascisse rappresenta il livello delle richieste fatte dai consumatori e l asse delle ordinate indica l entità delle allocazioni effettuate dal fornitore. 41

Tecniche di gestione della relazione tra richiesta di servizio e allocazione In [56] vengono proposte 3 tecniche che vanno integrate fra loro per affrontare tale problematica: 1. Resource Pooling with Multi-Clouds 2. Dynamic Load Balancing and Migration 3. On-demand Deployment 42

Resource Pooling with Multi-Clouds Resource Pooling with Multi-Clouds: questa tecnica prevede di creare e mantenere multiple istanze degli stessi servizi in un pool, migliorando la disponibilità e il throughput complessivo che contribuiscono alla scalabilità. Inoltre, considerando un cloud costituito da molti servizi, si può realizzare una configurazione multi-cloud formata da una griglia di molteplici nodi cloud. Quando un singolo cloud ha raggiunto il limite sulle risorse e sul numero di istanze che può utilizzare, i suoi cloud vicini possono condividere il carico: questa tecnica di pooling assicura un grado di scalabilità predefinito per la maggior parte dei casi con un alto livello di domanda. 43

On-demand Deployment On-demand Deployment: tale tecnica si deve occupare di gestire le risorse e le componenti software a livello di sistema dalla parte del fornitore dei servizi. Nell ambito del cloud computing, si possono individuare diverse componenti e risorse che sono necessarie per effettuare il deploy dei servizi e per eseguirli: Esempio: l ESB (Enterprise Service Bus) [67] che è un infrastruttura software che fornisce supporto ad architetture SOA complesse. Se una di tali componenti viene meno o rivela un basso livello di QoS, le applicazioni SaaS non funzionerebbero normalmente e, di conseguenza, la loro scalabilità verrebbe coinvolta. In definitiva, il ruolo dell On-Demand Deployment è quello di monitorare gli elementi correlati all applicazione SaaS allo scopo di determinare quelli non funzionanti e di rendere applicabile il deployment degli elementi coinvolti. 44

Dynamic Load Balancing and Migration Dynamic Load Balancing and Migration: questa tecnica prevede di condividere il carico sui servizi SaaS e di migrare gli attuali carichi su un altra istanza delle applicazioni SaaS o su un nodo cloud vicino; per utilizzare tale tecnica, occorre progettare e installare un System-level Scheduler e un Load Dispatcher: Quando i servizi sono invocati, il System-level Scheduler definisce un piano dettagliato per eseguire l applicazione SaaS richiesta che specifica quale istanza viene utilizzata per eseguire il servizio e quali risorse nel pool sono allocate per l invocazione. Il Load Dispatcher ha il compito di identificare le istanze dei servizi con bassi valori di QoS (Quality of Service), allo scopo di determinare una nuova istanza del servizio e di migrare il carico attuale dell invocazione sulla nuova istanza a runtime. 45

Architettura per gestire la scalabilità Sull ESB al centro dell architettura, più cloud sono connessi in una griglia e ogni cloud mantiene un pool di istanze dei servizi Al di sopra dell ESB, il componente Scalability Manager, che implementa le 3 tecniche prima descritte: monitora le invocazioni dei servizi gestisce le applicazioni SaaS e gli elementi correlati per supportare la scalabilità. In definitiva, questa architettura è basata sul principio che se i servizi e le risorse sono duplicati sui cloud e se tutte le istanze disponibili sono utilizzate dai consumatori, il deploy delle altre istanze può essere realizzato on-demand in modo che le risorse siano scalate in modo flessibile. 46

47