Le blog d'Archiloque

Compte rendu : La duck conf 2020

Julien Kirch, le 30 janvier 2020

Ça fait bizarre de faire le compte-rendu d’une conférence après en avoir été le créateur.

En effet, après lancé l’idée et avoir piloté seul la partie contenu en 2018 puis avoir fait monter à bord Cyril et Mathieu Poignant, j’ai quitté Octo en juin dernier pour Enercoop[1] alors que les discussions sur le programme de 2020 démarraient.

Même si j’avais confiance en eux, cela fait très plaisir de voir que la conférence vit maintenant sa vie sans moi.

En général

Une conférence au masculin

L’an dernier, nous n’avions pas réussi à avoir de speakeuse et je m’en étais excusé.

Cette année, il n’y avait pas non plus de speakeuse, mais le sujet n’a pas été abordé, et le code de conduite n’a pas été mentionné. Si vous ajoutez les slides presque uniquement au masculin, j’ai été très désagréablement surpris qu’Octo s’inscrive à rebours de ce qui se fait dans la plupart des autres évènements.

Les talks : le fond est là, la forme pas toujours

Je ne sais pas comme le dire avec des pincettes : un certain nombre de talks manquaient de finition.

Pas de plan annoncé, déroulé pas clair, nombreuses redites … dans plusieurs cas, je me suis retrouvé à lutter pour suivre le fil de ce qui était dit, alors que le contenu était là.

C’était assez rageant car j’avais le sentiment que 90% du travail avait été fait mais que les 10% manquants auraient pu faire une vraie différence.

J’aurais aussi aimé des talks un peu plus ciblés sur l’architecture et des retours d’expériences un peu plus exotiques.

Kubernetes, Kubernetes, Kubernetes !

Sur le sujet du cloud, Kubernetes a régné en maître quasi-absolu. Cela tranche beaucoup avec l’état du marché, ou même le panorama discuté à la conférence l’an dernier (PaaS, lambda …).

C’est une conséquence directe du fait qu’Octo vend de l’expertise Kubernetes, et que les personnes font des talks sur les sujets qu’ils connaissent, mais quand même.

Ce qui m’a le plus gêné, c’est l’absence de recul sur la complexité que Kubernetes impose aux équipes de développement : quand j’entends dire plusieurs fois qu’il faut avoir un ops, au moins à temps partiel, par équipe de développement pour gérer les fichiers de déploiements pour des applications standards et que tout le monde a l’air de trouver ça normal, j’ai un peu l’impression d’être un extra-terrestre. Qu’une expertise particulière soit nécessaire pour remplir les fichiers de configuration d’une application standard, c’est une faiblesse patente de l’offre (ou de l’approche) Kubernetes, et je comprends très bien que des entreprises redéveloppent des outils spécifiques, même s’ils ne donnent pas forcément satisfaction, pour éviter cela.

Les talks

Désiré Atanga : Kube is the new mainframe

Le talk parle des biais qui freinent l’adoption de Kubernetes à travers un parallèle avec le mainframe. L’idée est que lors de leur sortie, le mainframe et Kubernetes fournissent tous les deux des fonctionnalités qu’on ne trouve pas forcément dans les solutions existantes, mais, alors que le mainframe s’est imposé sans problème, ce n’est pas le cas de Kubernetes.

Beaucoup de choses dans le talk, et parfois difficiles à suivre.

Les éléments que j’en retiens :

  • Les plateformes “DevOps” développées par certaines entreprises pour simplifier le travail des projets peuvent être un frein, car elles empêchent d’utiliser tous les avantages de Kubernetes, ce qui peut diminuer l’intérêt pour les projets de les utiliser

  • Les contraintes d’avoir une application douze facteurs pèsent toujours, même si les frameworks récents sont en principe compatibles avec ces contraintes, cela peut soit augmenter le ticket d’entrée pour migrer sur Kubernetes, ou carrément empêcher de le faire.

Alain Faure & Laurent Sollier : no code : la démocratisation du développement

