Quoi de neuf Docteur ? J’ai mal à mon architecture !

Par
Conférences 20 février 2018
Temps de lecture : 6 mn

Le 30 janvier dernier avait lieu la première conférence concernant l’Architecture par nos confrères d’Octo : #LaDuckConf.

Pourquoi cette conférence ? Comment c’était ? Pourquoi un canard ? Autant de questions auxquelles nous allons tenter de répondre dans ce billet.

Une conférence orientée architecture

Comme le disait son créateur Julien Kirch : “Pourquoi il n’y a pas de conférence orientée architecture à Paris” alors qu’il y en a ailleurs en Europe et aux Etats Unis.

Le pari est pris et la Duckconf est née : “La première conférence qui met les pieds dans la marre” (sûrement l’explication du canard, en plus de ça). Comme d’habitude avec Octo, nous avons le droit à une signature graphique, à un esprit un peu décalé sur la forme et à beaucoup de sérieux sur le fond.

  • Un track unique sur une journée dans une grande Salle du Palais Tokyo
  • 12 talks
  • 250 participants

Le lieu

Le palais Tokyo Avenue Wilson à Paris à une station de RER et quelques stations de métro de la Gare du Nord (pour les nordistes qui étaient présents). La salle est au sous-sol, on descend des marches dans une ambiance qui oscille entre club louche et une expo d’art moderne 😉

 

Palais Tokyo

 

 

J’ai trouvé la salle appropriée à l’évènement, par contre l’espace pause et déjeuner est clairement à revoir, mais bon ce n’est pas le plus important.

Nous étions dans des fauteuils confortables, le son et les lumières étaient au rendez-vous, il n’y a pas eu de couac technique.

Voilà pour le côté logistique, passons à ce qui nous intéresse le plus : le contenu.

Les Talks

De manière générale, ce que j’ai aimé dans les talks, c’est qu’il n’y avait pas de “rock star”, il y avait des speakers avec un vrai message et un véritable contenu. On évite l’effet buzz word, name dropping et les punch lines qui viennent parfois ponctuer une présentation quelque peu artificielle, qui sent plus le talk d’opportunisme que de la démarche sincère.

On commence bien avec Ludovic Cinquin, Directeur Octo, qui vient nous expliquer pourquoi nos projets informatiques échouent.

On passe en revue, chiffres et rapports d’étude à l’appui, toutes les idées reçues concernant les projets informatiques. On parle d’organisation, de communication, de productivité… et à chaque idée, la salle sourit devant la simplicité du constat et grimace un peu en se disant qu’elle le vit ou l’applique parfois au quotidien.

  • Non, un nouveau développeur à un mois de la deadline ne va pas sauver le projet.
  • Non les incentives financiers ne vont pas aider une équipe dont les objectifs sont interdépendants et différents.
  • L’occupation full time des développeurs et leur switch de tâches plusieurs fois par jour nuisent grandement à la santé d’un projet.
  • Être éloignés, même de 30 mètres, équivaut à travailler dans un autre pays et dégrade les relations entre les équipes.
  • Les objectifs quantitatifs sur la résolution de ticket ou la couverture de code mènent systématiquement à l’effet cobra.

Je vous laisserai découvrir toutes les idées reçus dans la présentation sur slideshare, mais il ne vous faudra pas longtemps avant de retrouver dans quel projet ou au sein de quelle équipe vous les avez toutes vu s’appliquer.

Visiblement, pragmatisme et bon sens sont inversement proportionnels à l’incompétence ou la désorganisation du middle management.

Ensuite on barbotte dans un Data Lake avec Thomas Vial

Cette présentation nous familiarise avec le langage propre au big data et à ces fameux data lake.

“Le data lake Hadoop doit rationaliser la BI du Groupe et porter les use cases analytiques, grâce à une démarche agile centrée sur la gouvernance des données.”

Vous aurez beau relire cette phrase plusieurs fois, elle ne prendra pas plus de sens. Thomas tente de démystifier le big data et d’effacer le buzz pour nous expliquer le réel interêt à mettre en place une telle architecture, un tel chantier, ou tout simplement ne pas le faire pour de mauvaises raisons.

  • Non le big data n’est pas un synonyme d’élephant jaune, enfin pas toujours.
  • Pour mettre en place un data lake, il faut :
    • Analyser le besoin d’architecture à court terme
    • Prioriser en fonction du besoin, stop à l’effet hype
    • faire des POCS ! Ces systèmes sont complexes à appréhender
  • Utiliser des solutions hybrides, tant dans les technos que dans l’hébergement des solutions.
  • Favoriser l’APIsation, c’est favoriser l’adoption du projet.
  • La documentation accentue la visibilité et favorise l’adoption.
  • Dernier conseil : commencer par le batch, réflechissez à deux fois avant de vous lancer dans le temps réel.

