Ma geecon 2014 – deuxième jour

Mon deuxième jour de Geecon, le grand jour pour moi, mon slot sera à 16 h 40 dans la room 1. Mais cela ne m’a pas empêché de suivre quelques présentations dont je vous ferai le détail dans l’article. Au menu pour cette journée:

• « Deploying And testing Microservices » par Sam Newman
• « Java: Anticipating the unexpected » par Oleg Selajev
• « Microservices and REST with Spring Boot » par Josh Long
• « Deconstructing the Lambda Architecture » par Darach Ennis
• « 10 secrets to succeed when deploying in the cloud » par Séven Le Mesle.

Début de journée

Les slots commencent à 9h et je suis encore à l’hôtel, la course commence.

J’arrive juste pour la fin de la présentation de Tim Boudreau « Everything you were taught about Java is wrong ». Tim s’y attaque à toutes les idées reçues sur Java et sur la façon de programmer. Il lutte contre les beans anémiques qui s’opposent à la programmation orientée objet. N’ayant pas suivi la présentation entièrement, je n’en dirais pas plus. Je pense que je la regarderai quand elle sera publiée sur le site.

Après un petit-déjeuner, je me décide pour ma prochaine séance.

Deploying And testing Microservices par Sam Newman

Dans cette Geecon les Microservices sont partout, commençons donc par là. Sam travaille pour ThoughtsWorks en Australie. Il est en train d’écrire le livre éponyme de sa conférence pour Oreilly. Après s’être présenté, Sam nous parle des avantages des architectures en Microservices.

• Simplicité de maintenance, les développeurs peuvent faire du refactoring sur de petites bases de source 1000 lignes de code ou moins.
• Dimensionnement facile, vous pouvez dimensionner votre infrastructure aux besoins réels, par exemple augmenter le nombre d’instances de service en fonction de leur charge.
• Flexibilité technologique, tant que le contrat est respecté vos services peuvent être développés en Ruby, Java, NodeJs, tout est envisageable.
• Autonomie, chaque microservice porte ses propres fichiers de configuration, et sa base de données.

Sam nous met en garde : cela peut aussi devenir un enfer. Il en vient maintenant aux pièges à éviter.

Premier piège : Les tests, qui s’échelonnent selon la pyramide de Mike Cohn du test unitaire, au test bout en bout, en passant par le test métier. Il nous propose de définir des scopes pour tester nos microservices : small pour des tests unitaires, medium pour des tests d’intégration internes à l’application et large pour les tests du service en simulant les dépendances. Nous devons nous satisfaire de cette échelle, car les tests bout en bout sur une infrastructure complète sont très difficiles à réaliser. Ce dernier scope, très large, doit être assuré par des robots testant la production.

Pour le deuxième piège, Sam nous parle de la gestion des versions d’application. Les services dépendent les uns des autres et ils évoluent vite. La première solution est de déployer deux versions coexistantes de microservices. Mais cette méthode a tendance à dupliquer l’infrastructure complète. Une meilleure solution consiste à maintenir les versions précédentes dans les microservices en remappant l’ancien modèle vers le nouveau. Pour vérifier la rétro-compatibilité, il propose de fusionner les tests d’intégrations des microservices par groupe.

Le dernier piège concerne le couplage des services. Il faut toujours pouvoir les livrer et les déployer indépendamment. Sam nous recommande de définir un contrat REST entre le producteur et ses consommateurs. Pour rédiger ce contrat il nous propose Pact. Un outil pour définir le contrat des services REST. Pact construit un mock du service qui pourra être utilisé pour simuler le service aux clients. Selon Sam, cela permet de couvrir le scope large qu’il avait défini. Je dois reconnaître que l’idée est plaisante.

Dans la dernière partie de sa présentation, Sam nous  parlera de déploiement. Il nous propose des solutions d’infrastructures pour aller du développement à la production à base de virtualisation :

• Vagrant, pour les développeurs et les tests d’intégration, car c’est très facile à provisionner et permet de gérer des scores par service.
• Linux Containers pour la production. Cela évitera au moins l’overhead des machines virtuelles à hyperviseur.