Un talk sur les solutions de no-code (à base d’interface-souris) ou de low-code (genre Excel mais pour du développement) qui permettent à des personnes ayant pas ou peu d’expérience de développement de pouvoir créer des applications.

Même si les choses progressent, le constat ne change pas depuis des années : on peut faire des choses avec ces systèmes, mais plus la complexité de ce qu’on veut faire augmente, plus leurs contraintes et limitations réduisent leur pertinence vis-à-vis d’outils de développement classiques.

J’ai été un peu brusqué sur la reprise du discours patronal sur “il manque 50.000 développeurs” qui repose sur des projections de 2012 et qui traduit surtout le sentiment que les personnes qui développent sont trop payées.

Une des propositions de valeur des solutions low-code est de pouvoir confier à des personnes moins compétentes et donc moins chères, des tâches qu’on confierait sinon à des développeurs et développeuses “classiques”.

Il serait plus courageux d’assumer la chose directement plutôt que se reposer sur des chiffres sortis de leur contexte.

Ilker Aksen & Borémi Toch : Les papys de l’ESB ont une histoire à vous conter

Il s’agit d’un rappel sur les fondamentaux des échanges dans le SI au travers de l’histoire des ESB.

Pour les personnes qui n’ont pas connu ces outils et à qui ils ne donneraient pas envie, c’est surtout l’occasion de mieux expliquer certaines pratiques actuelles, et d’éviter de reproduire les erreurs du passé.

Je conseille ce talk quand il sera disponible en vidéo, mais comme Ilker a été mon manager pendant 5 ans, je ne suis pas tout à fait objectif.

Thomas Wickham : votre organisation est aussi agile que le moins agile de ses composants

Le sujet du talk n’est pas l’agile mais la vélocité, et son message est que d’augmenter le nombre de personnes qui développent n’est pas forcément la solution pour délivrer plus de fonctionnalités si le goulot d’étranglement est ailleurs.

Dans son raisonnement, Thomas essaie de montrer les effets induits par l’augmentation du nombre de personnes sur le développement, mais pour cela il mélange plusieurs choses : d’une part, ce qui augmente linéairement avec le nombre de personnes et ce qui augmente plus vite que le nombre de personnes ; d’autre part les choses qui arrivent dans tous les cas avec celles qui risquent d’arriver.

La conclusion semble être aller de soi, mais on a l’impression que, pour y arriver, il a mélangé des choux et des carottes.

Fabien Arcelier : mon DSI veut une MEP par jour, comment faire de l’archi quand tout est en mouvement ?

J’ai eu le sentiment d’avoir assisté à deux demi-talks .

La première moitié du talk se base sur le livre Accelerate pour expliquer que, pour faire la différence aujourd’hui, il faut livrer plus vite et qu’il est possible de le faire sans baisse de qualité, et cela indépendamment de votre stack technique.

La deuxième moitié est un mélange de patterns à mettre en œuvre pour pouvoir délivrer plus vite et de conseils sur la posture de l’architecte dans un environnement de ce type.

Si je suis d’accord sur les solutions techniques exposées comme la fourniture des sondes de monitoring ou la prise en compte des défaillances, le discours sur la posture de l’architecte m’a laissé dubitatif.

Fabien défend l’idée d’un architecte de SI qui devrait avoir une posture de coach·e qui n’impose rien au projet mais qui est tout de même garant du SI. Dans une organisation, il est tout à fait normal que, de temps en temps, les besoins ou les priorités des applications et du SI ne soient pas les mêmes.

Dans ce cas, je pense qu’il est légitime que la personne qui porte la voix du SI, typiquement un ou une architecte SI, pèse dans la décision pour influencer les choix. On ne peut pas espérer que des projets défendent le point de vue du SI quand cela va à l’encontre du leur.

Du coup, affirmer que l’architecte doit être uniquement dans une posture de coaching revient soit à mettre en risque le SI, soit à tenter de ne pas assumer son pouvoir d’influence sur les projets.

