Cos’è Google App Engine?

Google App Engine è il sistema più semplice per collaudare le potenzialità di un servizio PaaS. Difatti è un servizio che permette di ospitare la propria Web Application all’interno dell’infrastruttura cloud di Google.
E tutto sommato è anche una soluzione economica: difatti Google mette a disposizione gratuitamente uno storage di 500 MB e una potenza di calcolo sufficiente ad ospitare una applicazione con un numero di visite di circa 5 milioni al mese. Se questi valori dovessero andar stretti, è possibile utilizzare il servizio di billing per acquistare storage oppure potenza di calcolo.

E’ possibile accedere alla propria app sia tramite un sottodominio di “appspot.com”, sia attraverso un proprio dominio che però deve essere configurato con le Google Apps.

Google mette a disposizione due sandbox collaudate per sviluppare le proprie applicazioni: una in Java e l’altra in Python. Questo sembrerebbe precludere l’utilizzo di Google App Engine agli sviluppatori Ruby e PHP, anche se una possibile soluzione è quella di utilizzare Java per pubblicare un interprete PHP o Ruby e, quindi, riuscire ad utilizzare questi linguaggi.
In realtà questa non può essere la miglior soluzione in quanto è “un passaggio in più” che rende l’esecuzione della propria applicazione meno performante e perciò consiglio vivamente di utilizzare una sandbox supportata direttamente; in qualsiasi caso, se volete provare questa strada, date un’occhiata a Quercus per interpretare il PHP o jRuby per Ruby on Rails.

Nel caso in cui vogliate utilizzare direttamente uno dei due linguaggi, è possibile utilizzare il framework Django scegliendo la sandbox Python (in realtà serve una versione modificata chiamata Django norel per via del datastore non relazionale) oppure Lift scegliendo Java, anche se in questo caso è necessario passare per un interprete Java/Scala un po’ come per PHP o Ruby.

Come vedremo in un successivo articolo, Google mette a disposizione anche un suo framework in Java per creare applicazioni Web 2.0, Google Web Toolkit; questo per dire che per massimizzare l’investimento nello studio degli SDK di Google, forse la scelta di Java è la più indicata.

Esiste infine una terza Sandbox implementata in via sperimentale che consente di programmare in Go. Go è un linguaggio di programmazione semplice, nuovo, estremamente efficiente e nato proprio per lavorare su ambienti cluster e cloud. Anche se poco diffuso sembrerebbe un’ottima scelta per non dover lavorare su linguaggi potenti ma complessi come Java o Python.

Un discorso a parte merita il datastore: per memorizzare i dati da gestire con l’applicazione, Google mette a disposizione un suo sistema moltro simile all’SQL classico, ma con alcune limitazioni per renderlo efficiente su un sistema estremamente distribuito come è il suo cloud. GQL, ad esempio, permette di lavorare con una sola tabella alla volta e non permette in alcun modo le operazioni di join. In pratica tutte le funzionalità “relazionali” sono disabilitate, cosa che lo rende molto simile a NoSQL.

Un motivo per gioire, uno per essere preoccupati

Quest’oggi abbandoniamo i temi legati alla tecnologia che contraddistinguono gli articoli di questo mio blog per analizzare ciò che emerge dalle ultime vicende politiche.

Inutile girarci attorno, tra amministrative e referendum l’attuale maggioranza si è presa una bella batosta. Se pensiamo al referendum, non solo tutti e quattro i quesiti hanno raggiunto il quorum con una percentuale di votanti che si attesta attorno al 57%, ma il voto è andato in tutti i casi per circa il 97% al SI. Ciò vuol dire che la maggioranza assoluta (oltre il 50%) degli Italiani ha votato Si, mentre ricordo che l’attuale legge elettorale prevede che governi il partito di maggiornanza relativa (nelle ultime elezioni il 37,38%).

Da ciò ne consegue una cosa: numeri alla mano risulta evidente che non è più possibile pensare di avere in Italia un sistema “all’americana” con due grandi partiti che si contendono il voto, ma ci dovranno essere almeno due diverse coalizioni che siano in grado di fare sintesi delle loro posizioni (come dice il proverbio la verità sta nel mezzo).

Sinceramente ho sempre avuto un preconcetto riguardo la visione bipartitica che si è voluto dare al sistema politico italiano: la visione della P2 portava a questo e il fatto che chi ha dato il via a questa iniziativa sia stato Veltroni (seguito a ruota da Berlusconi quando è salito sul predellino) mi ha sempre lasciato sconcertato.

