Cloud Computing : Scalability- True or False

Nonostante la definizione in bozza del NIST, National Institute of Standards and Technology si continua a parlare di Cloud Computing come se fosse la tecnologia capace di fare tutto.

Una di queste feature tanto nominata è la presunta scalabilità innata della tecnologia, pertanto partiamo innanzitutto da una corretta comprensione della scalabilità:

Possiamo definirla come la capacità di un sistema di crescere in base al numero di richieste esterne al sistema stesso. Generalmente si intende la crescita in orizzontale, cioè su “commodity hardware”, che si riassume aggiungendo server economici per aumentare la potenza del sistema e naturalmente bilanciarne il carico. Effettivamente sembra calzare con il Cloud Computing che per definizione sarebbe una infrastruttura scalabile semplicemente, basata su “commodity hardware” e capace di erogare potenza su richiesta all’utente finale. Molti dei solution architects si ricorderanno benissimo le complessità affrontate nel riuscire a far scalare le applicazioni dei clienti, ed inoltre consideriamo che la maggior parte dei più grossi portali e social network hanno sviluppato proprie logiche per scalare, logiche nate dalla tipologia della applicazione.

Quando nel 2007 ci imbattemmo nei servizi di Amazon AWS, fu leggendo il sito per eccellenza dedicato alla scalabilità highscalability.com dove era pubblicato un articolo che ipotizzava l’uso dei webservices di Amazon per lo sviluppo dei social network, allora non era ancora stato coniato il termine Cloud Computing. Come ormai noto il Cloud Computing, si basa sulla virtualizzazione dei server , dei servizi di storage e di network, pertanto fino a non molto tempo fa i più esperti giudicavano male l’uso della virtualizzazione in quanto le singole macchine virtuali non potevano avere le stesse prestazioni di una eguale configurazione senza strato hypervisor, ancora oggi se ne possono trovare di architetti contrari. Non è sbagliata come obiezione, ma il ragionamento che porta a preferire il Cloud all’approccio generico è l’enorme risparmio economico e la semplicità e velocità di approvvigionamento delle risorse, rispetto la messa in opera di nuovo hardware che comporta anche personale qualificato per le configurazioni. Se poi pensiamo che Amazon, il più grosso e-commerce al mondo funziona con una infrastruttura eguale ai servizi AWS che eroga ai clienti, ci fa riflettere anche sulle prestazioni di una corretta implementazione in Cloud. Amazon ha maturato nel tempo e sviluppato in house quelle che sono le elastiche logiche del Cloud che vende ai clienti di AWS, come è possibile vedere in questo video dove Jeff Bezos, fondatore di Amazon.com descrive Amazon Web Services che è un prodotto nato dai laboratori di Amazon per gestire la loro infrastruttura:

Come noto il Cloud Computing può erogare servizi in tre modalità :

  1. SaaS
  2. PaaS
  3. IaaS

piramidmodel

Nel primo caso Saas (Software as a Service) c’è una applicazione già sviluppata e quindi già pensata per scalare nella infrastruttura sottostante. In questo caso non è detto che sotto ci sia una Cloud; è per esempio il caso di gmail, google documents, SalesForce.

Nel secondo caso PaaS (Platform as a service) c’è una piattaforma capace di ospitare applicazioni fatte da altri, ma queste applicazioni devono soddisfare i ristretti requisiti richiesti; è questo il caso ad esempio di google app engine che consente di pubblicare applicazioni in java e non preoccuparsi se il traffico su queste applicazioni cresce a dismisura. Anche in questo caso non è sempre vero che il substrato sia una Cloud.

L’ultimo è l’ IaaS (Infrastructure as a services), che rappresenta una serie di interfacce software (API , webservices) usabili mediante autenticazione, con le quali è possibile programmare le risorse computazionali che ci occorrono per far andare la nostra applicazione. Pertanto questo livello non è scalabile naturalmente, ma dovremmo noi essere capaci di programmarlo per scalare la nostra applicazione; l’esempio più chiaro è più noto di IaaS è AWS (Amazon WebServices).

Soluzioni

