Devoxx France – Retour sur les jours 1 & 2

Du 20 au 22 avril au Palais des Congrès, c’était la 5ème édition de Devoxx France, la conférence des développeurs passionnés !

Nous ne pouvions pas manquer ce rendez-vous incontournable. Une trentaine de Xebians était présente. Voici leurs retours sur les conférences "Coup de coeur". 

Notre favori du jour 1

Flexbox, et le CSS redevient fun ! – Hubert Sablonnière

Hubert SABLONNIÈRE nous présente dans son Tools in Action les différentes possibilités et cas d’usage des Flexbox.

Longtemps, on a utilisé la propriété float pour positionner nos divs les unes à la suite des autres. Or "float" n’est originalement prévu que pour positionner du texte autour d’un block et non pour positionner des divs côte à côte. Elle ne donne que l’illusion que les blocks sont côte à côte… illusion qui disparait en de nombreuses circonstances, de l’absence de texte au positionnement aléatoire.

Puis sont apparus les flexboxs.

Les Flexbox permettent en effet un réel positionnement des blocks entre eux, fiables et paramétrables, suivant un axe principal. Il permet de définir comment répartir avec l’espace excédentaire (propriété flex-grow), sur qui impacter le manque de place (flex-shrink).
On peut ainsi choisir selon quel axe principal (horizontal ou vertical) les différents éléments vont s’organiser (flex-direction), comment ils vont se repartir(flex-justify), ainsi que leur positionnement sur l’axe secondaire (flex-alignement), etc.

Un tools-in-action d’une demi-heure efficace, pédagogique & ludique.

Nos favoris du jour 2

DevOps vu par un hacker – Hicham Tolimat

Par Clément Rochas

«We need hackers in the loop» est un bon résumé de ce talk de Hicham Tolimat. Le talk commence par présenter sa définition du hacker : le hacker n’est pas l’individu cagoulé derrière un clavier mais plutôt un médecin d’Internet. Il connaît toutes les parties d’Internet, on lui amène son site en consultation, il fait des préconisations, des ordonnances. On parle donc d’un hacker qui est là pour améliorer les logiciels, professionnellement ou non.

Nous ne rentrerons pas dans les détails du discours, parfois un peu décousu, mais nous retenons le fil conducteur de cette conférence qui nous touche particulièrement. L’agilité a réduit la boucle de feedback entre développement et métier ; le mouvement DevOps a fait entrer dans la boucle les Ops. Mais, on laisse encore la sécurité en dehors de cette boucle de feedback rapide. Hicham regrette régulièrement d’avoir à faire des rapports de sécurité à ses clients très en aval de la phase de développement : dans le meilleur des cas, un audit prend une semaine, plus une semaine de validation par le supérieur, plus une semaine d’échanges avec le client ; le développeur reçoit donc un retour de sécurité au moins trois semaines après avoir écrit son code, moment auquel le code est déjà souvent complètement différent de ce qui a été audité. On pourrait gagner beaucoup de temps si hackers et développeurs pouvaient interagir sur le moment et travailler ensemble. Au traditionnel cycle dév → test → deploy prod, Hicham propose de substituer un cycle intégrant la sécurité : dév → test → deploy hors prod → sec check → deploy prod. Il s’agit d’améliorer le devOps en devOpsSec.

Pour résumer, l’orateur suggère une collaboration dév-hacker sur tout le processus. Il donne deux exemples de propositions concrètes : utiliser des tickets d’anomalies de sécurité (plutôt que le rapport de plusieurs pages après coup) et le pair programming dev-hacker. Avec l’émergence des technologies comme Docker ou IoT et des inquiétudes récurrentes sur la sécurité, intégrer des hackers dans nos équipes de développement semble être une idée intéressante, voire nécessaire si on en croit les dires de Fabrice Epelboin lors de la keynote de vendredi qui a attiré notre attention sur le fait que sans sécurité, pas de confiance et pas d’économie.

Pourquoi Maurice ne doit surtout pas coder en go – Jean-Laurent de Morlhon

Par Jerome Doucet

Lors de cette conférence, Jean-Laurent de Morlhon a proposé une découverte du langage Go en partant du traditionnel « Hello world », puis en passant par un certain nombre d’idiomes et d’éléments de syntaxe, pour finir sur l’outillage et les cas d’usage. La finalité de ce parcours est d’aborder les points forts du langage, mais de manière critique, en mettant en avant les sources potentielles de frustration, les manques au niveau du langage et/ou des outils du point de vue d’un développeur expérimenté découvrant le langage, pour finir sur une série de cas d’usages typiques de Go.

