Newsgroup: it.comp.os.dibattiti
Titolo: Java on GAE

Per chi è interessato, è stato rilasciato il supporto Java per Google
App Engine.
Sono supportate la 1.5 e la 1.6
http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html
E' già disponibile un esempio di utilizzo di Groovy su GAE, sebbene
Grails ancora non sia supportato:
http://blog.springsource.com/2009/04/07/write-your-google-app-engine-applications-in-groovy/
Questo significa ovviamente che potenzialmente è possibile usare altri
linguaggi per la JVM, come JRuby o Scala, e non ho ancora verificato
se qualcuno ha già provato ad usarli.
Groovy è supportato "by design", Guillaume Laforge ha collaborato
attivamente con Google per questo, gli altri non so ma è ipotizzabile
che il passo non sia troppo lungo.
Raffaele

 App Engine.
Io lancio un link e poi lascio Raffaele a scannarsi con ngw, rik0 e 
Dialtone.
http://highscalability.com/some-point-cost-servers-outweighs-cost-
programmers
http://unlimitednovelty.com/2009/04/twitter-blaming-ruby-for-their-
mistakes.html
http://www.theregister.co.uk/2009/04/01/twitter_on_scala/
Specialmente il secondo link e tutti i commenti sono interessanti.
Alè, sbranatevi :)
-- 
Vide

 Grails ancora non sia supportato:
http://blog.springsource.com/2009/04/07/write-your-google-app-engine-.
..
apropos JRuby on GAE:
http://olabini.com/blog/2009/04/java-on-google-app-engine/
reference per iniziare ad usare java on GAE:
http://code.google.com/appengine/docs/java/gettingstarted/introduction.html
Raffaele

 se qualcuno ha già provato ad usarli.
In realta` significa poco. In GAE Java ha i thread disabilitati il che
va a cancellare i vantaggi dei linguaggi piu` interessanti che girano
sulla JVM. Se volessi usare Ruby lo fare su EngineYard piuttosto che su
GAE.
-- 
Valentino Volonghi aka Dialtone
http://stacktrace.it
 -- Aperiodico di resistenza informatica
Blog: 
http://www.twisted.it/
Public Beta: 
http://www.adroll.com/

 Alè, sbranatevi :)
Ma non c'e` da sbranarsi. Twitter e` giu` ogni poche ore anche adesso. 2
giorni fa e` rimasto giu` per un bel pezzo. Alex Payne ha un libro da
vendere su scala e lo pubblicizza come se fosse la soluzione ai loro
problemi. Ci sono cose che in ruby, python e compagnia sono difficili da
fare e servono linguaggi dedicati come erlang e scala, ma a prescindere
devi avere sviluppatori che usano bene lo strumento che hanno, Twitter
non lo usava bene visto che faceva check di tipo in continuo, come
ammesso dallo stesso Payne, che e` venuto fuori con il quote che ritengo
piu` spiritoso di sempre "in big projects you end up developing your own
type system" che e` una bella cazzata e da l'idea di quanto poco siano
disciplinati gli sviluppatori di Twitter. E` solo che lui e i suoi
colleghi sono piu` attenti alle mode del linguaggio da usare piuttosto
che effettivamente a fare qualcosa che funzioni bene con quel
linguaggio. Poi tanto di cappello per Twitter ma se esistono ancora e`
solo perche` la concorrenza non ha mai saputo fare nulla che anche solo
si avvicinasse dal punto di vista dell'ubiquita`.


 GAE.
Mica ho detto che sia vantaggioso: questo solo il tempo e le prove su
strada potranno dimostrarlo.
Potersi fare si può fare, però, e si vedrà. Per JRuby c'è già l'"how
to".
Raffaele

 to".
