J’ai eu la chance ce Vendredi d’être présent pour la conférence annuelle RivieraDev. Je n’ai malheureusement pas pu être présent pour la totalité de la conférence, et c’est bien dommage au vu de la qualité de certains talk.

 

Il s’agit d’une conférence ayant lieu à Sophia Antipolis, et ce fut l’anniversaire de ces 10 ans cette année. Cette conférence m’a beaucoup fait penser au VoxxedDay Luxembourg aussi bien pour son ambiance (fun et convivial) que son contenu.

J’ai pris le parti pris d’assister aux conférences liées au DevOps, un choix que je ne regrette pas. Je suis un développeur C++, et je dois l’admettre, généralement plus intéressé par les conférences de bas niveau. Cependant il est impossible aujourd’hui d’ignorer l’immense stack technologique qui soutient nos applications en production.

Un développeur se doit de comprendre les problématiques d’infrastructure et le travail supplémentaire qu’il donne aux opérationnels afin de faire les choix de design les plus pertinents, aussi bien pour le développeur que pour la personne qui devra monitorer son bon fonctionnement.

Bien évidemment RivieraDev ne se limite pas au développement DevOps, mais les autres sujets (Java, développement Web etc…) me semblaient moins capitaux (pour mon usage quotidien aussi bien sur mes projets personnel que professionnel).

Voici les conférences auxquelles j’ai assisté, ainsi que mon avis.

 

Hacker les catastrophes naturelles:

Commençons par le commencement, la Keynote de la journée. Il s’agissait d’une conférence sur l’utilisation des technologies dans le cadre de la protection de la population contre les catastrophes naturelles (séismes, tsunami, ouragans etc…).

Pour comprendre à quelle point cette conférence était intéressante, il faut savoir qui est l’auteur de cette dernière. Il s’agit de Gaël Musquet, fondateur d’une ONG (Organisation Non Gouvernemental) appelé HAND – Hacker Against Natural Disasters.

 

Tout au long de son discours, on pouvait ressentir son implication et c’était très agréable à suivre. Et cela d’autant plus que c’était présenté avec beaucoup d’humour malgré la gravité des sujets.

A vrai dire les moments les plus drôles furent ceux où il expliquait la réalité de la situation actuelle concernant la façon dont les catastrophes naturelles sont reportées en France.. Je ne vais pas spoiler la présentation (qui est disponible sur YouTube) mais on utilise des fax :D.

 

Le point important à retenir, c’est qu’aujourd’hui, il n’y a strictement aucune raison (en tout cas aucune limitation technique) qui ferait que la population ne soit pas prévenue d’une catastrophe naturelle en avance et/ou que les populations prisent dans de telles situations soient coupées du monde (sans communication possible avec les autorités ou secours). Et le but de cette présentation est de nous montrer ce qui peut être mis en place.

Bref, une très bonne présentation de qualité, qui intéressera sans doute une majorité des développeurs que nous sommes.

Docker, Kubernetes & Istio : Tips, tricks & tools:

par Kévin Davin&Aurélie Vache

 N’étant pas un DevOps et ne m’intéressant que partiellement au sujet, cette présentation sera, pour moi, la plus compliquée à commenter. Cette conférence a pour but de montrer comment se servir de nombreux outils différents (près d’une 50taines d’outils présentés en tout).

Je pense qu’il est intéressant pour un DevOps de jeter un oeil à cette présentation car l’un des objectifs de cette dernière est d’expliquer quels sont les outils à ne plus utiliser car dépréciés. Dans un monde qui évolue aussi vite que celui du DevOps, je pense qu’il est primordial de se mettre à jour sur quels sont les outils les plus efficaces et standards du moment.

 

Des microservices aux migroservices

par Francois Teychene

Pour moi, la meilleure conférence de la journée (bien que les autres ne déméritent pas, celle-ci fut ma favorite).

Cette présentation effectuée avec beaucoup d’humour (apparemment Francois était malade… ca ne s’est pas beaucoup ressenti ^^) donne un retour d’expérience sur la migration de projets. Il nous explique son ressenti, et ce qu’il se passe généralement lors de telles migrations. Il faut savoir que l’orateur de cette présentation est un développeur passionné (Rust lover) qui est passé du côté opérationnel (et donc est devenu un DevOps).

La présentation commençant par une explication de ce que font les microservices, tel qu’on nous l’a présenté ces 4 dernières années, augmentation de la scalabilité, de l’efficacité des équipes de développement, réduction du “time to market” etc…

Suivi d’une métaphore très représentative de la réalité pour expliquer l’évolution des architectures entre le développement monolithique et en micros services.

  • Avant on faisait du code spaghetti (gros monolithe),
  • Ensuite on a voulu faire des designs avec des couches pour mieux séparer les problématiques techniques et métier. Et ainsi gagner en efficacité de développement. C’est le code en lasagne.
  • Et finalement on veut tout séparer en morceaux plus unitaires qui ont chacun leurs objectifs, c’est le code en ravioli.

