Categorie
Guide

Java, storie di compatibilità e lock-in nelle piattaforme cloud

Il cloud computing si appresta a diventare sempre di più una realtà per le aziende, e può succedere che ad uno sviluppatore sia richiesto di fare deploy su piattaforme cloud, quali ad esempio Amazon Beanstalk o Google App Engine. Nell’approcciarsi a questa nuova realtà esistono alcune differenze fondamentali delle quali bisogna tenere conto quando si programma, e che andiamo a discutere brevemente.

Oggetti Static

Conosciamo la differenza tra variabile di istanza e variabile di classe, la prima infatti non è statica, mentre la seconda sì. Usiamo una variabile statica per dire alla JVM che ci dovrebbe essere solo un’istanza di quella variabile. Se la variabile static è dichiarata con la parola chiave “final”, non ci saranno problemi in un ambiente distribuito, in quanto il suo valore non cambierà mai. Il problema esiste quando ci aspettiamo che il valore della variabile possa cambiare. Come in un ambiente di cluster, GAE e Beanstalk eseguiranno la vostra applicazione di JVM multiple. Se il valore della vostra variabile static è cambiato nella JVM, non verrà propagato ai cluster portando quindi a delle inconsistenze. E’ quindi raccomandato evitare variabili static a meno che non siano configurate come “final”.

Strategia di Caching

Questa riguarda le performance per evitare che certe operazioni diventino pesanti. A volte abbiamo bisogno di mettere in cache gli oggetti in memoria e quindi implementiamo la nostra strategia di caching, attraverso l’uso di un semplice HashMap o di altre soluzioni di caching disponibili. Il caching ha molti benefici, ma implementare una strategia di cache dovrebbe essere una pratica da trattare con attenzione. Questo perché il caching presenta lo stesso problema degli oggetti statici. La vostra cache sarà nella JVM locale quindi non sarà visibile nel cluster. Esistono alcune soluzioni, per esempio GAE usa Memcached e Beanstalk può far uso di ElastiCache che è il corrispettivo di Memcached. Quando sviluppate per un ambiente PaaS, siate sicuri di non implementare il vostro sistema di cache personale, ma cercatene uno che sia supportato dall’ambiente in cui vi trovate. Questa caratteristica ovviamente può essere l’amara causa del lock-in tecnologico di alcune piattaforme.

Sessioni Server-Side

In caso di ambiente unico diamo per scontata l’archiviazione dei dati di sessione delle applicazioni sul server. Soprattutto usando Google App Engine, sono stati rilevati dei problemi con la gestione delle sessioni. Da allora Google ha affrontato molti di questi problemi con dei suoi meccanismi di gestione di sessioni delle applicazioni Java. Per minimizzare la scrittura di una sessione nel datastore, archiviamo lo stato dell’applicazione in memoria. La maggior parte delle applicazioni sono scritte senza aver in mente nessun approccio alla PaaS con cui stiamo lavorando, quindi usiamo JEE com’è, con un approccio che funzionerebbe nel deploy di qualsiasi ambiente di cluster self-hosted, tranne che nella piattaforma di Google. Google implementa il proprio session management che risulta spento di default, quindi avremo bisogno di di abilitarlo in appengine-web.xml ed essere sicuri che tutti i nostri oggetti implementino l’interfaccia java.io.serializable.

Lascia un commento