Molte realtà stanno nascendo e stanno cercando di affermarsi nel mercato della scalabilità in Cloud. Tutte queste realtà sono software sviluppati sullo strato più basso, software capaci più o meno di rispondere agli eventi di sovraccarico bilanciandone il carico su nuove risorse richieste al sistema automaticamente. La maggior parte di questi software si posizionano tra il PaaS e l’ IaaS perchè devono consentire un minimo di programmabilità/configurazione all’utilizzatore che non può essere pertanto uno digiuno della materia; uno dei casi più rappresentativi è RightScale, che però oltre ad essere complesso è anche costoso.

RightScale crea uno strato più semplice della programmazione bruta dei comandi API di AWS, mediante vari casi già sviluppati ci si può far guidare nella creazione della nostra infrastruttura virtuale in Cloud, scalabile secondo le logiche che noi andremo a definire.

E’ di oggi l’uscita in beta della (da noi tanto attesa, in quanto c’era stata anticipata) soluzione di scalabilità propria di AWS. Amazon lancia in beta oggi i seguenti webservices:

  • CloudWatch
  • ElasticLoadBalacing
  • AutoScaling

Questi tre servizi che, come noto si utilizzano mediante scripting, consentono di monitorare le AMI (amazon machine image), di programmare un load balancer per la nostra applicazione e definire dei gruppi e dei trigger per far intervenire in automatico nuove risorse a sostenere le richieste di performance della nostra applicazione.

L’offerta sembra ottima, solo il CloudWatch ci sembra eccessivo in costi, monitorare 10 AMI costerebbe più del costo di una AMI sulla quale noi possiamo installare un sistema di monitoring che ne puo’ monitorare molte di più.

Tornando al problema della scalabilità, esistono quindi soluzioni in Cloud per garantirci uno sviluppo senza preoccupazioni, ma, solo dei buoni architetti possono sollevare le giuste eccezioni, come scaliamo un database?

DB Scalability

Ed è qui che possiamo dire che il Cloud Computing non consente naturalmente di scalare ma occorre adottare una complessa serie di accorgimenti che devono essere valutati caso per caso. Ormai è noto ai più esperti che scalare un database relazionale di un social network, cioè con un bilanciamento R/W circa al 50% non è cosa semplice e prevede tutta una serie di approcci di distribuzione delle richieste dividendo il database in tanti pezzi (sharding), modifiche alla applicazione ed inserimenti di inMemoryDatabase (es . memcached) per conservare memoria della posizione dei pezzi.

I piu’ smaliziati potrebbero dire che si potrebbe passare alla moderne soluzioni di inMemoryDataGrid, cioè una sorta di Cloud di risorse RAM sulle quali spalmiamo il nostro database. Beh sicuramente le prestazioni ne risulterebbero molto premiate, ma il costo di una risorsa RAM rispetto la risorsa HD è superiore dello stesso ordine di grandezza di quanto più performante è la RAM Vs HD, inoltre oltre ad essere antieconomico è anche sovrabbondante in quanto non tutti i dati della nostra applicazione è necessario tenere sempre online, perchè magari non richiesti da nessuno.

Altra moda molto commerciale, ma poco funzionale è la Cloud privata capace di scalare nella Cloud Pubblica (Hybrid Cloud). Innazittuto siamo ancora senza uno standard, pertanto dovrebbe essere sviluppata ad hoc per ogni cliente, secondo torniamo al problema precedente, se la nostra esigenza è la scalabilità del database, come lo scaliamo dalla Privata alla Pubblica? Considerando che generalmente la banda utile ad unire un CED privato con un datacenter dove risiede una Cloud è dell’ordine delle decine di Mbits in download e meno ancora in upload. Occorrerebbe attivare delle repliche che potrebbero facilmente disincronizzarsi.

Reali esigenze del cliente

Il cliente generalmente richiede semplicità, richiede di passare alla Cloud senza alcun impatto per il suo normale sviluppo, senza sconvolgere l’applicazione, senza abbandonare le logiche relazionali del suo database, perchè costituirebbero costi grossi, addirittura sostituzioni del personale in quanto non qualificato o non adatto a riscrivere l’applicazione per crescere in Cloud.

VMEngine sta rilasciando la sua prima release basata su un semplice approccio alla scalabilità, all’auto-scaling di tutta l’applicazione anche database server, ed intanto fa ricerca per rendere sempre più automatizzata la scalabilità e sempre più trasparente al cliente che puo’ tornare a sviluppare senza dover sconvolgere il know-how dei propri sviluppatori

Be Sociable, Share!

Related Articles

Leave a reply

Your email address will not be published. Required fields are marked *