Il motivo per cui io gioisco, quindi, è che la P2 ha perso un’altra volta.

Ora veniamo alle dolenti note, queste totalmente apolitiche.

E’ evidente che uno dei motivi che hanno portato prima alla vittoria dei due outsider Pisapia e De Magistris e poi ai 4 si referendari, sia stata una mobilitazione diversa rispetto al passato. Ormai si parla ovunque dell’importanza che ha Internet e del ruolo che possono assumere i social network come Facebook e Twitter per coinvolgere le persone: che si parli della mobilitazione in Medio Oriente, delle elezioni di Obama o dei nostri Referendum, sempre lì si va a cascare.

Una volta si faceva campagna elettorale nelle piazze, poi è arrivato Berlusconi che ha utilizzato la sua egemonia televisiva per “bombardare” di spot il suo vasto pubblico televisivo ridimensionando il potere delle campagne elettorali “di piazza”. Ora, sebbene la TV rivesta ancora un ruolo importante nello spostamento delle opinioni, tutti si rendono conto che ha perso il suo appeal soprattutto tra i giovani che utilizzano Internet come mezzo di informazione primaria.

Questo è il punto: da operatore di settore non posso che essere contento che “il mio media” inizi ad essere importante come “gli altri media”, ma anche preoccupato perchè le avvisaglie di un interessamento della politica per “controllare” Internet ci sono tutte.

Soffermandoci all’Italia mi viene in mente il decreto Romani di cui abbiamo già parlato quando ci siamo soffermati sull’iniziativa di sitononraggiungibilie.it, ma il problema non è certamente solo italiano: lo scorso mese in Francia si è tenuto il G8, anticipato da una riunione dei “grandi” per parlare proprio di Internet, il cositdetto e-G8. A questa riunione i francesi hanno invitato soprattutto rappresentanti di governo e del settore privato, mentre chi ha creato e gestito Internet in questi anni ne è stato escluso. Mi riferisco ad associazioni internazionali come ISOC, ICANN, W3C e  RIPE che hanno da sempre il compito di far funzionare la rete ma che in quella occasione sono state totalemente ignorate.

Questo, a mio avviso, è un’altro segnale che “c’è qualcosa che non va”, dove la politica non vuole “usare i mezzi” ma li vole “controllare”.

Questione di entropia

Come riportato in Wikipedia, l’entropia, in fisica, è una grandezza che viene interpretata come una misura del caos in un sistema fisico o più in generale nell’universo.
Ma a noi cosa interessa?
L’entropia viene utilizzata sui server nella randomizzazione: maggiore è l’entropia disponibile, migliore sarà la qualità dei numeri casulali generati. Un’alta quantità di entropia è necessaria per operazioni che necessitano di elevate quantità di numeri casuali, tra i quali, il caso più comune, è la generazioni di chiavi PGP.
Per sapere quanta entropia abbiamo a disposizione su un server linux, basta lanciare il comando:

cat /proc/sys/kernel/random/entropy_avail

Se il valore è basso (inferiore a 200), è necessario intervenire in quanto probabilmente si utilizza come sorgente /dev/random.
Per risolvere il problema, bisogna installare il demone rng e configurare come sorgente hardware il device /dev/urandom. Su un sistema Linux Debian/Ubuntu lanciare:

sudo apt-get install rng-tools

Quindi editare il file /etc/default/rng-tools aggiungendo la seguente riga:

<strong>/etc/default/rng-tools</strong>
HRNGDEVICE=/dev/urandom

e avviare il demone:

sudo /etc/init.d/rng-tools restart

Ora il valore di entropia disponibile sarà molto più elevato.

Realizzare una piattaforma per ospitare una webapp

Bene, acquistare un servizio PaaS “non LAMP” non vi convince e volete realizzarvi il vostro sistema per ospitare il nuovo Twitter. Intanto in bocca al lupo! Vediamo quali sono gli elementi di una piattaforma destinata ad ospitare servizi “di un certo livello”, in modo che possiate ragionare su quali scelte dovrete affrontare.

