Embedding Tomcat 7 for unit tests

Recently (in fact, few months ago), I have had to develop a small REST service exposing some methods that could be invoked remotely by a REST client (using GET and POST methods). The service contract was so simple that I took less time to write the service class by using Jersey that declaring all the Spring dependencies in the project pom.xml or creating a new application with the Play! framework.

As a not fully agile developer, I didn’t write the tests before starting the service (oh !! you don’t respect the TDD ? no ! I don’t — unless for this time — :)). So after finishing the few lines of code of my service (<500 lines), came the time to test my service.

Then I was wondering myself how could make quickly an integration test in my JUnit test case inside my IDE, before creating a new Jenkins Job (yes ! this time I’ve heard about the CI :)). Below some of them :

  • Servlet Unit test
  • using Arquilian
  • starting manually an external servlet container
  • starting a container with Cargo
  • using an embedded server started during the test setup phase (@Before for instance)
  • etc…

As a lazzy developer as usual, I opted for the simpliest choice (for me) : using an embedded Tomcat server.

First, I added the following line (dependencies management) in my project pom.xml. Yes! here the project is a Maven based project.


<properties>
	<tomcat-version>7.0.26</tomcat-version>
</properties>
...
<!-- TEST -->
		<dependency>
			<groupId>org.apache.tomcat.embed</groupId>
			<artifactId>tomcat-embed-core</artifactId>
			<version>${tomcat-version}</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.apache.tomcat.embed</groupId>
			<artifactId>tomcat-embed-logging-juli</artifactId>
			<version>${tomcat-version}</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.apache.tomcat.embed</groupId>
			<artifactId>tomcat-embed-jasper</artifactId>
			<version>${tomcat-version}</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.apache.tomcat</groupId>
			<artifactId>tomcat-jasper</artifactId>
			<version>${tomcat-version}</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.apache.tomcat</groupId>
			<artifactId>tomcat-jasper-el</artifactId>
			<version>${tomcat-version}</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.apache.tomcat</groupId>
			<artifactId>tomcat-jsp-api</artifactId>
			<version>${tomcat-version}</version>
			<scope>test</scope>
		</dependency>

And then, here comes the code… :)

Please note that there are so many different ways to achieve the same goal, therefore my following code is provided  for the example purpose only. Of course, you can write your classes by using your own style :)

First, I wrapped the Tomcat inside a Runnable that will be started during the test init phase

//import are removed
public class EmbeddedServer implements Runnable {

	private Tomcat	tomcat;
	private Thread	serverThread;

	public EmbeddedServer(int port, String contextPath) throws ServletException {
		tomcat = new Tomcat();
		tomcat.setPort(port);
		tomcat.setBaseDir("target/tomcat");
		tomcat.addWebapp(contextPath, new File("src/main/webapp").getAbsolutePath());
		serverThread = new Thread(this);

	}

	public void start() {
		serverThread.start();
	}

	public void run() {
		try {
			tomcat.start();
		} catch (LifecycleException e) {
			throw new RuntimeException(e);
		}
		tomcat.getServer().await();
	}

	public void stop() {
		try {
			tomcat.stop();
			tomcat.destroy();
			deleteDirectory(new File("target/tomcat/"));
		} catch (LifecycleException e) {
			throw new RuntimeException(e);
		}
	}

	void deleteDirectory(File path) {
		if (path == null) return;
		if (path.exists()) {
			for (File f : path.listFiles()) {
				if (f.isDirectory()) {
					deleteDirectory(f);
					f.delete();
				} else {
					f.delete();
				}
			}
			path.delete();
		}
	}

Finally run my JUnit tests where my client could request my REST service that has been previously deployed on the embedded Tomcat instance

public class MyAppDeployedOnLocalTest {

	@Before
	// or @BeforeClass
	public void startServer() throws ServletException {
		embeddedServer = new EmbeddedServer(9090, "/myservice");
		embeddedServer.start();

	}

	@After
	// or @AfterClass
	public void stopServer() {
		embeddedServer.stop();
	}

