Meetup architecture, les meilleures pratiques du moment

Performances, découpage, gestion de la complexité des systèmes, Tech.Rocks a réuni la communauté lors d’un meetup consacré à trois des grandes questions d’architecture. Trois experts CTO y ont répondu, en livrant leurs bonnes pratiques.

Les speakers, who’s who :

- Cyrille MARTRAIRE CTO de Arolla

- Stéphane LANDELLE, CTO de Gatling

- Arnaud LEMAIRE Responsable R&D de LGO Group

Ce meetup a été animé par Ludi AKUÉ, CTO de Carlili

1. CONTRÔLE TOTAL DE LA PERFORMANCE AVEC STÉPHANE LANDELLE (SL)

Quand les performances sont un enjeu ?

SL : "Il y a tout un tas de situations dans lesquelles les perf sont un enjeu. C’est le cas, pour un site e-commerce ou une application centrale d’un business. Ça l’est quand on encaisse un trafic conséquent, fluctuant ou même quand on prend de gros pics exceptionnellement.

Les perf sont aussi un enjeu quand on a des perspectives de croissance. C’est d’ailleurs important de l’avoir en tête au moment où l’on construit son MVP. L’objectif n’est alors pas de tenir la perf mais de démontrer une viabilité sur un marché. En conséquence, on va faire des choix de technologies, d’infrastructure ou d’architecture pour y parvenir. Il faut ainsi savoir jusqu’où le MVP est capable de nous accompagner.

Et puis, les performances sont un enjeu dans une architecture complexe. Mon conseil, il faut monter un POC consistant, qui fasse sens par rapport à sa cible et qui permette de maîtriser ses choix technologiques."

Que risque-t-on à mal envisager ses performances ?

SL :"Les risques sont nombreux. On peut endommager ses ventes, ses sources de revenus et donc encorner son image de marque. On peut aussi voir ses coûts d’exploitation augmenter. Ils peuvent être multipliés par deux ou trois avec l’autoscaling notamment."

C’est quoi un test de charge ?

SL : "Un test de charge consiste à simuler du trafic. Celui-ci est composé de différents profils. Ils correspondent soit à des situations réelles ou soit à des situations imaginées comme une future augmentation de trafic, ou un changement du taux de conversion."

Illustration par Tommy Dessine

Pourquoi passe-t-on souvent à côté des tests de charge ?

SL : "Parfois, tout simplement par excès de confiance. On se dit qu’on est un super ingénieur. On perd de vue que l’erreur est humaine, qu’on a tous nos limites. Une autre explication vient du fait de penser que le scaling out résout tout. Certes, rajouter des machines, même automatiquement se fait rapidement, sauf que ça induit une complexité supplémentaire et ça peut faire exploser l’exploitation.

Le dernier point est lié au rôle du CTO qui, parfois manque de soutien de sa hiérarchie. Les équipes sont conscientes de l’intérêt des tests de charge seulement elles sont lancées dans une course à la feature. On ne prend pas le temps pour les user stories car trop perçues comme ayant peu de valeur. Ceci étant, c’est la responsabilité du CTO d’analyser les risques et de mettre des moyens en face."

Comment envisager la réalisation de tests de charge ?

SL : "On définit tout d’abord des exigences de performances. C’est la partie la plus complexe, où l’on implique tout le monde : les gens du métier, les donneurs d’ordres, la Q/A, des Ops aussi.

Deuxièmement, on établit un process pour intégrer les tests de charge au cycle de développement.

Puis, une question se pose : est-ce que l’on fait des campagnes de tests manuelles ou lancées depuis l’intégration continue ? On identifie ensuite la responsabilité, qui met en place les tests, les exécute et analyse leurs résultats. Il vaut mieux les confier à des profils techniques.

Autre étape, définir une infra pour les tests. C’est une démarche itérative (on fait tourner les tests, on identifie le problème, on développe, déploie et valide un fix). Potentiellement, un goulot d’étranglement peut en cacher un autre. Il faut donc itérer. Cela suppose de remettre en état les environnements de ses applications, d’utiliser des technologies de container et de restauration.

Dernière question à se poser : quelle est l’échelle du test de charge ? Cela a un impact sur le coût.

Mon conseil, commencer petit, fixer des priorités et de se concentrer sur les applications les plus critiques, celles qui ont le plus d’enjeux. L’architecture est bien souvent un ensemble complexe. Il s’agit de travailler en isolation, de découper le problème en plus petits problèmes."

Comment se mettent en place les tests de charge dans la pratique ?

SL : "On a besoin de deux types d’outils. Un premier va nous permettre d’injecter de la charge sur une application. Il va simuler du trafic et des comportements virtuels d’utilisateurs. Il ne s’agit pas d’URL bashers. L’idée est d’introduire la dispersion statistique. L’outils en question travaille au niveau du réseau. Il discute avec le serveur du protocole http et simulent des comportements de navigateurs web sans pour autant en être. Des injecteurs, il en existe plein, dont Gatling qui propose de rédiger les tests sous forme de code.

Autres outils à avoir sous la main, un monitoring. Il existe plein en opensource comme en solutions commerciales."