Si pongono tutti i problemi che ci sono ora con Python. L'API e` la
stessa e i problemi pure. Non si sa nulla di come Google distribuisce le
istanze e di come BigTable sia sincronizzato (se e` sincronizzato) tra
diversi data center (se usi diversi data center).
E` ottimo per fare applicazioni in partenza ma devi avere un'exit
strategy prima ancora di iniziare, intanto perche` le quote usabili
anche a pagamento sono piuttosto basse.
E` molto piu` utile a google per far integrare terze parti con i suoi
servizi, o con i servizi che offrira` in futuro, avendo sotto controllo
le caratteristiche di performance e availability dei prodotti di queste
terze parti, e in teoria qua parlo perche` so ma non posso dire, ma
tanto il 20 Aprile sapra` piu` o meno tutto il mondo penso.


 tanto il 20 Aprile sapra` piu` o meno tutto il mondo penso.
Odio le cose dette ma non dette! :O
Attendo fiducioso, intanto se trovo il tempo dò un'occhiata a
JavaOnGAE
Raffaele

 wrote:

E perche' mai ? Per un giorno Twitter ha restituito 500 a manetta, si
e' perso meta' thumbnail ed e' andato giu' per 40 minuti.
Gli sviluppatori ammettono candidamente di essersi creati un type
system, forse ignari che Ruby ne ha uno, e di usare kind_of? a pie'
sospinto.
Un tizio con un libro in Scala in arrivo si mette a pompare Scala in
ogni dove, per poi postare sul suo blog cose tipo "siamo tutti
fratelli" mentre altrove dice che Ruby serve a fare siti "in cui la
gente deve solo cliccare in giro".
Si scrivono una message queue in Ruby che fa cagare, con l'autore che
dice che era "buona abbastanza" per quei tempi (ma che di fatto non
stava in piedi).
Il tutto, mentre altri siti non rompono nemmeno tanto i coglioni e non
sono giu' ogni 10 giorni per "unscheduled maintenance" (
http://tr.im/
isxO).
Il problema qui, e' che non si capisce se Twitter non scala per colpa
di Ruby, o Ruby non scala per colpa di Twitter. A me pare la seconda,
ma magari mi sbaglio.
Per la cronaca, io ho cassato RoR per un bel pezzo di backend, per
sostituirlo in parte con Sinatra e in parte (in futuro) con Erlang.
Mica mi metto a dire che Ruby e' una merda - in parte perche' continua
a tenermi in piedi l'ambaradan che per la cronaca e' sviluppato da me
e da 1 ventunenne lato backend, in parte perche' tanto chi se lo
prende piu' il mio libro. Per certe cose e' meglio usare altro.
Sta gente che a cadenza semestrale "vede la luce" mi fa sorridere (e
Scala, francamente, ha bisogno di tanto buzz, visto che tra Haskell ed
Erlang, relative tecnologie e relative pubblicazioni (come il nuovo
Real World Haskell), sia per il libercolo di @al3x (perche' anch'io
sono fanatico di Twitter) che per la tecnologia stessa la vedo tanto
tanto dura [1])
  ngw
[1] Dico, sono sicuro che un linguaggio funzionale che fino ad 1 mese
fa non aveva la tail recursion perche' la stupenda JVM non la supporta
(a differenza del CLR Microsoft) sia assolutamente *aaaaaaawesome*
come direbbero loro, ma continuo a preferire Erlang e Haskell.

 Specialmente il secondo link e tutti i commenti sono interessanti.
Una cosa che ho scoperto ieri sera al BayFP poi...
Twitter ha un ingress rate di messaggi di circa 100 al secondo, si non
scherzo.
Hanno quindi 140 caratteri a messaggio per 4 byte a carattere (unicode)
520 byte per ogni messaggio, facciamo che per overhead degli header e
via dicendo diventano anche 700 byte a messaggio, a 100 al secondo
abbiamo 70KB di ingress bandwidth.
Ora moltiplicare 70KB per il numero medio di follower e` poco
interessante, piu` interessante e` vedere l'impatto del caso pessimo:
prendiamo l'account piu` grosso che hanno, britney spears che ha 750.000
circa followers.
700 byte * 750.000 = 525MB/sec 
perche` ogni messaggio viene duplicato a ognuno dei follower altrimenti
ci sarebbero altri problemi, questo e` comunque fatto nel modo piu`
stupido possibile.
Al di la` del fatto che una 10GBit maneggia quel traffico come nulla, un
sistema di messaging come RabbitMQ configurato in cascata:
        -  RMQ
        /  RMQ
  RMQ   -  RMQ
        \  RMQ
        -  RMQ
Significa che l'overhead sul primo RMQ e` di 5 messaggi. E ciascuno
degli altri RMQ ha overhead di 1/5 dei 525MB precedenti e quindi
perfettamente gestibile da una normale gigabit.
A questo punto resta la scelta di come fare replicazione e dove mettere
i messaggi. Io direi che 525MB/sec di ingress messi nel database sono il
loro vero problema e non il linguaggio scelto.
Hanno architettato un sistema di messaging come se fosse un sistema
basato su un database, questo e` evidente perche` quando segui qualcuno
ti compaiono anche tutti i suoi messaggi passati. Questo e` il loro vero
fallimento e la tecnologia che usano non li aiutera` a far scalare il
database.
Dovrebbero smettere di usare un database per passare all'uso di un
servizio basato su un layer di messaging come quello che ho mostrato
sopra e in cui lo storage finale e` un file append only simile a quello
che usa Facebook per le foto (cercare Haystack per riferimenti) e che e`
veramente stupidissimo da implementare nel modo piu` semplice.
La replicazione si ottiene moltiplicando il numero di RMQ nel punto
finale facendo in modo che un messaggio che deve arrivare a me sia messo
in N diverse macchine.
Per finire esiste tranquillamente la possibilita` di non fare tutto in
hard real time (che tanto non fanno in hard real time ugualmente) e
semplicemente separare il delivery del messaggio dalla presa in
responsabilita` da parte di un RMQ, e` meno consistente (eventualmente
consistente si direbbe) ma non si puo` fare un sistema enorme senza
rilassare qualche constraint sulla consistenza dei dati.
E in tutto questo stiamo parlando di 6 o 7 macchine mediamente potenti
(normali dual core con una generosa dotazione di ram e non
particolarmente potenti) sarebbero in grado di gestire un traffico
_almeno_ 3 o 4 volte piu` grosso di quello attuale di Twitter senza
batter ciglio.
A questo punto il problema sarebbe come esporre questi dati al web visto
che ora sono semplicemente in un file di testo... Beh e` banale a
pensarci, questo sistema ha il vantaggio inconfutabile che e`
completamente push senza pero` avere i problemi delle architetture
push. Questo significa che all'arrivo di un messaggio posso rigenerare
tutte le cache interessate (ad esempio rigenero gli ultimi 40 messaggi e
li piazzo in un memcache o in un analogo key-value store
distribuito), anche questo e` simile a quello che fa facebook per la
loro replicazione che quando invia una nuova riga con mysql va anche a
cancellare la relativa entry in memcache in modo che possa essere
rigenerata.
Nel caso volessi avere una cosa piu` astratta inizierei ad andare a
parare verso filesystem distribuiti (cloudstore, mogileFS, hdfs e altri)
e metterei il file di testo di ciascun utente in questi, ancora
alternativamente ogni utente ha una serie di chiavi in un key-value
store distribuito che tengono traccia dei messaggi che hanno ricevuto. 
Io con questo sistema faccio tranquillamente 4000 messaggi al secondo
via _WAN_ (in cui il nodo di ingress sta in una rete diversa dai nodi di
arrivo, in particolare era tra EC2 e la nostra co-location) anche se il
mio usecase non e` il messaging ma solo guaranteed delivery.
Ci sarebbero tante altre cose da aggiungere ma il punto fondamentale
resta... Gli architetti di Twitter sono li` perche` sono stati davvero
molto fortunati. Scala non sara` la fine dei loro problemi, solo della
credibilita` dei loro ingegneri.


 CUT
Tra parentesi, ho un invito in mailbox per farmi un happy hour a SF
con un certo Gosling.
Non ci posso andare perchè è il primo Maggio e sono in Italia, ma se
mi reinvitano ci vado sicuro.
E poi vengo probabilmente licenziato :D
  ngw
-- 
Nicholas Wieland (ngw), Zooppa CTO
911 Western Avenue, Suite 420, Seattle, WA  98104  USA,
http://www.zooppa.com
http://www.nofeed.org

 reference per iniziare ad usare java on GAE:
http://code.google.com/appengine/docs/java/gettingstarted/introductio.
..
Lista delle compatibilita:
http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine
Raffaele