Pour la deuxième édition de sa “conférence archi”, Octo Technology accueille les passionnés d’architecture pour assister à une suite de retours d’expérience, concrets et parsemés de Take Away. Cette année, exit le Palais Tokyo, direction l’espace Saint Martin au cœur de Paris.

Pour le résumé de la première édition, c’est par ici !

Cette conférence orientée architecture propose un programme unique proposant des talks d’environ 30 minutes sur des domaines variés. La quasi totalité sont animés par des consultants Octo… ou d’anciens consultants Octo, comme pour dire qu’on ne quitte jamais véritablement Octo ?

L’espace Saint Martin

Si vous avez l’habitude de participer à des conférences et que vous êtes attaché aux “à côté”, ce n’est pas le point fort de cet événement.

Les sujets sont présentés dans un amphi moderne et confortable. A la DuckConf, pas de questions après les sessions, les talks s’enchaînent, introduits par les organisateurs en quelques phrases sur le sujet. Les pauses sont agrémentées de douceurs, jus, thé et café (du café translucide … dommage quand on s’est levé à 5h du mat’).

Nous avons déjeuné Égyptien, dans un gymnase, rien à dire sur la qualité des mets proposés, nous avons même pu goûter à la mascotte Octo (les canards étaient proposés en médaillon).

 

Bonne surprise en récupérant nos affaires (nous bénéficions d’un vestiaire), la majorité des livres blancs Octo étaient disponibles en format imprimé.

Nous ne vous résumerons pas chaque talk, il vaut mieux regarder toutes les vidéos ici. Dans le désordre, ceux qui nous ont le plus plu.

MICROSERVICES & TRANSACTION DISTRIBUÉE

J. STAINER & B. LE FOULGOC

Comment gérer vos transactions dans une architecture distribuée ? Ou plutôt comment assurer la résilience de vos services si l’un d’entre eux est défaillant ? et comment faire collaborer vos services ensemble ?

Les deux principaux patterns nous sont présentés et peuvent pour nous aider à anticiper ces problématiques :

• le pattern chorégraphie : les services s’appellent les uns les autres. Il est important de définir pour chaque service une alternative d’appel, appelée compensation généralement mise en œuvre grâce à des mécanismes de Circuit-breaker par exemple

https://www.thoughtworks.com/de/insights/blog/scaling-microservices-event-stream

Attention aux dépendances cycliques entre vos compensations difficilement détectables !

• le pattern Orchestrateur :

  

  https://www.thoughtworks.com/de/insights/blog/scaling-microservices-event-stream

  La même représentation vue par Octo :

  

Je sais ce que vous vous dites … non, ce n’est pas un ESB que vous voyez sur les schémas ! Il s’agit d’un composant centralisé, certes, mais qui n’a pas vocation à contenir de logiques métiers, faire de la transformation ou que sais-je… son rôle est ici de maintenir un journal d’état des transactions afin de pouvoir réagir en cas d’erreur sur un service (par une compensation par exemple)

 

Attention à ce que ce composant ne devienne pas SPOF !

Comment éprouver ces patterns ? S’assurer que vos transactions distribuées agiront comme vous le souhaitez ? Nos speakers pratiquent le Chaos Engineering (pratique popularisée par Netflix) : provoquez des défaillances sur votre infra et voyez comment elle réagit (éteindre un serveur, stopper un service, etc). Sans forcément le faire en production, utilisez votre environnement de préproduction pour jouer au Chaos Monkey, c’est plus sage quand on n’a pas la maîtrise d’un géant du web.

EVENT DRIVEN : EST-CE QUE JE SUIS PRÊT ?

Wassel ALAZHAR

Ce talk nous démontre les avantages d’une architecture orientée événement. Tout y passe, le CQRS, l’event storming, les technologies… et finalement énormément de mises en garde et de trolls, presque pour nous dissuader d’y aller ?

 

Finalement, comme dans toutes les architectures, la prudence est de rigueur, pour les bonnes raisons, tester, douter, recommencer et ne pas essayer de tordre le modèle.

En tout cas, ces patterns vous aideront à découpler des composants qui n’ont pas besoin de se connaître ou d’agréger des données hétérogènes en temps réel.

 Ne vous lancez pas dans l’event driven architecture sans impliquer votre métier dans des ateliers d’event storming :

HYPERLEDGER/FABRIC : DU POC À LA PRODUCTION

PEVA BLANCHARD

Peva nous a montré, de l’idée au projet, l’implémentation de la technologie blockchain dans un contexte particulier. En effet, Peva nous parle d’un marché américain de la Tulipe, autorisé dans quelques états, mais pas dans d’autres… Ce qui pose des problèmes de paiement dans les boutiques vendant des tulipes avec des cartes d’établissement bancaire fédéral… On comprend donc tout de suite qu’on parle d’une autre plante, moins colorée et avec des vertus “spéciales”.

Mais cette évocation de la tulipe dans toutes les autres slides, pour nous parler de producteur, de circuit d’approvisionnement… rend la présentation plus légère et drôle. Tout en parlant d’un sujet qui utilise une technologie aux concepts très techniques et parfois complexes, le talk est très pédagogique. Etant nous-même en pleine expérimentation blockchain et Hyperledger, nous avons été très attentifs !

Pour résumer :

OBSERVABILITÉ

FABIEN ARCELLIER

