Stampa Invia un commento Invia questo articolo

Con Mark Little, Senior Director Engineering del middleware di Red Hat svisceriamo l'idea della piattaforma transazionale distribuita che vuole disegnare il cloud dopo il 2013. Anche con il contributo dei ricercatori italiani.

Mark Little è il responsabile dell'engineering del middleware di Red Hat, ossia, lavorando con i team di prodotto ne influenza la direzione tecnica.

Svolge questo lavoro forte di un backgroud consistente che parte dall'affidabilità dei sistemi distribuiti. Poi da Chief Architect contribuì a fondare Arjuna Technologies ed è stato anche responsabile dello sviluppo tecnico Soa e degli standard per JBoss.
Ha la forza tecnica, dunque, per sostenere il peso delle nostre domande, tese a fare chiarezza sul significato dell'iniziativa progettuale Cloud-Tm.

Quando avete cominciato a pensare a Cloud-Tm e quanto ci avete messo per far partire il progetto?

L'idea di realizzare una piattaforma di memoria transazionale distribuita elastica e auto-ottimizzante per il cloud è stata inizialmente concepita ed elaborata in un paper realizzato nel maggio 2009 e presentato nel corso del secondo Workshop Large Scale Distributed Systems. Il progetto fu avviato ufficialmente a giugno 2010, e la prima decisione tecnica chiave, presa alla fine di luglio, fu di trasformare diversi recenti progetti JBoss, come Infinispan, Hibernate Ogm e Hibernate Search, nella dorsale della piattaforma Cloud-Tm. Nel primo anno del progetto i ricercatori di Inesc-Id e l'Università La Sapienza di Roma hanno collaborato da vicino con gli architect e ingegneri Red Hat/JBoss sulla progettazione dell'architettura della piattaforma.

Puntate dunque a creare un nuovo paradigma di sviluppo e gestione applicativa. Ma cosa c'è di difficile nello sviluppare applicazioni per il cloud?

