GAE, approfondimento su Google App Engine

Dopo averne paralato qui, e dopo aver approfondito lo studio di Google App Engine voglio condividere con voi le mie esperienze.
GAE è stato studiato come il metodo da seguire per creare applicazioni web (HTTP- driven) da ospitare sui web server di Google. A differenza di EC2, e GoGrid, GAE scende nel campo delle piattaforme cloud fornendo un framework di tecnologie rigide, con le quali creare applicazioni senza preoccuparsi della loro architettura e dei picchi di traffico e carico. Il software è realmente open source, infatti nelle pagine dedicate alla cloud di Google si trova tutto, ivi compresi i listati dei sorgenti (Python). La prima caratteristica della rete che si riscontra è la mancata scalabilità hardware della rete stessa. Per ogni account, infatti, il Google App Engine associa solo una CPU (intel con clock pari a 1.2 GHz con architettura X86 32-bit). Nonostante questa grossa limitazione che rende la rete abbastanza rigida, le sue caratteristiche sono tutte monitorate, come: il carico della CPU, la banda trasmissiva impiegata, le risorse realmente impiegate per ogni singola applicazione. Un dettagliato pannello di controllo, infatti, riporta un lungo elenco di voci che indicano i consumi effettivi (in continuo aggiornamento).
Un’ulteriore caratteristica che discosta GAE dalle comuni reti cloud è la completa mancanza di virtualizzazione di sistemi operativi di ogni tipo; esso, infatti, permette la sola esecuzione di codice Python, eventualmente associato ad un framework proprietario o ad una versione alleggerita di Django. Per usufruire della rete GAE e, quindi, iniziare a sviluppare le applicazioni, è necessario scaricare l’ambiente di sviluppo, che ricreerà le stesse condizioni tecniche di GAE sulla propria macchina locale; l’SDK contiene, infatti, un web server, un database, le strutture per recuperare indirizzi HTTP(s), quelle per l’invio di email e per la manipolazione d’immagini.

Per poter controllare il consumo effettivo di risorse, GAE mette a disposizione tutta una serie di servizi che le applicazioni possono sfruttare:

Il Datastore: database un po’ particolare denominato BigTable, formato da una piattaforma distribuita operante sul file system proprietario, GFS.
Google Accounts: è una API che permette di avere automaticamente un sistema di login per le applicazioni, basato sugli accounts Google
URL Fetch: le applicazioni possono accedere all’esterno, recuperando il contenuto di URLs remoti sfruttando API basate sulla stessa infrastruttura che Google usa per altri suoi prodotti
Mail: usata per inviare email con o senza allegati anche verso l’”admins” delle applicazioni.
Memcache: è uno storage di tipo “in-memory key-value”. Permette di inserire in cache strutture, valori, risultati di query complesse e rendere, quindi, il recupero degli stessi più veloce.
Image Manipulation: permette di ridimensionare, ruotare ed effettuare operazioni basilari su immagini in formato JPEG e PNG.
Sandbox: è un ambiente sicuro, affidabile, indipendente dall’hardware, dal sistema operativo e dalla ubicazione fisica del sistema di servizio di web in cui vengono conservate le richieste di rete dei vari utenti. Questo metodo garantisce accessi sicuri, contemporanei e multipli alla rete GAE

Ogni operazione (richiesta) sottoposta all’GAE, sia in entrata che in uscita, consuma un certo livello di risorse addizionali che vengono addebitate sul proprio account.
L’idea fondo è all’incirca la stessa dei cellulari prepagati. Esistono due tipi di “abbonamento” o profilo quello “Free” (o gratis) e quello “Billing” (o a pagamento). Il profilo gratis è associato per default ad ogni account.
Se le risorse consumate dall’utente sono inferiori a quelle previste per il profilo free l’utente non paga nulla, altrimenti, se supera il limite, va in “burst” e cambia automaticamente profilo e passa a quello billing. Chiaramente esiste un metodo per controllare la tariffazione delle risorse addizionali ed è accessibile anche all’utente: Google Checkout.

Conclusioni

Un sistema rigido come la Rete GAE comporta anche diversi limiti. Non si tratta, infatti, di un prodotto completamente nuovo: la piattaforma, infatti, è la stessa alla base di molti attuali servizi di casa Google, come Google Earth, Google Sites, o Google Finance e al suo interno integra una serie di applicazioni e funzionalità che Google utilizza già da tempo in tutto il mondo.
Google ha comunque espresso la volontà di migliorare le potenzialità del proprio servizio cloud. Attualmente Google è in continua ricerca di soci validi per il progetto cloud, aziende del settore interessate (si è appena associata ad Salesforce), o singoli utenti e/o sviluppatori disposti a testare ed eventualmente migliorare i servizi forniti dalla rete. Il sistema GAE è ancora in fase di studio ed è offerto a tutti nella versione previous release che permette ai team tecnici un continuo testing real-time del prodotto e quindi l’individuazione delle carenze dell’architettura stessa.

href="http://www.cloud-solution.it/gae-approfondimento-su-google-app-engine/">

Go Runtime Environment, il linguaggio di programmazione Cloud

Go è un linguaggio di programmazione nato da un progetto open source per rendere più produttivi i programmatori della nuvola.

Go è espressivo, conciso, pulito ed efficiente. I suoi meccanismi di concorrenza permettono di scrivere programmi facilmente e attraverso il meccanisco multicore lo rende particolarmente adatto al Cloud.  Anche Google ha capito la potenza di questo nuovo linguaggio e lo ha subito incluso nella lista dei runtime supportati dalle App Engine.

A questo indirizzo trovate le specifiche Google App Engine (GAE).

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.