Go est ainsi présenté comme un langage simple, efficace et pragmatique, facilement déployable car compilé statiquement. L’accent a aussi été mis sur le fait que la librairie standard est relativement bien fournie. Quelques limites et frustrations sont cependant rapidement venues nuancer le discours. Le dogmatisme du langage a été identifié comme pouvant être un frein à son adoption par Maurice. Go est en effet pourvu d’idiomes lisibles mais verbeux et ne propose pas de support du paradigme fonctionnel. De plus, si le parti pris de forcer la standardisation de beaucoup de conventions de code évite un certain nombre de débats peu constructifs (sur le formatage du code par exemple), il peut être source de frustrations pour les développeurs habitués à plus de liberté. Enfin l’absence de certaines fonctionnalités, par ailleurs très populaires dans beaucoup d’autres langages, comme l’héritage ou encore les types paramétrés peut être vécu comme un "retour en arrière". 

L’outillage a lui aussi été assez longuement challengé. Si la générosité de la boîte à outils fournie par défaut a été saluée, le côté (trop) rustique de l’outil de build, l’absence d’une librairie d’assertion par défaut, la difficulté de faire des mocks et divers problèmes avec les outils de gestion de dépendances sont venus nuancer les bons points du tooling.

Et au final, Maurice doit-il faire du go ou pas ? Si Maurice accepte de suivre la façon de faire de Go en acceptant ses limitations, oui. La conclusion est que go possède de grandes qualités, mais il n’est pas parfait et ne conviendra certainement pas à tout le monde ni à tous les usages. C’est un langage de choix lorsque l’on veut faire de la programmation système, des micro-services ou encore des programmes en ligne de commande.

Très bonne tant sur le fond que sur la forme, cette conférence était à la fois structurée, ludique et enrichissante. On regrettera néanmoins la trop rapide présentation des possibilités en matière de programmation concurrente du langage qui sont souvent considérées comme étant l’un des principaux points forts du langage.

Traefik, a modern reverse-proxy – Emile Vauge

Par Cyril Verdier

Les reverse-proxy actuels sont reconnus et performants, mais conçus avant l’ère des microservices déployés dans des conteneurs dans un contexte très dynamique avec un orchestrateur, du service discovery et une infrastructure très abstraite.
Dans cette conférence, Emile Vauge nous présente Traefik, le reverse-proxy qu’il a créé pour répondre à ce besoin. 

L’idée est simple : Traefik va être connecté à l’orchestrateur pour pouvoir configurer dynamiquement les routes pour les domaines et applications. Là où il est beaucoup plus complexe de gérer des fichiers de configuration statiques et un reload nécessaire pour HAProxy ou Nginx par exemple.
Le support de plusieurs orchestrateurs est proposé, entres autres Docker (et Swarm), Mesos / Marathon, Consul, Etcd, Zookeeper.

Emile Vauge nous gratifie d’une démo claire et fluide avec un Traefik connecté au démon Docker (via socket) puis avec un cluster Mesos / Marathon, et on peut constater la création dynamique des routes et le load-balancing pour plusieurs déploiements d’un même conteneur. Ces routes sont créées dans ce cas à partir de labels spécifiques sur les conteneurs Docker, ou du nom des images ou des jobs Marathon.

Enfin une excellent idée : le support du SSL dynamique avec Let’s Encrypt. Un certificat valide peut être généré automatiquement pour chaque domaine dynamiquement configuré (éventuellement même à la volée lors de la première requête).
D’autres plus sont à noter comme le support des WebSockets, de HTTP 2 ou encore la gestion au travers d’une API REST ou d’une UI simple et efficace.

Le projet, encore jeune, démarré en Septembre 2015, a récemment été adopté par plusieurs projets tels que MANTL (de Cisco Cloud), à la place de HAProxy.
Il semble avoir un avenir plutôt prometteur.

Analyzing Images with Google’s Cloud Vision API (Quickie) – Sara Robinson

Par Yoann Benoit

Au cours de ce Quickie Sara Robinson a présenté l’API Google Cloud Vision avec en cadeau bonus l’API Speech, qui est en version alpha. Si vous cherchez une image dans Google Images, vous avez probablement remarqué des propositions de catégories d’images au-dessus de celles proposées pour votre recherche. De même, les utilisateurs de Google Photos peuvent bénéficier de la catégorisation automatique de leurs images (personnes, paysages, etc.). Toutes ces informations obtenues à propos des images sont notamment rendues possibles grâce à des Réseaux de Neurones complexes. L’objectif de l’API Google Cloud Vision est de proposer au sein d’une API REST la puissance de ces algorithmes sans avoir de réel background en Machine Learning. Cette API permet donc d’utiliser des Réseaux de Neurones déjà entraînés.

