Devoxx France 2016 - Compte Rendu

le 13/05/2016 par Benjamin Brabant, Fabien Lamarque, Antonio Gomes Rodrigues

Encore cette année, Octo a participé à Devoxx France 2016 en tant que speaker et visiteur.

Devoxx est une conférence qui parle de Java, BigData, DevOps, IoT, Mobile, Performance... sous divers formats de conférences (keynote, university, quickie, tools-in-action, hands-on-lab).

Tous ces thématiques et formats contribuent à la richesse de l'événement.

Vous trouverez dans cet article un tour d’horizon des conférences que nous avons pu suivre et aimer.

Cette sélection vous permettra, je l'espère, de faire un choix sur les nombreuses heures de vidéos disponible sur la chaîne YouTube de Devoxx France.

Infra & Cloud

Déployez vos applications sur un cluster Kubernetes avec Ansible (Smaine Kahlouch, Antoine Legrand, Jean-Christophe Sirot)

CFP Devoxx
Ressources : Kubespray Ansible

Cette session était un Hands On Lab pour une (première) prise en main de Kubernetes, l’outil de gestion de conteneurs Google, utilisé notamment pour leur offre Google Container Engine ou encore par OpenShift. Au programme :

Déploiement du cluster
Commande de base
Déploiement d'un moteur de blog
Utilisation d'Ansible pour automatiser ce déploiement
Partager les applications avec KPM

Les speakers étant tous commiters Kubespray, on a pu toucher à quelques outils supplémentaires. Parmi eux Kargo qui offre un client consistant à “générer” une configuration ansible prête à l’emploi pour déployer son cluster Kubernetes. Également KPM, un ansible-like adapté à Kubernetes dans lequel on retrouve la gestion de l’idempotence et qui va adresser des problématiques particulières telles que la gestion de version d'images.

Kubernetes (open-source), actuellement en version 1.2 de 03/2016 facilite le passage de Docker “à l’échelle” et adresse des problématiques telles que :

l’organisation des ressources
la répartition de la charge
l’ordonnancement

Kubernetes est constitué d’un master jouant le rôle de chef d’orchestre et de noeuds qui vont héberger les services selon le plan de répartition défini.

Le master se compose de :

API Server : c’est le point d’entrée principal par lequel on va pouvoir contrôler entièrement notre cluster.
ETCD : key-value store distribué, basé sur l’algo de consensus raft, pour stocker les états.
Controller Manager : s’assure en permanence que la typologie définie est bien en place.
Scheduler Server : réalise des tâches d'orchestration, par exemple déplacer des services pour respecter la répartition des ressources définie (Work In Progress).

Les noeuds se composent de :

Container Engine : Un système de conteneur (Docker, Rocket supporté à 85%).
Kubelet : Démarre et arrête des conteneurs en fonction des demandes du master.
Proxy : Configure les règles de transfert réseau.

Pour appréhender Kubernetes, il est nécessaire d’avoir en tête les quelques notions supplémentaires qu’il apporte :

Pod : groupe de conteneurs qui partagent la même adresse IP, le même volume, etc. C'est la plus petite unité de gestion de Kubernetes.
ReplicaSet : Une ressource contenant le nombre souhaité de réplicats d'un Pod.
Service : Interface donnant accès à un groupe de Pods. Agit comme abstraction “fonctionnelle” des pods et répartiteur de charge.
Deployment (depuis v1.2, anciennement "Replica Controller") : Une description de l'état souhaité d'une application. On définit également une stratégie pour arriver à cet état (rolling update, ...).
ConfigMaps : Volume utilisé pour stocker la configuration utilisé par les pods
Secrets : Un volume dédié au stockage des mots de passe, clés ...

La Blockchain en détails (Benoît Lafontaine, Yann Rouillard)

Disclaimer : nous n'allons pas être très objectifs sur cette conférence puisque ce sont des Octos qui l'ont présenté.

Cette session au format "university" (3 heures) à l'avantage de revenir sur les concepts de base de Bitcoin, essentiel pour comprendre tous les concepts autour de Blockchain.

Dans une deuxième partie, c'est Ethereum, le projet phare du monde Blockchain, qui est expliqué (en se référant à la première partie). Et surtout, on y voit du code ! Ce qui est assez rare dans les présentations autour du sujet. On y détaille donc :

Comment est structuré un programme
Comment on upload un programme sur le réseau
Comment interagir avec un programme

et aussi un certain nombre de problématiques techniques, comme :

