Le BreizhCamp, c’est une conférence du tonnerre qui a lieu tous les ans à Rennes ! Excellents intervenants, sur toutes les technologies sans aucune barrière : du .NET, du Java, du Python, du NoSQL, des méthodes, etc. Bref, le meilleur investissement en temps de formation possible… Ci-dessous quelques notes sur les différentes sessions que j’ai suivies.
Session Devops
Nicolas Ledez se définit lui-même comme un architecte Lego. Il présente une session sur le principe Devops, qui consiste à intégrer les opérationnels (admins systèmes, DBA, etc.) dans les équipes de développement, de façon qu’ils soient inclus sur le projet dès le début. Pour le conférencier, il est essentiel d’ajouter une troisième personne, à savoir l’assurance qualité.
Le principal problème de compréhension, pour lui, est que le développeur est payé pour faire du changement, alors que l’opérationnel est payé pour faire de la stabilité. Pour réduire ce hiatus, il est important d’impliquer les opérationnels dès le début du projet, et ne pas les mettre devant le fait accompli, en leur demandant de casser toute leur architecture pour s’adapter à un nouveau projet logiciel. Typiquement, qu’ils ne se rendent pas compte le jour de la mise en œuvre qu’il faut douze fichiers de configuration à des emplacements différents. Pour cela, le mieux est de sensibiliser les devs aux contraintes de la production, en les faisant par exemple participer à l’installation de leur logiciel, et ce dès les premières itérations. Nicolas Ledez parle aussi de faire du pair programming avec un sysadmin, mais j’ai un peu de mal à voir comment il peut jouer le jeu.
On revient un peu en arrière en desserrant les contraintes de mise en production, car elles n’ont pas prouvé leur efficacité pour réduire les coûts de problèmes à l’exploitation. Pour cela, on peut par exemple laisser les développeurs créer leur propre système d’installation sans tout centraliser, du moment que ça correspond aux besoins du logiciels et du client au final. Dans le cas de l’outil Capistrano, par exemple, on crée des scripts atomiques pour réaliser des opérations a distance.
Un outil comme Vagrant est très adapté aux approches Devops. Il permet de piloter Virtual Box avec Ruby, et de créer ainsi dynamiquement des machines virtuelles pour les besoins de tests de déploiement, voire même la gestion élastique de ressource. C’est un Git qui centralise les settings nécessaires. Une démo achève de convaincre que cet outil pourrait nous amener à de fortes améliorations de productivité sur nos installations. A tester, donc… Pour cela, on se place dans un répertoire, et on fait un vagrant init pour créer le fichier de conf, qui sera modifié pour pointer sur l’image voulue, et ensuite on lance vagrant up pour démarrer la machine. Il y a d’autres outils avancés : Vagrant provision pour lancer une recette Chef sur la VM, Guard pour relancer les tests lors de la modofication des fichiers (permet donc de ne pas avoir à relancer à chaque fois les tests à la main).
L’amour est dans le graphe
Session très intéressante sur les bases de données NoSQL orientées graphes, et en particulier Neo4J dans notre cas. L’explication est faite par une personne qui a travaillé sur un projet pour Meetic, et qui consistait à parcourir des graphes de relations entre les personnes, afin de proposer des rencontres avec des personnes en fonction d’affinité supposée. Typiquement, si MEC1 s’est mis en relation avec GIRL1, on peut retrouver tous les MECx qui ont aussi contacté GIRL1, puis montrer à MEC1 la liste des autres filles que ces MECx ont également contactées (en éliminant les doublons, et bien sûr GIRL1, que MEC1 a déjà draguée contactée).
Il y a deux grosses difficultés qui sont levées par la base de donnée spécialisée dans le graphique. Déjà, un problème de performance : si on parcours la liste des GIRLx après avoir bouclé sur MECx, qui lui-même vient d’une boucle sur GIRL1, et encore au-dessus un niveau de boucle pour trouver GIRL1 qui n’était certainement pas la seule contactée par MEC1… Bref, combinatoire exponentielle et à peu près aucune chance de ne pas saturer un serveur avec le nombre d’entrées sur Meetic. Neo4J, par contre, travaille uniquement avec des nodes de graphes en mémoire, ce qui permet de traiter des milliards de connexion.
L’autre fort intérêt d’utiliser une base de données orientée graphe est qu’elle fournit une grammaire d’interrogation super concise. Imaginez faire le scénario décrit plus haut avec une réquête SQL. Pas facile à faire… Tandis qu’avec le langage Neo4J, il suffit d’écrire MEC1 -contacte-> GIRL(*) <-contacte- MEC*) -contacte-> GIRL(*). Du coup, ça s’explique encore plus facilement qu’en français. La grammaire ” -relation->” permet de décrire le sens de la relation et son type de restriction. On peut également écrire ” <-> ” pour requêter par rapport à tous les types de relations possibles entre les entités, etc. Bref, un langage extrêmement concis et puissant pour faire des requêtes sur les graphes d’objets.
Plénière jour 2
La keynote était réalisée par deux anciens de chez Google, sur le sujet de la veille technologie entre autres. Entre boulimie de techno et rétrograde, ils recommandaient de réaliser chacun son propre radar techno, en méthode Hold Assess Trial Adopt.
Google Trends pour suivre des technos ou autre. Astuce : rajouter tutorial comme mot clé pour voir l’adoption effective d’une technologie.
Cloud patterns
Une des sessions les plus dynamiques (grâce à Nicolas De Loof, le dictateur en chef de l’organisation BreizhCamp, complètement déjanté) et qui a porté bien des messages qui résonnent à mes oreilles, et me font dire que décidément, tout le monde va vers la servicialisation et les architectures de type SOA.
L’idée était de faire voir des bonnes pratiques qui émergent des premières années de mise en place des technologies Cloud. Ca porte bien sûr sur le déploiement, le versioning, mais aussi le développement, l’architecture, etc. Une mine d’information. Les conférenciers commencent par citer quelques outils dont ils ont un usage grandissant, comme Yslow, Google Page Speed pour la gestion de la performance, et Mongo Gridfs pour le stockage centralisé.
Ensuite, une des recommandations principales, et qui s’applique parfaitement à nos propres produits, à savoir de tout faire en stateless : pas de session, pas de cache, et attention aux frameworks en dessous qui en font. Une fois que tout ceci est sécurisé, on facilite non seulement le parallélisme, mais aussi la montée en charge, le déploiement, etc. Pour Nicolas, l’élasticité promise par le Cloud ne peut être pleinement réalisée qu’en mode stateless.
La deuxième information importante est que “SOA : this time it is for real”. Bref, après des années de fausses annonces, de prévision de SOA-isation du marché, d’outils prétendant que faire du SOA pouvait se gérer par une simple installation d’un middleware, nous arrivons enfin dans un monde où les mises en production se basent sur SOA pour améliorer effectivement le service rendu. Adoption par pragmatisme, donc large, plutôt que réservée aux précurseurs. La diapo associée était la suivante :
Après une explication sur le mode de déploiement habituel, les présentateurs montrent cette architecture qui est en train d’apparaître, et qui par un bus ESB de type RabbitMQ, permet de mieux gérer les déploiements élastiques en séparant les serveurs Front End et Back End. Cela permet une recette séparée, une meilleure élasticité, et une meilleure utilisation des ressources. Sans compter les avantages en termes de débogage. Nicolas ne tarissait pas d’éloges sur ce mode de développement, qui simplifie fortement la vie de l’administrateur système qu’il est.
La suite aurait pu être enregistrée pour être diffusée à tous les développeurs de France et de Navarre : un service web, ce n’est pas du WSDL, mais un vrai service externe utilisable en grille. Ce mode permet de ne plus avoir peur de toucher à un morceau de l’installation car on est à peu près sûr de l’absence d’impact sur un autre (sauf dépendance, bien sûr). Enfin, Nicolas insiste sur la nécessité de passer à ce genre d’architecture dès maintenant pour les nouveaux développements, car la réintégration après coup est difficile.
Et de conclure avec une slide présentant la bible de l’intégrateur, à savoir le bouquin sur les EIP que j’essaie de forcer tout le monde à lire ! Ca fait plaisir 
Une bonne pratique pour garder des environnements les plus propres possibles : utiliser les variables d’environnement système pour la configuration. En effet, elles ne forcent pas à faire des fichiers, sont accessibles depuis tous les processus, et sont faciles à changer au lancement par un script. C’est une idée en provenance de 12factors.net.
Pour faciliter les migrations de version de bases de données, les intervenants recommandent Liquibase ou Rails Migration. Le premier est apparemment assez générique (contrairement au second, uniquement pour Ruby on Rails). J’y reviens un peu plus bas, vu que je suis allé voir une session dédiée.
Le blue / green deployment est ensuite montré : il s’agit d’alterner production et pré-production comme on le fait sur Azure, par exemple, en changeant simplement les adresses IP virtuelles. Cela permet de préparer une pré-production tranquillement, de la recetter, et en un seul instant, de basculer la production dessus. La production ancienne devient alors le nouvel environnement qui servira pour la pré-production du prochain changement de version. Ceci a également un avantage pour faire de la réversion, et revenir à l’environnement précédent en cas de problème. Evidemment, si on ne gère pas les duplications de messages entrants, il faut gérer la mise à jour des bases de données, ou être dans un cas où l’on peut se permettre de perdre quelques enregistrements (serveurs de logs, etc.). Toujours pour la base de données, on peut faire une migration en deux étapes comme pour la prévalence (ou comme expliqué dans le bouquin “refactoring database”). La conférence explique ensuite le Canari Release, le A/B testing (voir qui réagit mieux aux nouvelles features, et augmenter tel ou tel déploiement en fonction des résultats). La notion de “Pretotype” est expliquée : créer la face visible d’une feature sans rien derrière. Il faut alors utiliser le cloud comme volant d’ajustement. Ce qui est stable est un volant de test en continu, il faut juste héberger les différentes solutions.
Nagare
Nagare.org, pour voir ce framework web écrit en Python, et à base de continuation, à l’opposé du consensus MVC Framework.
En particulier, Nagare prend l’approche statefull avec du memcache derrière pour rendre la clusterisation possible. Perso, ça me paraît extrêmement hasardeux, et les démos ne m’ont pas rassuré. Peut-être conceptuellement intéressant, mais il faut attendre que ça fasse ses preuves (10% de chance) ou que ça se plante en beauté (90%) pour savoir.
Liquibase
Comme promis plus haut, quelques détails de plus sur Liquibase. Il s’agit d’un outil de gestion de la montée en version des bases de données. Il y a aussi un générateur de SQL de mises à jour, sous la forme d’un outil simple et rapide, traitant toutes les bases, avec possibilité de migration inverse, de gestion très fine des cas de figure, y compris exotiques, etc.
En bref
Quelques informations sans aucune cohérence, mais qui peuvent avoir un intérêt :
- WinJS peut faire du XHR crossdomain
- Virtual box : VMs sans frontal visible possible
- MarkdownConverter pour transformer automatiquement le contenu MD d’un div en HTML
- Return this dans les méthodes pour faire du fluent
- CQRS est pratique pour découpler la montée en version de la base. Côté modification, le cycle de vie est couplé a l’appli, et de l’autre, il est couplé aux clients de consommation, voire à n clients.
Conclusion
Encore une fois, des conférences extrêmement intéressantes, avec plein de bonnes idées originales, et qui permettront de gagner du temps sur plein de questions lorsqu’elles se présenteront.
Le point fort des conférences restant bien sûr la présentation des patterns de Cloud, qui insiste à fond sur la nécessité de servicialiser. Ca fait plaisir de voir son cheval de bataille mis de plus en plus en avant