1) Infrastruttura IaaS
Il livello più basso è quello relativo al servizio IaaS, cioè l’hardware virtuale che ospiterà la nostra piattaforma sulla quale creeremo l’applicazione. E’ possibile scegliere di utilizzare un fornitore come RackSpace, Amazon, ecc. oppure crearsi il proprio cloud privato/ibrido con sistemi come OpenNebula, OpenStack o Eucalyptus. Riguardo la scalabilità, dal punto di vista hardware tutti i fornitori di servizi IaaS hanno infrastrutture hardware in grado di scalare all’occorrenza, mentre nel caso di cloud privati dobbiamo anche preoccuparci di avere una base hardware adeguata e di monitorarne l’utilizzo per aggiungere nuovo hardware all’occorrenza.
Riguardo a come scalerà il nostro sistema, come dicevo nel precedente articolo, innanzi tutto dobbiamo programmare un sistema che prevede la possibilità di essere scalabile: avere una infrastruttura che ci permette di “accendere una nuova macchina” all’occorrenza, ma che poi rimane ferma perchè noi non abbiamo previsto tecnicamente la sua accensione, serve a poco.
Fatta questa ovvia precisazione, tutti i fornitori di servizi cloud IaaS prevedono la possibilità di interfacciarsi attraverso delle REST API in modo da poter accendere e spegnere le macchine virtuali all’occorrenza. Quindi scegliamo attentamente il sistema di cloud che ci permetterà, in caso, i minori problemi in caso di future migrazioni: le API più diffuse sono quelle di Amazon, ma stanno prendendo piede velocemente le API OCCI.
Se non ci si vuole affidare alla programmazione usando le API, è possibile usare sistemi meno sofisticati per raggiungere il medesimo obiettivo: affidarsi ad un sistema di monitoraggio esterno come Nagios per programmare l’accensione e lo spegnimento di istanze a VM al raggiungimento di determinati livelli di utilizzo.

2) Sistema Operativo
Ovvio, no? Si parte dal basso e in una infrastruttura IaaS bisogna scegliere anche questo elemento 🙂
E’ inutile spendere troppe parole su questo: resta bene inteso che è necessario scegliere Microsoft Windows Server nel caso in cui si voglia programmare in .net 😉
Se invece pensate di utilizzare altri linguaggi, utilizzate la distribuzione Linux che preferite.

3) Linguaggio di programmazione
Python, Rails o Java/Scala, quello che preferite, sono tutti adatti; se volete seguire il trend del momento scegliete Rails.

4) Framework e componenti aggiuntivi
Dipende dal linguaggio, ovviamente: Ruby nel caso di Rails, Django nel caso di Python, Lift in caso di Java/Scala. Se avete scelto Ruby on Rails, ricordatevi di installare su tutti i server che eseguiranno l’applicazione le gemme necessarie.
E’ importante prevedere un sistema di code per eseguire le operazioni più lunghe in background; se utilizzate Ruby on Rails, ci sono delle gemme già pronte allo scopo: resque, BackgroundJob e delayed_job. Se volete un gestore di code non legato a ruby valutate RabbitMQ; se volete un servizio esterno “bello e pronto” e avete deciso di essere ospitati su Amazon, potete utilizzare SQS.

Infine, se avete scelto di ospitare la vostra App su un cloud privato OpenNebula e avete scelto di programmare con Ruby on Rails, non fatevi sfuggire la gemma per utilizzare le OCCI API per comandare il cloud OpenNebula!

5) Frontend Web
Si tratta del “web server” che risponderà alle richieste e le rigirerà ai server ospitanti l’applicazioni in load balancing: nginx è la soluzione più utilizzata, anche se in passato ho avuto ottime esperienze con HAProxy. Infine potete valutare Rack o Mongrel nel caso in cui abbiate scelto Rails.
Se scegliete di usare nginx, una buona idea è di far servire i contenuti statici (ad es. immagini, file .js, file .css ecc) direttamente dal frontend web e di rigirare ai server con l’applicativo solo le richieste dirette verso i contenuti dinamici. In passato ho scritto un articolo su come proxare le richieste di file PHP con nginx, l’articolo può servire come base epr il setup di questo componente.

6) Proxy e database per i dati
In una applicazione “on-the-cloud” è vietatissimo salvare i dati sul disco locale: questi devono obbligatoriamente risedere all’interno di un database. Se così non fosse, si avrebbe un “disallineamento” tra i server che fanno girare l’applicazione, mentre avendo i dati salvati all’interno di un database gli stessi sono condivisi tra tutte le istanze delle VM che faranno girare l’applicazione e pronti per essere disponibili anche alle eventuali VM spente.
Pertanto risulta evidente che i servizi di “disco virtuale” dei servizi IaaS, non servono per contenere i dati, ma per contenere l’applicazione. Unico elemento “borderline” potrebbe essere un servizio di storage a blob come Amazon S3 o OpenStack Swift per memorizzare elementi statici come immagini, file js, ecc.
Inutile dire che i database relazionali più comuni sono PostgreSQL e MySQL e che probabilmente saranno sufficienti alla Vostra applicazione in quanto comunque possono entrambi scalare in lettura, bilanciando quindi il carico di lavoro delle query. Se però abbiamo necessità di scalare in maniera molto più elastica, stanno emergendo nuove basi dati come MongoDB o NoSQL.
Ultima possibilità, Amazon mette a disposizione il servizio Simple DB ed RDS.
Ovviamente l’utilizzo intensivo di un database è estremamente dispendioso per cui è praticamente obbligatorio installare un sistema di cache locale: il sistema più utilizzato è senza dubbio memcached.