La gestion des versions d'un programme
la migration de données
Le coût : on paye à la ligne de code exécuté
La rapidité

Au final, si vous voulez comprendre techniquement comment tout ça marche et comment développer sur Ethereu, voici la vidéo : La Blockchain en détail (Benoît Lafontaine - Yann Rouillard)

Traefik, a modern reverse-proxy (Emile Vauge)

HAProxy et ses concurrents ont été créés il y a longtemps avant l'arrivée des :

Microservices
Docker
Mesos
Service Discovery (consul, zookeeper, etcd, eureka, …)

Ces nouveautés entrainent des infrastructures de plus en plus dynamiques et apportent de nouveaux challenges aux load balancers "classiques" tel que la nécessité de pouvoir régénérer dynamiquement la configuration. C’est pour résoudre ces difficultés que Traefik a été conçu.

Traefik est un reverse-proxy et un load-balancer dynamique implémentant le retry et le pattern circuit breaker. Il permet de construire sa configuration à chaud à partir de différents backends (Docker, Mesos/Marathon, Swarm, Etcd, Consul, Zookeeper...).

Après cette présentation, l’auteur a réalisé une démonstration de l'intégration avec Mesos et Docker. Un point qui a retenu notre attention est l'intégration de Let's Encrypt qui permet notamment la génération gratuite à la volée d'un certificat SSL pour chaque domaine. La session s'est terminée par un benchmark comparatif avec NginX, plutôt en défaveur de Traefik, mais qui montre que cette solution est tout de même déjà très performante.

Afin de répondre à la demande, l’auteur a dû créer la société Containous afin de développer à plein temps Traefik et fournir du support. Traefik a déjà acquis une certaine notoriété. Il est notamment utilisé par Cisco Cloud (MANTL) ainsi que sur Apollo de CapGemini.

Finalement, j’ai beaucoup aimé cette présentation très didactique.

Stack Overflow behind the scenes - how it's made (Oded Coster)

Oded Coster de Stack OverFlow nous a éclairés sur :

leurs outils de supervision (MiniProfiler, Bosun et Opserver)
leurs outils de communication (Google Docs, Trello, Hangout et Stack Chat)
leurs contraintes de performance et de volumétrie
leur architecture technique

D’un point de vue architecture, ils utilisent de nombreuses technologies Microsoft (IIS, SQL Server…) qu’ils complètent avec d’autres stack (ELK, HAProxy, Redis…).

Oded Coster nous a partagé leur retour d'expérience sur de grands sujets du moment. Leur infrastructure n'utilise par le Cloud dont ils n'ont pas la nécessité et qu'ils ne jugent pas assez fiable et trop cher pour leurs besoins. Stack Overflow n'utilise pas non plus de solution NoSQL (après une expérience malheureuse avec Cassandra) qu'ils ne jugent pas assez mature pour leurs besoins malgré une volumétrie supérieure à 1To. Finalement, pour répondre aux problématiques de performance,

En termes d'organisation, Stack Overflow se répartit en petites équipes d'ingénieurs expérimentés mondialement distribués.

Le tout avec un retour d’expérience :

Méthodologie de performance
Pourquoi ils n’utilisent pas de Cloud (pas assez fiable et trop chère pour leurs besoins)
Pourquoi ils n'utilisent pas de NoSQL (pas assez mature pour leurs besoins malgré une base de données de plus de 1To)
L’avantage de communiquer par oral (ici avec hangout) pour pallier aux faiblesses de la communication écrite
Les avantages d’avoir une petite équipe d’ingénieurs expérimentés et expert dans leurs domaines
Comment faire les bons choix de technologie (ce qui fonctionne le mieux pour eux et non ce qui est à la mode)

Présentation très intéressante et loin des buzz actuels qui nous dévoile comment un des sites les plus utilisés dans notre domaine est construit.

Langage & Framework

Property Based-Testing (Cyrille Martraire, Romeo Moura)

Inventée pour Haskell, démocratisé par Scala, cette méthodologie change le paradigme des tests unitaires tel qu’on le connait. Innovante, cette technique est puissante pour tester et découvrir les propriétés mathématiques de nos méthodes, ce qui va simplifier et guider le design de nos applications.

Outillage : scalacheck, java quickcheck, et d'autres pour des langages tels que f# et haskell.

Tout part du principe qu’en BDD, il ne faut pas tester des généralités, il faut des exemples concrets. Une propriété est quelque chose de tout le temps vrai. Par exemple est-ce que cette propriété est vraie ?