On révise son théorème de CAP

Le théorème CAP ou CDP, aussi connu sous le nom de théorème de Brewer dit qu’il est impossible sur un système informatique de calcul distribué de garantir en même temps (c’est-à-dire de manière synchrone) les trois contraintes suivantes1,2 :

  • Cohérence (Consistency en anglais) : tous les nœuds du système voient exactement les mêmes données au même moment ;
  • Disponibilité (Availability en anglais) : garantie que toutes les requêtes reçoivent une réponse;
  • Tolérance au partitionnement (Partition Tolerance en anglais) : aucune panne moins importante qu’une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome).

Bon ça c’est pour la définition from wikipédia : https://fr.wikipedia.org/wiki/Théorème_CAP

Dans la pratique, il faut se poser les bonnes questions : que faire dès lors que nous sommes en partition ? Que mettre en place et à quel coût ? As t on réellement besoin de haute disponibilité ?

Ces questions sont surtout à poser au métier, en découlent d’autres : quel comportement souhaitez vous pour votre application ? Jusqu’où êtes vous prêt à aller pour rendre le service ?… Il faut éviter de voir les choses trop compliquées dès le départ et arbitrer : peut être que mon système ne sera pas parfait dès le début, mais par contre j’ai identifié les risques, j’en connais les conséquences et je pourrai les assumer (enfin j’espère !).

C’est aussi l’occasion de rappeler que nous utilisons tous au quotidien un système distribué : Git, et heureusement nous ne passons pas beaucoup de temps à résoudre des conflits…

Je m’arrête là, en espérant vous avoir donné envie de plus. Je ne vais pas vous faire un résumé complet de toutes les vidéos, le mieux est que vous vous fassiez votre propre opinion avec la chaîne Youtube.

Dans les talks qui suivirent, j’ai beaucoup aimé :

  • Le guide de suivi des architectes “Big Data” pour son aspect concret et pragmatique. Sans forcément mettre en avant la technologie, surtout les concepts et du bon sens.

  • Une infrastructure peut en cacher une autre pour la petite histoire racontée avec pédagogie et de bonnes illustrations (je parle de usecase bien entendu).

  • Préparez-vous, les messages de ce talks ne seront pas déliverés exactly-once, probablement parce que j’ai récemment beaucoup travaillé avec des message–oriented middleware. Ce talk a été une bonne surprise, avec pour le coup une forme originale, tant sur le ton du speaker Augustin Grimpel, que sur la forme de ses slides : “dessinés” et minimalistes dans le bon sens du terme.

  • Au secours, le marketing a choisi Salesforce : SAAS ou le progiciel 2.0 : la plus belle lettre de démotivation qu’on puisse envoyer à un gros éditeur comme Salesforce. Le ton est décalé, les arguments ne sont pas anti produit, il sont en faveur du bon produit au bon endroit pour la bonne problématique. Qui n’a jamais du travailler avec un techno choisie pour une raison arbitraire techniquement infondée ? On se sent concerné forcément.

  • Reuse : vraie ou fausse bonne idée : je me répète dans ce billet, mais décidément beaucoup de pragmatisme et de bon sens. Personnellement convaincu par les problèmes issues des approches multi BUs ou des framework d’entreprise avec du métier… Quand vouloir gagner du temps vous en fait perdre énormément.

  • Stop à ma résilience à la Papa : un bon dialogue entre les deux experts qui mêlent cas concret et pattern d’architecture comme on les aime.

https://twitter.com/IneatLab/status/958371424196063233

  • Mon mainframe fait du digital sans casser ma tirelire : j’avoue avoir décrocher, pardonnez-moi, probablement pas assez concerné par le mainframe, ni assez curieux pour le coup et probablement fatigué par une journée complète de talks.

Je pense que vous aurez compris que j’ai plutôt bien apprécié la conférence et suis prêt à assister à la prochaine, si prochaine il y a !

Pourquoi ?

  • Parce qu’on ne m’a pas vendu (survendu) une technologie.
  • Parce qu’on m’a donné des exemples et de vrais cas concrets
  • Parce qu’ils ont été clairs, simples et concrets
  • et coin, coin, coin…
Retour

Vous pouvez aussi aimer

5

Petit guide de Takeoff conf 2013

Par , , , et
Conférences 12 mars 2013
Temps de lecture : 5 mn
4

WWDC19 – Day 2

Par
Conférences, Mobilité 12 juin 2019
Temps de lecture : 4 mn