Google Cloud Vision va vous permettre d’obtenir différents types d’information sur des images via une requête au format JSON : LABEL_DETECTION (catégorisation de l’image), FACE_DETECTION (détection de visage, position et sentiments), LANDMARK_DETECTION (détection du nom et de la position GPS d’un monument, etc.), LOGO_DETECTION (logos d’une marque, d’une association, etc.), TEXT_DETECTION (détection et récupération du texte d’une image), SAFE_SEARCH (indication sur le fait qu’une image puisse choquer une catégorie de la population).

Pour terminer, Sara a présenté la nouvelle API Google Cloud Speech, en version alpha, capable de faire de la transcription de speech vers du texte en 80 langues. En quelques lignes de code, il est possible de configurer l’enregistrement de quelques secondes de discours et d’obtenir sa retranscription écrite ainsi qu’un score de confiance. En s’essayant au français, toute la phrase de Sara a bien été retranscrite … sauf son prénom !

De l’IoT, des timeseries et de la prédiction avec Android, Cassandra et Spark – Amira Lakhal

Par Yoann Benoit

Dans son talk, Amira par du postulat que, bien que le domaine de l’Internet of Things soit en plein essor avec de plus en plus d’objets connectés autour de nous, les données récoltables et récoltées restent difficiles à analyser car pour la plupart non structurées. Sa présentation nous expose comment s’en sortir dans un cas d’application concret : la reconnaissance d’activité physique avec l’accéléromètre de son smartphone. En combinant un certain nombre de technologies et en s’entourant d’amis conciliants pour faire les cobayes, Amira nous a montré un moyen de répondre à ce problème.

Premièrement il faut être capable de récupérer la donnée. Pour cela, quoi de mieux que de se coder une simple application Android récupérant en temps réel la donnée de l’accéléromètre du smartphone. Cette donnée accessible, il faut maintenant pouvoir la stocker ! Le choix d’Amira s’est porté sur Cassandra, base de données orientée colonnes. Afin d’éviter le problème de la création d’une nouvelle SSTable à chaque insertion de données et la perte d’information au fil du temps, il faut se tourner vers un type de données particulier : Le Time Series Data Model. Enfin, pour éviter la limite du nombre de colonnes pour une même table (tout de même quelques millions, mais cela vient vite avec des données arrivant à chaque milliseconde!), il suffit de stocker les données par user et par jour. Et le tour est joué !

Maintenant que l’on peut collecter et stocker la donnée, il est temps de l’analyser et de préférence en temps réel. C’est là que Spark entre en scène, d’autant plus qu’il existe déjà des connecteurs entre Spark et Cassandra pour charger des tables en RDD et pour écrire des données dans Cassandra. Forcément, Spark Streaming semble être l’outil idéal pour analyser les données en temps réel via Spark, le seul problème étant qu’il n’existe pas à l’heure actuelle de Receiver Cassandra pour Spark Streaming. Qu’à cela ne tienne, il suffit de s’en créer un custom, en faisant une simple surcharge des méthodes onStart et onStop. Il ne reste plus qu’à définir les bonnes configurations du Spark Context ainsi que la durée des batchs que Spark Streaming va analyser et on a maintenant le pipeline complet de traitement de la donnée.

Mais il manque en fait un léger détail : Comment traiter cette donnée pour obtenir une prédiction d’activité physique sur un batch de quelques secondes ? C’est à ce moment là que le Machine Learning (et les cobayes !) entrent en jeu. Pour pouvoir créer un modèle de classification (Standing/Sitting/Walking/Running), l’API MLlib de Spark a été utilisée et plus précisément d’algorithme Random Forest. Petit problème, pour pouvoir entraîner un modèle de Machine Learning pour de la classification, il nous faut un jeu d’entraînement, pour lequel on a des données collectées pour les différentes activités, ainsi que l’activité actuellement réalisée. Pour cela, Amira a réalisé un module supplémentaire dans son application Android qui permet de dire quelle activité la personne est en train de réaliser, et de collecter la donnée en même temps. Un petit groupe de personnes s’est alors prêté au jeu et a permis la collecte d’une base d’apprentissage pour entraîner le modèle de classification. Cette base d’apprentissage est stockée dans une table à part entière dans Cassandra qui est en réalité la même table que lors de la simple collecte de la donnée, mais avec en plus le label associé.

