SnowCamp 2020

Le pattern _API Gateway_ est une solution bien connue au problème de la communication avec une application conçue en _microservices_. Il permet d'éviter aux navigateurs ou terminaux mobiles d'envoyer un grand nombre de requêtes pour afficher un seul écran ou page web.

En pratique, ce pattern est souvent implémenté par un service HTTP/JSON. C'est pourquoi il est souvent difficile pour les développeurs web, mobile et backend de se mettre d'accord sur un format d'échange qui soit à la fois flexible et concis tout en répondant au besoin de chacun des frontends.

GraphQL est un langage de requête et de définition de schéma pour vos services backend. Il peut-être utilisé sur différents transports (par exemple HTTP ou Websocket) et donne aux développeurs frontend la capacité de recevoir exactement la quantité de données dont ils ont besoin. Cela fait de lui un très bon candidat à l'implémentation du pattern _API Gateway_.

Ce workshop commence par une brève introduction à GraphQL. Puis vous développerez une _gateway_ pour une application de vente de musique. Vous apprendrez comment charger des données depuis des services HTTP ou une base PostgresSQL et protéger vos utilisateurs avec de l'authentification. Nous nous concentrerons sur le cas d'utilisation plutôt que sur la technologie GraphQL elle-même (on peut trouver facilement de la documentation sur le web).

Pré-requis pour cet atelier
- d'un JDK8 or JDK11
- d'une version récente de Maven
- d'une version récente PostgreSQL (ou de Docker)
- d'un IDE Java

Mettons ensemble les mains dans le cambouis d'Apache Kafka et Kafka Streams !

On entend parler de Kafka partout, et Confluent Inc fait de son mieux pour que le buzz ne s'arrête surtout pas. Il faut bien reconnaître que si Kafka, le log, s'impose comme élément incontournable de applications distribuées depuis 2011, ce n'est pas pour rien. D'ailleurs, les fonctionnalités plus récentes de Stream Processing et de base de données distribuée en font plus une solution "end to end" qu'un simple "building bloc".

Pourtant nous même, qui l'utilisons en production depuis plus de 2 ans et avons déjà animé des ateliers sur le Stream Processing avec Kafka, nous sommes rendu compte que malgré les beaux schémas et les promesses, Kafka n'est pas si facile que ça à maîtriser. Et certains concepts qui nous semblaient clairs ont finalement nécessité que l'on se replonge dans le design de la bête.

Dans cet atelier nous proposons une présentation générale d'Apache Kafka et Kafka Streams en mettant l'accent sur les aspects qui peuvent sembler simple de prime abord mais dont les subtilités se cachent entre les lignes (assignation des partitions, transactions, etc.).
Et bien sûr, ensuite, place à la pratique et à la résolution de problèmes pour prendre en main l'API Processor, le DSL, la gestion de l'état en mode tests unitaires ou sur un cluster standalone. Et pour les plus rapides : injection de failles pour voir comment la maintenance des garanties ("delivery semantics") de Kafka (Streams) se manifeste.

Pré-requis pour cet atelier
IntelliJ IDEA Community Edition ou supérieur

Dans le cadre d'un projet IOT d'envergure dans lequel nous devons télé-relever des informations de capteurs disséminés partout en France, nous avons mis en place une architecture de stream processing à base de microservices Java, Apache Nifi et Apache Flink.
Une telle architecture présente l'avantage d'une meilleure maintenabilité et d'une meilleure scalabilité. Cependant, sa mise en oeuvre est plus délicate et la robustesse de l'ensemble de la solution nécessite des précautions supplémentaires. D'autant plus, lorsque le client annonce qu'une garantie transactionnelle infaillible doit être apportée sur l'ensemble de la chaîne.
Notre approche originale a consisté à s'appuyer sur l'usage d'un orchestrateur externe qui permet d'implémenter plusieurs design patterns de microservices : la traçabilité globale, les sagas transactionnelles et la supervision distribuée. Cet orchestrateur s'appuie sur la solution Opensource Camunda, qui s'appuie elle-même sur la norme Business Process Modeling permettant de décrire des processus métiers complexes et d'orchestrer un système complet. Cela présente donc le triple intérêt de superviser, orchestrer et documenter le fonctionnement du système.
Lors de cette session, nous aurons donc l'occasion d'aller au delà du discours commercial de la magie du microservices pour aborder les véritables problématiques de la supervision et de la mise en production d'une architecture répartie complexe.

Bénéfices de la session :
Découvrir les design patterns de l'architecture microservices
Découvrir ou approfondir les problématiques d'une telle architecture complexe répartie
Découvrir le business process modeling et son application sur un tel problème
Découvrir le produit opensource Camunda

Nos systèmes sont designés de manière optimiste, de la gestion technique des erreurs à la modélisation de nos interfaces.
Que ce soit les codes d'erreurs, les exceptions ou les modélisations plus avancées, elles servent pour arrêter un traitement et _potentiellement_ afficher un message d'information à un utilisateur.

Mais avec les architectures microservices, la distribution des traitements ou une simple volonté de résilience, la gestion des erreurs est devenue un enjeu important de tous les systèmes afin qu’ils restent accessibles de tous, tout le temps tout en maintenant le système dans un état cohérent.