LXC est aujourd’hui en production sur plusieurs systèmes, selon lui Docker est très prometteur mais encore trop alpha pour la production. Avec toutes ces machines virtuelles, Sam nous recommande des outils permettant de packager des images virtuelles déployables sur différents systèmes. Il utilise Packer pour créer ses images et provisionner ses machines avec Ansible. Avec Packer, les images peuvent être déployées à peu près partout : Amazon, Vmware, VirtualBox, GCE, Docker, …

Sam conclut avec un take away à retenir :

• N’oubliez pas la pyramide des tests, définissez bien vos scopes
• Trouvez la balance entre les tests et les remèdes rapides
• Déployez une chose à la fois
• Préférez les contrats orientés consommateur aux tests d’intégration
• Explorez la piste des déploiements par image pour pallier les différences d’infrastructure

Le dernier slide, « Thanks! », exactement ce que j’ai en tête, merci. C’est le moment de choisir ma prochaine présentation. En regardant le programme, je retiens « 50 new features of JEE 7 in 50 min » par Arun Gupta, et « Java: Anticipating the unexpected » par Oleg Selajev.

« Java: Anticipating the unexpected » par Oleg Selajev

Oleg travaille pour ZeroTurnAround sur JRebel, son ton est un peu hésitant.  Dans sa présentation il nous montre quelques cas limites de la JVM. D’abord il nous parle des ThreadLocal, chaque thread doit avoir sa propre instance.,Cela rappelle étrangement le SimpleDateFormat qui n’est pas ThreadSafe.  En clair pour Oleg il faut éviter à tout prix de passer par un ThreadLocal.

Je vous passerai le code récursif utilisé pour fausser la pile d’appel en catchant la StackOverflowError.

Il nous parle ensuite des cache-miss du CPU avec la bonne utilisation du cache CPU, les performances sont multipliées par 10. Oleg poursuit avec une méthode pour bloquer un fork-join pool complet. Par défaut les threads bloqués ne sont pas notifiés au pool. Le fork Join pool ne prend pas en compte le blocage et ne lance donc pas de nouveaux Threads. Oleg nous recommande alors le ForkJoinPool.ManagedBlocker, qui lui est notifié des blocages.

Son conseil suivant évitez les shallow if. Ils testent le résultat d’une méthode par exemple:

[java]if (validateNotTooHigh(x)){
x++;
}[/java]

Mais ils peuvent être facilement abusés via la stack ou une concurrence mal gérée. D’accord, dans certains contextes cela peut échouer, mais soyons honnête je continuerai à faire des shallow if. Au moins vous êtes prévenus.

Oleg continue ainsi sa présentation en nous montrant des cas limites de la JVM les NullPointers dus au cast de Integer à null, ou sur des switchs objet.

Ses conseils pour finir :

• Le compilateur est votre ami, faites attention aux warnings
• Le bytecode c’est simple, pensez à lire le bytecode pour voir exactement le plan d’exécution.

Pour ma part, je sors en me disant que rien ne m’a franchement surpris dans tout ça. Mais sachez que les slides de sa présentation sont disponibles ici: https://speakerdeck.com/shelajev/java-anticipating-the-unexpected-geecon-2014.

Je retiendrai tout de même le coup d’oeil au bytecode. Après une bonne pause déjeuner, je pars, mon mac sous le bras, pour suivre ma prochaine présentation.

« Microservices and REST with Spring Boot » par Josh Long

Josh est Spring developer advocate pour Pivotal. Très à l’aise, il commence par se faire un selfie avec la salle. Ensuite il débute avec quelques nouvelles de l’actualité Spring, la plateforme spring.io en tête.

Il se lance maintenant dans le sujet : C’est quoi les micro-services ? Une SOA en mode réduit ? Une architecture SOLID ?Pour Josh ce sont des services déployés sous conteneur linux.