	public void test_send_request_without_parameters (){
            Client client = ...
            Reply reply = client.sendRequest();
            assertTrue (reply.isOk());
    }
}

And ..voilà ! :)

2013, année du PaaS

Bonne Année

Puisque la tradition permet de s’échanger les voeux pendant tout le mois de janvier, au nom de tout FastConnect, je souhaite une bonne année aux lecteurs de notre blog.

Ma Boule 8 magique

Alors que je butinais sur la toile j’ai remarqué que les voeux étaient pour beaucoup l’occasion d’effectuer des prédictions avantageuses pour l’année prochaine…

À mon tour, j’aimerais partager ma vision du futur des Systèmes Informatiques (SI). En 2013 nous prévoyons une explosion des projets autour du PaaS. Ce sentiment est fondé par les retours positifs de nos clients mais aussi par les analystes : Gartner Says Worldwide Platform as a Service Revenue Is on Pace to Reach $1.2 Billion.

Qu’est-ce que le PaaS

Les offres SaaS et IaaS sont globalement plus anciennes, plus matures et mieux comprises. Par exemple Salesforce, fournisseur d’offres SaaS, a été créé en 1999 et Amazon a lancé son offre EC2 en 2006.

GIF - 39.7 ko

Remarquons au passage que la présentation de IaaS/PaaS/SaaS comme une pile technique du Cloud Computing est trompeuse car il est possible de construire une offre SaaS sans s’appuyer sur un PaaS (et cela a été fait puisque le SaaS est plus ancien).

Le SaaS est la fourniture d’une application (gestion des comptes clients, brms, etc.) via le réseau. Il s’agit pour le client de consommer le service dont il a besoin, via une interface et/ou une API et sans se préoccuper de sa mise en oeuvre.

Le IaaS est la fourniture d’infrastructure (stockage, serveurs, etc.) via le réseau. En générale le IaaS est implémenté grâce à des techniques de virtualisation, mais c’est bien plus. Un IaaS, comme tout « As A Service » doit offrir une grande agilité aux utilisateurs. Personnellement je me le représente comme un data center programmable.

Le PaaS est souvent dessiné comme une couche entre les deux autres… ou comme étant la virtualisation de la couche middleware. Bref c’est ce qui est au milieu :-) Si je compare l’informatique au bâtiment – comparaison fréquente – la construction d’une application serait du préfabriqué : les développeurs s’appuient en effet sur des briques « middlewares ». Le PaaS est la fourniture de ces briques « middlewares » via un réseau.

Le PaaS est donc un outil pour les développeurs qui utilisent dans leur travail quotidien des middlewares tels que les bases de données ou les serveurs d’applications.

Un PaaS pour quoi faire ?

Beaucoup d’entreprises ont commencé leur stratégie Cloud Computing en espérant diminuer les coûts de leur SI. Mais l’intérêt substantiel du Cloud Computing est de redonner de l’agilité au métier.

Il est très naturel d’envisager sa stratégie Cloud en commançant par le IaaS et le SaaS qui sont plus matures et mieux compris. Cependant nous, FastConnect, sommes convaincus que le PaaS est finalement la couche qui a le plus de valeur, en particulier pour les moyennes et grandes entreprises où les DSI sont très structurées et manquent souvent d’agilité.

Pour répondre à ce besoin d’agilité, le IaaS ne suffit pas. Qu’importe que l’on puisse déployer un serveur en un click si son achat est un processus toujours aussi difficile ou si l’on dépend d’une autre équipe peu agile pour l’installation d’un middleware.

L’objectif ambitieux du PaaS est de redonner de l’agilité au SI de bout en bout.

Typologie des PaaS

Le Gartner divise le marché du PaaS en :

  1. application platform services (aPaaS),
  2. cloud application life cycle management (ALM) services (almPaaS),
  3. cloud BPM platform services (bpmPaaS),
  4. cloud integration services (iPaaS)

Il s’agit pour l’essentiel de services middlewares particuliers (notons que la frontière entre le PaaS et le SaaS est finalement mince, un bon sujet de dispute pour nos experts à la machine à café).