Il suffit ensuite d’entraîner le Random Forest de MLlib avec la base d’apprentissage, une fois les données passées par quelques étapes de transformation (Feature Engineering), ce qui va nous donner un modèle utilisable pour prédire en temps réel notre activité. Pour cela, le modèle est exporté sur un service REST. On peut maintenant utiliser tout cela pour accomplir une activité physique, collecter la donnée via l’application Android, la stocker dans une table Cassandra, la transformer par batch avec Spark Streaming, et enfin faire la prédiction via la modèle sur le service REST. Et ça fonctionne ! Une belle brochette de technologies et de bonnes idées pour une application réussie. Et cerise sur le gâteau, Amira a tout open-sourcé (Appli Android, Modélisation & API REST) pour nous permettre d’apprendre de ses expériences.

Stack Overflow behind the scenes, how it’s made – Oded Coster

Par Alexis Kinsella

Oded Coster travaille dans la core team de Stack Exchange, une plateforme de questions / réponses qu’on ne présente plus, du moins aux développeurs. Qui ne s’est pas rendu un jour sur Stack Overflow pour trouver une réponse à un problème rencontré ? Stack Overflow est la déclinaison la plus connue de la constellation de sites que propose Stack Exchange.

Les dessous du fonctionnement de Stack Overflow restent cependant mois connus, et les choix de l’équipe méritent de s’y attarder, ils peuvent être très différents de ce qu’on pourrait imaginer pour un site de cette envergure.

Oded Coster ouvre la session sur quelques chiffres qui viennent rappeler de quelle échelle nous parlons. Ce sont plus de 200 millions de requêtes quotidiennes reçues dont 65 millions de pages vues, soit plus de 3 TB de trafic envoyé chaque jour pour aider les développeurs ! Mais également 500 millions de requêtes SQL.

Premier étonnement, Stack Overflow fonctionne à cette échelle avec une base SQL des plus classiques, SQL Server en l’occurrence. C’est un indice … la plateforme fonctionne grâce aux technologies Microsft, en particulier DotNet. On pourrait imaginer qu’à cette échelle, avec une simple base SQL, on rencontre des problèmes de performance, mais il se trouve que nos compères de Stack Overflow sont très attachés et très connaisseurs du SQL et SQL Server en particulier. Ils sont en quelques sortes des virtuoses en la matière et arrivent à en tirer le meilleur. Ils se targuent même de produire en moyenne les pages web du site en 22.71ms, ce qui peut laisser rêveur nombre de développeurs. La home page en particulier est générée en à peine 11.80ms.

Là où le bât blesse, c’est lorsqu’on apprend que pour arriver à gérer cette volumétrie et apporter ces performances, ils s’appuient en tout et pour tout sur 9 serveurs web et 4 servers SQL (384GB de 12 cores x 2 tout de même !). Les serveurs web fonctionnent grâce à IIS. Chacun de ces serveurs dispose de 64GB et 12 core x 2.

Pour gérer certaines problématiques très particulières telles que les Tags, ils utilisent un produit maison qui permet de répondre à leurs besoins très spécifiques en la matière, grâce à un outil appelé Tag Engine. L’équipe s’appuie également sur d’autres serveurs plus classiques tels qu’Elastic Search ou bien encore Redis et des load balancers HAPRoxy.

Le sentiment de volonté de maîtriser leur stack applicative et matérielle est bien présent, au point que sont détaillés, les matériels réseaux qu’ils utilisent telles que switches, firewalls, et routeurs. Il est par ailleurs intéressant de noter qu’ils ne font pas tourner leur plateforme chez un provider Cloud classique, ils gèrent tout eux-mêmes.

Une fois la partie chiffres présentée, Oded va s’attarder sur l’équipe. Nous découvrons que l’équipe n’est pas composée de plus d’une dizaine d’ingénieurs. L’équipe est distribuée un peu partout sur le globe (Angleterre, Slovénie, Marjoque et USA). Leurs outils de communication sont Google Docs, Trello, Stack Chat (un outil de messaging de leur cru) et Google Hangout. Ce dernier outil sert à améliorer la qualité des discussions dès qu’elles nécessitent plus que quelques échanges. Du point de vue du speaker, les communications écrites entrainent de nombreuses déperditions (sens, ton, …). En particulier, Google Hangout permet de réaliser les Team Meetings qui peuvent réunir 15 personnes voir plus. En conjugaison de Stack Chat, ils utilisent des bots qui les préviennent d’anomalies : nombre inhabituel d’exceptions, mais également les notifient régulièrement : Exécution de builds d’intégration continue ou encore de déploiements en production.

Les outils de développement sont, somme toute, classiques puisqu’il s’agit de Visual Studio, Git, Gitlab, TeamCity et SQL Server Management Studio. On notera tout de même qu’ils n’aiment pas tellement les outils en ligne tels que GitHub, qu’ils préfèrent aussi garder un contrôle total sur leurs outils et de fait de ne pas avoir à dépendre d’un service tiers. Ce qui semble cohérent par rapport à leur politique de gestion de leur infrastructure hors des acteurs Cloud habituels.