Suivant cette métaphore comme fil d’Ariane, nous apprenons les difficultés rencontrées aussi bien en termes de maintenance que de développement qui peuvent être (et qui sont généralement) rencontrés lors d’une migration vers une architecture microservice. Il nous explique aussi le changement de mindset que doit avoir le développeur afin de ne pas créer de dépendance trop forte entre les micro-services qui entraînerait des modifications en cascade dans le cadre d’une évolution du business.

La gestion des logs et de la stack technique (énorme) qui doit être mise en place et maîtrisée par les opérationnels pour le bon fonctionnement du système.

Finalement, une présentation autant didactique que divertissante que je conseillerais à n’importe qui. Car comme dit lors de mon introduction, tout développeur se doit de comprendre les problématiques opérationnelles. Et ces dernières sont particulièrement bien expliquées par le biais d’un retour d’expérience lors de cette présentation.

Sous le capot des conteneurs Linux

par Allesio Coltellacci

 

J’ai déjà eu le plaisir d’assister à cette conférence lors du VoxxedDay Luxembourg. La présentation à évoluer afin d’être plus interactive (avec confirmation de la loi de Murphy lors de certaine improvisation :D). Le but de cette présentation est d’expliquer comment un conteneur Linux (Docker par exemple) fonctionne en interne. Comment il fait pour isoler un processus et quelles sont les fonctionnalités du Kernel utilisées pour cela.

Je n’ai toujours pas changé d’avis concernant cette présentation. Elle est très intéressante et démystifie docker. Ce qui est une bonne chose, et je pense, nécessaire au vu de son utilisation en milieu professionnel.

Choisir entre API RPC, SOAP, Rest, GraphQL? Et si le problème était ailleurs?

par François-Guillaume Ribreau

Cette présentation était très intéressante. Le but est de retracer l’historique des technologies qui ont été mises en place pour développer des APIs. Les API les plus fréquentes étant des API CRUD (Create Update Delete), nous pouvons constater que les développeurs refont souvent la même chose et font souvent perdre la possibilité au client de choisir son format de réponse (json, xml… ).

Il nous présente une technique plus déclarative pour développer nos API directement au niveau de la base de données. Grossièrement, le principe serait le suivant. L’api ne serait au final qu’une application générique qui passe une requête directement faite par le client à la base de données. Et la base de données n’expose que des vues sur ses tables qui représenterait uniquement les données que l’on veut accessibles par le client.

Il nous explique comment on pourrait utiliser via du LUA, des messages queue, capturer des événements afin, par exemple, d’envoyer un mail lorsqu’une action a été effectuée.

Ce résumé est grossier et si vous souhaitez en savoir plus, je ne peux que vous conseiller de voir la présentation. L’idée serait de revenir sur le débat, “Est-ce que de la logique doit être mise en place au niveau de la base de données ?”. La réponse à cette question a été pendant longtemps “non” car séparer la logique business des données fait plus de sens. Le fait de créer notre API d’une manière déclarative et non impérative impliquerait moins de bug. Et cet argument est l’argument principal (que je vois) pour reconsidérer la question.

Je n’ai pas été vraiment convaincu, pour avoir fait du PL SQL dans le secteur bancaire, je peux dire qu’il est très facile de faire des requêtes sous-optimale assez facilement. Se servir de cette méthode nécessiterait donc une expertise en SQL, qui plus est sans doute spécialisé dans la base de données utilisée (Oracle etc…).

Sans compter le fait que je suis contre le couplage des données et de la logique métiers. Cependant, je ne développe plus d’API CRUD depuis un moment, et il s’agit d’une opinion basé sur mon expérience, c’est pourquoi j’ai trouvé cette présentation très intéressante et je conseillerais n’importe quelle développeur d’API de la regarder afin de se faire sa propre idée.

DevOps in a Serverless World

par Alexis Moussine-Pouchkine

Alexis Moussine-Pouchkine est un développeur travaillant chez Google, qui nous présente de ce qu’est le Serverless.

Le but étant de démystifier le serverless et de nous rappeler que cette “absence” d’infrastructure ne signifie pas qu’il n’est pas nécessaire d’avoir des opérationnels. Mais qu’au contraire, des règles de bonne pratiques pour les développeurs afin de permettre au opérationnels de faire correctement leur travail sont absolument nécessaire (cet ensemble de règles étant appelé SRE chez Google).

Alexis nous présente également l’écosystème google afin de comprendre comment le serverless fonctionne, et comment en faire avec Google. Cette conférence était plaisante à suivre et j’y retournerais avec plaisir afin de me tenir au courant des actualités aussi bien en terme d’architecture que de développement. Seul petit bémol, il n’y avait pas tellement de goodies :>, j’adore les goodies 😀

Quentin Balland