Mais pour répondre à l’objectif ambitieux d’agilité, il est nécessaire de faire entrer tout le catalogue technique sous forme d’offres « As A Service » (toute ressemblance avec le SOA est purement fortuite). C’est la raison pour laquelle je crois beaucoup dans l’approche des solutions de PaaS Fabric tels que Cloudify, Tibco Silver Fabric ou OpenShift qui permettent de fabriquer son custom PaaS incluant tous les middlewares et services utilisés par l’entreprise. Ils permettent une grande souplesse d’intégration avec l’existant et, cerise sur le gâteau, évitent tout vendor locking.

Vers une agilité du SI de bout en bout

Finalement ce qui nous intéresse vraiment est de (re)donner au SI une agilité de bout en bout afin de permettre une agilité métier. Pour répondre à cet objectif très ambitieux l’organisation et les méthodologies doivent aussi être agiles.

Suivant cette tendance, la saison est au Continuous Delivery !

Déploiement automatisé

Plusieurs éditeurs proposent des outils afin d’aider à formaliser et automatiser les déploiements. Ces outils sont effectivement très efficaces pour réduire la distance entre les équipes de développement et de production qui ont des objectifs a priori contradictoires :

  • les développeurs agiles veulent livrer rapidement chacun de leur sprint sur leur environnement de test
  • la production veut maitriser les changements afin de diminuer les risques opérationnels.

L’objectif de ces outils est d’automatiser tous les déploiements, et de contrôler qui peut déployer quoi sur chaque environnement. De plus, par des mécanismes d’injection de configuration, ils aident le passage d’un environnement à un autre (DTAP). Les développeurs intègrent naturellement ces outils pour compléter leur chaine de compilation et de test continue. On parle de continuous delivery.

D’une manière générale ces outils savent déployer un WAR dans un Tomcat existant, mais ils ne savent pas déployer ce Tomcat juste avant. Ceci est particulièrement utile dans le cas des environnements de Tests qui ne fonctionnent que pendant une fraction de la journée. Le PaaS est la brique manquante qui permet cela.

Créer votre propre Usine de déploiement continu

Je vous invite évidemment à visiter notre nouveau site web et à lire nos offres Cloud
http://www.fastconnect.fr/fr/nos-offres/cloud

Nous proposons notamment de vous aider à mettre en place une usine de livraison continue fondée sur une usine GitHub/Jenkins/Nexus et un PaaS Fabric pour intégrer vos briques logicielles et middlewares particulières, et ceci en évitant le plus possible la rupture par rapport à vos habitudes et vos outils.

App-Store

Soirée FastConnect avec Software AG / Terracotta

Le Mardi 22 Janvier 2013 s’est déroulée une soirée FastConnect, et nous avons eu le plaisir d’accueillir Software AG / Terracotta pour nous parler de EhCache / BigMemory.

Personnellement, je trouve que cette solution répond à pas mal de besoins que je rencontre chez les clients.
De plus, la force de la solution est de pouvoir commencer avec un « petit cache » à l’aide d’EhCache (opensource, et qui s’intègre avec Hibernate ou Spring), puis bénéficier du cache « off-heap » avec BigMemoryGO, puis le rendre distribué avec BigMemoryMax.

600_198449722

A titre d’information, cette solution a été mise en production chez un client pour de la détection de fraude en temps réel, avec un volume de 16To en mémoire! Le mot « BigData » prend tout son sens.

Capture d’écran 2013-01-24 à 16.14.58

Je ne vous en dit pas plus, et je vous laisse découvrir EhCache / BigMemory à travers la documentation officielle.

Nouvelle version du driver VirtualBox pour Cloudify

Je voulais vous annoncer la sortie de la nouvelle version 1.2 du driver VirtualBox pour Cloudify: https://github.com/fastconnect/virtualbox-cloudify-driver

Release note:

  • Compatible avec Cloudify 2.2 (ne fonctionne plus pour 2.1)
  • Compatible avec VirtualBox 4.1 et 4.2

