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!