Autre talk, autre ambiance. Fabien nous parle d’un sujet qui nous tient à cœur : l’observabilité. Les nouvelles architectures, sont de plus en plus distribuées, morcelées, hétérogènes… si tous ces concepts nous ont aidé dans le time to market, dans l’isolation et la coopération, ils ont aussi apporté leurs lots de complexité.

Pour garantir un système pérenne il doit reposer sur les 4 piliers suivants :

 

Rien de nouveau sous le soleil, mais Fabien vous donne des clés et des cas concrets pour faire de l’observabilité, non pas une composante annexe, mais bel et un bien un composant core de notre architecture ! :

Pour conclure, quelques outils pour vous aider à rendre observable votre système :

THE BORING ARCHITECTURE

NICOLAS DE NAYER  & MICHEL DOMENJOUD / DOCTOLIB

Pour terminer notre tour des talks et nos impressions, nous vous parlons d’une session qui nous a particulièrement plu. Un retour d’expérience de Doctolib, tout en pragmatisme, raisonné et ouvert. Il n’est pas rare d’avoir dans nos équipes des développeurs qui laissent chez eux leur humilité en venant travailler. Les adeptes du “c’est pas propre“, “personne ne fait ça”, “il faut mettre cette nouvelle stack“, garants des normes et standards universels. C’est le comportement inverse qui nous est décrit dans ce talk animé par deux Doctolibiens (ex-Octo, évidemment) qui annoncent la couleur en nous parlant d’emblée de “boring architecture“.

 

Sauf que leur talk est tout sauf ennuyant.

Certes il va à l’encontre de la grande tendance du micro service. Le découpage va vous aider à réduire le time to market, rendre autonome vos équipes, vous rendre résilient, scalable à l’infini et accessoirement peut ramener l’être aimé et trouver les numéros du loto. Doctolib ne vient pas du tout en adversaire des microservices, il vient tout simplement rappeler des aspects importants de l’architecture. Cette dernière ne doit pas enfermer l’équipe qui délivre finalement un produit global, elle doit être performante, sécurisée, maîtrisée… et surtout elle doit être portée par les équipes.

Les enjeux de Doctolib, ne sont pas très différents de beaucoup d’entreprises : une équipe métier et technique qui a connu et connait une forte croissance, une activité florissante qui apporte son lot de contraintes et de promesses, une architecture technique performante qui doit être au service de l’entreprise…

 

Le monolithe est encore ton meilleur ami. Pour répondre à 3000 requêtes par seconde et écrire 17 000 informations par seconde, Doctolib dispose principalement d’une application web Ruby avec un front développé en React, d’une base de données Postgresql et depuis peu d’un cluster Elasticsearch pour la recherche fulltext :

Ce dernier est justement apparu suite à des problèmes de performance dans la recherche. L’idée d’Elastic était arrivée plus tôt, mais l’équipe a estimé qu’elle n’était pas allé au bout des possibilités de Postgresql pour cette feature et elle eut raison. Cependant quelques mois plus tard, croissance des données et du trafic ont eu raison des limites de Postgresql, laissant ainsi la place à Elastic. C’est donc valable pour toutes les technologies poussées par l’équipe : en quoi elle va améliorer la qualité ou la performance de l’application, est-ce que sa nouveauté/complexité en vaut la chandelle ? Si oui, l’équipe fonce, sinon mesures à l’appui, on reste comme on est.

Pour nous, chez Ineat, il n’y a pas de pire ennemi que cette phrase “on a toujours fait comme ça“, mais elle est à mettre en perspective avec d’autres, qui deviennent parfois des règles d’or :

 

Nos speakers nous le rappellent à plusieurs reprises, ce qui marche ici pour eux peut ne pas fonctionner pour d’autres, et ne plus fonctionner chez eux dans 6 ou 12 mois. Pour le moment, la raison, l’organisation (et pas des moindres : plusieurs feature teams, totalisant quelques 50 développeurs, sur un monolithe, dans un repo Git unique, avec un time to market très court…) et le pragmatisme sont les drivers de l’architecture de Doctolib. Peut être reviendront-ils l’année prochaine avec une session “Mon monolithe m’a tué, vive les micro services“, mais pour le moment nous garderons ce REX à l’esprit, c’est possible.

Pour conclure

Vous l’aurez compris, cette journée nous a conforté dans l’idée que l’architecture n’est pas une science exacte. Comme le disait Conway “les organisations qui définissent des systèmes … sont contraintes de les produire sous des designs qui sont des copies de la structure de communication de leur organisation.“, alors même si à chaque fois nous sommes persuadés de poser les bonnes bases, il faut accepter que nous écrivons le legacy d’un autre à chaque ligne de code, à chaque diagramme technique.

L’architecture logicielle emprunte beaucoup de termes à l’architecture de bâtiment : plan d’occupation, urbanisme, brique… mais elle n’a cependant pas le même “temps”. Le temps de l’informatique est beaucoup plus rapide que celui de la construction. Les cathédrales nous survivent, l’informatique n’en est pas encore là, elle est trop mouvante et en constante évolution pour résister aux épreuves des années.

Alors il faut donc avancer sereinement, en prenant les concepts de chacun des talks résumés plus haut : parfois il faut oser, souvent il faut avancer par la preuve, par la mesure (quasi obsessionnelle), se remettre en question, appliquer les patterns, résister à la tendance parfois et y succomber aussi comme le dirait Oscar Wild.

Nous en tout cas nous ne résisterons pas à la prochaine édition de la Duck Conf, vivement janvier 2020 !