En attendant une explication plus détaillée de l’installation du driver, voici une première version: https://github.com/fastconnect/virtualbox-cloudify-driver/issues/1

Les nouveautés de Mule 3

Mule 3 apporte un nombre important de nouveautés par rapport a mule 2.
Parmi celles-ci on retrouve principalement :

  • l’ajout de la notion de flow
  • l’ajout de Mule Studio avec un environnement de developpement graphique
  • l’ajout d’un data mapper graphique

Flow

Un « Flow » est un mecanisme simple et flexible qui permet d’orchestrer des services en utilisant les capacités sophistiquées de Mule ESB.

Un Flow est composé d’un « Message Source » et d’un enchaînement de « Message Processor ». Par rapport à l’utilisation des « Services », qui définissent explicitement les phases d’inbound et d’outbound d’un composant, ce qui limite la flexibilité, les « Flows » ne définissent rien explicitement. On peut configurer dans un même « Flow » les différentes étapes nécessaire à la résolution de la problématique et ainsi éviter d’agréger des services ensemble à l’aide des « vm transport » ou des « chaining router ».
flow_mule

Mule Studio

http://www.mulesoft.com/sites/all/themes/mulesource/images/products/xml-mule-flows.png

Mule Studio est un environnement de développement intégré basé sur Eclipse. Il permet de développer, débugger et déployer des applications Mule ESB. Il laisse le choix au développeur d’utiliser l’environnement graphique ou d’éditer les fichier xml à la main.

L’environnement graphique permet au développeur de disposer des blocs afin de créer des Mule Flows qui sont à la base des applications Mule. D’un simple drag and drop, il est possible de créer une séquence d’événement pour traiter les messages. Chaque bloc peut être configurer à l’aide d’une boite de dialogue grâce à des champs d’options.

http://blogs.mulesoft.org/wp-content/uploads/2011/03/mule-studio.png

Toutefois il reste possible d’éditer les fichiers de configuration xml à la main. Les développeurs peuvent facilement changer de mode d’édition car Mule Studio synchronise les relations et les paramètres des différents composants.
Mule Studio améliore l’éditeur xml en y apportant l’auto-complétion intelligente (listes des composants, listes des options pour un composant, …) grâce à une liste déroulante qui se met à jour en temps réel en fonction du contexte.

http://blogs.mulesoft.org/wp-content/uploads/2011/06/Screen-shot-2011-06-27-at-3.07.12-PM.png

Data Mapper

http://www.mulesoft.com/sites/all/themes/mulesource/images/products/data-mapping-capabilities.png

Mule Data Mapper est entièrement intégrer à Mule Studio

  • Transformation visuelle des données
  • Génération des meta-données à partir de schémas ou d’un échantillon de données
  • Les formats de données supportés sont XML, JSON, CSV, POJOs, and Excel
  • Des transformation plus complexes peuvent être appliquées en utilisant des règles, des recherches et des capacités d’édition plus avancée.

Bonus

La vidéo de présentation de Mule 3:

Les 5 mercenaires du Devops au Devoxx France

Du 18 au 20 avril 2012 s’est tenu la première édition du Devoxx France. A cette occasion, j’ai eu la chance de découvrir le mouvement Devops grâce à la présentation de ses 5 mercenaires que sont :

Devops est une contraction de Développeur et Opérationnel. Ce mouvement tente de réconcilier les développeurs et les opérationnels.

Malgré l’arrivé des méthodologies Agiles dans la plupart des structures, le monde des développeurs et des opérationnels reste scindé en deux. D’un coté, nous avons les développeurs qui fournissent aux opérationnels un « livrables », pendant que les opérationnels tentent de déployer le dit livrable.
Très souvent, la définition du livrable n’est pas la même que l’on se trouve du point de vue du développeur ou de l’opérationnel.
L’une des recommandations du DevOps est de définir un livrable compréhensibles par les deux parties.
Pendant la présentation, les 5 mercenaires nous montrent une forme de livrable depuis un Jenkins. Les livrables sont des packages natifs, des RPMs en l’occurrence.
Cette forme de livrable  :
  • est auto-suffisante
  • peut être facilement déployé
  • peut être rollbacké
  • est archivable
  • est configurable