Henri Decourt & Cédric Martin : mettre une refonte sur orbite, plus qu’une affaire de technique

Le talk raconte une refonte d’un domaine d’un SI réalisé pour un client, en insistant sur les aspects organisation et métier.

En effet, une refonte est un chantier d’envergure, et doit se piloter comme un programme, ce qui suppose planning, appuis politiques et négociations.

Les messages sont intéressants et font un bon tour d’horizon des sujets, il a juste manqué de parler un peu d’architecture.

Adrien Graux & Daniel Sabin : l’API management : au-delà des promesses

Le talk fait un état des lieux de ce qui fonctionne vraiment dans les solutions d’API management et de ce ne donne pas satisfaction pour un besoin d’exposition d’API à l’extérieur du SI.

En résumé : ce qui fonctionne vraiment bien est la partie “reverse proxy de luxe”, pour le reste comme la sécurité, le portail pour les développeurs ou développeuses ou les capacités de traitement des flux, c’est bof ou bof bof.

Adrien Graux & Daniel Sabin en profitent pour passer en revue les bonnes pratiques à date sur les différents sujets, ce qui permet de se mettre au goût du jour, même si je n’ai pas l’impression que les choses aient beaucoup changées.

J’ai apprécié la fin de la présentation où les deux speakers expriment leur envie que les solutions se concentrent sur là où elles savent faire et laissent tomber le reste, même si j’ai de sérieux doute sur le fait que cette approche soit compatible avec les objectifs financiers des éditeurs.

Le discours m’a fait sourire car quand les solutions d’API management sont sorties, une partie des architectes expérimentés les comparaient aux solutions UDDI qui fournissaient des portails développeur et développeuses pour du SOAP et qui avaient plutôt été un désastre.

On leur répondait “oui mais comme c’était du SOAP, c’était le MAL, alors que le REST c’est le bien, et du coup là on les solutions SOAP ont échoué, le REST va réussir”.

Au final il semble que le problème ne soit pas forcément un problème de technologie.

Lucas Boisserie & Benjamin Brabant : elle est où ton appli ? dans mon kube !

Un retour d’expérience d’une mise en place de Kubernetes qui s’est bien passé, en présentant les fonctionnalités de Kubernetes, l’impact sur les applications (encore les douze facteurs) et l’organisation de l’accompagnement.

Rien de rare mais une bonne synthèse sur le sujet pour les personnes qui connaissent peu le sujet.

Pascal Martin : migration de 6play : l’amour est dans le cloud

Pascal Martin raconte la migration de 6play, le service de replay de M6 et d’autres télévisions depuis leurs serveurs physiques vers le cloud.

Le speaker est énergique et l’histoire est bien menée. On voit bien combien le fait d’avoir un vrai gros problème, ici de scalabilité, peut aider à faire prendre des décisions et à avancer les choses dans un chantier de cette ampleur.

La présentation montre les différents patterns de migrations choisis, certains orthodoxes et d’autres moins, et insiste bien sur l’ampleur de la tâche et des compétences à acquérir par l’organisation.

Et ça me fait toujours plaisir d’entendre des organisations contentes d’utiliser du PHP.

Didier Bernaudeau & Jean-Baptiste Joly : continuous security : secure a devops world

Les deux speakers montrent que dans un delivery automatisé, chaque étape peut s’appuyer sur différents outils permettant de vérifier tel ou tel aspect de la sécurité de l’application.

Même si ces outils ne font pas tout (étonnant, non ?), ils permettent tout de même de couvrir un certain périmètre, et l’intégration dans la chaîne de déploiement permet d’éviter de prendre du retard sur ce qu’on livre comme on le fait dans un audit post-release classique.

J’aurais aimé que les auteurs donnent un peu plus leur avis sur la pertinence des nombreux outils, et sur la manière de prioriser leurs mises en œuvres, pour éviter l’efet catalogue.


1. D’ailleurs on recrute