2. L’ARCHITECTURE À L’ÉCHELLE SOLIDE AVEC CYRILLE MARTRAIRE (CM)

Une architecture idéale, ça existe ?

CM : "Quand on parle d’architecture, il y a trois points à avoir en tête. Le premier, la base est d’avoir des buts précis en termes de solutions. De vérifier précisément les problèmes que l’on cherche à résoudre.

Deuxième point dont il faut avoir conscience, à chaque fois que l’on amène une solution, on crée des bébés problèmes. Par exemple, on met en place un cache, on se retrouve ensuite avec une invalidation de cache.

Le troisième point nous conduit à la définition même d’architecture. Il est essentiel d’avoir des solutions réversibles. En effet, quand on s’engage sur un choix lourd, irréversible, comme un framework avec beaucoup de technologies, on se ferme des portes. Le propre du logiciel est de changer tout à tout moment. Une architecture est idéale quand toutes les décisions sont réversibles avec des options ouvertes."

Illustration par Tommy Dessine

Comment parvenir à une architecture à l’échelle solide ?

CM : "Dans une entreprise qui démarre, une startup early stage, tout est un. UN gros composant, UNE équipe fait tout. Tout le monde touche à tout sans limite. À chaque nouveau besoin, on ajoute du code. On met en prod par grand paquet d’un coup. Au bout d’un certain temps, on se rend bien souvent compte que ce système ne convient plus. Le travail des uns et des autres s’interfère. Une alternative apparaît, la coordination. Seulement, cela coûte du temps et de l’effort. Des travers peuvent émerger. On passe son temps à se coordonner sans rien délivrer. Tout ce qui allait vite devient lent. La frustration se développe. À ce stade, la solution est de découper le système. De passer d’un morceau à 5, avec plusieurs composants, plusieurs équipes…

Faut-il un outillage particulier ?

Des technologies pour découper existent et sont connues : les PaaS, les containers, les orchestrateurs, les CI/CD pipelines. Idem en matière de pratiques : microservices, architectures en Event-Driven, API, Gateway… tout ça on sait faire. En revanche, les grosses questions sont : comment on découpe ? Où met-on ses contours ?"

Comment découper son système ?

CM : "On commence tout d’abord par prendre du recul en se posant la question : quelles sont mes zones fonctionnelles ? Paiement, catalogue, biling… On l’aborde d’un point de vue métier. On parle alors avec tous les leaders concernés. On définit ainsi avec eux les domaines, nos zones d’expertise. Ensuite, on décline sous forme de découpage technique. Cette démarche s’appelle DDD, pour domain driven, à savoir dirigé par le domaine, le métier. Ensuite, il s’agit d’identifier les bouts de découpage à partir des sous-domaines métier. On peut y procéder à partir du langage, des champs lexicaux des systèmes. On peut porter attention aux mots avec des suffixes en ing ou en tion : biling, shipping, recommandation, navigation…

L’autre méthode pour découper s’intéresse au but. Prenons un élément du vrai monde comme un livre. Selon des contextes particuliers, on peut le modéliser de différentes façons en sous-domaines. Dans un catalogue, un livre n’a rien à voir avec un livre pour livrer. En termes de livraison, un livre est un objet avec un poids, des dimensions. En matière de recommandation, il est une référence achetée en même temps que d’autres. Quand on fait de l’architecture depuis longtemps cette idée est peut-être hérétique. Jusqu’ici, on avait tendance à chercher l’unification. Il faut abandonner ça et modéliser plusieurs fois les mêmes choses du vrai monde pour différents buts."

Illustration par Tommy Dessine

Comment on s’y prend en pratique ?

CM : "Concrètement, pour découper son système en sous-domaines, le mieux est d’interviewer des « sachants » pour comprendre la façon dont ils pensent leur système. Puis, on synthétise leur propos schématiquement de sorte à faire ressortir les éléments convergents. L’event storming fonctionne d’ailleurs bien ici.

Au final, on obtient un document qui ressemble aux bonnes vieilles cartes d’archi, avec un cahier des charges strict. Au moment de l’appliquer, il est inutile de tout faire parfaitement d’un seul coup et de vouloir atteindre son but immédiatement. Au contraire, on va se dire : cette carte est ma cible idéale. Puis, à chaque fois qu’on a un projet transformant, comme la réécriture d’un bout, la croissance d’un autre, on va en profiter pour s’aligner. On avance par opportunité et non par avance. On ne stocke pas.

Bien sûr, le legacy et le découpage parfait ne correspondent pas toujours. On vit avec. L’idée est de découper au fil de l’eau, au fil de la croissance et d’échapper ainsi à la tyrannie du un."

Est-ce que le découpage suppose des points de vigilance particuliers ?

CM : "Dès lors que l’on découpe, on a de fait un contrat, un protocole (JSON,node, java) que chaque côté s’engage à respecter. Il y en a partout à l’intérieur des systèmes, entre nous et nous. Il peut tuer toute agilité s’il est mal envisagé. Il s’établit plutôt au début. La règle d’or des contrats est de ne pas les casser et de les respecter.

