Ces conférences portent sur des sujets d’innovation et de prospective adressés régulièrement lors de notre évènement USI : Big Data, Lean Management, ruptures technologiques qui changent la DSI, Internet des objets, etc.

Pour chaque entreprise, le programme MyUSI est adapté aux enjeux que vous nous préciserez. Notre challenge est de créer une émulation et (r)éveiller vos futurs innovateurs.

www.octo.academy

LES my USI

ARCHITECTURES & TECHNOLOGIES

> Les nouvelles Architectures Web Front-End

> Data science & Machine Learning

> Docker, le container léger

> Dessine-moi une API… Et dis-moi comment la manager !

> Les architectures de demain

+D’INFOS >

DYNAMIQUE D’ÉQUIPE

> L’optimisme, outil de performance : de l’enthousiasme à la mobilisation animé par Philippe Gabilliet

> La métaphore des jardins animé par Christian Monjou

> Comprendre ce qu’est le temps pour mieux le vivre animé par Bruno Jarrosson

> Trop humains pour réussir ?

> Plaisir et productivité, 10 règles d’or

> Les lois universelles de l’informatique

+D’INFOS >

MÉTHODOLOGIES & CHANGEMENT

> La responsabilité culturelle : UX Strategy

> Vers l’entreprise agile

> DevOps en pratique

> De la pensée projet à la pensée produit

+D’INFOS >

PROSPECTIVE

> Le wearable computing

> Banque digitale : les FinTech cannibalisent la banque

+D’INFOS >

STRATÉGIE SI

> Les secrets des Géants du Web

> Le SI en 2020

> La révolution digitale

> Cloud en 2015 : vers la DSI Cloud broker…

> BigData

+D’INFOS >

www.octo.academy

OpenShift

La genèse de la version 3

Depuis juillet 2014, OpenShift s’est lancé dans un vaste et ambitieux projet de refonte de son architecture en vue d’intégrer en son sein – les désormais incontournables – Docker et Kubernetes.

Pour OpenShift, lancer ce projet il y a 1 an était particulièrement audacieux, et constituait une stratégie risquée. Alors que la course avec Cloud Foundry battait son plein, OpenShift a choisit de se lancer dans un long chantier de refonte technique au détriment de l’enrichissement fonctionnel de son produit et de la compatibilité avec la précédente version. Nous pensons, aujourd’hui qu’ils ont fait le bon pari.

A date, le projet Origin regroupe 74 contributeurs sur Github dont les 10 plus actifs travaillent tous chez Red Hat. Cette communauté plutôt active, a réalisé 15 itérations en 11 mois et vient de rendre disponible sa version bêta 3 qui est déjà très prometteuse. Une première release candidate est attendue pour fin juin 2015 pour OpenShift Enterprise.

Bien que la solution soit principalement portée par Red Hat, elle repose fortement sur Kubernetes (de Google). Ceci pose la question de la gouvernance qui n’est pas forcément triviale et qui dépend de la bonne entente et de l’alignement des visions des deux entreprises. Qu’adviendra-t-il des nouvelles fonctionnalités poussées par Google : viendront-elles enrichir Kubernetes au détriment d’OpenShift? Visiblement, la question n’est pas encore tranchée.

Toutefois, si le soutien de Google se confirme, une gouvernance bicéphale de ces géants ne pourra être que bénéfique à OpenShift. Il permettra de confirmer l’avance prise sur la concurrence de Docker Enterprise (Machine, Compose et Swarm).

Construire et déployer automatiquement ses applications : le fonctionnement

OpenShift v3 offre nativement 3 modes de construction automatisée d’une application :

• Le mode Docker-File : permet de construire automatiquement un container Docker en fournissant à OpenShift l’adresse d’un gestionnaire de code source pointant sur un Docker-File et ses dépendances.

• Le mode Source-To-Image (STI) : permet de construire automatiquement une application en poussant le code source applicatif dans OpenShift (à l’instar des buildpacks dans Heroku).

• Le mode Custom Build : permet de fournir sa propre logique de build d’une application en fournissant à OpenShift une image Docker conçue à cet effet.

OpenShift 3 permet aussi de définir une stratégie de déploiement automatisé d’une application lorsque qu’une nouvelle version d’image est publiée dans la registry ou lorsque que la configuration de l’application est mise à jour.

En complément de ces modes de build et de déploiement, OpenShift 3 offre la possibilité de définir ses propres « blue prints » applicatifs sous forme de fichiers « templates » au format Json ou Yaml. Ces « blue prints » décrivent à la fois la topologie de l’architecture de l’application et la politique de déploiements des containers. Le schéma ci-dessous illustre l’assemblage des différents composants d’un « template » d’une application 3-tiers dans OpenShift.

Schéma d’une architecture d’une application 3 tiers dans OpenShift v3

Les différents composants assemblés dans un « template » sont en partie hérités des concepts de Kubernetes. Les principaux objets à retenir sont les suivants :

• Un « POD » est un environnement d’exécution de container(s) Docker local à un serveur (on déploiera deux types de containers sur un même POD s’il est nécessaire de partager des ressources locales).
• Un « Service » est un point d’entrée (VIP) rendant abstrait un accès « load-balancé » à un groupe de containers identiques. En principe, on déploie un Service par tiers de l’architecture.
• Un « Service Deployer » ou « Deployment Config » : est un objet qui décrit une politique de déploiement d’un container sur la base de triggers (par exemple : redéployer lorsqu’une nouvelle version d’une image est disponible dans la registry Docker)
• Un « Replication Controller » est un composant technique en charge de la résilience des POD
• Une « Route » expose un point d’entrée (DNS hostname ou VIP) à l’extérieur d’une application

Grâce à ses différents mécanismes de déploiement et à la possibilité de définir ses propres « blue prints », OpenShift v3 se plie aux architectures applicatives les plus complexes et exigeantes.

Sous le capot : une architecture élégante

Le déploiement d’une infrastructure OpenShift 3 peut se faire soit de manière standalone (en déployant l’image Docker suivante : « openshift/origin »), soit de manière distribuée en utilisant les playbooks ANSIBLE fournis par OpenShift. Dans ce dernier cas, on déploie sur des serveurs des rôles de type « Master » ou de type « Node ».

Les nœuds de type « Master » servent à la fois à :

• traiter les requêtes à l’API d’administration (en provenance du CLI ou du portail Web)
• réaliser les opérations de build des images et de déploiement des containers
• assurer la résilience des PODs (réplication)

Les « Masters » utilisent un annuaire distribué etcd pour le partage de configuration et la découverte des services.

Les « Nodes » hébergent les PODs et exécutent des containers (application et/ou Registry).

Schéma d’architecture de déploiement d’une infrastructure OpenShift v3

L’architecture ainsi proposée est à la fois distribuée, scalable et résiliente. Le seul bémol concernant le passage à l’échelle : le provisionnement et la gestion de la capacité des serveurs sous-jacents restent à réaliser manuellement pour le moment.

Il est possible d’interagir avec la plateforme au travers de son API REST, en CLI ou via son portail Web (uniquement en lecture seule, pour le moment).

Portail web d’administration d’OpenShift v3

Le point de vue d’OCTO

OpenShift 3 propose une passerelle intéressante du monde du « Platform-as-a-Service » vers le monde du « Container-as-a-Service » (CaaS). La solution proposée par Red Hat est audacieuse et son architecture est à l’état de l’art. Nous apprécions particulièrement le format de spécification des « blue prints » d’architecture et d’orchestration de déploiement.

Dans sa version actuelle (bêta 3), OpenShift met peu l’accent sur l’exploitabilité de la plateforme. Il faudra donc attendre encore un peu avant de l’employer en production. Toutefois, on retrouve à la roadmap des user stories à ce sujet :

• concentration de log avec ElasticSearch–Logstash–Kibana ou Fluentd
• monitoring avec Heapster,
• métrologie,
• facilités pour le déploiement de clusters.

Apprendre à modéliser une application dans OpenShift 3 constitue selon nous, un nouveau métier et à ce titre requiert de nouvelles compétences afin de se poser les bonnes questions : Comment organiser les conteneurs? Faut-il utiliser des routes ou des services? Comment gérer les données (persistence, réplication, sauvegarde)? Comment gérer le multi-tenant? Que devient mon usine de développement et de déploiement (UDD)?

En synthèse, cette solution de PaaS privé s’annonce très prometteuse. Elle permet de réduire le time to market en automatisant dès le début du projet, les processus de construction et de déploiement d’une application. Elle est compatible avec les architectures Web les plus complexes, bien que les problématiques de la gestion des données et de l’intégration avec des services externes ne soient que partiellement adressées pour le moment.

Nous croyons qu’Openshift 3 a tout pour s’imposer sur le marché comme la référence en matière de PaaS privé basé sur Docker.

Pour aller plus loin : http://fr.slideshare.net/NewHopeKim/open-shift-and-docker-october2014

En guise de rappel, Devoxx est une groupe de conférence initié en Belgique qui regroupe un grand nombre de développeurs du monde Java mais pas seulement. La variété des formats de conférences (keynote, university, quickie, tools-in-action, hands-on-lab) contribue à la richesse de l’événement. Cette année on a parlé BigData, DevOps, IoT et Mobile mais aussi traditionnellement Java Modulaire et la clôture des Cast Codeurs.

Cet article a pour but de faire un tour d’horizon des conférences que nous avons pu suivre, de vous donner un premier retour et de vous fournir les pointeurs pour approfondir si vous le souhaitez.

DevOps

Quand Devops rencontre BigData (Olivier Bazoud, Vincent Heuschling)

• CFP Devoxx
• Présentation : Full
• Ressources : HOL

Cette première session était un Hands’on, animé par Olivier Bazoud et Vincent Heuschling, je n’ai donc pas pu prendre beaucoup de notes. Les 4 exercices sont disponibles sur le GitHub et sont bien découpés. En 3 heures je n’ai pas l’impression d’être allé très loin avec Spark mais j’ai au moins pu toucher du doigt son utilisation.