La Stack technique est composée de C#, ASP.NET / MVC (Razor) et, comme vu plus tôt, de IIS & SQL Server. Quant au monitoring et l’alerting, l’équipe s’appuie sur des outils maison (Bosun, Opserver et MiniProfiler) et des outils plus classiques tels que Grafana.

Quand on en vient aux systèmes sur lesquels s’executent les applicatifs, Oded nous explique qu’ils fonctionnent aussi bien sous Windows, logique me direz-vous, que sur Linux. En fin de session, une question est posée quant à l’arrivée prochaine de SQL Server sur Linux. Très pragmatique dans sa réponse, Oded répond qu’ils utiliseront SQL Server sous Linux si le produit se relève mieux fonctionner avec et n’engageront pas de migration si les résultats ne tendent pas à démontrer un gain significatif. Il explique que les choix de l’équipe sont simplement guidés par ce qui fonctionne le mieux pour eux.

On apprend que l’équipe, très orientée performance, pourrait faire s’exécuter le site sur un seul serveur web ! Néanmoins ils ne le font pas. Il y a plusieurs raisons à cela, mais avant tout, il explique que la charge CPU de leurs serveurs dépasse rarement quelques pourcents. Une charge CPU à plus de 20% est une alerte, signifiant que quelque chose ne fonctionne pas correctement et que l’équipe doit se pencher dessus.

Concernant le Cloud, Oded explique que cela leur reviendrait plus cher à faire fonctionner leur plateforme dessus que via leur setup serveur actuel. Par ailleurs, les pré-requis de très haute performance et de contrôle précis de la performance sont des sujets impossible à résoudre dans le Cloud. Enfin, une migration nécessiterait un re-engineering important de la base de données, chose non concevable pour ces spécialistes du SQL. En complément, Oded expliquera que la latence et le réseau ne sont pas suffisamment fiables à leur yeux pour répondre à leurs besoins.

En conclusion, on retient que la plateforme Stack Exchange, dont le site Stack Overflow est le représentant le plus connu, fonctionne grâce à un petit nombre d’ingénieurs très expérimentés et aguerris aux technologies qu’ils utilisent, tout cela en ayant une maîtrise parfaite de leur infrastructure, de son monitoring avec un focus très important sur la performance, probablement une métrique clé de leur succès.

La présentation peut être trouvée à l’adresse suivante: http://OdedCoster.com/Devoxx.fr-2016

Docker for Windows & Mac : mais pourquoi on n’a pas eu ça dès le début ? – David Gageot

Par Fabian Gutierrez

David Gageot de chez Docker nous a expliqué les détails de la très attendue implémentation native de Docker pour Mac et Windows (pour l’instant est toujours sur invitation). Il nous a parlé en détail de la nouvelle stratégie pour pouvoir utiliser Docker sur Mac et Windows et voir si finalement nous pouvions laisser tomber Docker-machine (et même boot2Docker si vous vous en souvenez encore).

Avec cette stratégie, il n’est plus nécessaire d’accéder à nos conteneurs par

boot2docker ip

ou même

docker-machine ip myenv

Maintenant, grâce à un peu de "magie noire" d’iptable, une nouvelle entrée est créée et l’ip du daemon Docker est disponible sur Docker.local. Donc, si par exemple on exécute la commande suivante :

docker run -i -t -p 9200:9200 -p 9300:9300 --name elasticsearch elasticsearch

le conteneur elasticsearch est disponible sur http://docker.local:9200.

Sur Mac, ils utilisent le Hypervisor Framework déjà présent sur Yosemite comme alternative à Virtualbox. L’hyperviseur exécute Docker dans une petite machine virtuelle Linux basée sur une distribution Alpine Linux. Cela permet d’avoir des machines virtuelles très petites et rapides. La démonstration se déroule sans soucis et en quelques clics, nous avons un daemon Docker fonctionnel.

Sous Windows par contre, ce n’est pas si simple et ça prendra plus de temps pour avoir le même niveau de support. Ils s’en sortent de toute façon avec hyperv. Sur cette plateforme, il reste quand même beaucoup de questions ouvertes, surtout en relation au futur support de certains features linux dans une version ultérieure de Windows10.

Ça promet le 2016 pour Docker !

100% Stateless avec JWT (JSON Web Token) – Hubert Sablonnière

Par Arthur Sudre

Hubert SABLONNIÈRE nous a présenté les JWT. Il s’agit d’un standard RFC open, permettant d’échanger des données d’identification entre deux parties en JSON. Plus généralement, JWT permet de gérer une session client/serveur. Lorsque l’utilisateur se logue, le token est généré côté serveur et stocké dans un cookie côté client. Il est composé de trois parties : header, payload et signature.