Dans leur exemple, ils proposent de livrer des RPMs contenant le conteneur Tomcat ainsi que le War de l’application. Cela permet aux développeurs de maintenir une configuration du conteneur répondant aux besoins de leur application.

Une partie du déploiement de l’application peut être configurable et/ou laissée à la main des opérationnels afin de configurer les éléments dédiés aux environnements de production (mot de passe de la base de données, etc…).
Les RPMs peuvent être construits par Jenkins et mis à disposition des opérationnels sur un dépôt Maven.
Les opérationnels peuvent alors aller chercher une version spécifique du livrable pour le déployer, voir même utiliser Jenkins; ou tout autre outil de Build continu.
En allant même un peu plus loin, il est possible de configurer le Jenkins afin de déployer régulièrement l’application. Nous parlons alors de déploiement continu.
Cette approche permet
  • une meilleur entente entre les opérationnels et les développeurs
  • d’améliorer la qualité du livrable
  • d’augmenter la satisfaction des utilisateurs

Cependant, la mise en place de cette recette miracle peut rencontrer quelques difficultés :

  • Une résistance forte du au choc culturel. Toutes les structures ne sont pas prête à accepter une étroite collaboration entre les opérationnels et les développeurs.
  • Généralement, il est fortement recommandé d’avoir une application qui pratique déjà l’intégration continu. Oui, ça peut peut-être faire sourire, mais les applications qui pratiquent l’intégration continue ne sont pas aussi courantes.

GigaSpaces Document API and JAXb

I wrote this article and the plugin that ships with it last year when GigaSpaces 8.0 was released and realized that I never finally published both the sources and article so here it is!

GS8 introduced a new way to store data in a flexible manner: the space document.

Document is an evolutive object storage that allow users to dynamically add or remove properties and even dynamically add indexes on any property.

Some of my clients uses XML to model their data and where quite happy to be able to seamlessly be able to make evolve their Space object as easily (or even more easily) as their XML schema.

As this need sounded quite interesting to me I build a small plugin for JAXb that allows to generate Document compliant classes directly from your XML Schemas.

You can download the source code and test it from here: https://github.com/fastconnect/jaxb-gigaspaces

Nouveau driver VirtualBox pour Cloudify

Je travaille beaucoup avec Cloudify ces derniers temps: ce produit merveilleux me permet de déployer un cluster MongoDB ou Hadoop en quelques minutes (et pas en quelques heures ou jours…)
Je réalise pas mal de présentations sur ces sujets, avec des démos, donc j’ai besoin de créer de nouveaux clusters très rapidement.
Grâces au Cloud et aux IaaS comme Amazon EC2, je peux déployer un gros cluster avec de nombreux serveurs. Mais pour cela, il me faut une connexion internet chez le client chez qui je fait la démo: et ça, c’est mission impossible!

Cloudify permet de créer un Cloud local sur mon portable, mais cela pose quelques problèmes:

  • Je suis sous MacOS X, et certaines Recipes ne fonctionnent que sous Linux
  • Quand je créé un cluster MongoDB, et que j’utilise le même port pour chaque instances, ce n’est pas un problème si ces instances sont sur des machines différentes… mais avec le « Cloud local », j’ai des conflits de ports…
  • etc.

J’ai alors décidé de créer un vrai Cloud sur mon portable pour pouvoir faire mes démos sans connexion Internet. Ainsi, je peux simuler un déploiement proche de la réalité.
Mon portable possède 16Go de RAM, donc je peux créer plusieurs machines virtuelles (pas trop non plus, mais assez pour une démo).
Pour ce faire, j’ai d’abord essayé d’installer OpenStack, mais c’est plutôt complexe à installer/configurer, surtout sur MacOS.

