Le tour des nouveautés

• Une interface revue

• Multitâche mis en avant

• Des widgets redimensionnables

• L’action bar (barre système)  ou la fin des boutons physiques

Le régal des mobiles

• Un meilleur navigateur

• Android Beam

• Face unlock

Au déverrouillage classique par code, android 4.0 ajoute un module de reconnaissance faciale qui permet de débloquer votre téléphone.

• Application People

Ces différentes fonctions sont incluses respectivement dans Android Beam API, Camera API et social API.

Partager

• Bleeding Edge HTML5
• Modern Web Apps with HTML5
• Jruby Enhancing Java Developers lives
• Working off the grid: HTML5 Offline
• Flying with Griffon
• Jboss AS5 – Death of slow
• Cracking Clojure
• Mongo DB Workshop
• Integation Camel CXF ServiceMix ActiveMQr
• Jenkins From Continuous Integration to Continuous Delivery
• Building Next Generation Enterprise App in Java
• Introduction to WebIntents
• Hibernate Performance AntiPattern
• Intro to HTML5 Game Programming
• Code Review with Git and Gerrit
• Language, Library, VM Co Evolution in JAVA SE 8

Partager

Ensuite, cette conférence marque vraiment un virage: on sent que l’on passe du domaine JAVA EE à celui du Web & de la mobilité.

Clairement DEVOXX 2011 a été sous le signe de HTML5, ANDROID avec dans leur sillage respectif tout l’écosystème des solutions WEB (explosion technologique 1 : on a parlé de Play, Scala, Ruby…) & celui de la mobilité (explosition technologique 2: première conférence sur PhoneGap par exemple).

Pour le Web, cela a été mis en avant dans le talk de Matt Raible, développeur avec un certain talent de speaker. Il fait pas dans la démesure mais c’est simple et efficace. Matt nous a montré comment développer une application web mobile (thanks phonegap) avec des technologies émergentes (Scala, Play, Jade, CofeeScript, Less)

Pour le mobile, cela a bien été mis en avant dans la keynote du day 2 de TimBray: le développeur qui ne va pas sur le mobile n’a pas d’avenir a t’il dit en substance … un brin provocateur.

HTML5 a été la grande star avec les 2 présentations (ici & ici) de Google ou l’on a eu droit à des démos bluffantes: interaction avec le bureau, mode offline, détection du réseau, speech recognation, web intent dans l’esprit Android ou comment en quelques lignes de code pouvoir s’interfacer avec n’importe quel réseau social.

Plus que jamais le browser est la plate-forme. Ce qui veut donc dire que JS en sera le langage? On a jamais été fan, c’est bien pour cela qu’on fait du GWT. Mais entre les lacunes de JS (faiblement typée & difficilement debuggable), celle de GWT (complexité de code), Google pense qu’il y a une ligne médiane: DART. Dart, c’est quoi donc … aller sur le blog de nos amis de Xebia pour en savoir plus

One more thing ….bien sur l’annonce de la première keynote. Devoxx a fait un petit: Devoxx France. Le lancement est programmé au printemps 2012. Même format qu’Anvers mais à Paris. On en a de la chance! Bravo en tout cas à Antonio & son équipe pour leur abnégation à lancer cette entreprise.

Partager

Dans un article parut hier, InfoQ explique qu’après les annonces de la semaine dernière où Adobe indiquait abandonner le développement de Flash pour les plateformes mobile et TV, Adobe envisage de donner Flex à une fondation Open Source. Dans la FAQ officielle de Flex, Adobe écrit même : «In the long-term, we believe HTML5 will be the best technology for enterprise application development.». En outre, les investissements important annoncés dans les outils de création orientés HTML5 laissent penser qu’Adobe se recentre sur les outils, domaine où il reste tout à faire, et où leur savoir faire est manifeste.

Oracle, avec sa solution de RIA JavaFx, reste donc le dernier grand à n’avoir pas succombé au chants du HTML5. JavaFx, n’est pas seulement vu comme une solution de RIA, mais il se positionne aussi comme un remplaçant de Swing.
Cette approche est-elle encore d’actualité ? L’avenir nous dira si JavaFx trouve son public.

Partager

Les développements phonegap semblent tout indiqués pour s’orienter vers une solution GWT. Plusieurs bibliothèques proposent déjà des implémentations phonegap / GWT.

Les différents projets GWT pour phonegap