• Le header contient généralement deux éléments : le type de token et l’algorithme de hashing tel que HMAC SHA256 ou RSA. 

{
  "alg": "HS256",
  "typ": "JWT"bg)
} 

• Le payload, contient ce qu’on appelle les claims, qui sont les éléments de description du token. On retrouve trois types de claims :
  • réservés : ils sont prédéfinis dans le standard mais ne sont pas pour autant obligatoires :
    • iss (issuer) : émetteur du token
    • sub (subject) : sujet/utilité du token
    • aud (audience) : à qui il se destine
    • exp (expiration) : date d’expiration
    • ntb (not before) : date à partir de laquelle il est valide
    • iat (issued at) : date de génération
    • jti (jwt unique id) : identifiant unique

Rq : les claims réservés sont limités à trois caractères car JWT a pour objectif d’être compact.

• • privés : données à partager (les informations de la personne authentifiée)

{
  "sub": "1234567890",
  "name": "Hubert Sablonnière",
  "admin": true
}

• La signature : le hash des deux composants précédents, en utilisant une clé (secret) partagée entre le client et le serveur :

const hash = HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

Hubert a poursuivi sur la gestion de la clé côté serveur et les différentes architectures pour la gestion de la session côté serveur. Par exemple, lors de l’utilisation d’un load balancer, on peut utiliser "l’affinité de session" pour lier l’identifiant de l’utilisateur à un serveur, qui stocke les informations de cet utilisateur et permet de l’authentifier. Il y a aussi possibilité de mettre en place un système de réplication de mémoire entre les serveurs de sorte que tous puissent valider l’authentification d’un utilisateur.

Une autre difficulté est la gestion de la clé, celle-ci étant partagée par le client et les serveurs (dans le cas d’un load balancer). Hubert n’a pas répondu sur les méthodes à mettre en oeuvre pour renouveler la clé, cependant il propose d’utiliser un chiffrement asymétrique pour sécuriser davantage l’architecture. Un seul serveur qui possède la clé privée et génère le token à transmettre au client, le client et les autres serveurs possèdent la clé publique et peuvent déchiffrer le token pour récupérer les informations du token.

JWT est simple à mettre en place. Il permet de sécuriser facilement les données identifiant l’utilisateur en les stockant côté client ce qui permet une récupération et une manipulation facile.

ES6 c’est maintenant – Christophe Porteneuve

Par Paul-Guillaume Déjardin

Vert.x pour l’IoT dans l’embarqué – Laurent Huet  

Par Cyril Verdier

Laurent Huet nous présente lors de cette conférence un usage de Vert.x dans l’IOT pour faire fonctionner un petit montage : un Raspberry Pi et un ODroid en réseau, connectés chacun à quelques capteurs, un bouton, une LED, des écrans.

Pourquoi Vert.x ? C’est un système évènementiel simple et léger, avec une empreinte faible, qui fonctionne bien même sur ces petits systèmes et dont il va nous montrer le côté versatile.

Lors de plusieurs démos, Laurent Huet fait communiquer les composants des deux montages, puis les deux montages entre eux et expose enfin les données en temps réel au travers d’une interface web minimale. On peut retenir :

• Les schedulers intégrés à Vert.x, pour déclencher périodiquement une LED par exemple

  vertx.setPeriodic(1000, event -> { … });

• L’utilisation du bus de messages pour propager les évènements issus des capteurs en point à point ou en diffusion globale (broadcast)

  vertx.eventBus().send("myButton", buttonState);
  vertx.eventBus().consumer("myButton", event -> { ... });

• La possibilité d’exécuter les traitements bloquants (tels qu’imposés par les APIs de certaines librairies utilisées pour s’interfacer avec les composants des montages) sur un threadpool séparé, via quelques lignes de code

  vertx.executeBlocking(future -> { ... });

• Le mode cluster : une simple option -cluster dans la ligne de commande et les instances de Vert.x sur les deux montages se découvrent et partagent leur bus de message

  vertx run fr.lhuet.devoxx.MyApp -cp build/myjar.jar -cluster

• Le pont avec SockJS, permettant d’exposer des adresses du bus de message à un client JS directement via une WebSocket et de créer une interface d’écoute des évènements des capteurs en continu

  router.route("/eventbus/*").handler(SockJSHandler.create(vertx).bridge(options));

  var eb = new EventBus('http://...')
  eb.onopen = function(){
   eb.registerHandler('bus-address', function(err, msg) {
    ...
   })
  }