Autre point, le partage des données. Il faut savoir qui - pour chaque bout de données - fait autorité. Pour l’adresse de facturation du client, c’est probablement le billing, ou pas, pour des raisons historiques. Concernant le mode d’échange des données, tout est possible, de la simple vue en base de données jusqu’au messaging avec des contrats d’événements clairs."

Vous retrouverez les slides de Cyrille MARTRAIRE sous ce lien : https://speakerdeck.com/cyriux/architecture-at-scale-the-essentials-tech-dot-rocks-meetup

3. Maîtriser la complexité de son système avec Arnaud LEMAIRE (AL)

Comment augmente la complexité d’un système ?

AL : "On a tendance à penser qu’elle a une relation linéaire avec la montée en taille. En d’autres termes, si mon système double, je dois m’attendre à ce que la complexité double aussi. Or, en réalité, c’est une exponentielle où assez rapidement, quand la taille augmente, la complexité devient énorme.

On peut faire l’analogie avec la construction. Pour fabriquer une cabane de jardin, au niveau de l’outillage et des techniques impliquées, rien n’est très complexe. Un marteau, une planche, quelques clous, on arrive à faire une structure qui tient debout. Pour une maison individuelle, déjà, la montée en complexité apparaît avec des contraintes. Quant à la construction d’un gratte-ciel, les questions qui se posent sont complètement différentes. Il s’agit de permettre à des gens de monter 40 étages, leur amener de l’eau sous pression, garantir leur sécurité avec des systèmes de détection incendie…"

Comment réagissent les systèmes une fois leur taille critique atteinte ?

Illustration par Tommy Dessine

AL : "Autant dans le BTP, le système s’écroule quand il franchit sa taille critique. Il s’effondre sous le poids de sa propre complexité. Le souci, dans le domaine du logiciel, qui est par nature intangible, on ne voit malheureusement pas l’effondrement. On le ressent. On se retrouve avec des applications qui meurent d’elles-mêmes à cause d’une complexité devenue trop conséquente. Souvent, la réponse à cela, est d’essayer de construire plusieurs petits systèmes individuels. C’est souvent de là que viennent les éléments liés aux microservices. Seulement, ce type d’architecture peut conduire à multiplier la complexité des systèmes entre eux au lieu de l’additionner. On retombe alors dans le problème initial, une courbe exponentielle et un SI intenable.

Autre difficulté, dans un SI composé de différents domaines, souvent les petits systèmes ont été construits de façon organique. Ils s’avèrent plus ou moins fragiles. Dès que l’on en modifie un, on peut en casser un autre qui n’a rien à voir, par effet de bord. On peut tout à fait voir tomber le système de recherche parce que celui de la gestion des stocks est down. En cause, une mauvaise vision de ce tout ce qui se passe en réalité entre tous ces blocs."

Comment maîtriser la complexité ?

AL : "On a deux problèmes à appréhender. Le premier est lié à une orchestration mal agencée. Le second concerne des systèmes trop curieux les uns envers les autres. Prenons le cas suivant, quand une commande est passée sur un site e-commerce. Le système de commande prévient le système de paiement : on a une commande à faire payer. On cherche à savoir ensuite si la commande est bien payée auprès du système invoicing. Une facture est générée en statut paid. Puis, on va chercher le pdf associé pour l’envoyer au système fullfilment, qui pourra l’imprimer et le placer dans le carton avec commande. Le problème ici, le order management s’intéresse trop à ce que font les systèmes de paiement et de facturation. Pour éviter ça, on a tendance à passer à une architecture réactive qui ferait apparaître encore d’autres problèmes. C’est une erreur. Il vaut mieux poser des frontières claires avec surtout des points uniques. Permettre aux systèmes de collaborer les uns avec les autres. Pour y parvenir, on peut tout à fait promouvoir un système existant. Considérer la brique facturation comme frontière par laquelle tout doit passer. Il est de surcroît possible de construire un nouveau système qui va servir d’intermédiaire. Il en existe trois grands types : les agrégateurs de données, les orchestrateurs ou encore le proxi avec une façade."

Illustration par Tommy Dessine

Vous retrouverez les slides d'Arnaud LEMAIRE sous ce lien : https://speakerdeck.com/lilobase/complexite-and-localite-tech-dot-rocks-juin-2020

Prochain rendez-vous de la communauté Tech Leaders, jeudi 18 juin 2020 lors d’un meetup qui pose les questions suivantes. Quel est l'état de la relation entre CTO et CPO ? Peut-on avoir la double casquette ? Quels sont les axes de collaboration quand on n'a pas les mêmes objectifs ?

Jean LEBRUMENT CPO/CTO et co-fondateur de Brigad, Pierre FOURNIER Ex-CPO ManoMano, Evelyne NOTTON CTO de Splio, Meriem BERKANE, CTO de Octo & co-présidente du comité contenu de Tech.Rocks seront présents pour y répondre.

Tous Les Articles
×

Vous y êtes presque...

Nous venons de vous envoyer un e-mail. Veuillez cliquer sur le lien contenu dans l'e-mail pour confirmer votre abonnement !

OK