Des services donc du SOAP, Josh a envie d’étrangler les gens qui trouvent SOAP simple. Les microservices ont besoin d’être simple, et de fonctionner uniquement en HTTP. La conclusion vous l’aurez compris est de faire du REST.

REST, oui, mais attention au Richardson Maturity Model. Avec Spring MVC on démarre au niveau 2 avec des ressources définies par URL et l’utilisation des verbes HTTP. C’est le moment de la séance de live coding, en commençant par générer son zip de départ avec spring initializr.
Josh va donc nous construire une application REST avec Spring Boot. Il en profitera pour parler de Spring-Data, de la nouvelle annotation @Configuration.
L’application finit par démarrer avec une datasource par défaut, un petit coup de Spring MVC et le tour est joué le service est en place.

La présentation passe des slides à l’IDE en copiant des gros blocs de code depuis la solution. Josh en vient au niveau 3 du modèle : HATEOAS – Hypermedia as the Engine of Application State. Il faut donc que les ressources se décrivent elles-mêmes avec des liens hypermedia.
En utilisant RepositoryRestResource, on atteint le niveau 3, Josh nous déroule le guide de spring.io.

Josh amène maintenant le problème de la sécurité des services. L’OAuth répond selon lui au besoin parfaitement, et cerise sur le gateau SpringSecurity le supporte.

Le service de bookmark est terminé, il peut être déployée dans le cloud sur Heroku, Cloud Foundry et Cloudbees.
La présentation touche à sa fin, j’ai bien aimé ce que j’ai vu. Mais ça me laissera un arrière-goût de plaquette marketing.

Pour ma prochaine conférence, je choisis les lambda architecture.

« Deconstructing the Lambda Architecture » par Darach Ennis

La présentation nous fait démarrer par les architecture de données, qui doivent faire la balance entre scalabilité et vitesse. Attention BigData ne concerne pas la vitesse. Cela concerne les 5v :

• Volume
• Velocity
• Variety
• Veracity
• Value

Darach nous fait un peu l’histoire du Bigdata chez Google avec la sortie de GFS en 2003. Au commencement, il n’y avait que du batch processing. Puis on a commencé à faire du streaming par incrément. Il prend exemple sur twitter qui doit vous remonter les tweets proches de vous rapidement. La solution est d’envoyer toutes les données à deux couches :

• Speed Layer, une couche rapide pour les données fraiches
• Batch Layer, la couche de batch

En bout de chaine il faut fusionner l’agrégat avec les données fraîches. Pour assurer le fonctionnement de la couche rapide, il nous recommande d’utiliser une méthode d’agrégation symbolique.
Pour finir, il nous parlera des dernières innovations chez google avec MillWheel, une solution de Stream Processing à grande échelle.

Ce que je retiendrai de cette présentation: Google mène la barque BigData, avec des années d’avance. Je sors de cette séance un peu déçu, j’ai trouvé l’ensemble trop théorique.

Je pars encore une fois avec mon mac pour ma prochaine présentation.

10 secrets to succeed when deploying in the cloud par Séven Le Mesle.

Voici les slides de ma présentation :

Fin de journée

Me voici libéré de mes obligations, je n’ai plus qu’à profiter de la keynote de fin de journée par Kevlin Henney dans la même salle.

Dans sa keynote, Kevlin nous fait comprendre que les choses ne se passent pas toujours comme on les prévoit. C’est un peu le syndrome de l’architecte tour d’ivoire. Celui qui définit une architecture idéale sans contact avec la réalité. Je retiendrai la phrase : « Aucune interface ne survit à son implémentation ! » La clé est de rentrer vite dans l’implémentation pour éviter les plans sur la comète. Les remarques font mouche, et le discours a du fond, une très bonne keynote de mon point de vue. Je vous recommande de la voir quand elle sera publiée. 

Cette deuxième journée de Geecon se termine. Dans l’ensemble les présentations étaient moins bonnes que la veille. J’ai appris des choses et j’ai passé l’épreuve du feu. Oui c’était encore une bonne journée. Le tout se finira par le dîner des speakers et quelques bières.