En conclusion Vert.x se prête très bien au jeu avec un code qui reste simple et une boîte à outils bien adaptée à ce contexte.
Le code est disponible à l’adresse : https://github.com/lhuet/vertxOnRpiAndOdroid

Containers, VMs, Processes… Isolation, performances, I/O… Comment ces technologies fonctionnent et comment les différencier ? – Quentin Adam

Par Ivan Beauvais

Dans cette présentation, Quentin Adam tient à nous mettre au fait des différentes manières d’isoler des processus sous linux et des limitations de chaque solution.

• chroot permet de changer le répertoire racine d’un utilisateur ou d’un processus. Ce type d’isolation permet une sécurité très limitée. Il nous fait d’ailleurs la démonstration d’un programme “chrooté” qui sort de son isolation pour accéder aux répertoires parents.
• La virtualisation permet de démarrer plusieurs systèmes d’exploitation sur une même machine physique. La gestion de ces machines isolées les unes des autres est faite par un hyperviseur. Bien souvent, Docker est mis en avant comme alternative pour palier au coût supplémentaire de l’émulation d’une machine complète. Mais ce coût n’est pas toujours justifié :
  • Le matériel a évolué, les instructions VT-X permettent d’avoir des performances très proches du physique.
  • Les solutions de virtualisation ont la réputation d’être longues à démarrer mais il s’agit souvent d’une mauvaise configuration. De plus lent à démarrer n’induit pas lent tout court.
  • Dans la majorité des applications il n’est pas nécessaire d’économiser les ressources : le cpu et la mémoire sont rarement utilisés au maximum.
• Les conteneurs, popularisés avec Docker :  grâce au control groups et les “linux namespaces”, un système d’exploitation est capable d’isoler l’exécution de processus. Mais aujourd’hui, avec Docker, cette isolation comporte des limitations :
  • Par défaut, les processus sont démarrés en root.
  • Un processus dans un conteneur peut exécuter des actions qui affectent l’hôte et donc potentiellement les autres processus. Il nous fait la démonstration d’un conteneur Docker qui forke un grand nombre de processus pour atteindre la limite de l’hôte. Il n’est alors plus possible de lancer de processus sur l’hôte ou dans les conteneurs.
  • Cela pose des problèmes de monitoring : l’hôte peut ne plus avoir de ressource disponible mais pour les processus dans les conteneurs tout se passe bien.
  • La distribution officielle de Docker est Alpine Linux et, du fait qu’elle utilise sa propre version de glibc, ne peut pas être aussi stable et securisée qu’une distribution classique.

En conclusion, la technologie des conteneurs n’est pas de la “virtualisation light”. Elle a ses avantages et inconvénients. Il souligne d’ailleurs qu’elle est utilisée chez Clever Cloud. Cependant si un client veut utiliser une image Docker elle sera démarrée dans une machine virtuelle car il n’est pas acceptable d’isoler des clients différents uniquement avec des conteneurs.

Scaling with Kubernetes, Automatically! Learn Kubernetes API through writing a visualizer to an autoscaler – Ray Tsang

Par Tomas Rodriguez

Ray Tsang, Google Cloud Developer Advocate, nous explique dans cette conférence comment créer son propre autoscaler pour Kubernetes en utilisant uniquement l’API REST de Kubernetes. Ceux qui suivent l’actualité de l’orchestrator de conteneurs le plus populaire du moment se poseront la question : Pourquoi implémenter soi-même un autoscaler quand cette fonctionnalité existe déjà OOTB ? Pour plusieurs raisons. La première et la plus importante est que le but de l’exercice est de comprendre l’API REST de Kubernetes et que l’écriture d’un autoscaler custom n’est qu’une excuse pour entrer dans les internals de Kubernetes. La deuxième, et moins importante, est que l’exercice fut développé contre la version 1.0.0 qui n’a pas le autoscaling OOTB.

Et bien, pourquoi voudrait-on scaler ? Parce que notre niveau d’exécution de CPU dépasse un certain seuil, parce qu’il nous reste trop peu de mémoire disponible, ou encore parce qu’on a plus d’espace en disque. Ce sont des exemples des métriques les plus utilisées mais elles ne sont pas les seules, et comme Ray va nous démontrer, rien ne nous empêche de créer un autoscaler qui utilise une métrique différente définie par nous-même.

Mais autoscaler une application qui est stateless est relativement simple, n’est-ce pas ? Pour ajouter encore plus de complexité, Ray a décidé de autoscaler un cluster de cache distribué Infinispan. Infinispan est un cache distribué développé par JBoss et c’est le cache par défaut utilisé dans JBoss AS.