Objectifs du Hands On Lab (HOL) :

1. Manipuler des données avec le REPL
2. Analyser des Apache Logs
3. Détecter des anomalies dans des logs réseau
4. Utiliser un cluster

Dans une architecture BigData, la difficulté repose souvent sur l’analyse de logs. Deux outils principaux du BigData :

• Hadoop (HDFS, MapReduce, OpenSource, Google en 2006)
• Spark (Fonctionnel, In Memory, Midsize Data, Berkeley AMPLab)

Spark part du postulat que la plupart des Datasets ne dépassent pas le Giga, il va pouvoir tenir dans la RAM de plusieurs machines. Quelques avantages :

• Rapide (RAM)
• Fonctionnel (moins de code)
• En pleine croissance (Spark SQL, Spark Streaming, MLlib, GraphX) en 3 ans
• Spark Shell : permet de tester des commandes en live

Les données sont stockées dans un RDD (Resilient Distributed Dataset) qui rejoint le principe habituel d’éclatement de la donnée en partitions qui vont être exécutées sur plusieurs noeuds (1 partition = 1 processus).

Hadoop se base sur le MapReduce (splitter les fichiers sur HDFS pour les traiter parallèlement).

Une brève phrase de conclusion sur le Big Data en général que j’ai finalement bien aimée :

« La difficulté du machine learning réside plus dans le choix des données, de la pondération choisie pour chaque colonne plus que de l’algorithme d’apprentissage en lui même. »

Mesos University (Aurélien Maury, Pablo Lopez, Jean-Baptiste Claramonte, Jean-Pascal Thiery)

• CFP Devoxx
• Ressources : Github

Mesos, qui signifie « milieu » en grec ancien, est un système de clustering se voulant générique : une interface de partage de ressources pour faciliter le support d’applications distribuées. Mesos trouve son origine à l’université de Berkeley 2009, initialement conçu pour pallier les problèmes de certaines applications distribuées comme Hadoop.

L’objectif de Mesos est d’augmenter la densité applicative dans le cluster, exploitant ainsi chaque machine qui compose le cluster de manière plus efficace, par opposition au fait d’instancier des noeuds dont les ressources ne sont pas pleinement exploitées (ex. : un serveur web qui consomme beaucoup de mémoire mais peu de ressources CPU). Son défi est de fournir ce dont les applications distribuées ont besoin (signal start/stop, monitor-clean, etc.). D’autre part, Mesos supporte tous les types de noeuds au sein de son cluster (VM, conteneur (LXC, Docker), bare metal).

L’architecture de Mesos repose sur un pattern master/slave. Les slaves informent le master des ressources dont ils disposent via des offres. Ces dernières contiennent obligatoirement la quantité de CPU et de RAM disponible. D’autres ressources sont implémentées par défaut. Le master collecte les offres et les distribue aux frameworks. La notion de framework correspond au couplage d’un scheduler qui va, avec le master, lancer les tâches et d’un executor, facultatif, qui va exécuter les tâches. Pour éviter que le master et le scheduler ne deviennent des SPOF, il va être nécessaire de les redonder. C’est là qu’intervient Apache Zookeeper qui se base sur la notion de quorum pour l’élection d’un master, les autres devenant standby master.

Dans les faits, les serveurs dont on dispose sont toujours hétérogènes !

On peut définir ses propres ressources ce qui est pratique dans le cas d’un cluster que l’on construit petit à petit et dont les machines sont donc de puissances et fonctionnalités hétérogènes (ex: on achète une machine avec un GPU car on a besoin de traiter des images).

Mesos est un projet qui va apporter une grande valeur ajoutée à votre cluster de machine pour l’exploiter au mieux. Des frameworks tels que Marathon ou Chronos de la Mesosphere enrichissent le framework pour aisément pouvoir construire son propre PaaS et gérer ses jobs. Les speakers ont également mis en avant l’importance du DevOps dans l’utilisation réussie de Mesos. En effet les développeurs sont les mieux placés pour savoir les ressources dont ont besoin leurs applications pour fonctionner.

En conclusion, pour réussir son déploiement Mesos :

Keep C.A.L.M.S ! (Culture Automation Lean Measurement Sharing)

Uniformisez vos postes de développement avec Docker Compose (anciennement Fig) (Etienne Peiniau)

• CFP Devoxx
• Ressources : Github

Ce Quickie par Etienne Peiniau présentait l’outil Fig plutôt connu dans l’écosystème Docker, qui est devenu depuis peu Docker Compose suite au rachat par Docker. Il répond aux cas d’utilisation suivants :

1. Déploiement des dépendances applicatives
2. Réplication sur les postes de développement

Pour le configurer, on écrit un fichier docker-compose.yml dans son projet qui va assembler à la racine l’ensemble des services docker à bootstrapper.

Quelques commandes utiles (qui s’apparentent fortement à la ligne de commandes Docker) :

• docker-compose up : bootstraper l’ensemble des conteneurs
• docker-compose logs : voir tous les logs en sortie standard des conteneurs
• docker-compose ps : lister les conteneurs de cette composition

En conclusion, j’entendais souvent parler de Fig sans trop comprendre à quoi m’attendre. Après ce quickie, cet outil me semble à la fois indispensable et très simple à utiliser si on a déjà quelques bases en Docker.

Groovy’s release process (Guillaume Laforge, Cédric Champeau, Fred Simon)

• CFP Devoxx
• Présentation : Full

Une présentation par l’équipe Groovy, dont Guillaume Laforge, et sponsorisé par JFrog, l’outil de management d’artéfacts utilisés par Groovy depuis peu. Le talk a permis de retracer l’histoire de Groovy et l’évolution de son processus de release pour finir par une petite apparté sur JFrog.

Groovy qui est un compilateur a des besoins spécifiques qui sortent du lifecycle classique de maven. Initialement le déploiement était effectué par Maven avec le plugin Jelly mais manquait de flexibilité. Il leur a été nécessaire de passer à Ant pour plus de souplesse avant de finalement utiliser Gradle, lui même basé sur Groovy.

Concernant l’intégration continue du projet, initialement celui-ci utilisait Codehaus qui :

• se base sur WebDAV pour pousser les artéfacts et la documentation
• prenait plusieurs secondes pour lister / changer de dossier
• prenait plus d’une heure pour uploader des centaines de fichiers Javadoc
• est en cessation d’activité depuis février 2015 et les dépôts sont en cours de migration

Finalement Groovy est passé à Team City développé par Jetbrains. Ce dernier dispose d’une communauté qui maintient des agents de build spécifiques à différentes plateformes. Les besoins de Groovy sont très spécifiques et il ont une grosse combinatoire à tester pour le langage :

• Plusieurs versions du JDK (6, 7, 8, 9)
• Invoke dynamic en 7+
• Toutes les branches de maintenances Groovy
• Backward compatibility avec Gradle, Grails, etc…

D’autre part il leur manquait une grande partie d’automatisation et de nombreux workflows ont été longtemps effectués manuellement (tagging, mise à jour de version, VCS, etc.) engendrant de nombreuses erreurs. Un autre problème se posait pour la maintenance des codes insérés dans la documentation qui finissaient par être obsolètes. Désormais, la documentation réalisée sous Ascii Doctor permet de tester tous les codes unitairement !

Finalement, Groovy utilise JFrog pour la gestion de ses artéfacts. Artifactory est l’équivalent d’un dépôt Nexus qui permet de gérer les différents snapshots générés à chaque commit. Il supporte Python, Debian, Docker, npm, maven, gradle, ivy, nuget, rpm, yum, etc. Bintray stocke les releases qui sont signées et déployées sur Bintray JCenter (synchronisé avec Maven Central). Le site web et la documentation peuvent être uploadés et mis à jour automatiquement.

Scaling Docker with Kubernetes (Carlos Sanchez)

• CFP Devoxx
• Présentation : Full
• Ressources : Github Plugin Jenkins

Google déploie près de 20 milliards de conteneurs par semaine ! Docker, qui adresse les applications orientées services essentiellement, est une nouvelle solution qui apporte ses propres problèmes…

Docker combine LXC et UFS (Union FS), un système de fichiers qui présente différentes couches. Linux est requis (cf. Boot2Docker MAC/WIN) mais on s’approche du Build once, run anywhere et de nombreux dépôts officiels sont disponibles pour récupérer les images Docker

Conteneurs vs VM :

Les conteneurs sont isolés mais partagent le même OS (et librairies lorsque c’est possible). Les VM virtualisent au dessus d’un OS Hôte ou d’un Hyperviseur qui va initialiser un OS complet pour chaque VM.

DevOps :

Docker est un outil orienté développeur car il permet d’exécuter son app localement, de la configurer et d’exposer le minimum. Il est orienté opérationnel car il permet de masquer l’application et de laisser les opérationnels se concentrer sur les problématiques d’infra.

Kubernetes a été crée par Google il y a un peu plus d’un an et vient adresser la problématique de gestion de conteneurs sur plusieurs hôtes. Il peut être qualifié de container cluster orchestration. Il permet de configurer de multiples hôtes (nodes / minions) grâce notamment à une API et offre la possibilité d’agir plus ou moins sur l’emplacement des conteneurs spawnés. D’autre part, il propose un monitoring plus haut niveau que Docker.

Kubernetes est composé d’un master qui joue le rôle de serveur d’API et se base sur ETCD pour la synchronisation de configuration. Il s’articule autour de nodes qui se composent à minima de Docker, ETCD, SkyDNS et Kubelet (qui s’assure de l’état des pods). Enfin les pods sont un groupe de conteneurs collocalisés qui partagent le même network/namespace/ip et volume (host mounted, empty volumes, GCE data disks, …). Pour chaque pod on configurera le nom de l’image Docker, les ports à exposer, les volumes à monter et un label (tag) si nécessaire.