En même temps, quand j’ai besoin de faire des choses spécifiques qui nécessitent un OS Linux, j’utilise Vagrant.
Vagrant est génial: il me permet de créer une nouvelle VM à partir d’un template, et la configurer à l’installation grâce à un script de bootstrap.
Pour créer les VM, Vagrant utilise VirtualBox, et ils existent de nombreuses « boxes » (template de VM, similaire à des AMI Amazon): http://www.vagrantbox.es/

En fait, je peux même créer plusieurs VM avec Vagrant, et exécuter Chef ou Puppet comme script de bootstrap…
Donc en théorie, je peux déployer un cluster MongoDB/Hadoop avec Vagrant.
Mais ce n’est pas aussi puissant que Cloudify:

  • Vagrant ne fournit pas un contexte global au déploiement, donc on ne peut pas faire de dépendances entre les services
  • Vagrant ne fournit pas de monitoring, de gestion du fail-over ou de l’auto-scaling
  • Vagrant ne peut créer des VM que sur la machine local, pas sur un serveur distant
  • Il y a plein de limitations au niveau des scripts de déploiement, c’est pourquoi Cloudify utilise Chef/Puppet, et que ces derniers ne remplacent pas Cloudify

Suite à ça, j’ai décidé d’implémenter mon propre driver VirtualBox pour Cloudify: je conserve la puissance de Cloudify, mais je peux simuler un réel déploiement (avec des VM Linux, etc.). Et surtout: je peux faire tout ça sur mon portable sans connexion Internet!

Vous pouvez trouver ce driver sur Github: https://github.com/fastconnect/virtualbox-cloudify-driver

Pour l’utiliser, il vous suffit de l’ajouter dans le « overrides package » de Cloudify (voir la documentation de Cloudify) et de configurer le driver comme expliqué dans le Readme.

Ce driver utilise le WebService de VirtualBox, il y a donc quelques prérequis:

  • Après avoir installé VirtualBox, il faut créer une « HostOnlyInterface » qui sera utilisée par les VMs de Cloudify
  • Il faut aussi configurer le WebService pour ne pas utiliser l’authentification: VBoxManage setProperty websrvauthlibrary null
  • Ensuite, démarrez le WebService: vboxwebsrv
  • Téléchargez une « box » depuis http://www.vagrantbox.es/, et placez la dans un répertoire qui va contenir toutes vos « boxes »
  • Enfin, configurez le driver. Il faut spécifier le chemin du répertoire qui contient les « boxes », il faut donner le nom de la « HostOnlyInterface », et il faut spécifier l’URL du WebService.ATTENTION: l’URL du WebService doit utiliser l’IP de la HostOnlyInterface, car elle doit être accessible par la VM qui va contenir le Manager de Cloudify

Si vous avez suivi ces étapes correctement, vous devriez pouvoir créer un Cloud « local » avec VirtualBox!