for all integers a,b; a+b >= a

Cette propriété est fausse, car : si b < 0, a + b < a

Le test de propriétés s’accompagne d’un fuzzer (on y reviendra) qui génère des valeurs permettant d’invalider la méthode telle qu’elle est écrite. Le framework générera donc des échantillons pseudo-aléatoires de valeurs de a et b, et vérifiera que la propriété est toujours vraie. Dans le cas ci-dessus, l’outil permet d’invalider la propriété et de la réécrire :

for any positive integers a, b ; a + b >= a Note : le signe mathématique for any est ∀.

De la même manière, le fuzzer pourra trouver des bugs, par exemple sur les overflows d'integers. Il n'est donc pas déterministe, et essaie aléatoirement une palette d'entrées. Rien ne nous dit que le fuzzer ne trouvera pas de valeur invalidant la propriété 6 mois après l’écriture d’une méthode. C'est un complément aux tests unitaires et non un remplacement.

Une autre facette du test par propriété est qu’il n’est pas nécessaire de donner des valeurs particulières.

def pricing(quantity, price) { return quantity * price; }
assertThat(pricing).isEquals(quantity * price)

À noter dans l’exemple, il y a le même code dans le test (multiplication du prix par la quantité) et dans la méthode. Et ça c'est mal.

Un test de propriété doit rester plus simple que le code qu'il utilise.

Le test et la propriété guident le design par le domain. "Est-ce que cette règle est vraie dans tous les cas? Vraiment ?" En trouvant les exceptions des propriétés au moyen du fuzzer, on explore l'espace fonctionnel plus vite.

Exemple : si on fait deux tests "une dose de 3gr de paracétamol est mortelle"; "une dose de 1gr de paracétamol n'est pas mortelle", on n’indique pas quel est le seuil, le test unitaire n’a que peu d’importance ici. La propriété équivalente (“Tout dosage supérieur à 2,34 gr de paracétamol est mortel”) serait une bien meilleure documentation vivante que 5 tests unitaires.

Une autre propriété intéressante du Fuzzer est le shrinking, dès que le framework trouve un contre-exemple, il essaie de le réduire au plus simple cas qui fait échouer le test. Dans le cas de la somme de a et b, il peut trouver a=329847, b = -10298328420 comme contre-exemple, puis afficher après l’étape de shrinking “a=5, b = -10”. Pour conclure sur le fuzzer, c'est la sérendipité, et peut permettre de prévenir de plus de bugs qu’un test unitaire.