Pour entrer en matière, Ray nous explique qu’un autoscaler n’est qu’un groupe de composants qui travaillent ensemble pour ajouter plus de conteneurs en fonction d’une métrique bien définie :

• Un collecteur de métriques, typiquement sous la forme d’un agent Java.

• Un serveur de métriques, qui agrège les métriques provenant des différents agents.

• L’autoscaler proprement dit, qui est en charge d’appliquer une politique de scaling. Par exemple, démarrer un nouveau conteneur si l’utilisation CPU dépasse 90%.

• Un actuator, qui est le composant qui crée les nouveaux conteneurs.

Le collecteur de métriques et l’actuator existent déjà (Infinispan expose toutes les métriques en JMX et l’actuator est tout simplement un Replication Controller). Les deux seuls composants à développer sont l’autoscaler et le serveur de métriques.

Dans notre cas, la métrique à surveiller va être le nombre d’entrées dans le cache distribué, et la politique de autoscaling est qu’il ne peut pas y avoir plus de 100 entrées par noeud (en moyenne). Il fait le choix d’utiliser Spring Boot en Groovy pour développer rapidement ces deux composants. Pour l’autoscaler, l’algorithme est relativement simple, une fonction est exécutée avec une fréquence fixe pour comparer l’état réel du cluster avec l’état souhaité. Si ces deux là sont différents, alors on appelle l’actuator pour modifier l’état du cluster de façon à ce que l’état réel s’approche de l’état souhaité. Par exemple, si le cache distribué contient 150 entrées et 1 seul noeud, il appellera l’actuator pour ajouter un noeud dans le cluster (scale out) de façon à ce que le nombre d’entrées par noeud soit au dessus de 100. Si le cache distribué contient 50 entrées et 5 noeuds, il appellera l’actuator pour réduire le nombre de noeuds (scale in).

Ray utilise aussi un outil graphique pour montrer sous la forme de cercles les noeuds qui composent le cluster ainsi que le nombre d’entrées que le cluster contient. On peut ainsi voir en temps réel comment dès qu’on ajoute plus d’entrées un nouveau noeud est ajouté au cluster. Sans doute une façon très utile de visualiser un sujet qui peut être très abstrait autrement.

En conclusion, pour peu que l’on connaisse bien l’API REST, la seule limite aux composants qu’on peut développer pour Kubernetes est notre imagination. Même pas besoin de maîtriser Go pour développer un nouveau composant !

Vous avez ici les liens vers le code source de l’autoscaler , le code source du projet gke et les slides utilisés pour une conférence précédente sur le même sujet.

String Concatenation de 1 à 9 – Rémi Forax

Par Mathieu Dulac

Rémi Forax a décidé, cette année, de nous parler des optimisations faites par la JVM et par le JIT lors d’opérations de concaténation de chaînes de caractères. Et sa recette fonctionne parfaitement, comme à chaque apparition : le fond est incroyablement maîtrisé et intéressant, parsemé d’anecdotes souvent drôles, mais toujours instructives. La forme est clownesque et singulière, à base de questions / réponses au public. 

L’ensemble de sa présentation propose un mélange de code Java et de bytecode généré avec la commande -XX:+PrintCompilation. Et comme toujours avec Rémi, ça pique !

Il commence par nous expliquer que la JVM optimise les concaténations de String par l’opérateur ‘+’, en les transformant en un StringBuilder. Inutile, dès lors, d’utiliser explicitement un StringBuilder, sauf lorsque la concaténation se fait dans une boucle.

Le JIT poursuit alors les optimisations en pré-calculant les tailles de chaînes de caractères statiques, avec en exemple la concaténation de "Hello" + " devoxx " + 2016, et construit la chaine finale à base d’array copy et de getChars. Cette optimisation est possible grace à l’option -XX:+OptimizeStringConcat, activée par défaut depuis les dernières versions de Java.

Néanmoins, ces optimisations ne s’appliquent pas dans la plupart des cas notamment lors d’appels polymorphes…

C’est ici que Indify String Concat (JEP 280) vient à notre secours dans la prochaine version de Java (9). Ainsi, les optimisations seront déléguées au niveau de la VM (et non plus au JIT) via InvokeDynamic, mais nécessiteront une recompilation du code.

Remi nous parle également d’une autre évolution de Java 9, Compact Strings (JEP 254) : en gardant la compatibilité ascendante, la structure interne des String va changer afin d’utiliser moins de mémoire. Le tableau de char UTF-16 sera remplacé par un tableau de byte et un champ pour l’encodage.

Pour conclure, Rémi appelle l’ensemble de l’auditoire à tester assez rapidement cette nouvelle structure de String, afin de remonter le maximum de bugs avant la release. Les slides de la présentation sont disponibles ici.