Comme le driver utilise le WebService de VirtualBox, ce dernier peut se trouver sur un serveur dédié.
VirtualBox n’est pas un vrai IaaS comme OpenStack, mais ça peut suffire dans certains cas, et vous pouvez installer une interface Web d’administration (http://code.google.com/p/phpvirtualbox/).

Lors de la réalisation de ce driver, j’ai rencontré un gros problème: je n’ai pas de serveur DNS pour mes machines virtuelles.
Ce qui veut dire que les VMs n’arrivent pas à se connaitre et communiquer entre elles.
Du coup, le driver configure la machine virtuelle juste après sa création: il configure la carte réseau, change le hostname et change le /etc/hosts.
Pour ce faire, il utilise le « VirtualBox Guests Addition », qui doit donc être installé sur les templates de VM (ce qui est le cas avec les « boxes », car Vagrant en a aussi besoin).
Avec ce « Guests Addition », un agent VirtualBox s’exécute au démarrage de la machine, et on peut l’utiliser pour effectuer des opérations comme la création de répertoires, ou l’exécution de programmes.

La bonne nouvelle, c’est que grâce à cet agent, on peut effectuer les mêmes opérations peut importe l’OS (Windows, Linux, etc.).
La mauvaise, c’est que le processus de configuration du réseau est différent suivant l’OS, et n’est pas le même sur Linux et Windows.
Pour le moment, le driver utilise des chemins et des commandes Linux (sed, etc.).
Du coup, le driver ne fonctionne que pour des machines virtuelles Linux, et il n’a été testé qu’avec Ubuntu

Le driver est OpenSource (APL), donc vous pouvez contribuer et ajouter vous même le support des VM Windows ! (et tester sur d’autres distributions Linux)

J’espère que ce driver puisse vous être utile, et puisse vous aidez à tester Cloudify sur votre poste local!
Vous pouvez trouver d’autres informations techniques sur le README sur Github:
https://github.com/fastconnect/virtualbox-cloudify-driver
Vous pouvez télécharger ce driver depuis notre repository Maven OpenSource.

Morning with MongoDB et MUG

Le 7 Novembre 2012 se sont déroulés 2 événements: le « Morning with MongoDB » et le « MongoDB User Group (Paris)« .

Morning with MongoDB

Vous pouvez retrouver les slides des présentations sur le site de 10gen.
Pour plus d’information sur l’événement, regardez ici.
L’agenda de cette matiné été le suivant:

  • Présentations de 10gen (MongoDB et BigData)
  • Présentations de cas d’utilisations des clients
  • Présentations de cas d’utilisations des partenaires (dont FastConnect!)

Je ne vais pas vous détailler toutes les présentations, mais juste quelques remarques qui me semble interessantes.

10gen ont parlé de la Roadmap, et on note les prochaines fonctionnalités pour la 2.4:

  • Intégration de Kerberos et LDAP/AD
  • Hash comme clé de répartition pour le Sharding
  • Moteur V8 pour le MapReduce
  • Recherche par intersection de polygones pour la recherche GeoSpatial
  • Amélioration du framework d’aggregation

Criteo et le Figaro on un usage commun: stocker des données de sources hétérogènes dans MongoDB grâce à la flexibilité du schéma. Pour Criteo, ils peuvent stocker dans une seule même base les catalogues de produits de plusieurs vendeurs, et pour le Figaro, ils peuvent stocker les données des différents sites web au même endroit.

Je remarque aussi un retour d’expérience qui revient fréquemment: grâce à des performances bien supérieurs aux RDBMS (dans leurs cas d’usages), MongoDB supprime la nécessité d’un cache, et la complexité qui va avec (gestion de l’eviction, mise-à-jour, etc.)

MongoDB s’avère être aussi efficace pour stocker les logs: en effet, les « Capped Collections » sont très utiles pour cet usage, et on peut choisir un niveau de « Write Concern » différent en fonction de l’importance du log (DEBUG, WARN, etc.)

Enfin, MongoDB et sa simplicité à mettre en place la réplication, sert à fournir des données à travers le monde (WAN).

Je vous laisse consulter les présentations ici, ainsi que ma présentation sur un cas d’usage MongoDB avec Hadoop:

MongoDB User Group

Ce MUG était orienté Cloud:

Nous avons eu une première présentation de la plateforme Cloud Scalr, et comment déployer et monitorer MongoDB dessus.

S’est suivie une présentation sur un retour d’expérience avec MongoDB sur le Cloud (Azure) par Pierre Couzy (Microsoft) et Yann Shwartz.
Cette session était très intéressante, car on découvre les pièges à éviter et les problèmes que l’on peut rencontrer dans des situations réelles.
J’ai beaucoup aimé cette présentation car elle recoupe beaucoup avec notre retour d’expérience avec MongoDB sur le Cloud. C’est pourquoi nous essayons de mettre en place ces bonnes pratiques sous la forme de scripts Cloudify!

Pour terminer, nous avons eu le plaisir d’accueillir Matt Bates qui nous a présenté le nouveau framework d’aggregation de la version 2.2 de MongoDB, ainsi que les futures évolutions.

Je remercie au passage les organisateurs du MUG, les hébergeurs et les différents speaker.

En conclusion, c’était une journée riche et interessante !