Il y a des cas de redondance de données (prix d'achat, prix de vente, marge; on en connait 2, on trouve le troisième). En rédigeant la propriété, on peut mettre en avant une incohérence qui serait ici la dépendance entre ces trois variables.

De la même manière les tests suivants ne sont pas tellement explicites:

assertToxic(mix(jusdepomme, poison));
assertToxic(mix(jusdorange, poison));
// -> OSEF du fruit

La propriété équivalente (qui se sert de types) serait plus utile:

assertToxic(mix(anyJuice, poison))
//-> on a une propriété

La plupart des propriétés intéressantes sont à un plus haut niveau architectural, quelques exemples de propriétés:

tokenize, then append -> identité

serialize, then deserialize -> identité
read A, write B, read B -> A == B
create, exist. -> Cette propriété n'a que peu de valeur, c'est trop bas niveau.
sort(List) == sort(sort(List)); c’est l’idempotence du tri.
sorted list, remove() -> still sorted
list , sortedList -> same content, same size.

Comparer des fonctions est facile en propriété, il permet de faire un oracle et de refactorer du code:

compare brute force vs algo optimisé
compare list vs set
parallel threaded vs single threaded
approximate vs exact (10/3 = 3.33 + 3.33 + 3.34),

Les propriétés sont devinées, mais ne sont pas absolument vraies, c’est intéressant de travailler en se disant qu’un test vert ne donne pas d’information, le test en question peut très bien échouer dans 6 mois quand le fuzzer tombera sur un cas limite. Un test rouge vous donnera au contraire de nombreuses informations sur la manière de refactorer votre code.

NB: la détection de fraude est un gros client de property-based testing -> ça permet de lever beaucoup d'anomalies.

la-quête-du-graal.js (Siegfried Ehret, Romain Maton)

CFP Devoxx

La présentation commence par le constat que tous les ans un nouveau framework JavaScript arrive sur le marché que beaucoup de développeurs sautent dessus. Ce qui donne l'impression qu’une application de moins de six mois est déjà legacy.

La méthode de comparaison pour la suite de la session nous est présentée.

Les auteurs passent en revue un grand nombre de frameworks (JQuery, Backbone, Ember, Angular…) en décrivant :

L’historique de framework
Leurs points forts
Leurs points faibles
Leurs avis

À la fin de la présentation, les auteurs donnent leur préférence (Ember) et des points communs de certains des frameworks.

Une explication sur le nombre élevé de frameworks est avancée (“Car les géants se battent entre eux pour gagner des devs”).

À mon avis il y a trop de frameworks présentés en si peu de temps pour un développeur non front. Ce que je retiens est qu’il y a beaucoup de frameworks et que la plupart sont encore maintenus et que donc il n’est pas forcement nécessaire de changer de framework tous les 6 mois.

Les slides sont disponibles sur https://dev.ehret.me/la-quete-du-graal.js/#/

Pourquoi Maurice ne doit surtout pas coder en go. (Jean-Laurent de Morlhon)

Jean-Laurent de Morlhon développeur Java expérimenté nous a fait, au cours de cette session, un retour d’expérience sur son apprentissage du langage Go. Go est notamment le langage choisi par Docker pour sa compilation statique au runtime. Go construisant ses artefacts sous forme de binaire, ceci rend son installation très facile, mais engendre par contre une certaine lourdeur de l'exécutable (Hello World ~ 2Mo, Application Server ~ 7Mo).

Le langage assez bas-niveau est simple, efficace et permet une gestion fine de la mémoire, des processus, du wait sur les I/O, etc. Le code est relativement verbeux, mais se lit aisément ce qui est appréciable. À l'inverse ceci apporte quelques lourdeurs dans certaines écritures telles que la gestion des erreurs. Par contre l'absence d'héritage, de généricité ou d'idiomes fonctionnels (hormis fold & map) peut dissuader certains développeurs à se jeter dans le bain.

package main
import "fmt"
func main() { fmt.Println("Hello World!") }

L'outillage de l'écosystème Go est assez riche, mais est assez rustique et présente tout de même quelques limites. L'écriture d'un mock par exemple nécessite de recréer une interface et d'écrire une classe qui l'implémente. Parmi les outils, on compte :

gotest : outil standard de test unitaire fourni avec go
goget : outil qui télécharge les bibliothèques externes et les rajoute sur le GO_PATH, avec vos propres sources
godep : liste les dépendances et les récupère en les dupliquant dans le GO_PATH et le dossier vendor
gofmt : permets de formater le code source
golint : vérifie le bon respect du style de code
govet : reporte les potentielles erreurs commises dans l'utilisation du langage

Performance

Pourquoi il ne suffira pas de faire du HTTP 2.0 pour faire des applications performantes... (Cyrille Dupuydauby, Raphaël Luta, Thomas Pierrain)

Une session University très interactive (https://twitter.com/raphaelluta/status/722902759406575617) où on a pu (re)découvrir l’intérêt de la couche TCP sur un réseau potentiellement non fiable. Nous sommes embarqués dans l’investigation d’un problème de performance (23.742 secondes de temps de réponse en moyenne :o) sur une application Web PhP “classique” interagissant avec de nombreux backends en RPC, SOAP, REST et MoM.

Quelques points clés à retenir :

Face à un problème de performance, avant toute chose commencer par mesurer. Attention au biais qu’apporte la moyenne (surtout en cas de valeurs hautes atypiques), préférer les percentiles.
Pour un navigateur, 70% du temps passé l’est dans les interactions réseaux (d’après un benchmark Google sur Blink). Chercher à optimiser en premier lieu le JavaScript, le DOM ou les styles sera souvent contre-productif.
Pour une page web, la bande passante, sauf s’il elle est très faible (< 3Mbps) n’aura que peu d’impact sur les performances. La latence, elle, a un très fort impact. À noter que sur les 20 dernières années la bande passante a augmenté 1000 fois plus vite que la latence n'a diminué.
La latence du réseau est le facteur limitant de la performance Web. HTTP 2 améliore la performance sur les réseaux lents, mais nécessitera quelques adaptations de l’application pour en maximiser les bénéfices.

Raphaël nous a présenté de façon très didactique le fonctionnement du protocole HTTP 2. Il faut savoir qu’il se distingue en deux implémentations :

H2 : implémentation la plus répandue au-dessus de HTTPS (TLS 1.2)
H2C : implémentation encore controversée HTTP (TCP en clair)


HTTP 1.1	HTTP 2
Mode requête-réponse	Connexion TCP unique
Synchrone,	Asynchrone
Parallélisme limité (6 connexions TCP/domaine ouvertes par le navigateur)	Parallélisme inhérent au protocole (assets obtenus en concurrence par le navigateur)
Protocole Textuel	Protocole Binaire
METHOD/HEADER/BODY (+ variations selon les méthodes)	Format simple : HEADER/BODY
	Encapsulation HTTP 1.1

L’arrivée de HTTP 2 ne va pas rendre magiquement une application web performante. De manière générale, toute optimisation qui va permettre de réduire la quantité de données transitant par le réseau est bonne (activer la compression des données, minifier les scripts, minimiser le poids des images). Par contre celles qui consistaient à réduire le nombre de requêtes en HTTP 1.x sont à bannir en HTTP 2 (inliner les petits contenus, concaténer les scripts, créer des sprites).

Cette présentation, pour les plus novices, permet d’appréhender très concrètement le challenge qu’a la couche TCP de transmettre de manière fiable de l’information sur une couche physique non fiable. Elle nous a également apporté des tweaks réseau concrets à réaliser sur son système Linux ainsi que des outils pour simuler latence et perte de paquets de la couche TCP; à retrouver dans le support de présentation. Si les développeurs ne devaient retenir qu’une chose : ne jamais considérer qu’une application fonctionne de manière performante sur le réseau LAN sans la mettre à l’épreuve sur le réseau WAN (ou au moins le simuler).

Le réveil de la Thread (David Shay)

Session sur les anti patterns et leurs solutions lors de la construction d’applications multi-threadées.

L’auteur nous explique progressivement une succession de patterns (1 thread par couche, utilisation de queue, mise à jour sélective, merge des données, batch…).

Lorsque cela est possible, il nous donne la méthode Java à utiliser (newSingleThreadExecutor…).

Session intéressante, mais malheureusement trop courte si on connaît déjà un peu le domaine.

High-Performance Hibernate (Vlad Mihalcea)

Vlad Mihalcea (Hibernate Developer Advocate) nous présente comment utiliser de manière optimale Hibernate.

La session démarre sur une citation de l’éditeur d’APM AppDynamics précisant que plus de la moitié des problèmes de performance d’une application proviennent de la base de données.

Puis avant de rentrer dans le vif du sujet, Vlad Mihalcea nous explique comment il calcule le temps de réponse d’une exécution d’une requête à la base de données.

Après cette rapide mise en place, on passe en revue tous les concepts d’Hibernate :

Connection providers
Identifier generators
Relationships
Batching
Fetching
Caching

Le tout avec :

Des benchs pour démontrer les gains de chaque optimisation
Des conseils applicables directement
Des exemples de configuration.

Présentation intéressante, mais qui aurait mérité d’être plus longue afin d’aller plus loin pour ceux qui connaissent déjà bien Hibernate.

Les slides sont disponibles sur http://fr.slideshare.net/VladMihalcea/high-performance-hibernate-devoxx-france

Outils

De Jenkins Maven/Freestyle à Pipeline (Adrien Lecharpentier)

Dans ce Tools In Action, Adrien de Cloudbees nous a présenté le plugin Jenkins Pipeline qui offre une DSL pour décrire une construction de projet (v1.0 25/11/2014 | v2.0 05/04/2016). Dans une utilisation classique de Jenkins, il va falloir créer des jobs manuellement et généralement plusieurs jobs par artefact (build, test, déploiement ...). Avec le plugin Pipeline, il va être possible de développer avec un DSL groovy un workflow complet de déploiement continu. Ci-dessous un aperçu de la structure du script :

stage 'Build' { node('maven') { // build maven } }
stage 'Test' { node('docker') { // build container // run integration test } }
stage 'Validation' { // ask user for confirmation }
stage 'Publish' { // Push container in docker registry try{ unput publish it } finally{ docker.withRegistry('truc') } }

Ce script va pouvoir être configuré dans un job défini à cet effet dans l’IHM Jenkins. Mais bien plus intéressant, il va être de pouvoir versionner cette configuration avec le code source de l'application. Une fois le job Jenkins adéquat configuré, un système va scanner le dépôt Git pour détecter les fichiers de configuration “Jenkins pipeline”. Chaque branche comprenant un fichier de configuration “Jenkins pipeline” va automatiquement déclencher la création d'un nouveau "sous-job" portant le nom de la branche. Ce dernier va être exécuté à chaque nouveau commit et sera détruit si la branche vient à disparaître.

Apache Maven, Java 9 et le projet Jigsaw (Hervé Boutemy, Arnaud Héritier)

Arnaud Héritier et Hervé Boutemy, contributeurs au projet Maven, nous ont présenté l’avancement de l’intégration des évolutions (essentiellement Jigsaw) apportées par Java 9 (release prévue en avril 2017) à Maven. Java 9 est compilé en version 8 (52.0) actuellement ce qui va être corrigé pour passer à 53.0.

Les speakers ont passé en revue quelques nouveautés que va apporter Java 9 :

[JEP 223] New Version-String Scheme : la numérotation des versions change à partir de Java 9 qui sera véritablement la version 9.x.x et plus 1.7.0_27
[JEP 224/225] New Javadoc Style : un nouveau champ de recherche a notamment était ajouté à la Javadoc désormais compatible HTML5/CSS3 !
[JEP 238] Multi-Release JAR Files : Il sera possible en Java 9 de combiner dans un jar du code java 7 ou 8 qui sera sélectionné selon la version du JRE utilisé à l’exécution.
[JEP 247] Compile for Older Platform Versions : une nouvelle option du compilateur -release permet de compiler avec le rt.jar du JDK 7/8

Actuellement, il existe deux versions du JDK 9 :

Classique : nouveautés JDK 9 sans les modules
Jigsaw (seule cette version sera release)

Le projet Jigsaw (qui traîne depuis quelques années) ajoute la notion de modules au JDK qui permettra d'avoir enfin un mécanisme de visibilité fiable et un moyen d'expression des dépendances. Ces évolutions seront appliquées au JDK lui-même et c'est donc la mort du fameux rt.jar. On trouvera un fichier "module-info.java" de la forme suivante :

module com.foo.bar { requires org.baz.quz exports com.foo.bar.xxx exports com.foo.bar.yyy }

Il existe une notion de "automatic module" qui va permettre de dépendre quand même d'un package qui n'aurait pas été exporté dans un module. Java va automatiquement détecter et gérer ce genre de cas. Côté Maven, de nombreux plugins vont devoir évoluer (c.f page wiki à cet effet). Les travaux en collaboration avec Oracle pour adapter Maven à Jigsaw ont bien simplifié la tâche. Maven a déjà géré un grand nombre de problèmes et fonctionne avec Jigsaw. Toute la partie test (surefire, ...) ne gère pas encore les modules jigsaw, mais c'est à venir.

Un travail a également été lancé pour modulariser maven avec Jigsaw (maven-compat sera le plus gros obstacle à cette migration), mais ce n'est pas la priorité. L'un des enjeux pour Maven était de répondre à la JEP 238 apportant les Multi-Release JAR Files. Pour y répondre, le plugin maven-multimodule va permettre de détecter les différents JDK sur lesquels le code doit être buildé. Il va créer un sous-module par version de JDK détectée et le maven assembly va coordonner tout ça correctement.

Une des questions que l'on peut se poser est l'avenir du pom.xml face au nouveau module-info.java. Le pom.xml n'est pas voué à disparaître avec Jigsaw. Le module-info.java porte quelques infos supplémentaires et différentes du pom.xml, mais ne vient pas en remplacement de ce dernier qui apporte bien d'autres fonctionnalités.

Sécuriser ses applications back et front facilement avec Keycloak (Sebastien Blanc)

Sébastien Blanc de RedHat nous a présenté la solution Keycloak, un service permettant d'externaliser les problématiques d'authentification présentant comme avantages de :

laisser ces aspects à des spécialistes
ne pas complexifier l'application avec ces problématiques
profiter de l'effet d'échelle grâce à la centralisation de la solution
profiter d'un SSO de fait

Keycloak propose un ensemble de services (authentication, registration, social authentication, user dashboard, ...) et supporte un grand nombre de technologies (Java, NodeJS, SDK Android/iOS, LDAP, SAML, ...). La démonstration est convaincante, l'outil s'intègre assez simplement à son projet et donne envie de l'utiliser pour son projet, pour peu que l'on puisse accepter de déléguer l'authentification à un service tiers.

Comme le compte rendu le montre, les thèmes abordés sont très vastes et permettent d'apprendre énormément de choses intéressantes tout en rencontrant certains conférenciers qu'on suit depuis de nombreuses années.

Avec quelques petits regrets sur la durée (un peu courte) de certaines conférences qui auraient mérité un peu plus de temps.