Ora che abbiamo descritto cosa vi serve per programmare… happy coding!

Scegliere una piattaforma per ospitare web application

In questo articolo valuteremo alcuni servizi PaaS per ospitare web application.

Questo perchè non tutte le applicazioni sono uguali e, innanzi tutto, bisogna capire cosa dovrà fare l’applicazione per scegliere il linguaggio e il framework di sviluppo più opportuno e quindi, di conseguenza, il servizio PaaS adeguato. Non bisogna essere “talebani” focalizzandosi su un solo sistema per tutta la vita, bensi conoscere e saper valutare le differenze in modo da scegliere di volta in volta quello più adatto alle necessità dell’applicazione.

Premettiamo una cosa: se, come nel 99% dei casi, la nostra applicazione non è altro che un sito web con qualche feature 2.0, con collegamenti a database e vi aspettate che generi un traffico relativamente poco impegnativo, scegliere PHP non è sbagliato. Se invece si tratta di quell’1% dei casi in prevedete che l’applicazione verrà utilizzata intensamente (indendiamoci… voglio dire milioni di contatti giornalieri, non qualche centinaio o qalche migliaio), PHP probabilmente non è la scelta più adatta.

Difatti, se prendiamo in esame l’utilizzo delle risorse hardware, salta subito all’occhio che la maggior parte dei siti web passano il loro tempo “in idle”, cioè non sono costantemente visitati. In una simile situazione, che è la più comune e quindi anche la più semplice da affrontare, l’utilizzo di un linguaggio come PHP su una piattaforma di tipo PaaS tradizionale basata su una installazione LAMP condivisa è una scelta economicamente e tecnicamente poco impegnativa e che permette uno sviluppo dell’applicazione che è tutto sommato abbastanza facile.

LAMP, per chi non lo sapesse, è l’acronimo di Linux Apache MySQL PHP, cioè i quattro componenti che formano questo tipo di servizio PaaS. Risulta evidente che avere solo quattro componenti da gestire rende il sistema estremamente facile (e quindi economico), però impone dei limiti tali per cui in quel restante 1% dei casi si rende necessario un sistema molto più complesso.

Difatti, nel restante 1% dei casi concepiremo la nostra applicazione per non essere usata “spot” ma per essere un qualcosa che una volta lanciato continua ad operare; già da subito capiamo che scegliere una piattaforma LAMP per lo sviluppo non è la scelta migliore in quanto riusciremmo in pochi secondi a prendere possesso di tutte le risorse hardware della macchina facendola “sedere”. Per applicazioni di questo tipo Rails, Python e Java/Scala (e perchè no C++) sono linguaggi molto più adatti perchè permettono di lavorare a più stretto contatto con il sistema… anche se magari sembrano molto più impegnativi .

Inoltre, in una situazione di questo tipo, è importante prevedere che la nostra applicazione sia “scalabile” e che quindi non sia un unico grosso processo che gira su una macchina, ma che sia formata da più processi ed elementi che possono girare indipendentemente su più macchine. Così facendo la nostra applicazione potrà beneficiare delle potenzialità delle piattaforme cloud che permettono di istanziare nuovo hardware virtuale “on demand” permettendo alla nostra applicazione di scalare virtualmente all’infinito senza però dissanguarci per creare una infrastruttura hardware adeguata… oltre ad aggiungere una importantissima tolleranza ai guasti.

Oltre ai servizi PaaS su piattaforma LAMP dei “soliti noti” e di parecchi piccoli ma efficienti ISP, esistono già in commercio alcuni servizi PaaS “non LAMP” che sono in grado di scalare facilmente, anche se non sono proprio a buon mercato. I più conosciuti sono:

Se, invece, volete avere il massimo controllo di ogni componente e crearvi la vostra piattaforma “non LAMP” sopra una infrastruttura IaaS, vedremo in un prossimo articolo quali sono i componenti essenziali che la compongono.