Il cloud è una tecnologia relativamente nuova e ci sono ancora diverse difficoltà da affrontare per potenziare la produttività degli sviluppatori software.
Strumenti e supporto Ide stanno migliorando e gli standard stanno iniziando a emergere, quindi anche se lo scenario è ancora alquanto confuso, prevedo (o meglio spero) che la situazione si consolidi a breve su questo fronte.
Una volta rimossi questi ostacoli tecnologici, tuttavia, gli sviluppatori dovranno in ogni caso affrontare, a mio avviso, la principale difficoltà associata al passaggio verso il cloud: la mancanza di garanzie precise relative ai livelli di sicurezza, disponibilità e scalabilità che si possono prevedere da un'applicazione implementata nel cloud.
Prendiamo la scalabilità elastica per esempio, una delle funzionalità maggiormente pubblicizzate del modello pay-only-for-what-you-use del cloud computing.
Ciò che la maggior parte dei cloud provider non dirà è che l'aggiunta di nuove risorse di elaborazione alla piattaforma non necessaria porterà dei vantaggi in termini di prestazioni percepite dall'utente.
Scalare le applicazioni orizzontalmente (allocando nuove macchine virtuali o istanze server a un'operazione) non è semplice come effettuare l'upgrade a una macchina più potente con incrementi significativi in termini di Cpu, memoria e storage locale.
A meno che un'applicazione non sia parallelizzabile, e cioè partizionata naturalmente in sottotask indipendenti che possono essere utilizzate in parallelo senza interdipendenze reciproche, gli overhead necessari per sincronizzare lo stato delle applicazioni che operano su piattaforme distribuite possono facilmente divenire dominanti e limitare in modo significativo la scalabilità delle applicazioni.
In questi sistemi, lo sfruttamento della località dei dati al fine di ridurre la frequenza di interazioni remote tra componenti distribuiti, così come l'utilizzo di meccanismi efficienti di sincronizzazione dello stato, è essenziale per ottenere un'elevata scalabilità.
Purtroppo, oggi si tratta di una sorta di magia, dominata solo da specialisti nel computing parallelo e distribuito, e fuori dalla portata dei programmatori medi.
La risposta che vogliamo fornire con Cloud-Tm è duplice. Da un lato, lo sviluppo di astrazioni di programmazione semplici e potenti, quali Transactional Memories, che hanno l'obiettivo di nascondere ai programmatori la complessità pur consentendo loro di scrivere applicazioni che possono scalare orizzontalmente fino a centinaia di nodi.
Dall'altro, progettare meccanismi pervasive di self-optimization che garantiranno massima efficienza nell'utilizzo di risorse acquistate nel cloud, riducendo al minimo i costi amministrativi e operativi delle applicazioni cloud.

Il middleware di Self-Optimizing Distributed Transactional Memory potrà davvero essere da solo l'automatizzatore del cloud o serve dell'altro?

Nel progetto Cloud-Tm ci focalizzeremo sulle difficoltà legate a self-tuning e elastic scaling dell'in-memory transactional data grid, e questo già ha a che fare con un elevato numero di parametri di configurazione.
Infatti stiamo investigando l'adozione di una vasta gamma di tecniche self-tuning, associando soluzioni che derivano da aree quali machine learning, control theory, così come tecniche di modellazione delle performance analitiche e basate sulla simulazione.
Al momento stiamo applicando tali tecniche a problemi di self-optimization specifici quail l'identificazione, sulla base dei carichi di lavoro e del scala del sistema attuali, i setting ottimali affinché il batching level possa essere utilizzato dal sistema di comunicazione di gruppo, o se avvalersi di una strategia di data replication single-master piuttosto che multi-master.
Una domanda più generica della quale ci stiamo occupando è se è possibile progettare tecniche di self-tuning generiche che sono sufficientemente astratte e robuste da automatizzare l'ottimizzazione di componenti software arbitrari.
Questo obiettivo è estremamente ambizioso, ma la sua riuscita porterebbe allo sviluppo di un building block potente e valido che potrebbe consentire al self-tuning di diventare una funzionalità realmente pervasiva di infrastrutture It complesse.

Quando sarà pronto? Come sarà distribuitò? Chi lo potrà usare?

Il progetto dovrebbe concludersi nel luglio 2013 e i risultati essere distribuiti con uno schema open-source, ma i dettagli del licensing non sono ancora stati definiti. Il software stack sviluppato dai diversi partner del progetto sarà integrato in una serie di immagini di macchine virtuali pronte all'implementazione e all'uso da parte di numerosi fornitori IaaS.

Sarà sicuro? E del cloud, in se stesso, sarà garantito il funzionamento costante?

Il focus del progetto Cloud-Tm non è sulla sicurezza ma sul data management transazionale e la programmazione nel cloud. Tuttavia, siamo coinvolti in un'interessante collaborazione con ricercatori di un altro progetto sostenuto dalla Comunità Europea, TClouds, che stanno sviluppando soluzioni molto interessanti per garantire la sicurezza dei dati archiviati nel cloud.
Il nostro piano è di integrare le soluzioni sviluppate da entrambi I progetti, posizionando la piattaforma Cloud-Tm sopra l'astrazione cloud storage sicura che TClouds sta realizzando.
Riguardo l'operatività costante, assicurare fault-tolerance e high availability delle applicazioni cloud sono due dei principali obiettivi del progetto Cloud-Tm.
La mia vision è quella di un cloud nella quale i programmatori dispongono di semplici meccanismi dichiarativi per esprimere il grado di failure resiliency necessario per le loro applicazioni, come la durata massima degli outage di servizio cumulativi al mese, e negoziare il costo di tali livelli di servizio con il cloud provider.
Il middleware Cloud-Tm monitorerà e riconfigurerà proattivamente i componenti individuali della piattaforma cloud al fine di garantire che i livelli QoS user-defined siano soddisfatti a costi minimi (in termini di risorse ridondanti aggiuntive allocate per assicurare l'operatività delle applicazioni utente).
Purtroppo le sfide da affrontare al fine di materializzare la vision non sono solo tecniche ma anche e soprattutto di natura legale/commerciale.
Oggi, la maggior parte di infrastrutture e piattaforme public cloud offre esclusivamente servizi best effort, e sono estremamente restii ad affrontare le responsabilità contrattuali associate al garantire Service Level Agreement pre-determinati.
Sono sicuro che il modello QoS-oriented immaginato sarà applicabile, spero a breve, nei private cloud. Se vedremo questo modello adottato in ambienti public, nel prossimo futuro, rimane invece una questione apert.
La risposta alla quale dipenderà dal successo che progetti come Cloud-Tm avranno nel dimostrare la reale fattibilità di questo modello.

Stampa Invia un commento Invia questo articolo