La 4ème édition de Devoxx France s’est déroulée du 08 au 10 Avril dernier au Palais des Congrès de Paris.
Ce fut une nouvelle fois un grand succès servit par une organisation irréprochable.
Présents côté speakers et côté spectateurs, nous vous proposons un retour sur les présentations qui nous ont marquées.
Vous aurez, d’ici quelques semaines, tout le loisir de les visionner sur la chaine dédiée de Parleys et pourrez, nous n’en doutons pas, approfondir les notions que nous allons aborder dans cet article.
Ce retour sera découpé en deux parties:
- Nos coups de coeur ;
- nos favoris; comprendre les présentations desquelles il y a un ou plusieurs petits trucs à retirer.
Les premiers feront l’objet d’un résumé détaillé tandis que les secondes vous donneront un aperçu plus court du sujet.
Nos coups de coeur
Changing the wheels of a moving car (Conference)
Nicolas De Loof, architecte chez Cloudbees, est venu nous présenter un riche retour d’expérience sur cette startup qui, en quelques années, est devenue un acteur important du as-a-Service.
Le contexte
Cloudbees s’est longtemps positionné comme un fournisseur de PAAS avant de compléter et de recentrer son offre autour du build-on-demand via Jenkins.
Cet outil est pour le moins particulier :
-
il dépend fortement du file system et de l’API liée ;
-
il existe environ 1200 plugins à gérer ;
-
une application peut faire n’importe quoi, un build fait n’importe quoi !
La mutation
Son succès ne se démentant pas, l’équipe technique a entamé une longue mutation d’un état décousu à un système bien rodé.
En 2010, leur service reposait sur :
-
des nœuds de builds isolés, recyclés entre plusieurs builds ;
-
des pools de machines de builds avec un GC Mark & Swap ;
-
des snapshots des builds précédents.
2 ans plus tard, le système d’information s’articulait autour :
-
de LXC pour l’isolation des builds ;
-
d’un pool de machines via des conteneurs avec snapshots et affinité pour un serveur chaud (i.e. lancer les builds liés sur une même machine).
La transition a été menée de manière douce :
-
feature toggles ;
-
rollout par tranches de 10%, 50% ;
-
rollout par typologie d’utilisateurs (comptes freemium) ;
-
rollout par remplacement naturel des serveurs.
Ce dernier point est primordial car, chez Cloudbees, terminer un serveur est une action quotidienne. Tout remplacement se fait via ce biais :
- mise à jour d’OS ;
- patch de sécurité ;
- serveur fatigué ;
- chaos monkey.
Les services sensibles sont gérés via la technique dite du Blue/Green deployment.
Les bonnes décisions et leçons apprises
Certains choix sont au départ des hacks et s’avèrent par la suite être judicieux et deviennent des core platform values. C’est le cas chez Cloudbees pour la terminaison de serveurs à tout va ainsi que pour la mise en place d’une application REST en façade des services EC2 et d’un simulateur des Amazon Web Services (AWS).
Enfin, Nicolas a souligné 5 éléments essentiels dans la réussite de Cloudbees :
-
Open-Sourcing : ouvrir son code, c’est obtenir des feedbacks rapides et parfois même les corrections prêtes à être intégrées. Ce fut le cas pour l’image Docker embarquant Jenkins.
-
Continuous Delivery : le coût d’un changement est fonction de l’écart entre les déploiements. Livrer souvent et par petits incréments, c’est réduire ce coût et les risques liés.
-
Near-to zero downtime : si une interruption est assez courte, l’utilisateur se plaindra sûrement de sa connexion et ne se rendra même pas compte du déploiement. Ne visez pas le zero-downtime à tout prix !
-
Communication : ne cachez pas vos interruptions de service ou changements, soyez transparents sur vos échecs et expliquez vos actions. C’est une marque de compétence fortement appréciée par vos utilisateurs.
-
Monitoring : il existe un réel besoin d’outils perspicaces afin d’identifier la bonne personne à informer en fonction du problème constaté. Il est important d’identifier les évolutions des indicateurs à plusieurs niveaux :
-
Check engine (healthcheck) ;
-
notifications, alertes ;
-
analytics.
-
Note : Nicolas a beaucoup misé sur sa tenue et nous tenons à l’en féliciter.
Savoir faire le deuil de son code (Quickie)
Dans ce format court, Ellène nous aide à comprendre qu’il existe de fortes similitudes entre la vie de développeur et la vie privée. Ainsi, les étapes d’un deuil, quelqu’il soit (disparition, rupture, etc.), sont applicables à notre code lorsque survient un bug, en production de préférence.
Ces étapes sont au nombre de sept :
-
Etat de choc/déni : c’est une défense de l’esprit, aucun raisonnement n’est alors possible.
-
Douleur et culpabilité : on cherche un moyen de compenser l’erreur commise, le plus sale soit-il.
-
Colère : c’est un sentiment ressenti face à l’injustice, qui peut nous pousser à rejeter la faute sur les autres.
-
Marchandage : c’est la chasse aux sorcières ; il nous faut un responsable !
-
Dépression/douleur : le bug est accepté mais l’on n’est pas en mesure d’y faire face ; on se trouve dans un état passif et l’on souffre.
-
Reconstruction : on cherche des activités pour s’échapper, on demande de l’aide, on trouve des solutions plus propres.
-
Acceptation : on se projette dans le futur ; les réalités de la vie sont enfin acceptées.
Dans beaucoup de cas, certains développeurs s’arrêtent à l’étape 5 ce qui peut engendrer des abandons de carrière voire une démotivation qui se retrouve tôt ou tard dans la qualité du code produit.
Pour faire face à la douleur, il est donc nécessaire de comprendre ces étapes. Il s’agit d’éviter les décisions radicales prises sous le coup d’une émotion. Il faut apprendre à parler, à se confier afin de laisser retomber les sentiments et de pouvoir agir rationnellement. Enfin, il s’agit de ne pas prendre les choses trop à cœur ou trop personnellement. Il ne s’agit pas de vous, il s’agit de votre code (cf. la carte Xebia Essentials « No Blame But No Mercy »).
Tolérance aux pannes avec le Circuit Breaker Pattern (Quickie)
Nombreuses sont les applications qui, aujourd’hui, doivent s’interfacer avec des services externes. Avec l’avènement des conteneurs (mais pas que !), la scalabilité n’est désormais plus un rêve lointain. Mais pour être scalable, il faut être tolérant aux pannes. Or, on ne peut prétendre stabiliser des services dont on n’a pas la charge. Que faire si ces derniers, par exemple, ne tiennent pas nos pics de charge ?
Les conséquences en cas d’indisponibilité sont subies et désagréables :
-
gaspillage des ressources (CPU, mémoire) ;
-
appels plus longs car souvent bloquants (timeout) ;
-
cascading failure : la chute d’un service entraine la chute d’autres qui en dépendent.
Pour faire face à ce type de situations, Mouhcine Moulou (société Soat) nous a présenté le Circuit Breaker Pattern. Son crédo : s’il faut échouer, alors échouons vite ! Il agit en fait comme un disjoncteur entre le service appelant et le service appelé.
Par défaut, le Circuit Breaker est fermé ; les requêtes sont donc possibles. Si certains critères sont atteints (erreurs, temps de réponse), alors il est ouvert et plus aucune requête ne passe, évitant ainsi les désagréments évoqués précédemment.
Après un certain temps, le Circuit Breaker repasse dans un état semi-ouvert ; il laisse passer un ou quelques appel(s) afin de déterminer la santé du service. Si le service est de retour, le Circuit Breaker repasse au statut fermé. Sinon, il redevient ouvert.
Ainsi cette solution permet :
-
des temps de réponses rapides, même en cas d’erreur ;
-
un meilleur usage des ressources ;
-
une diminution des cascading failures ;
-
un monitoring plus aisé, puisqu’à poser sur le Circuit Breaker.
Plusieurs implémentations sont disponibles, notamment en Scala & Java via Akka, où subsistent néanmoins quelques inconvénients.
Le Continuous Merge chez LesFurets.com (Conference)
Arnaud Pflieger est venu nous présenter la manière dont a été mis en place le Continuous Delivery chez LesFurets.com, célèbre comparateur d’assurances.
Lorsque l’on parle de Continuous Delivery (voir cette présentation d’Axel Fontaine sur le sujet), on pense souvent au modèle TBD (Trunk Based Development/Deployment/Delivery). Le principe est simple ; tout se passe sur la branche master (ou trunk). Chaque commit donne lieu à un build, à toute une batterie de tests automatisés et in-fine, à un déploiement. Or, selon Arnaud, ce modèle possède quelques inconvénients :
-
le volume des tests automatisés requis pour s’assurer un déploiement serein est important. Une mise en place incrémentale est donc difficile ; tout doit être prêt pour la première MEP ;
-
idem avec l’automatisation des déploiements ;
-
le nombre de feature toggles devient vite important et atténue la maintenabilité de l’application.
Si l’on peut être plus ou moins d’accord avec ces constatations, toujours est-il qu’elles ont poussé LesFurets à partir sur un modèle à base de feature branches, où l’une des règles principales est que personne ne commite dans le master. Quelques statistiques les concernant :
-
1 MEP par jour ;
-
entre 3 et 10 feature branches par MEP ;
-
entre 40 et 70 feature branches en cours.
Arnaud nous avoue que l’équipe a longtemps planché sur la technique a utiliser pour réconcilier toutes ces branches sans retomber sur le modèle TBD. Pour ce faire, LesFurets ont développé un script qu’ils ont par la suite publié en Open Source ; git octopus.
Octopus se charge de fusionner plusieurs branches en une seule, en se basant sur la commande git merge. Les branches à fusionner peuvent être filtrées selon un pattern particulier, par exemple, toutes celles commençant par feature-. La branche résultante est systématiquement recréée à chaque fusion ; elle ne possède donc toujours qu’un seul commit. En se basant sur cet outil, LesFurets ont mis en place le workflow suivant :
Tout développement donne lieu à une nouvelle branche en local (ticket-x), tirée depuis master. Une fois ce dernier terminé, la branche est poussée vers le repository features où Octopus passe régulièrement pour fusionner toutes les branches de cet environnement. Cela permet de lancer la batterie de tests automatisés sur le résultat de la fusion. Les branches qui sont alors souhaitées en production sont poussées sur le respository releases où, là encore, Octopus se charge d’en faire la fusion (en incluant la branche master) et de lancer la batterie de tests (automatisés et manuels) sur le résultat. Si ces derniers sont satisfaisants, alors l’unique commit de la branche octopus-releases est fusionné à la branche master.
Bien évidemment, les conflits peuvent surgir lors de la fusion des branches et dans ce cas, Octopus démarre une phase de diagnostic. Il va tenter de fusionner chaque branche individuellement avec la courante afin de déterminer laquelle est en conflit.
Note : ce processus de détection n’est pas sans faille ; voir le site de git octopus pour plus de détails.
Dans tous les cas, une résolution manuelle est nécessaire. Chez LesFurets, cela consiste le plus souvent :
-
à retirer des branches non-indispensables (refactoring, reformatage) ;
-
à sortir temporairement la branche fautive de la fusion ;
-
à positionner une branche devant l’autre (via un
git rebase).
En conclusion, nous avons pu nous apercevoir qu’il était possible de faire du Continuous Delivery sans faire de TBD, ceci permettant de maitriser plus sereinement le rythme des MEP. En revanche, quelques inconvénients sont à noter :
-
une (très) bonne maîtrise de
gitest nécessaire ; -
la gestion des conflits représente le SPOF (Single Point Of Failure) de cette méthode et peut donner lieu à la réécriture d’un historique partagé ce qui est très souvent déconseillé ;
-
la méthode s’applique très bien à une application monolithe, beaucoup moins à une architecture micro-services.
En tout cas, LesFurets ont fait preuve d’une belle transparence dans leurs choix, bons comme mauvais et nous ont offert là un nouvel élément pour atteindre le Continuous Delivery.
Nos favoris
De l’API au protocole (Conference)
Dans une conférence d’une richesse rare, Geoffroy nous invite à nous interroger sur l’usage que nous faisons des protocoles afin de bâtir nos API. Il souligne l’importance de mesurer l’adéquation des technologies utilisées avec le contexte dans lequel on se trouve. Selon lui, il nous faut choisir plutôt que subir les choix des autres. Si, par exemple, vous ne jurez que par REST/HTTP/TCP et détestez SOAP/CORBA and co., attendez-vous à être sacrément secoués dans vos convictions. A ne manquer sous aucun prétexte.
Unit testing concurrent code (Quickie)
Dans ce Quickie, Rafael se propose de résoudre un défi loin d’être simple ; tester un code concurrent en étant le plus déterministe possible. A travers une série d’exemples, il nous présente les outils existants pour ce faire (TestNG, ThreadWeaver, jcstress), leurs fonctionnements, leurs points forts et les pièges dans lesquels ils peuvent nous faire tomber (ah, sacré Java Memory Model!). Une présentation constituant un bon point d’entrée pour quiconque souhaite s’intéresser au sujet.
Uniformisez vos postes de développement avec Fig (Quickie)
A travers un aperçu de Docker Compose (Fig ayant passé l’arme à droite depuis), Etienne nous propose une solution simple pour unifier et accélérer l’installation des postes de développement. Il revient sur les principes mis en œuvre (orchestration de conteneurs), sur la configuration pour ce faire (fichier YAML) ainsi que sur les avantages obtenus. Il livre en complément quelques astuces pour éviter les pièges les plus simples, comme par exemple, le partage du repository Maven pour ne pas tout recharger à chaque lancement. Une présentation efficace et applicable dès le lendemain pour se faciliter la vie ainsi que celles de ses collègues.
API asynchrones en Java 8 (Conference)
Outre les lambdas, streams, API Date et autres joyeusetés, Java 8 nous a également apporté de nouveaux outils pour faire de l’asynchrone. Dans cette présentation, Jose Paumard nous livre un rappel sur l’existant avant cette version et déroule la JavaDoc des classes CompletionStage et CompletableFuture (l’équivalent des ListenableFuture dans Guava). Idéal pour débuter sur le sujet, beaucoup moins si vous en êtes déjà familiers.
Les idées reçues dans l’informatique (Conference)
Dans un format conférence qui aurait gagné à être plus court, le directeur général d’Octo nous présente 8 idées reçues de l’informatique puis les contredit, chiffres et lois à l’appui.
Les sujets abordés tournent autour des livraisons, de la productivité, de la maintenance, des primes, de la localisation des équipes, de la taille des projets et du coeur de métier des entreprises.
Building fault tolerant microservices (Conference)
Dans cette conférence, Christopher nous présente les points auxquels il faut faire attention pour avoir un service qui soit tolérant à la panne. Pour savoir si votre service l’est, il n’y a pas de secret : il faut tester ! Pour cela, Christopher utilise plusieurs outils : Cucumber pour formaliser ses tests d’acceptance et Vagrant, Saboteur ainsi que Wiremock pour simuler le service tiers que doit appeler notre service à tester. En combinant tout ça, on simule facilement des réponses inattendues ou des erreurs réseaux. On peut alors prédire le fonctionnement de notre système sur ces problématiques. De la gestion des timeouts et des threads, au monitoring avec Zipkin ou Graphite, en passant par l’utilisation de librairies tel que Hystrix, vous aurez un tour d’horizon complet des solutions qui s’offrent à vous.
Web Components, Polymer and Material Design (Conference)
L’entrée en matière de cette conférence est originale : Horacio commence par dire que finalement les Web Components ne sont pas nouveaux car Swing faisait la même chose. Quand il a quitté le monde du client lourd pour le web, il passait d’une interface utilisateur évoluée et réactive à… une jsp sans style et qui ne faisait pas grand chose. On était en 2000. Ensuite le web a rattrapé son retard avec JEE, Javascript, GWT et enfin les single page application et leur librairies comme AngularJS et sa notion de directive qui se rapproche des web components. On assiste ensuite à un passage en revue assez exhaustif de tout ce que les navigateurs implémentent ou implémenteront pour passer aux Web Components : templates, shadow DOM, elements, imports. On est rassurés car pour une fois, la standardisation ne s’est pas faite dans la douleur et on a réellement l’impression que les vendeurs voulaient coopérer.
I don’t always write Reactive applications, but when I do, it runs on Raspberry Pi (Conference)
Le sujet de l’application réactive que Mathieu et Alexandre nous présente est très sérieux : fournir à la planète entière l’application indispensable lorsque les zombies attaqueront. Ce sujet très alternatif est le fil rouge de cette présentation. On nous présente l’architecture mise en place pour faire tourner un site soumis à une charge constante durant la conférence – métriques à l’appui – et hébergée sur 7 Raspberries. C’est fou ce que ces petites machines peuvent faire tourner : Elastic Search, Cassandra, NGINX ou encore Akka Cluster. En une heure, nous n’avons évidemment pas le temps de nous attarder sur le code mais il est disponible sur github pour étudier tout cela à posteriori. Le clou de la démonstration est le débranchement de certains Raspberry et la constatation de la dégradation du service mais sans interruption franche : le réel intérêt des applications réactives.
Priming Java for Speed (Conference)
Après avoir réglé le problème des pauses du garbage collector, Gil a demandé à ses clients quel était la deuxième chose la plus ennuyeuse avec la JVM. Il se trouve que beaucoup d’entre eux se plaignaient d’un temps de démarrage peu efficace. En réalité plus que du démarrage (côté serveur, on peut faire chauffer sa JVM comme on le souhaite), c’est plutôt le moment où on sollicite dans les conditions de production une JVM chauffée qui pose problème. En effet, si on prend le cas d’un système de trading, à l’ouverture du marché, de nombreuses optimisations effectuées par la JVM (réordonnancement, suppression du code mort, des variables locales, des constantes, de l’inlining, etc.) sont annulées car les données changent et deviennent moins prédictibles puisqu’il s’agit des vraies données. Or c’est bien à l’ouverture du marché qu’on a besoin de notre bytecode optimisé. Gil nous explique donc que la stratégie de sa JVM consiste à logger toutes les optimisations avec du contexte pour expliquer pourquoi elles sont faites à l’instant t afin de pouvoir les rejouer au redémarrage d’une JVM. Plus besoin de temps de chauffe : votre algorithme a déjà une performance maximum dès l’ouverture du marché.
Conclusion
Ce retour ne saurait être complet sans la session des Cast Codeurs, enregistrée le vendredi soir et animée par Guillaume Laforge, Emmanuel Bernard, Antonio Goncalves, Arnaud Héritier ainsi que Vincent Massol. Un moment de franche rigolade, de partage et de nostalgie bien mérité après 3 jours de dure labeur.