Que fait-on lorsqu’une erreur intervient ? Peut-on compenser voire gérer l’erreur depuis le système pour l’utilisateur ?

La réponse a ces questions se trouvent autant dans la définition du produit que dans le choix technique.
Un outil bien conçu est un outil intelligent qui peut faire les bons choix au bon moment pour l'utilisateur. Et si on apprenait ensemble à concevoir nos erreurs ?

Plus que jamais, nous avons besoin de sécuriser nos échanges et de renforcer notre confiance dans nos outils pour garder nos données à l'abri des yeux indiscrets. Peut-être que franchir le pas vous semble insurmontable. Peut-être que vous vous dites que tout ça reste une affaire de groupes d'hackitivistes éclairés. Plus probablement, il vous manque sans doute juste une connaissance simple de l'univers du chiffrement, et de la fantastique boîte à outils qui l'accompagne.

Alors profitons-en, on embarque pour un tour d'horizon de la crypto : chiffrement, techniques, outils… Nous regarderons quels outils existent, pourquoi et comment les utiliser. Et parce que le web ne serait pas parfait s'il n'était pas ouvert, nous nous intéresserons aussi bien aux clients "lourds" qu'aux alternatives web (et il en y en a plein).

Mieux : puisque nous ferons le tour des techniques, observons les outils que met à notre portée de dev le W3C avec l'API WebCrypto : ajouter du chiffrement et une gestion fine de la sécurisation se révèle désormais beaucoup plus pratique.

Ceinture et bretelles : attachez-vous bien, on chiffre !

Currently there are several tools to analyze the behavior and performance of an application, but traditionally the way of displaying results is that of tabular, either flat or tree. In this talk we will take a peek at some alternative tool that "enlightens" the darkest corners of the behavior of our applications and the JVM, showing them in a completely new and more visual way: the FlameGraphs. During the intervention a "peek under the hood" will be given to some JVM mechanisms to understand the reasons behind the failures of most well known profilers.

26 novembre 2018 : l’équipe sécurité d’event-stream, un paquet npm, est contactée au sujet d’un paquet infecté qui permet à son auteur de dérober des Bitcoins. Ah non, il n’y a pas d’équipe sécurité d’event-stream. On contacte donc directement la personne responsable du paquet. Bon, il se trouve qu’elle ne maintient plus le paquet. Allez, on réveille le RSSI de la boî... Non plus ? On se retourne contre l’entreprise qui a audité un paquet aussi largement distribué ? Audiquoi ? Il n’y a pas eu d’élévation illégitime de privilèges. Pas de spoofing. Pas de vulnérabilité dans le code de Github, ni du côté de l’app, ni du côté de npm à proprement parler. Juste un attaquant intelligent qui a demandé à maintenir un paquet npm et qui a tranquillement injecté son code malveillant une fois mainteneur officiel. Dans l’open source, la chaîne de confiance est primordiale pour garantir la sécurité du développement, et la sécurité organisationnelle est parfois négligée : examinons les bonnes pratiques à mettre en place.

Michelin propose aujourd'hui des offres de service autour du pneu connecté permettant aux flottes de poids lourd d'optimiser leur poste coût pneumatique. L'ensemble des données de ces pneus connectés remontent depuis différents capteurs dans une plateforme d'ingestion et d'analyse que nous venons de réécrire afin de répondre à des exigences de performance et disponibilité. Nous montrerons au travers d'un retour d'expérience et d'exemple concrets, comment une architecture micro-services réactive basée sur Eclipse Vert.x nous a permis de moderniser notre stack de collecte et services IoT. Nous aborderons les difficultés rencontrées par l'équipe avec le passage à la programmation asynchrone, le réactif, et plus généralement les architectures micro-services. Nous illustrerons différents points techniques avec une mise en perspective des atouts de Vert.x pour les challenges rencontrés.

L'architecture Event Sourcing est de plus en plus adoptée dans les projets. Cependant réussir son implémentation demande beaucoup d'efforts et de rigueur.

Venez découvrir un retour d'expérience sur une implémentation d'une architecture Event Sourcing dans la banque : les pièges à éviter et les pratiques à adopter!

L'un d'entre nous deux souhaitait nommer cet exposé « ORM, The Vietnam of Computer Science » mais c’est à la fois de mauvais goût et l'autre n’aurait jamais accepté. Plus exactement cette session s’adresse à tous les amoureux du SQL mais aussi des amateurs des ORM car nous allons, sans trop troller, raconter pourquoi nous en sommes là. Nous avons tous connu des projets difficiles avec JPA et Hibernate mais est-ce une raison d’abandonner ?

Ce sera aussi un retour sur les expériences heureuses ou difficiles tirées de 15 ans de pratique de JBDC aux ORM en passant par les promesses comme iBatis ou l’aventurier JOOQ. La finalité est d'expliquer notre vision du bon usage de chaque solution, comment tout est une question de compromis et pourquoi les ORM ont absolument leur place mais sont si souvent mal compris et utilisés.