De nombreux fournisseurs de conteneurs existent déjà :

• Google Container Engine
• Azure
• vSphere
• Rackspace
• oVirt
• Vagrant
• CloudStack
• Ubuntu
• Tectonic (on top of CoreOS)

Carlos Sanchez a cité pendant sa session plusieurs projets/plugins autour de Kubernetes et le support déjà assuré par de nombreux providers nous pousse à vouloir tester rapidement cet outil !

*Data

InfluxDB : La base de données chronologique OpenSource autonome (Nicolas Muller)

• CFP Devoxx
• Présentation : Full

Un quickie de Nicolas Muller présentant la base de données InfluxDB, opensource par ErrPlane (MIT License) écrit en Go, taillée pour le stockage de séries temporelles. Une time serie est un regroupement d’événements qui se sont passés dans le temps :

• fichier log
• timeline twitter
• git commits
• pages vues
• …

En 2015, on attend d’un outil de collecte, stockage et visualisation d’événements qu’il soit simple à installer et administrer, adapté au BigData, qu’il supporte HTTP et JSON et qu’il soit bâti sur des API. Ce n’est pas encore vraiment le cas des outils existants :

• Graphite : PB d’installation, pas de scaling aisé
• OpenTSDB
• Collectd
• Sensu
• DropWizard
• …

InfluxDB répond à ces contraintes. Il est simple à installer et manager, n’a pas de dépendances externes, propose une interface HTTP et est scalable horizontalement. Il propose également l’échantillonnage de données par période de temps ce qui est une fonctionnalité souvent attendue.

InfluxDB est assez simple à appréhender. Il est basé sur le concept de Database équivalent à celui qu’on connait avec les SGBD classiques. Le concept de Time Series est une sorte de table pour le temps avec un sequence number et des colonnes. Une série temporelle est composée de points (ou événements) correspondant en quelque sorte aux lignes d’une base de données SQL. Enfin InfluxDB propose une langage SQL Like pour requêter des séries.

Nicolas Muller a évoqué un certain nombre de bonnes pratiques connues à ce jour.

InfluxDB est très adapté à des nombreuses séries avec peu de colonnes. Requêter sur des colonnes autre que le temps est possible mais entrainera de mauvaises perfs. Dans ces conditions, on crée autant de tables qu’il y a de valeur métier.

En terme de nommage, la règle à suivre est la suivante :

 <tagName>.<tagValue>.serieName

Exemples  v0.8 :

• arduino.uno.shield.ethernet.sensor.dht11.temperature
• arduino.uno.shield.ethernet.sensor.dht12.temperature
• arduino.uno.shield.wifi.sensor.dht22.humidity
• …

En V0.9, les tags seront gérés directement par Influx :

1
2
3
4
5
6
7
8

{
    name: <b>"temperature"</b>
    tags: {
        arduino: <b>"uno"</b>
        shield: "ethernet"
        sensor: "dht11"
    }
}

A noter qu’une migration automatique en V0.9 d’InfluxDB sera possible si on a respecté la convention de nommage ci-dessus en V0.8 et inférieur. De plus, la nouvelle version de Grafana va supporter directement la V0.9.

InfluxDB semble être une techno prometteuse dans le domaine des séries temporelles omniprésentes de nos jours (IoT, monitoring, etc.). Le produit évolue rapidement et Grafana, l’un des incontournables de la DataViz, est associé à InfluxDB et OpenTSB qui permet des montées de versions synchronisées de ces outils.

Avro : la souplesse du JSON, les performances du binaire (Alexandre Victoor)

• CFP Devoxx
• Présentation : Full

Un quickie par Alexandre Victoor (SCGIB) présentant Apache Avro, un système de stockage initialement utilisé pour le stockage distribué dans Hadoop qui est maintenant un projet à part entière chez Apache.

Avro permet d’échanger du JSON (ou binaire ou autre) pour lequel on va pouvoir définir un schéma de référence pour ses données. Ainsi, à l’initialisation, client et serveur réalisent un HandCheck pour vérifier qu’ils sont en accord sur un schéma et commencer à échanger. Dans le cas contraire, la connexion est coupée.

Aux données échangées est associé un hash correspondant au schéma de données utilisé. Ceci permet de facilement faire évoluer un schéma d’échange de données dans Avro et de le diffuser petit à petit vers ses clients. Le schéma complet et donc stocké côté serveur et l’overhead à chaque échange est donc limité à quelques bits pour connaître l’identifiant du schéma.

Applications Concurrentes Polyglottes avec Vert.x (Julien Viet)

• CFP Devoxx

Julien Viet, ingénieur sur le projet Vert.x, nous a fait une présentation de ce framework polyglotte dont on entend beaucoup parler depuis un certain temps. Vert.x est un projet sous la fondation Eclipse financé par RedHat, actuellement en version 2.1.x de production, la version 3 milestone 4 est en cours de développement. Java 8 obligatoire depuis la version 3 qui utilise beaucoup les expressions lambda.

Vert.x est une stack pour développer des applications pour la JVM inspiré par Erlang/OTP et Node.js pour les paradigmes asynchrones non bloquants. Il est polyglotte (Java, JS, Groovy, JRuby, Jython, Scala, …), léger et embarquable adapté aux hautes performances (support du cluster / failover).

Le framework suit le modèle réactif (il implémente reactive-streams en version 3) éliminant ainsi les problèmes de concurrence (l’utilisation du même thread au cours de l’exécution est garantie). Vert.x est composé d’un core léger avec peu de dépendances et expose une API asynchrone.

Vert.x est fondé sur deux principaux composants :

• Verticle qui est déployé dans Vert.x quel que soit le langage et exécuté sur un thread unique. La communication avec lui se fait par messages. De manière générale on va, pour une application donnée, tenter de séparer les différentes briques en autant de Verticles.
• Le Bus d’événements est le système nerveux de Vert.x. Il force l’isolation des Verticles qui échangent des messages grâce à lui. L’échange est essentiellement Point à Point de données immuables dans le format souhaité (généralement JSON ou byte).

Enfin, basé sur Nashorn et SockJS, Vert.x est également utilisable dans le navigateur qui fourni la même API que pour le serveur. En conclusion Vert.x favorise l’écriture d’architectures en microservices par son modèle asynchrone et sa communication par event bus. Sa compatibilité multilangages (automatisée à partir de la version 3) en facilitera d’autant plus son adoption.

Algorithmes distribués pour le Big Data (DuyHai DOAN)

• CFP Devoxx
• Présentation : Full

HyperLogLog est un algorithme qui consomme peu de mémoire pour gérer des compteurs sur un très grand nombre de données, moyennant une perte de précision de quelques pourcents. Pour cela, il faut calculer des probabilités basées sur les données rencontrés (hash a forte variabilité) en analysant le nombre de bits consécutifs à zéro. Il faut également faire des moyennes pondérées pour éviter que certaines valeurs occasionnelles faussent les résultats.

Paxos est un algorithme de consensus distribué. Dans les faits, un maître gère les conciliations et en cas de problème, un nouveau maître prend la main. Il est capable de terminer les travaux du premier. En cas de collision, un délai aléatoire est ajouté avant la reprise.

DuyHai DOAN a eu l’ambition de nous expliquer les algorithmes HyperLogLog et Paxos. Il s’est plutôt concentré sur les justifications sous-jacentes aux algorithmes que sur l’implémentation réelle ou l’utilisation. Mission accomplie !

Jeu de rôle massivement multijouer avec Firebase (Thomas Guerin, Alexis Moussine-Pouchkine)

• CFP Devoxx
• Ressources : Play Store

Pour finir la journée du jeudi, une présentation de la base de données Firebase en action dans un jeu vidéo aux allures d’Ingress ! L’objectif de ce tools-in-action était de faire un jeu android pour capturer les gares avant que les autres ne le fasse.

Firebase est une BDD NoSQL orientée document qui offre un mécanisme de synchronisation de la donnée en temps réel. Elle se charge pour nous de l’abstraction de la couche transport (WebSocket, SEE, …), des problématiques de coupures réseaux et des fallbacks pour support les anciennes plateformes.

En plus de se charger du problème de synchronisation, Firebase propose de nombreux SDK qui permet de profiter de ce service pour toutes ses applications (Android, Java, Angular, iOS, Ember, React, Node, etc.).

Pour Egress, GeoFire a été utilisé pour apporter le support de la localisation. De manière concrète, on va créer un objet Firebase mappé sur l’url de la base de données. L’authentification sera gérée par Firebase (ex : ref.authWithOAuthPopup), puis on définit des callbacks côté client :

• geoQuery_stations.on(« key_entered ») : on sélectionne une zone sur la carte, geoQuery va chercher les gares correspondantes
• geoQuery_stations.on(« key_exited ») : on se déplace dans une autre zone, geoQuery va masquer les gares correspondantes

En conclusion, avec cette petite démo fun, on voit rapidement que Firebase va plus loin qu’une base de données classique. Non seulement elle propose un mécanisme de synchronisation des différentes applications par événements mais aussi elle offre des fonctions pratiques comme l’authentification, où la localisation via la librairie GeoFire.

Performance

Programmation Lock-Free : les techniques des pros (Jean-Philippe Bempel)

• CFP Devoxx
• Présentation : Partie 1, Partie 2

Jean-Philippe Bempel de ULLINK a partagé ses connaissances sur les différentes approches pour proposer des algorithmes sans verrou. Il a évoqué les implémentations proposées depuis Java 7 et les améliorations dans Java 8. Il a évoqué les algorithmes immuables CopyOnWriteArrayList<E> pour insister sur les impacts au niveau du GC.

La stratégie lock striping utilisée par l’implémentation Java 7 de ConcurrentHashMap<K,V> consistait à sharder les données en bloc pour y associer des locks. Cette approche n’est plus utilisée en Java 8.

Il a par ailleurs expliqué les différents type de barrières, gérées par le compilateur et/ou le processeur. Il a évoqué les différents types de verrous processeurs, en lecture et écriture. A noter qu’un processeur x86 n’a besoin que d’un lock en écriture, via des instructions assembleurs proposées par la classe Unsafe. Il a également rappelé que le passage en Kernel n’implique pas forcément un Context Switch. Cela dépend du traitement demandé. Il y a traversée en Ring 0 du processeur.

Finalement, il nous conseille de suivre le blog de Martin Thomson (Mechanical Sympathy) qui prône le rapprochement du code au plus près de la machine et du processeurs. Une conférence de très haut niveau, riche en information, simple dans les explications et technique comme on aime !

HAProxy level 2 : des bases aux problématiques de scaling (Nicolas Helleringer)

• CFP Devoxx
• Présentation : Full

Ce tools-in-action proposait un retour d’expérience sur l’utilisation de HAProxy dans un test géant effectué pour Critéo.

En résumé, HAProxy tient très bien la charge tant qu’il n’est pas saturé en CPU. Une petite combinaison d’outils permet d’avoir de la haute disponibilité entre plusieurs instances HAProxy.

Un monde où 1ms vaut 100 M€ (Thierry Abaléa, Alexandre Victoor)

• CFP Devoxx
• Présentation : Full

Dans le domaine de la finance de marché, les performances sont de l’ordre de la micro seconde. En effet, il faut profiter d’opportunités financières qui sont disputées par des dizaines de milliers de concurrents. Aux Etats Unis, les stock options représentent 1,1M de transactions par seconde.

Objectifs :

La conférence se construisait autour d’une application de finance de marché dont il fallait optimiser les performances.  L’architecture initiale de l’application était la suivante :

• un thread unique qui va jouer le rôle d’event loop
• des threads qui interceptent les IO en amont et en aval
• la communication entre les deux est réalisée par une BlockingQueue

Pour se mettre en jambe, le talk a commencé par un petit quizz :

1. Pour une matrice donnée, quel est le parcours le plus rapide entre :
   1. celui en ligne : car il est compatible avec les caches processeurs
   2. celui en colonne : celui-ci invalidera constamment le cache le rendant inefficace
2. Pour calculer une valeur absolue, il est plus efficace :
   1. d’utiliser Math.abs : on fait simplement une opération sur les bits
   2. de faire un if sur le signe : les données étant aléatoire sur le signe, le mécanisme de prédiction du processeur va être inefficace et on va perdre beaucoup de cycle d’horloge à changer de branche de prédiction.

En matière de performance, l’une des obsessions est de constamment mesurer. Faire constamment du microbenchmarking avec JMH par exemple car une intuition d’optimisation peut se révéler fausse ou pire contre productive.

L’outil statistique est primordial dans les mesures de performance. Attention, utiliser la moyenne pour la latence d’un système n’est pas forcément une bonne solution car on n’a pas une distribution aléatoire de valeurs et la moyenne risque simplement d’être noyée dans la variation des valeurs. On utilise l’outil statistique percentile qui permet d’avoir la distribution de toutes les valeurs et de produire un histogramme (cf. HDRHistogram by Gil Tene pour réaliser des histogrammes avec impact minimal sur les performances).

Martin Thompson parle de « Mechanical Sympathy » pour réconcilier le code avec le matériel. En effet pour obtenir les meilleures performances il ne faut pas négliger la machine sur laquelle les instructions de notre programme vont être exécutées.

Pour avoir des performances optimales, on cherche à développer des algorithmes non bloquants, on veut ainsi au moins un thread en progression tout le temps. Plusieurs choix se posent sur le type de file à implémenter ConcurrentLinkedQueue, Queue SPSC ou encore Lamport Queue. Cette dernière utilise une file circulaire qui consiste en un tableau, un index d’écriture et un modulo. Ainsi on a un gain de débit de x4 entre BlockingQueue et Lamport Queue.

Notes sur volatile :

Le buffer (tableau) d’index sont stockés en « volatile ». En Java 1.4 on a pas le comportement attendu car c’est le buffer qui est volatile pas la valeur à l’intérieur ! En Java 1.5, le volatile a plus d’utilité car il se base sur le principe d’happens before.

Exemple : si mon tableau a été écrit dans le buffer à un index 2, et qu’au moment de la lecture de l’index par mon consumer il vaut 3, celui-ci va quand même aller chercher la dernière valeur avec laquelle le thread en question à écrit dans le buffer, en l’occurrence 2.

D’autre part, le coeur d’un processeur a un Store Buffer qui permet au registre de limiter un peu les accès au cache L1. Le volatile a un coût lié au fait qu’à chaque accès, il va commiter le Store Buffer dans le cache L1 et vider ce buffer. On perd donc cette optimisation.

Il a été également évoqué l’utilisation d’un Chronicle Logback Appender basé sur un Memory Map File pour des raisons de performance, ou encore de surparallélisation et de context switching lié au changement de processeur d’exécution pour un thread.

En conclusion, un talk très abordable et très intéressant par deux ingénieurs de la SCGIB (Thierry Abaléa et Alexandre Victoor) concernant les enjeux d’une application haute performance en finance et les solutions qu’on peut avoir en Java. Des solutions rapides à mettre en oeuvre et efficaces et toujours la même obsession : mesurer !

Langage

Practical RxJava (Simon Baslé, Laurent Doguin)

• CFP Devoxx
• Présentation : Full
• Ressources : HOL, ReactiveX

Menée par Simon Baslé et Laurent Doguin, cette session était un Hands On Lab sur RxJava que j’ai trouvé très bien construit et où j’ai vraiment découvert et compris l’intérêt que peut avoir Rx dans son projet.