GWT-Phonegap (http://code.google.com/p/gwt-phonegap/)

GWT-Phonegap est un wrapper gwt pour la librairie javascript phonegap. Au menu de ce projet, on retrouve la géolocalisation, l’utilisation de l’accéléromètre, la caméra, le vibreur et l’utilisation du réseau. L’implémentation n’est testée que sur Iphone et Android. Ce projet intègre des bouchons utilisés lorsque l’application est utilisée sur un navigateur dépourvu de phonegap. Le développement consiste à tester la présence de chaque fonctionnalité et fournir un développement spécifique en fonction des capacités du navigateur hôte.

Pourquoi le choisir ? Si le choix est motivé par la création d’un site Web et d’une version mobile peu évoluée sur Iphone et Android seulement.

GWTMobile (http://code.google.com/p/gwtmobile/)

GWTMobile est un autre wrapper pour phonegap. Contrairement au précédent, il couvre l’ensemble des fonctionnalités de phonegap. Il propose en plus, un ensemble de composants graphiques adaptés aux mobiles dont le but annoncé est de se rapprocher du rendu natif. Il ne prévoit aucun bouchon pour les navigateurs hors mobile. Toutefois, cette orientation est intéressante puisque GWT se suffit à lui même pour développer des rendus et fonctionnalités différentes en fonction du navigateur.

Ce projet est à privilégier si le choix est motivé par la création d’une application mobile multi-plateformes.

Développement d’un projet phonegap avec GWT

Le développement d’un projet phonegap avec GWT ne diffère pas d’un projet GWT classique. Vous pouvez utiliser vos outils habituelles (eclipse, plugin GWT, maven, …) vos patterns préférés (MVC, MVP).

La contrainte de la solution réside dans les tests sur mobiles. En effet, le devmode de GWT n’est pas accessible depuis les mobiles. Le développement se fait donc en dehors d’un mobile et il faut compiler le javascript pour tester sur mobile. Cela oblige à prévoir des bouchons pour tester les fonctionnalités nécessitant la puissance de phonegap.

Il faut noter que le pattern MVP, préconisé par Google, est à privilégier puisqu’il permet de facilement créer des vues adaptées aux mobiles et des vues adaptées aux navigateurs de bureau.

Partager

Le cloud selon P. Chanezon (Google)

En intro, Patrick s’étonne du peu de gain de productivité sur la partie logicielle par rapport au gain sur le hardware (loi de Moore). Il nous décrit ensuite les grands changement d’architecture survenu dans les dernières décennies

• 60 Mainframe,
• 80 Client / Serveur
• 90 Web,
• 2010 Cloud, HTML5, Mobile… le browser devient l’OS

L’histoire du cloud démarre avec les sites grands publics (Google, Amazon, Facebook…) avec un passage de la scalabilité verticale (toujours de + gros serveur) à horizontal (standardisation du pc pas cher) et l’émergence de stack open source (Linux).

Il décrit ensuite la stack technique google sur le cloud:

• Storage distribué à tolérance de panne : Google File System
• Mémoire partagée distribuée : Bigtable
• Programmation abstraite : MapReduce
• DSL : Sawzall

Il nous explique ensuite que les développeurs devront s’adapter à cette nouvelle donne & réfléchir autrement (Ne plus faire de l’ACID & de la jointure, Ne plus faire des transactions à 2 phasesVoilà plutôt ce qui devrait les préocupper pour les prochaines années :

• Langage : Go, Scala
• NoSql : BigTable, Hbase, MongoDb, Cassandra
• Map/Reduce : Apache Hadoop
• Paxos
• Rest

Pour Patrick, le cloud peut être vu principalement sous les angles suivants:

• Le delivery (SAAS) type Google Apps, App Store Mobile … ou le constat actuel est la fragmentation de l’offre
• L’Infrastructure (IAAS) type Amazon … ou le constat actuel est le manque de standard
• Le plateforme as service (PAAS) type Google App Engine, Joyent, Heroku, Stax (Cloudbees), Amazon …ou le constat actuel est également le manque de standard & le risque d’une forte dépendance au fournisseur (Vendor Lock In)

Sa vision pour le futur:

• Le software devient comme la mode : les objets de production sont industrialisés mais cela devient un métier d’artisan
• Il faut faire face au chaos de productivité : émergence de nouvelles offres, de nouveaux langages, des DSL … l’application va être un assemblage de composants hétérogènes

Ses conseils pour « survivre » :

• S’intéresser à l’Agile, Ui design, Javascript, HTML5
• Monétiser les applications
• Etre indépendant (be your own bitch)

Le cloud selon D. Girard (Sfeir)

Didier dresse le panorama de ce qui sont les inducteurs des solutions cloud:

• Pas les coûts
• Mais la réactivité / l’innovation / le marketing / l’ambition / l’agressivité / la démocratisation / la performance / le mérite (permet à de petites SSII de pouvoir monter des gros projets) / la sérénité (par rapport au montée en charge)

Il nous livre les outils qui ont été utilisés sur plusieurs projets

• Assembla /Github pour la gestion des source
• CloudBees pour l’usine logicielle (build, déploiement)
• Appengine (bigtable, mysql)

Le cloud représente 10% du CA de SFEIR. A son sens, le cloud est inévitable. Il va induire de nouveaux modèles organisationnels en SSII.

Le cloud selon G. Laforge (VMWare)

G. Laforge (Groovy, Grails, Gaelyk) bosse maintenant pour CloudFoundry& nous présente leur solution:

• PAAS de VmWare
• Open Source
• Multi Langage (Java,.Net, Js, Ruby) / Multi framework
• Moteur d’exécution d’app (node, rails, servlet, Spring)
• Stack de services intégrés (App Engine, Azure, RabbitMq, Mysql, MongoDb…)
• Unité de travail : l’application (pas l’infra…)
• Approche indépendante d’un fournisseur (CloudFoundry, Amazon AWS, Cloud privé)
• IDE : Eclipse Spring Source Tool

Le cloud selon N. De Loof (CloudBees)

CloudBees permet d’une part d’avoir une usine logicielle sur le cloud. Cette stack est basée sur GIT/SVN/MAVEN & surtout JENKINS. Elle est manipulable via divers clients (HTTP, WEB UI, ECLIPSE Plugin). La solution est extensible La facturation s’effectue à la minute de build (tiens cela nous rappelle étrangement la facturation IBM à l’époque des mainframes … marrant ce pouvoir de l’IT de se ré-inventer). D’autre part, elle permet de déployer immédiatement des applications sur une stack d’exécution JAVA (TOMCAT/MYSQL actuellement). L’intérêt de la solution est de pouvoir ensuite tourner sur différentes infrastructures cloud (AMAZON WS actuellement mais aussi VMWARE, OVH…)

Le cloud selon Erwan (RunMyProcess)

RunMyProcess est une solution cloud de workflow. Plutot que présenter sa solution, Erwan nous rappelle que le cloud c’est aussi des risques liés au trou noir (comme c’est arrivé suite à la panne de l’infrastructure AMAZON WS) et donc des bonnes pratiques comme

• Redonder son application sur différentes zones de CLOUD
• Faire un programme « CrashMonkey » pour tenter de faire planter son infra & voir si tout va bien réagir
• Faire du monitoring (Nagios)

J’ai bien aimé son discours pragmatique qui nous rappelle aux tristes réalités des infrastructures IT & qu’il convient (même sur le cloud) de se préocupper de la disponibilité & du SLA dès lors qu’il y a de l’enjeu dans l’applicatif exposé.

Partager

• Soit réaliser un développement par plateforme, ce qui implique une multiplication du nombre de projet par le nombre de plateformes
• Soit réaliser un développement « cross-plateform »

Dans le deuxième cas, il est possible de réaliser un seul développement qui tournera sur toutes les plateformes grâce au framework PhoneGap.

Le principale avantage et inconvénient de ce framework est que tout le code se fait en HTML, JS et CSS. L’avantage est la facilité du code (tout le monde ou presque sait faire du HTML), l’inconvénient majeur est l’utilisation des ressources du téléphone en dehors du domaine d’utilisation de phonegap.

PhoneGap étant une plateforme extensible, regardons dans cette article comment réaliser un plugin dans PhoneGap.

Mise en place de l’environnement de travail

Avant toute chose, il faut commencer par créer un nouveau projet PhoneGap.

Sous eclipse créer un nouveau projet Android.

A la racine du projet créer 2 répertoires :

• /libs
• /assets/www

Copier phonegap.jar dans le répertoire libs, puis l’ajouter au classpath (disponible dans PHONEGAP_HOME/Android/phonegap-version.jar). Ajouter cette librairie au classpath du projet eclipse.

Copier phonegap.js dans le repertoire /assets/www copier (disponible dans PHONEGAP_HOME/Android/phonegap-version.js)

Copier le code suivant dans votre Activity principale.

Ajouter les permissions suivantes dans le fichier manifest du projet (après la balise root du fichier xml)

Pour finir il faut le fichier html qui est affiché par l’activité principale (à placer dans /assets/www/index.html)

Exécuter le projet pour voir si une page s’affiche sur le device.

Fonctionnement des plugins sous phonegap

Pour créer un nouveau plugin sous phonegap il faut définir au moins 2 fichiers :

• Un fichier JS qui correspond à l’appel du code natif (wrapper JS)
• Un fichier “natif” par plateforme qui correspond à l’implémentation du plugin.

Exemple (Hello World):

Fichier Java

La première étape consiste à écrire le plugin en Java. Pour cela créer une simple classe Java qui étend la classe Plugin.

import org.json.JSONArray;

import android.util.Log;

import com.phonegap.api.Plugin;
import com.phonegap.api.PluginResult;
import com.phonegap.api.PluginResult.Status;

public class HelloWorldPlugin extends Plugin {

@Override
public PluginResult execute(String action,
JSONArray data, String callbackId) {
Log.d(« HelloWorldPlugin », « Plugin HelloWorld est executé »);
return new PluginResult(Status.OK, « Hello World from Java !!! »);
}
}

Fichier Javascript

La deuxième étape est double, car elle consiste à crée le stub javascript (définir la signature de notre plugin java en javascript), puis de référencer ce stub auprès de PhoneGap.

//Register the native class of plugin with PhoneGap
PluginManager.addService(« HelloWorldPlugin »,
« fr.objectif.demopg.HelloWorldPlugin »);
});

La partie cliente

Pour finir dans notre application, il suffit d’appeler notre plugin en javascript, via PhoneGap

L’appel du plugin (index.html)

Exemple plus complet

Voici un exemple avec le listing des calendriers disponibles dans l’agenda :

Partie Java

import org.json.JSONArray;
import org.json.JSONException;
import org.json.JSONObject;
import org.json.JSONStringer;

import android.database.Cursor;
import android.net.Uri;
import android.os.Build;
import android.util.Log;

import com.phonegap.api.Plugin;
import com.phonegap.api.PluginResult;
import com.phonegap.api.PluginResult.Status;

public class CalendarPlugin extends Plugin {

enum CALENDAR_ACTION{
get
}
@Override
public PluginResult execute(String action, JSONArray data,
String callbackId) {
CALENDAR_ACTION act = CALENDAR_ACTION.valueOf(action);
try{
switch(act){
case get:
return getCalendars();
}
}catch (Exception e) {
Log.e(« Calendar Plugin », e.getMessage());
return new PluginResult(Status.ERROR, e.getMessage());
}
return null;
}

private PluginResult getCalendars() throws JSONException {
String[] projection = new String[] { « _id », « name », « displayname » };
Uri calendars = null;
if (Integer.parseInt(Build.VERSION.SDK) >= 8)
calendars = Uri.parse(« content://com.android.calendar/calendars »);
else
calendars = Uri.parse(« content://calendar/calendars »);

Cursor managedCursor = ctx.managedQuery(calendars, projection, null,
null, null);
JSONArray returnArray = new JSONArray();
while (managedCursor.moveToNext()) {
JSONStringer stringer = new JSONStringer();
stringer.object()
.key(« id »).value(managedCursor.getString(0))
.key(« name »).value(managedCursor.getString(1))
.endObject();
returnArray.put(new JSONObject(stringer.toString()));
}
return new PluginResult(Status.OK, returnArray);
}
}

Pour la partie Javascript

Partager

Java, .Net, les deux frères ennemis ? En y regardant de près, les deux plateformes ont pas mal de choses en commun et de bonnes raisons pour s’inspirer l’une de l’autre sur les aspects qui marchent bien, ou de tirer des leçons de leurs erreurs respectives.

On commence la présentation sur un schéma détaillant la stack de Java et .NET. On remarque que la JVM et la CLR de .NET ont une architecture très semblable. Les interlocuteurs retracent l’histoire des plateformes sur plusieurs sujets: On est tous d’accord sur le fait que .NET 1.0 ne vaut rien face au Java de l’époque

Round 1 : la persistance

Round 2 : les POJO et POCO

Dans cette section, pas grand-chose à dire. On a eu le droit à un bref historique :

JAVA :

EJB 1 puis EJB 2 pour ensuite laisser place à Spring ! Puis viens ensuite EJB 3 les injections de dépendance et les annotations.

.NET :

ADO.NET Entity Framework puis Linq to Entity. Ensuite 3 les injections de dépendance en.NET 2.0 (NInject,Unity,etc.) puis en .NET 4.0 (MEF) CDI intégré.

Round 3 : les frameworks Orientés web

JAVA :

On a l’embarras du choix ! Qui ne trouve pas sont framework préféré dans cette liste : JSF/Seam/Wicket/SpringMVC/Stripes/Struts/Tapestry/GWT/…

.NET :

On n’a pas le choix du framework vu que la plateforme est propriétaire, tous les outils sont intégrés dans Visual Studio. D’un coté ce n’est pas plus mal.

-ASP.NET Designer graphique

- Silverlight3, 4,5!(Silverlight2 # JavaFX2). Le point faible pour Java.

Round 4 : les web services

JAVA :

Au début des WS, nous avons seulement les RPC. Ensuite Java doit rattraper son retard car .NET a pris de l’avant et gère mieux les WS notamment avec le protocole SOAP en matière d’interopérabilité. Java crée donc JAX-RPC et la renomme plus tard JAX-WS car ce n’est plus du RPC ! Viens ensuite JAXB plus mature. Pour le REST nous avons JAX-RS.

.NET

-Les web Method

-WCF: framework de communication complet (RMI,SOAP,REST,JSON…)

Round 5 : le Cloud

JAVA :

Plusieurs plateformes disponibles :

-Google App Engine

-Amazon ElasticBeans

-RedHat

-CloudBees

Une standardisation est prévue dans JavaEE 7 tant attendu

.NET :

Une seule plateforme :
-Azure

Il est intéressant de noter que 50% des applications hébergées sur Azure sont écrites en Java ou PHP (les autre 50% en .NET bien sur).

Round 6 : les outils

JAVA :

IDE : Eclipse,NetBeans,Idea…

Build: Maven,Ant,Gradle

Intégration continue: Jenkins,Hudson

Qualimétrie: Sonar

.NET: Encore une fois un seul outil ou devrais-je dire plutôt un seul produit : L’aspect propriétaire a ses avantages

Visual Studio 2010 :

Touts les outils sont intégrés même pour l’intégration continue(TFS). Pas de plugin ou autre chose à installer.

Round 7 : langage supporté

JAVA :

Java n’est pas juste un langage, c’est une plateforme !

-Jruby

-Jython

-Scala

-Groovy et bien d’autre !

.NET :

-IronRuby

-IronPython et quelque autre

Round 8 : interoperabilité

JAVA :

On aurait tendance à dire que Java est une plateforme « run everywhere ». D’après les interlocuteurs…pas vraiment (il suffit de porter une application JavaFX sur un autre OS pour voir sont comportement…l’appli ne se lance même pas !). Pareil pour JME, il faut limite une version spécifique pour chaque modèle de téléphone…

.NET : n’en parlons pas

Conclusion

.NET:

• Ecosystème OpenSource riche (Aforge)
• F#,Async,Tinq,TPL
• Force d’intégration (TFS)
• Combien de temps pour un Linq en Java ?

JAVA :

• Depuis la sortie de Java 6 (2006), gros coup de frein dans le monde Java :

      - Conflits politiques dans le JCP
      - Départ des spec-leads

• Un nouveau lead apparait

      - JBoss via l’opensource et en collaboration avec le JCP
      - Oracle reprend la main et passe en force

On a donc deux plateformes mâtures. Java avance avec des spécifications ce qui permet à plusieurs acteurs de créer des outils performant. Mais je trouve qu’il faudrait mieux un outil standard qui marche bien plutôt que d’avoir trop de choix.

.Net est propriétaire il n’y a donc pas de spécifications à implémenter. Un produit, Visual Studio 2010 embarque avec lui tout les outils nécessaires pour la création d’applications web.

Partager

• Une faible latence
• Une très haute disponibilité
• Une scalabilité massive

La version actuelle est la 0.8. Elle est stable et a déjà été déployée en production chez de nombreux “Grands du web”.

Architecture

Cassandra est composée d’un anneau de noeuds. et chacun des noeuds possède plusieurs réplicats.

L’organisation en anneau permet d’affecter un intervalle à chaque partition, facilitant ainsi les ajouts et suppressions d’instances. Les réplicas permettent de récupérer facilement d’une défaillance.

Chaque client a la connaissance de 1 ou n noeuds. S’il ne connait pas le noeud auquel il doit réellement se connecter, il s’adresse à un des noeuds connus et ce dernier agit alors en tant que proxy et redirige l’information au destinataire.

Gestion des défaillances

Plusieurs mécanismes sont mis en place à fin de résister aux défaillances:

• Mécanisme d’anti-entropie, assurant des réplicas identiques
• Hinted-Handoff stocke les écritures pendant l’absence d’un noeud (comme une file de message). Lorsque le noeud redevient disponible, les requêtes lui sont transmises.

Stockage sur disque

L’écriture séquentielle sur disque est le plus efficace. Cassandra assure cela en chargeant d’abord les requêtes dans la mémoire du noeud et les exécute lorsqu’il y en a un certain nombre. En même temps, afin d’être sûr de ne pas perdre l’information, la requète est écrite dans un fichier de log (Ceci est une écriture séquentielle également puisqu’on l’ajoute en fin de fichier).

Note : Ce principe est également vrai pour les SSD. Bien que cette technologie réduise considérablement les temps d’accès, l’écriture séquentielle reste plus efficace.

ACID (atomicity, consistency, isolation, durability)

Une base de données doit assurer plusieurs propriétés afin d’assurer la bonne exécution des transactions :

• Atomicité : Toutes les opérations d’une transaction sont effectuées, ou aucune.
• Consistence : Validité des informations.
• Isolation : Peut y avoir plusieurs transactions en même temps. Une transaction ne verra pas les modifications apportées par une autre.
• Durabilité : Lorsqu’une transaction est faite, elle sera commitée. Après cela elle ne pourra plus être annulée.

   Le théorème CAP

Le théorème de CAP dit qu’une base de données ne peut assurer les trois propriétés suivantes en même temps :

• Consistance
• Disponibilité
• Tolérance aux défaillances

Seules deux de ces propriétés peuvent être assurées. Cassandra assure à tout moment la disponibilité et la tolérance aux défaillances. La consistance des données n’est alors que partielle. L’inconsistance des données vient de la répartition et la réplication des données entre les noeuds. Afin de réduire le risque de récupération d’informations erronées, pour chaque lecture on doit respecter la formule : R+ W > N où :

• R est le nombre de noeud lu
• W le nombre de noeud écrit
• N le nombre total de noeud

Ainsi si une information incorrecte est lue, ce sera détecté et Cassandra effectuera la validation par rapport au moment de la création de l’information pour retourner la donnée valide. Le nombre d’écriture et de lecture attendues peut être paramétré, laissant ainsi le choix aux développeurs entre efficacité et consistance.

   Atomicité et Isolation

Les données ne sont plus co-localisées et les transactions distribuées nuiraient à la disponibilité et aux performances, mais l’atomicité et l’isolation sont obtenus par opération sur une clé.

   Durabilité

Les écritures multiples en mémoire apportent la durabilité. Cette dernière est renforcée par l’écriture sur un ou plusieurs disques.

Modèle de données

Chaque id de ligne correspond à une liste de couples clé-valeur.

Cassandra définit également des Super-colonnes dont les valeurs sont des collections de colonnes.

Le modèle de données de Cassandra est cependant peu intuitif, la compréhension des super-colonnes n’étant pas aisée.

APIs disponibles

Différentes API sont disponibles pour accéder à Cassandra :

• Thrift, un RPC développé par Facebook. Il est disponible pour les principaux langages.
• Hector qui est un client de haut niveau pour Java. Il offre un mapping de type JPA.
• PhpCassa qui est un client pour PHP et PyCassa qui est un client pour python

Cassandra en production

Cassandra est en production chez de nombreux “Grands du web”. Il est cependant important de noter que les backups peuvent être problématiques avec des volumes importants et que la gestion du cluster requiert une équipe d’exploitation expérimentée. De plus son outillage est encore réduit.

L’intérêt pour l’entreprise

Un certain nombre d’avantages ont été avancés :

• Stockage polyglotte : une meilleure adéquation entre la BDD et les données
• Scalabilité linéaire : être à même de répondre aux besoins les plus gourmands
• Haute disponibilité : du multi-serveurs au multi-datacenters
• Elasticité : une intégration naturelle à la logique du Cloud Computing
• Curseur pour s’adapter : + de consistence ou + de fiabilité (Quorums)

Site officiel : ici

Partager