La première édition de la Duck Conf a eu lieu le 30 janvier dernier. Entièrement organisée par Octo, elle a pour but de donner un espace où parler architecture. Les organisateurs se sont en effet rendu compte qu’aucune conférence dédiée à l’architecture n’existait à Paris. Ils ont donc décidé de le faire eux-mêmes. C’est ainsi qu’est donc née la Duck Conf.

Ne me demandez d’où vient le nom, il parait que c’est issu d’un jeu de mots honteux. Mais le pitch est simple :

La conférence tech by OCTO, qui n’a pas peur de mettre les pattes dans la mare. Pour sa première édition, La Duck Conf livre un tour d’horizon des pratiques d’architecture de SI, fondé sur des expériences terrain et nos convictions. Quel que soit votre niveau d’expertise, si pour vous “technique” rime avec “pratiques”, follow the Duck…

Un track, une journée, une dizaine de talks.

Tout ceci a eu lieu au Palais de Tokyo, en face de la Tour Eiffel. Plutôt original sur le papier, ça s’est révélé peu pratique à l’usage. Mais c’est une première itération, il ne faut pas l’oublier. Au menu, une seule track, qui s’est déroulée comme suit :

Pourquoi nos projets informatiques échouent

Ce talk est une remise en question d’un certain nombre d’idées préconçues que l’on retrouve plus ou moins régulièrement quand on développe du logiciel.

  • « Il suffit d’ajouter des développeurs pour terminer plus vite ». Or la loi de Brooks (1975) dit spécifiquement l’inverse : quand on ajoute des devs, on aggrave le retard. A court terme, la vélocité baisse, car il faut former le(s) nouveau(x). Et il faut en moyenne entre 4 et 6 semaines pour constater un effet positif sur l’équipe.
  • « Supprimer les temps morts  permet d’augmenter la productivité ». Cette assertion est contradictoire avec la théorie des files d’attente, selon laquelle quand on utilise le CPU à 100%, le système s’engorge. Et quand on charge les devs à 100%, le temps de résolution d’une user story tend vers l’infini. Le mode optimal semble plutôt indiquer une cible autour de 80%. Exemple : le passage de 80 à 70km/h de la limite de vitesse du périphérique parisien a fait augmenter la moyenne de 18% et baisser les bouchons de 36%.
  • « Pour optimiser les ressources, il vaut mieux paralléliser les projets ». Or on constate plutôt l’inverse : une chute de la productivité de 40% et du QI de 10 points. C’est le coût du fameux context switching. Gérer les projets en série permettrait au contraire de réduire de 40% les coûts des projets complexes.
  • « Il vaut mieux prendre des profils chers pour la phase projet, puis se rattraper sur la maintenance ». Sauf que le coût de maintenance se situe en moyenne entre 40 et 80% du coût total.
  • « Réutilisation = baisse du coût ». Ça peut être vrai, mais un composant générique est généralement 3 fois plus complexe qu’un spécifique. Et il faut rajouter le coût des tests. Donc il est fortement conseillé de commencer par du spécifique et de s’attaquer à la factorisation au bout de 3-4 occurrences. Yagni, les amis. Yagni.
  • « Les primes sur objectif sont motivantes ». Sauf qu’il existe une multitude de contextes où ces mesures sont contreproductives. Il est recommandé de les restreindre aux tâches connues et solitaires. Et toujours se méfier qu’une métrique peut elle-même devenir l’objectif, plutôt que ce qu’elle mesure. La fameuse course à la bonne note.
  • « La localisation n’est pas importante ». Or, la courbe d’Allen dit qu’au-delà de 50m de distance entre deux personnes, c’est la même chose que plusieurs kilomètres. D’autant plus que plus la personne est distance, plus on a tendance à donner une image déformée de soi. Et la perception de la distance est primordiale. Loin des yeux, loin du cœur, n’est-ce pas ?
  • La taille du projet n’est pas importante. Or, Capers Jones a constaté que les coûts des projets, ainsi que le risque d’échec s’envolaient avec la taille. Les baby steps des méthodes agiles n’existent pas sans raison.

Vous l’aurez compris : pas mal d’infos, certaines parfaitement connues, d’autres nettement moins. Dans tous les cas, un rappel est toujours salutaire.

World Café express : comment influencez-vous votre entreprise ?

Pas simple d’organiser un World Café dans une salle pleine de fauteuils avec 200 personnes. Mais les discussions ont été très intéressantes, avec de vraies confrontations de points de vue et quelques conclusions inattendues du fait de l’hétérogénéité des participants (fonction publique vs privé, grosses structures vs très petites structures, et je ne parle même pas des domaines métier).