Le GitHub du HOL est fourni (et associé à un projet externe qui sert d’API défaillante https://github.com/simonbasle/practicalRxExternal) et chaque étape a une branche solution associée ce qui permet de comparer avec ce qu’on a fait.

Objectifs du HOL :

1. Migrer une application Web composée de divers services, dont certains externes et utilisant des mécanismes de l’API java.util.concurrent vers une application RxJava
2. Après la migration des premiers services, on commencera par faire compiler le code naïvement en faisant des appels bloquant dans les contrôleurs appelant ces services jusqu’à arriver à du RxJava full stack et un retour asynchrone avec le DeferredResult Spring.
3. On se concentrera ensuite sur la réalisation du ExchangeRateService. Appel de deux API externes :
   • Change Doge vers Dollar
   • Change Monnaie A vers Monnaie B

L’API gratuite n’est pas fiable. Une API payante est plus fiable il faudrait l’utiliser seulement lorsque l’API gratuite ne marche pas. Etant donné l’API payante, il faudrait tracer les coûts.

Solution :

1. Pour compter les coûts, compteur dans l’AdminService
2. On wrappe dans un onErrorResumeNext
3. On ajoutera un doOnNext pour le logging

ReactiveX est inspiré de Microsoft .NET (linq, rx) porté en Java par Netflix OSS. Il peut être intéressant d’utiliser RxJava dès lors que l’une des problématiques suivantes se présente : Asynchrone, Event Based, IO. Rx vient combler les limites de certains langages et offre des fonctions de composition, transformation, filtrage, gestion d’erreurs avancé, temporalité :

• Java Future => rapidement bloquant (appel à get)
• Callback hell
• Pas de composition
• Limite gestion d’erreurs, d’exceptions, annulations, synchronisation, etc…

Ceci mène souvent à un code plutôt illisible, en tout cas peu autoportant.

Le principe est simple, généralement en Java on manipule les collections en pull (pattern Iterable / Iterator). En RxJava, on va plutôt faire du push de données (pattern Observable / Observer). La donnée devient un flux, poussé vers le consommateur.

• Observable est un flux connectable à un Observer
• Observer propose les actions :
  • onNext : déclenchée pour chaque arrivée d’élément
  • onError : déclenchée lors d’une erreur
  • onCompleted : déclenchée lorsque le flux est terminé

Le framework offre un grand nombre d’opérateurs utiles en tout genre. En voici les principaux :

• Création
  • from : créé à partir d’une collection de données
  • just : créé à partir d’un objet
  • create : créé from scratch
• Sélection
  • take : sélectionne n élément à conserver
  • single[OrDefault] : retourne l’unique élément attendu, jette une exception sinon
  • first[OrDefault] : retourne le premier élément et arrête le flux où jette une exception en cas d’absence
  • last[OrDefault] : retourne le dernier élément et arrête le flux où jette une exception en cas d’absence
  • filter : sélectionne uniquement les éléments répondants au prédicat fourni
• Collecte
  • toList : agrège tous les éléments émis dans une liste jusqu’à ce qu’à complétion de l’émetteur
  • toBlocking : permet de retomber dans un comportement synchrone bloquant
• Transformation
  • flatMap : chaque élément obtenu est transformé via un « flatMap » en une liste d’autres éléments et mis dans une liste commune qui sera rendu lorsque la méthode « onComplete » est invoquée
  • reduce : à partir d’un flux d’événements on va appliquer une méthode qui va nous donner un résultat en sortie onComplete
• Trigger
  • doOnXXX : permet d’ajouter un intercepteur sur chaque événement d’un Observable
• Combinaison
  • concat : fusion de deux flux l’un après l’autre (bout à bout)
  • merge : entrelacement des deux flux selon l’ordre d’arrivée des éléments dans les flux
• Résilience
  • retry : on retente un certain nombre de fois l’opération tant qu’une erreur est remontée
  • onErrorResumeNext : on wrappe le flux dans cette méthode, s’il plante, on peut effectuer un autre appel

L’intérêt du paradigme réactif ne se fait sentir que s’il est déployé sur toute la stack de l’application. Il est pour cela nécessaire que notre framework REST permette de retourner des « promesses de réponse ». DeferredResult est un object de Spring qui permet de retourner des réponses REST asynchrone.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Observable<Map<String, Object>> costObservable = adminService.costForMonth(year, month)
 .map(cost -> {
 Map<String, Object> json = new HashMap<>();
 json.put("month", month + " " + year);
 json.put("cost", cost);
 json.put("currency", "USD");
 json.put("currencySign", "$");
 return json;
 });
DeferredResult<Map<String, Object>> deferredResult = new DeferredResult<>();
// Souscription du DeferredResult à l'Observable
 costObservable.subscribe(
 deferredResult::setResult,
 deferredResult::setErrorResult
 );
return deferredResult;

Avec l’utilisation de DeferredResult, on est enfin complètement asynchrone puisqu’on n’attend pas le résultat de manière active. On ne fait pas de timeout, si le résultat n’arrive pas, on ne fait pas d’attente active, Spring pourra faire autre chose. A noter que DeferredResult est bien un objet Spring et n’a rien à voir avec RxJava. RxJava ne propose pas d’outil pour réaliser des retours asynchrones d’appel HTTP, c’est à la charge du framework utilisé (en l’occurrence Spring). A noter RatPack, une alternative à Spring pour les WebServices http://ratpack.io.

Un hands-on bien mené qui nous a bien montré les intérêts directs que l’on peut avoir à utiliser Rx (polyglotte, performance, fallbacks, etc.).

 Ceylon Idioms (Gavin King)

• CFP Devoxx
• Présentation : Full

Ceylon est un langage de programmation sur la JVM à l’instar de Scala ou Groovy qui a passé le stade de la 1.0 il y a quelques mois maintenant. Cette présentation proposait de passer en revue une dizaine d’idiomes intéressants du langage et il est vrai que son système de typage est assez bluffant.

Ceylon dispose déjà de nombreux outils dans son écosystème et est compatible avec de nombreux contextes d’exécutions (Java SE, OSGi, Vert.x, Node.js, Browser, etc.).

Parmi les fonctionnalités caractéristiques :

• Langage multiplateforme grâce à la JVM
• Réification des types génériques (accès au typage générique au runtime)
• Union et intersection de types
• De nouveaux types Nothing ou Anything qui ne sont que la combinaison de types déjà existants
• De nouvelles représentation telles que Tuple ou Function

Tout d’abord, la combinaison des types permet d’avoir des fonctions à plusieurs types de retour potentiel sans avoir besoin de passé par un super type.

1
2
3
4
5

File|Path|SyntaxError parsePath(String path) => ...
 
 switch(result)
 case(is File|Url)
 ...

Il est possible d’avoir des collections d’objets hétérogènes fortement typés où l’on pourra jouer avec le switch de Ceylon pour effectuer le traitement adéquat.

1
2

List<Integer|Float> list = ArrayList { 1, 1.0, 1 };
Null|Integer|Float elt = list[3];

Le type Tuple est géré avec une LinkedList qui ne lui donne aucune limite et est utilisé pour définir dynamiquement une liste de paramètres à passer à une fonction.

1
2
3
4
5
6
7
8

[Protocol,Path] protocolAndPath = parseUrl("...");
// équivalent à
Tuple<Protocol, Path> protocolAndPath = parseUrl("...");
[Integer, Integer, String] tuple = ...
 
function f(Integer x, Integer y, String string) => x+y
Callable<Integer, [Integer, Integer, String]> callable = f;
Integer integer = f(*tuple)

Gavin King présentait en tout 9 idiomes. La souplesse du système de typage est ce qui m’a le plus marqué dans ce langage et donne envie d’aller plus loin avec et de voir un peu plus ce qu’il permet dans le domaine fonctionnel.

Modular Java Platform (Jigsaw JDK 9) (Brian Goetz)

• CFP Devoxx

Brian Goetz est venu nous présenter Jigsaw, le projet de modularisation du JDK dont on commence à désespérer la sortie reportée depuis le JDK 6 ! Jigsaw c’est la volonté de rendre la plateforme Java SE modulaire et de se débarasser du classpath et du rt.jar.

Motivations :

• Java a commencé comme une petite plateforme de ~2500 classes
• Désormais java a grandi mais il est toujours nécessaire d’avoir toute la plateforme même si on ne se sert que d’une partie (JRE = 55Mb)
• Les classes sun.* et *.internal.* sont des classes internes au JDK dont on ne devrait jamais a avoir utiliser directement. Dans les faits, il faut utiliser SecurityManager::checkPackageAccess dans chaque classe pour assurer l’isolation…
• Jar Hell : le problème apparaît du fait que le classpath n’a aucune information sur les choix a effectuer lors d’un possible conflit (lié à l’import de versions différentes du même jar par exemple)

La solution à ce problème de classpath, de sécurité est d’apporter un système de module (une cinquantaine) au JDK utilisable par le Java SE lui même mais aussi par les autres projets. Pour le problème de taille du JDK, la version 8 a commencé par apporter les profils compact :

• compact1 : 11MB
• compact2 : 17MB
• compact3 : 30MB

Le projet Jigsaw a connu du tumulte. Le premier gros travail a été d’identifier les dépendances existantes entre les différents potentiels module du JDK. Désormais, le projet est séparé en 4 JEP :

• JEP 200 : The Modular JDK
• JEP 201 : Modular Source Code
• JEP 220 : Modular Run-Time Images
• JEP TBD / JSR 376 : Java Platform Module System

La JEP 200 a proposé l’ajout d’une nouvelle méthode getModule() à Class permettant de connaître le module qui a chargé la classe.

1
2
3

$ java -XListModule => liste les modules chargés
jar:file:/path/to/jdk/jdk8/jre/lib/rt.jar|/java/lang/Class.class // Java 8-
jrt:/java.base/java/lang/Class.class // Java 9

Les modules peuvent dépendre les uns des autres mais il existe deux types de dépendances :

• Implementation Dependency : utilisé par le module mais non exposée pour les autres modules qui vont l’importer
• API Dependency : une dépendance qui va être nécessaire pour les modules qui vont utiliser le module en question.

Ceci règle le problème d’exposition des packages internes sun.*  et *.internal.*.

La JSR 376 propose un moyen pour les développeurs de définir leurs propres modules. Elle prévoie :

• une API Reflection pour les information du module
• l’intégration avec les outils (Maven, Gradle, IDE, etc)
• l’intégration avec les package managers (RPM, etc.)
• la configuration dynamique des graphs de module (EE Containers)

Finalement j’ai trouvé la présentation très intéressante et le projet à l’air d’avancer correctement !

Java; the next 20 years (Brian Goetz)

• CFP Devoxx
• Ressources : JEP

Après avoir rappelé les évolutions du langage pour proposer les classes génériques, Brian Goetz nous parle des Value Object pour regrouper les attributs des classes en mémoire et dans les conteneurs, afin de réduire le travail du Garbage Collector et les cache-miss du processeur lors de la navigation dans les objets. Cela permettra d’avoir les mêmes performances que le C++ ou C#. C’est une bonne évolution pour les algorithmes à haute fréquence.

Outils

Le taré du terminal : Outil pour développeur de l’extrême (Emmanuel Bernard)

• CFP Devoxx
• Présentation : Full Asciidoc

Présentation d’Emmanuel Bernard (Red Hat, Cast Codeurs) sur sa manière d’utiliser son outil de travail en automatisant au maximum son workflow, pour éviter le context switching durant son travail.

Il nous a notamment parlé de son environnement de commande TMux qui offre la possibilité de préparer plusieurs « univers » qui vont permettre de conserver différents contextes de travail. Il est également un grand friand de Vim qui offre un système de commandes efficace basé sur le pattern suivant :

[action][repetition multiplier]movement

• d2f. : supprimer 2 lignes et avancer jusqu’au prochain « . »
• shift + v : mode visuel vim
• set col « n » : largeur du document
• gq : mettre la sélection trop large à la bonne largeur de document
• J : mettre la sélection trop courte à la bonne largeur de document
• 0 : début de la ligne
• W : mot suivant
• dW : supprimer le mot suivant

Il existe également des plugins IdeaVim (IntelliJ) ou Vrapper (Eclipse) qui permettent d’avoir un environnement Vim dans son IDE préféré.

Plusieurs automatismes quotidiennement utilisés par Emmanuel :

Lorsque je me connecte pour la première fois à un serveur, on me demande mon mot de passe et j’envoie automatiquement ma clé ssh en autorized_keys.

Lancer une pull request qui faire le merge et l’ouverture du navigateur à la bonne page automatiquement.

Utiliser remote pour lancer compilation et tests en background et lancer une notification desktop à la fin permettant de faire du context switching efficace sur ses réseaux sociaux !

Le leitmotiv de ce talk fût finalement de ne pas hésiter à automatiser un maximum de tâche que l’on répète ne serait-ce que quelques fois par semaine. Pour s’inspirer, une communauté existe autour des dotfiles qui permet de trouver plein d’exemples (cf. https://dotfiles.github.io) qui donne vraiment envie de s’y mettre ! De même pour Git ou l’utilisation d’alias peut-être un premier gain de temps mais l’écriture d’un plugin relativement simple peut rendre de grands services aussi.

Un Jenkins amélioré avec Docker, Mesos et Marathon (Jean-Louis Rigau)

• CFP Devoxx
• Présentation : Full
• Ressources : TIA Mesos

Inspiré de Delivering Ebay’s, ce Tools in Action par Jean-Louis Rigau consistait à présenter rapidement un use case d’utilisation d’Apache Mesos et un de ses framework, Marathon, pour rendre son Jenkins fortement scalable !

Objectifs du Tools in Action (TIA) :

1. Simplifier la gestion de Jenkins en le conteneurisant avec Docker et le déployer dans Mesos via Marathon
2. Utiliser les ressources de Mesos pour créer des slaves Jenkins à la demande

Jenkins est un serveur d’intégration continue, maintenu par Cloudbees, écrit en Java. Ceux qui l’utilisent savent qu’il est généralement difficile à maintenir et à mettre à jour !

Docker est un gestionnaire de conteneurs opensource, écrit en Go, créé et maintenu par Docker Inc. Il sert à la construction d’applications et au déploiement sur tout type d’environnement.

Mesos est un gestionnaire de cluster opensource par Apache, écrit en C++. Il permet de gérer les ressources de son Datacenter et de se créer son propre cloud en allouant intelligemment ses ressources selon les besoins de ses applications.

Enfin Marathon est un framework Mesos opensource par Mesosphere qui est écrit en Scala. Il se charge du déploiement et management de conteneurs basés sur Mesos et joue en quelque sorte le rôle de sur couche simplificatrice.

En bref, le schéma d’architecture qui nous a été présenté lors du tools-in-action. J’achète si cela peut permettre de retrouver confiance en son Jenkins !

Le Continuous Merge chez LesFurets.com (Pflieger Arnaud)

• CFP Devoxx
• Présentation : Full
• Ressources : Github

L’équipe des furets ont fait le choix d’utiliser Git en mode feature branch. Malgré toutes les alertes sur cette approche, ils ont persisté et proposé des plugins à Git pour faciliter le merge multiple. L’idée est de sélectionner avant la mise en production, l’ensemble des branches à lier. Le résultat est placé dans un branche tampon sans historique. Les problèmes peuvent alors être résolus suivant plusieurs approches :

• faire un rebase d’une branche sur une autre pour aider au merge global
• ajouter des features flags
• etc.

Avec cette approche, ils publient plusieurs fois par jours.

Mais aussi…

Devoxx c’est 200 conférences en 3 jours et des choix à chaque session difficiles à faire ! Ci-après vous trouverez quelques conférences en vrac, non moins intéressantes !

• Le futur de la robotique personnelle (Rodolphe Gelin) : Cette conférence a été un grand moment. Des démonstrations en vidéo ont montrée où se focalise les recherches en ce domaine. Les robots doivent prélever les informations, deviner les sentiments du locuteur et analyser les signaux sonores pour savoir qu’on leur parle. C’est bien plus complexe qu’utiliser Google Now ou Siri.
• La problématique du contrôle des technologies de l’information (Eric Filiol) : Eric Filiol, grand prêtre de la sécurité nous a expliqué que nos dirigeants proposent des lois inapplicables car ils ne comprennent rien et sont faibles. Cela donne l’illusion de la sécurité, en offrant toute les dérives possibles sur un plateau. Il nous rappelle que les bugs que nous laissons sont les portes ouvertes à notre propre vie privée. Pensons-y !
• I don’t always write Reactive applications, but when I do, it runs on Raspberry Pi (Alexandre Delegue) : Une conférence très amusante où une pile de Raspberry Pi organisés en Cloud mobile est utilisée pour un site de commerce codé avec les stacks réactives Scala, Play et Akka.
• La phygitalisation, le super pouvoir du développeur pour créer des objets connectés! (Cyril Lakech) : Avec quelques centaines d’euro, un RaspberryPI, un Arduino, du cable et des LED, ils nous expliquent comment ils ont monté un rayon augmenté. Des leds s’allument et s’éteignent au fur et à mesure de l’ajout des critères de recherche. Cela permet de retrouver plus facilement un produit en rayon. Le code est ridiculement simple et l’expérience est top !
• Un robot peut-il apprendre comme un enfant ? (Pierre-Yves Oudeyer) : Pierre-Yves Oudeyer, directeur de recherche à l’Inria, nous a fait une démonstration d’un robot qui analyse son environnement au hasard, puis privilégie certaines pistes pour améliorer efficacement sa connaissance. Voir un robot sur un tapis pour bébé, jouer avec des mobiles ou communiquant avec un autre robot c’était vraiment sympathique et incroyable d’autant plus quand on sait qu’ils ne connaissaient rien avant de commencer.
• The upcoming decentralisation singularity. (Stephan Tual) : Stephan Tual nous propose de découvrir Ethereum une machine de Turing complètement décentralisée, dérivé des travaux sur les Bitcoins. Ce projet permet de mettre à disposition des développeurs une plateforme résistante aux fraudes.
• Recettes CQRS, pour bien cuisiner son architecture (Thomas JASKULA) : Thomas JASKULA nous parle de son expérience sur des architectures CQRS (Command Query Responsibility Seggregation). Il sépare la notion de commande synchrone et d’événement asynchrone. Il propose d’isoler les sous-systèmes en mode DDD (Domain Driven Design) et de les relier via un bus de message. Il propose également la méthode agile “Event Storming” proposée par Alberto Brandolini.
• http/2: A deux c’est mieux ! (Jean-François Arcand) : Jean-François Arcand nous présente les nouveautés de HTTP/2. Il explique en quoi cela représente une évolution importante. Il a la crainte que cela prennent des années avant de pouvoir l’utiliser partout, comme pour l’IP v6 qui date de 1996 ! La norme étant toute récente, il y a encore peu de retours d’expérience. Les évolutions de J2EE pour intégrer cela ne sont pas de son goût. Il préférerait une remise à plat des API pour exploiter au mieux HTTP/2 plutôt que d’étendre les API actuelles des servlets.
• Infinite Infinispan (Ray Tsang) : Une équipe de Google nous explique comment Infinispan permet d’ajouter et surtout d’enlever dynamiquement des machines. Il y a des scénarios plus complexes que d’autres mais il faut retenir que c’est une problématique à intégrer dès le début de la réflexion des architectures élastiques. A noter qu’Infinispan est régulièrement utilisé comme un cache distribué.

Le DevOps Day, c’est 2 jours de conférence intensifs où vous pourrez assister à de nombreuses présentations telles que :

• Containers, Germs, and Microservices parJohn Willis (Docker Inc.)

• What Happens Without Traction par Steve Pereira

• The importance of Why in DevOps par Boris Feld (Tinyclues)

• Bizdevops – from development to the customer par Sabine Bernecker-Bendixen (sof-ITby Personal Best!)

• DevOps Culture at BlaBlaCar – Keep CAMS and grow par Regis Allegre & Nicolas Blanc (Blablacar)

• Cognitive biases and our poor intuitions around probability par Nigel Kersten (PuppetLabs)

• Designing the Enterprise for Manufacturing par Scott Russell (Chef)

• Change management at scale: responsible agile delivery par Pierre-Yves Ritschard (Exoscale)

• Making the Elephant dance – Daily deliveries at SAP par Dirk Lehmann (SAP SE)

• Screwing up for fun and profit par Oliver Hankeln (HankelnConsulting)

Retrouvez tout le programme de la conférence ici.

En tant que sponsor, XebiaLabs vous fait bénéficier de 20% de réduction sur les billets avec le code de réduction "THANKS-XEBIALABS". Profitez-en.

Et évidemment, pour bien se préparer à la conférence, n’oubliez pas de relire le Techtrends DevOps.

Rendez-vous dans quelques jours.

Notre crédo : garantir l’excellence, la variété et l’adaptabilité de nos prestations.

NOS FORMATIONS PREMIUM : MARS – AVRIL

OFFICIELLES EN BIG DATA

– Analyse de données pour Hadoop 2.X Hortonworks avec Pig & Hive : 16 – 19 mars 

– Développer des applications pour Hadoop 2.X Hortonworks avec Java : 23 – 26 mars 

– Développer des applications pour Hadoop 2.X Hortonworks sous Windows : 7 – 10 avril 

www.octo.academy – academy@octo.com – @OCTOAcademy

AGILE & LEAN

– Découvrir les démarches agiles & la culture agile 16 – 17 mars

– Le rôle de Product Owner en pratique 18 – 19 mars

– Conception logicielle : écrire des cas d’utilisation efficaces 20 mars 

– Lean IT : optimiser ses flux plutôt que ses ressources 13 – 15 avril 

EN EXCLUSIVITÉ

– Créer un SI hybride avec le Cloud 30 – 31 mars

– Design Thinking : adapter ses pratiques pour une innovation participative 30 – 31 mars

– Fondamentaux de la Data Science 1er – 3 avril

– DevOps par la pratique 1er avril 

www.octo.academy – academy@octo.com – @OCTOAcademy

Ces dix dernières années ont vu le développement incroyable des projets Agiles qui se sont généralisés à travers les DSI du monde entier. Que cela soit votre premier projet Agile ou que cela fasse des années que toute votre entreprise a terminé sa migration, le résultat est bien souvent le même, les projets Agile livrent très régulièrement de nouvelles versions applicatives.

Malheureusement une version livrée par l’équipe de développement n’est d’aucune utilité tant qu’elle n’est pas en production. Et c’est bien souvent là que les choses commencent à coincer…

Dans cet article en deux parties nous verrons tout d’abord les indices montrant qu’il y a un problème puis dans une seconde partie comment améliorer la situation.

Un problème ?

• Vous avez beau livrer plus fréquemment, les versions n’arrivent pas plus vite en production
• MEP rime plus avec Mise en Problème que Mise en Production
• L’infrastructure est très peu Agile: les projets attendent longtemps leur environnement ou des modifications sur celui-ci
• Aucune communication entre les équipes projets et les équipes opérationnelles

Des solutions !

Si vous souhaitez en savoir plus, n’hésitez pas à consulter le Techtrends DevOps entièrement dédié à ce sujet:

The event itself was beautifully organised in a lovely space right in the centre of Paris (just off the Champs Elysées with several metro lines nearby). Many local companies were around as sponsors, including Normation (see why we were in a village dedicated to real free software – in French). Coffee, croissants, lunch and evening drinks were provided, and even some regional specialties from south west France (Bordeaux wine, Bayonne ham and Basque cheese – yum!).

The devops track took place on Friday morning, and I must say (as humbly as it possible to do so in a blog post about something I organised myself) that I’m very pleased with how it turned out. We were lucky enough to have one of the larger rooms in the venue, with a solid 60-ish attendees throughout the morning, and a video capture of all the talks.

The morning started out very tool-oriented, with two talks in French about Ansible and how to contribute to it, and Docker and how to manage it:

• How to participate and improve the ecosystem of Ansible by Simon Constans (@kos_si)
• Docker, l’étoile montante DevOps by Pierre Padrixe (@undefd) and Julien Vey (@julienvey)

After a short break (where I was happy to see several of the folk from the devops room come to our booth and chat :D), the morning moved on from tools to a much more culture-centric topic, with a talk in English from Fabrice Bernhard (@theodo) titled Digital transformation in large organisations – A real-life journey to devops in a French bank. This talk got a lot of attention, opening the eyes of many in the audience. The real-world talk about changing habits, questioning rules and introducing quick, iterative, development pushed to production servers in real time, within a large organisation got a lot of people thinking. I was particularly impressed that this French bank had taken the idea to heart and actually managed to get the CISO on board with the effort, helping them circumvent his own security policy when it made sense for the team and the business.

devops panel at Open World Forum

Last but not least, I closed the track by animating a panel discussion with some of the previous speakers and a “guest star”, Daniel Maher (@phrawzty). After covering the panelists background stories, we opened with a few questions I had prepared, on trying to show the way to “get started with devops” via some concrete actions. This got the speakers warmed up and sparked some questions from the audience. Across a varied selection of topics, I was very pleased to see a theme emerging: our panel was now talking more about culture, sharing and aligning to the business than technicalities and tools.

I feel this was a real success – after fighting to get some non tool-based talks into the devops track (which is in the “Code” theme at Open World Forum…), we managed to talk culture and empathy and everyone there loved it. I even had some students come up to me later in the day to say the devops panel was “amazing, the best part of the whole event”!

The videos from the track should be online shortly. I’ll post back here when they are – and in the mean time, book your tickets for next year’s event!

The post A recap of the devops track at Open World Forum 2014 appeared first on Rudder by Normation.

Agilité

8 pratiques critiques DevOps

Par Ludovic Perot

La convergence Agile / DevOps constitue le passage d’un cap dans la maturité d’une structure agile. Dans cet article, l’auteur liste 8 pratiques incontournables.

Pour des agilistes, les équipes dédiées, raisonner en MVP, délivrer en petits lots et la transparence devraient trouver un écho tout particulier.

http://devops.com/features/eight-critical-devops-practices-innovate-deliver-repeat/

Mobilité

Android – Implémentez les nouveaux composants de Material Design dans vos applications facilement

Par Gautier Mechling

Google (par l’intermédiaire de Chris Banes et Nick Butcher) vient de publier un excellent guide pour les développeurs répertoriant de manière très claire tout ce qu’il faut savoir pour mettre en place les nouveaux composants de Material Design dans ses applications.

Des explications et exemples de code sont fournis pour implémenter tous ces nouveaux composants : toolbars, ombres, nouvelles vues sous forme de carte, API palette permettant de récupérer les couleurs principales d’une image, et nouvelles animations (transitions activités/fragments via éléments partagés, reveal effect, stateListAnimator).

L’article est disponible sur ce lien, et est un must-read pour tous les développeurs Android.

Google Inbox utilise J2ObjC

Par Simone Civetta

J2ObjC a été publié depuis déjà quelques temps et ceci n’est pas une nouveauté. Ce qui est relativement moins connu, par contre, c’est que cet outil est toujours maintenu et utilisé par Google. En effet, grâce à ce post sur le Google Group du projet les développeurs de la nouvelle application Google Inbox (tout comme Google Sheets et Drive) ont confirmé que J2ObjC a été utilisé pour développer le nouveau client mail de Mountain View. Cela va sans dire, comme J2ObjC ne gère pas les librairies UIKit, la partie IHM a été développée directement en Objective-C et seulement le code métier est le résultat d’une conversion. Il reste tout de même intéressant de voir que ce projet est activement maintenu et utilisé par les ingénieurs Google. 

Craftsmanship

Global Day of Coderetreat

Par Diego Lemos

Le 15 novembre prochain (samedi) il y aura lieu partout dans le monde le Global Day of Coderetreat. Cet événement se déroule sur une journée et les participants travaillent ensemble sur un exercice (kata), afin d’améliorer leurs techniques de développement et design. Pendant toute la journée, les développeurs auront l’occasion d’échanger et d’essayer des nouvelles techniques sans la pression du travail de tous les jours. Dans cette vidéo, Corey Haines, l’un des créateurs du Coderetreat, explique le concept plus en détail.

A Paris, les inscriptions pour le Global Day of Coderetreat sont ouverts ici et ici. Si vous n’êtes pas à Paris, vous pouvez chercher ici l’événement le plus proche de votre région.

Front

Roadmap de TypeScript

Par Benoit Lemoine

L’équipe TypeScript annonce aujourd’hui sa roadmap pour les versions à venir.

• la version 1.2 se voulait une version corrective de la 1.1 . N’ayant pas de bugs majeurs, elle n’existera pas !
• la version 1.3 va se focaliser sur la standardisation de l’outillage ligne de commande, et ajoutera les types Tuples ainsi que la visibilité protected ;
• la version 1.4 ajoute le type union ;
• la version 1.5 et supérieur (2.0) veulent ajouter des fonctionnalités compatibles ES6.

Cette annonce est par ailleurs intéressante car elle met en lumière le fait que les équipes Microsoft travaillant sur TypeScript travaillent activement avec Facebook et Google car ces 2 entreprises sont chacunes en train de créer un langage super-ensemble de JavaScript typé statiquement (Flow pour Facebook et AtScript pour Google). On voit ici que la vieille réputation de Microsoft n’est plus d’actualité et qu’ils ont compris que le partage était la meilleure façon de s’enrichir !

Annonce de Jquery 3.0.0

Par Benoit Lemoine

JQuery annonce cette semaine l’arrivée prochaine de sa version 3.0.0. Cette version remplacera et la branche 1.x.x et la branche 2.x.x. Cependant pas de panique, il y aura 2 builds différents :

• Jquery 3.0.0 supportera les 2 dernières versions des browsers principaux du marché
• Jquery 3.0.0 compat supportera les vieux Internet Explorer.

La majorité des API restant rétro compatible, ce saut de version marque surtout la fin du double versionning. Et prouve que l’on peut être une librairie mainstream, et respecter correctement le versionning semantique. N’est ce pas underscore.js.

Back

Redis ou memcached ? Comment choisir

Par Romain Niveau

Redis et memcached sont deux outils open source utilisés pour faire du cache distribué. Les deux existent depuis quelques années et ont fait leurs preuves en production.

Comment choisir entre les deux ? 

Cet article nous propose de revoir les similarités entre les deux outils ainsi que leurs principales différences afin de nous aider à choisir.

Spring AMQP 1.4 RC1

Par Nicolas Jozwiak

Spring publie la version Release Candidate de AMQP. Voici les nouveautés et améliorations :

• Annotation @SendTo pour envoyer le résultat d’une méthode 
• Ajout du RabbitMessagingTemplate
• Ajout du Logback appender AmqpAppender
• Ajout du support pour RabbitMQ 3.4.0

Vous trouverez plus de précisions à cette adresse.

Le coin de la technique

DevFest Nantes

Par Thomas Guerin

Le vendredi 7 Novembre de 8h20 à 18h se tiendra la 3ème édition du DevFest Nantesà la Cité des Congrès. Cette année 24 sessions réparties en 5 tracks (Mobile, Cloud, Web et Découverte) sont au programme. Au menu ManageVM, Android Wear, Docker, Firefox OS …Pour plus d’informations le programme est disponible ici : http://devfest.gdgnantes.com/#nav-agenda

Alors que celle-ci est souvent vue comme un aboutissement, elle n’est qu’une première étape pour parvenir à des réalisations efficaces et maîtrisées.

Intégration continue, un socle indispensable

Pièce maîtresse de l’usine de développement, le serveur d’intégration continue est essentiel à tout projet de développement logiciel. Que ce soit Jenkins, Bamboo ou autre, il assure la bonne compilation du code, le jeu des tests unitaires, le packaging, le déploiement et l’exécution des tests dans un environnement d’intégration. Il est en outre indépendant des configurations spécifiques aux postes de développeurs pour éviter tout contournement des règles de base de qualité (assurées par SonarQube, par exemple) et garantir la répétabilité des processus.

Le code packagé est archivé dans un référentiel central. Cette archive sera utilisée pour le déploiement sur l’ensemble des environnements, y compris la production.

L’intégration continue fiabilise les activités de développement. Une fois en place, elle autorise l’organisation projet à pousser l’industrialisation au-delà des frontières de l’équipe de développement.

Déploiement automatisé, une nécessité

Il devient alors possible d’automatiser progressivement les actions de déploiements auparavant réalisées manuellement par l’équipe d’exploitation (mise à jour de bases de données, déploiement dans un serveur d’applications, etc.).

En plus de supprimer des tâches fastidieuses, cette automatisation permet de fiabiliser le processus de déploiement tout en augmentant la fréquence des livraisons pour validation auprès des utilisateurs.

Ces déploiements automatisés peuvent aller de scripts de déploiement dans les cas les plus simples jusqu’à la recréation complète de l’environnement cible (via des outils comme Puppet, Chef ou Docker). Tout comme le code, ces scripts et paramétrages ont leur place dans un gestionnaire de sources.

Cette étape ne peut être franchie sans la collaboration entre les équipes de développement et d’exploitation.

A ce stade, le déploiement en intégration peut d’ores et déjà se faire  automatiquement et fréquemment, s’il n’a pas d’impact au delà de l’équipe de développement. Les développeurs peuvent alors rapidement tester leur code dans un environnement proche de la cible.

En revanche, les déploiements sont déclenchés manuellement pour les environnements de qualification et de production, ce qui permet de rassurer l’ensemble des acteurs (équipe projet, clients et décideurs) tout en offrant un gain de temps non négligeable.

Tests d’acceptation automatisés, un idéal

Pour améliorer encore le time-to-market, il est nécessaire de réduire le temps dédié aux tests d’acceptation en environnement de qualification. Les testeurs, autrefois employés à les jouer de façon répétée, doivent désormais consacrer leur temps à la rédaction de tests automatisés. La qualité de ces tests ainsi que la couverture de l’application s’améliorent, ce qui assure la conformité aux attentes des utilisateurs.

L’exécution des tests est assujettie au déploiement automatisé de l’application, ce qui supprime encore des étapes manuelles et fluidifie le processus de livraison.

Déploiement continu en production, le graal ?

De nos jours, l’intégration continue est monnaie courante et son efficacité n’est plus à prouver. Elle constitue un prérequis pour quiconque souhaite moderniser ses pratiques de développements.

L’automatisation des déploiements en intégration est de plus en plus répandue, elle ajoute une visibilité aux développeurs quant à leurs réalisations.

L’automatisation des tests d’acceptation est moins fréquente. Elle correspond à une industrialisation poussée du processus de développement qui aboutit à une réduction du time-to-market.

Une fois la chaîne du développement jusqu’à la qualification maîtrisée, il ne reste plus qu’un pas à franchir pour parvenir au déploiement continu en production. Seule une poignée d’acteurs ont franchi le pas, de par la nature de leur activité (Google, Twitter, Amazon, etc.).

C’est ici que le changement est perçu comme le plus important, tant l’impact humain est grand. Des freins organisationnels notables subsistent (respect des normes, frilosité, communication lors des mises en production), et le bénéfice n’est pas évident pour tout le monde.

Retour sur la Journée DevOps organisée dans nos locaux le 10 juin dernier.

L’objectif de cette matinée, dédiée au mouvement DevOps et au Continuous Delivery, était d’échanger sur les synergies entre les équipes, les pratiques managériales et les outils afin de délivrer le meilleur logiciel aux clients de l’entreprise.Nous avons le plaisir de partager avec vous les différentes sessions de la matinée sur notre chaîne Viméo

En cliquant sur les liens, retrouvez :

–  la Keynote d’ouverture de Carlos Goncalves – Directeur des systèmes d’information de la banque de Grande Clientèle & Solutions aux Investisseurs, Société Générale

– Le retour d’expérience d’Antoine Raith, Responsable Développement socle eCommerce, SFR

– Le retour d’expérience avec Gilles Philippart, Coach Agile, Banque de Grande Clientèle et Solutions aux Investisseurs, Société Générale

Bonne séance !

Au passage merci aux organisateurs pour cette édition 2014. Les conférences sont toujours l’occasion de discussions passionnées sur les sujets les plus chaud du moment et puis c’est cool finalement de pouvoir assister à des conférences sans rien avoir à faire. Bravo aussi à l’initiative de faire un repas ouvert à tous le jeudi soir. On a ainsi pu partager les discussions passionnées des speaker diners avec d’autres passionnés.

Le but ce cette présentation est de revoir un peu nos idées reçues sur le monitoring. Même si le sujet n’est pas forcément très hype, Lean et Devops changent notre vision des mesures et les outils BigData viennent à notre secours.

La présentation se trouve là.

Sébastien Brousse a twitté sur une partie de la présentation où je fais un détour par la matière noire. Je pense que le rapport avec le monitoring est peu évident sans les explications que j’ai donné de vive voix et le slide ne vous sera pas forcément d’une grande aide.

Pour ceux qui n’étaient là en attendant la vidéo voici les explications et même quelques infos supplémentaires.

Mais pourquoi la matière noire ?

Non, je n’ai pas changé de métier, la présentation parlait bien de monitoring.

Tout d’abord il y a peu de femmes dans l’informatique et donc dans les conférences, et c’était l’occasion d’avoir deux grandes dames avec nous, Margaret Burbidge et Vera Rubin, deux astrophysiciennes.

La première a imaginé le concept de matière noire, la seconde a poursuivi les travaux et mis au point une méthode pour prouver son existence.

Nous on est n’est pas des astrophysiciens, je vais rester à un niveau assez général. Pour les détails, sur la matière noire je vous renvoie à Wikipedia.

Des galaxies prises en excès de vitesse

Cette découverte a un rapport avec le monitoring parce que tout ça découle de problèmes de mesure.

Les astronomes avait constaté depuis longtemps que les galaxies spirales tournaient trop vite par rapport à la masse qu’elles sont supposées avoir d’après les mesures.

Plusieurs hypothèses ont été avancées pour expliquer cette bizarrerie en particulier l’imprécision des mesures.

Dans les années 1970, Margaret Burbidge a refait les mesures avec toute la précision des moyens de l’époque. Et là, ça ne collait toujours pas.

Plutôt que de remettre en cause les mesures, Margaret Burbidge a remis en cause le raisonnenment. Si la vitesse ne colle pas avec la masse, c’est que la masse n’est pas celle que l’on pense.

A cette époque on évalue la masse à partir des objets que l’on peut observer au téléscope, donc ceux qu’on peut voir parce qu’ils émettent de la lumière. Par conséquent, elle en a déduit qu’il y a dans les galaxies quelque chose qui a une masse mais que l’on ne voit pas parce que ça n’émet pas de lumière. C’est le concept de matière noire.

Vera Rubin qui travaillait avec Margaret Burbidge a apporté des éléments de preuve en mettant au point une méthode de calcul de la masse basée sur l’influence gravitationnelle de la galaxie sur son environnement, ce qu’on appelle la masse dynamique. A la différence de la masse lumineuse, la masse dynamique est compatible avec la vitesse de rotation des galaxie spirales. Et la masse dynamique basée directement sur l’effet de la masse n’a pas de raison d’être fausse, ce qui justifie qu’il y a un élément non visible ayant une masse.

Bon, d’accord mais moi je mesure des requêtes HTTP

Ok, nous on ne mesure pas des galaxies, mais même si on peut parfois regarder le serveur, enfin la boîte, finalement ce qu’on mesure est tout aussi peu visualisable.

Cette histoire montre que c’est important de mesurer de la bonne manière.

Si on mesure des effets indirects, on est dépendant d’un modèle. Ce modèle c’est l’idée qu’on se fait du fonctionnement du système et il peut être faux.

Dans un certain nombre de cas, cette mesure indirecte marche, par exemple la masse lumineuse convient pour les objets très lumineux comme les étoiles. Mais de temps en temps, ça ne marche pas.

Bien sûr, on n’a pas toujours la possibilité de mesurer l’effet direct, et de temps en temps on doit se baser sur une mesure indirecte parce que c’est plus abordable. Dans ce cas il faut rester vigilant, et savoir remettre en cause le modèle qu’on se fait du système.

Notre matière noire

Qu’est ce que c’est notre matière noire à nous les informaticiens ?

Ce sont les caches, les buffers, les load balancers, les heuristiques sur les files d’attente, les optimisations de JVM, tout un tas de mécanismes internes au système qui le rendent plus performant, mais qui font aussi que certaines de nos mesures ont un comportement erratique ou n’ont plus de sens dans certaines situations.

Au final, mesurer correctement les performances d’un système ou d’une application informatiques est une activité qui réserve toujours des surprises. On ne peut pas se contenter de poser des sondes au petit bonheur la chance sans comprendre ce qu’on fait. Il faut comprendre le système et comment il fonctionne pour le mesurer correctement.

On a un peu plus de chances, en cas de doute on peut souvent se reporter à la documentation (quoique à la réflexion pas toujours) ou demander au développeur (enfin des fois … ).

Mais par contre, un cache c’est beaucoup moins beau sur les photos qu’une galaxie spirale.

Les images proviennent toutes de la galerie d’images de la Nasa.

A cette occasion, Xebia ouvre ses portes afin d’échanger durant une après midi sur les synergies entre les équipes d’exploitation et les équipes de développement. Le but étant de fluidifier les processus et d’atteindre un but commun : délivrer le meilleur logiciel aux clients de l’entreprise.

Programme

• 14h-15h :

La boite à outils de l’équipe DevOps
Puppet, un outil pour les installer tous 

• 15h05-16h05 :

De l’Intégration Continue au Déploiement Continu avec Jenkins
Culture, automatisation, mesure et partage sont les piliers du déploiement applicatif avec XL Deploy de XebiaLabs 

• 16h10-17h10 :

Graphite, un outil de monitoring applicatif
Atelier AppDynamics 

• 17h15-18h15 :

Tests de performance en continu
Des dashboards pour tous avec ElasticSearch, Logstash et Kibana

Intervenants

• Clément Rochas, consultant chez Xebia,
• Matthieu Nantern, consultant chez Xebia,
• Cyrille Leclerc, Architecte Solutions chez CloudBees,
•  Geoffroy Warin, consultant chez Xebia,
•  Benoit Moussaud, directeur technique de XebiaLabs France,
• Charles Blonde, consultant chez Xebia,
•  William Montaz, consultant chez Xebia,
•  Guillaume Arnaud, consultant chez Xebia,
•  Vincent Spiewak, consultant chez Xebia.

Intéressé(e) ? Plus d’informations ? Comment s’inscrire ? 
Rendez-vous sur notre page dédiée à l’événement Journée DevOps. 

We’re happy to announce that Theodo has been confirmed as a bronze partner of dotScale 2014 !

dotScale is a unique tech conference on Scalability, DevOps and Distributed Systems. The best hackers worldwide are invited to share their insights on stage! This year’s edition will count the likes of Paul Mockapetris (inventor of the DNS), Jeremy Edberg (former Reddit Chief Architect and Site Reliability lead at Netflix), Mitchell Hashimoto (creator of Vagrant) or Fabien Potencier (creator of Symfony). Many others have been announced for a promising line-up !

The series of conferences will take place on May 19th in Paris. See you there !