La bonne nouvelle, c’est qu’on semble tous d’accord sur le fait que l’architecte version tour d’ivoire va mourir de sa belle mort, et que l’on se dirige plutôt vers des architectes distribués dans les équipes opérationnelles et qui se coordonnent grâce à des communautés de pratique.

La vie après le théorème CAP

Le théorème CAP nous dit qu’on peut au mieux satisfaire deux des contraites suivantes : consistance (Consistency), disponibilité (Availability) et tolérance à la partition réseau (Partition tolerance). C’est très théorique, mais quelques enseignements intéressants peuvent en être tirés :

  • ce théorème ignorait la latence. Les systèmes distribués étant dorénavant la norme, le théorème a été mis à jour.
  • la consistance et la disponibilité ont rarement besoin d’être parfaites. Et le web et les microservices vont dans ce sens.
  • L’architecture pragmatique se trouve quelque part à mi-chemin entre l’inutilité et le Graal. Sachez placer votre curseur.
  • Quel comportement adopter en cas de panne d’un noeud du système. C’est une décision business.
  • Est-ce que l’investissement en vue de grapiller des dizièmes, centièmes voire milliers de points de disponibilité est rentable ? C’est aussi une décision business.
  • Réfléchissez bien à vos partitions. Un appel http est une partition. Un envoi de message est une partition.

Il existe de multitudes de stratégies. Regardons git, Wikipedia, Dropbox, la Blockchain… Et comme dirait George Box : tous les modèles sont faux, mais certains sont utiles.

How to make your mobile (API) happy ?

Deux problématiques critiques quand on développe une API pour application mobile :

  • qu’elle soit très user-centric
  • sa performance

Si on mappe simplement l’interface sur les APIs existantes, on générera une mauvaise UX. On va donc chercher à minimiser le nombre de requêtes nécessaires pour l’affichage et limiter la taille du payload. On utilisera éventuellement des optimisations (pagination, compression, cache) pour aller plus loin.

Il est très fortement recommandé de développer une couche d’API dédiée au mobile qui permet à la fois d’abstraire la complexité sous-jacente et de gérer des spécificités de ce contexte, comme du cache applicatif. Celle-ci minisera le nombre d’allers-retours réseau, de coller à l’UX et d’apporter des fonctionnalités dédiées.

Une infrastructure peut en cacher une autre

Petit tour d’horizon plutôt intéressant sur les infrastructures modernes. La trame est bonne : on suit un petit projet, très simple (un site, une base de données), qui petit à petit nécessite de complexifier l’infrastructure : montée en charge, nouvelles fonctionnalités, travail collaboratif, test, sécurité, etc. On parle donc DevOps, densification via la containerisation… Mais aussi d’organisation et de méthodologie.

Préparez-vous, les messages de ce talks ne seront pas déliverés exactly-once

Quand on met en place un système de messaging entre un producteur et des consommateurs, nous avons généralement le choix entre deux stratégies :

  • la livraison au plus une fois
  • la livraison a minima une fois

Ce bon talk fait donc le point sur ces deux stratégies, les use-cases où ils s’appliquent et en profite pour tordre le cou à la promesse faite par certains éditeurs d’une livraison exactly-once. On y parle également idempotence et déduplication.

Stop à la résilience à la papa

Tour d’horizon des techniques modernes de résilience. On fait le point sur les techniques traditionnelles, en immense majorité basées sur l’infrastructure et on regarde comment on a ces dernières années basculé vers une résilience applicative moins coûteuse et plus adaptée aux techniques de développement d’aujourd’hui : messaging et http.

Conclusion

Si la journée était très inégale et l’organisation à roder, il y a de bonnes choses à retenir. Premièrement : il y avait un vrai manque sur une conf orientée architecture à Paris et la Duck Conf a une proposition pour y remédier. C’est une première bonne chose. Ensuite, plusieurs sessions valaient le déplacement, et auraient même mérité un peu plus de temps. Le format aurait gagné à être plus digeste et à laisser plus de place à la discussion qui est une des réelles raisons d’aller assister à une conférence : parler à ses pairs.

Bonus : les autres sessions

Superbe maison d’architecte avec vue sur le lac

Big Data : Guide de survie des architectes

Au secours, le marketing a choisi salesforce : SAAS ou le progiciel 2.0

Reuse : vrai ou fasse bonne idée ?

Mon mainframe fait du digital sans casser ma tirelire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *