Discussion :

[Michael Guilloux]

DevOps : l’architecture en microservices pourrait permettre de réfuter le mythe du mois-homme
Selon le CTO d’Electric Cloud

Comment accélérer le développement et le déploiement des applications ? Selon Anders Wallgren, CTO de la société Electric Cloud, la solution pourrait se trouver dans le DevOps avec l’introduction de l’architecture en microservices. Wallgren va jusqu’à affirmer que les microservices sont en train de prouver que le mythique homme-mois n’est plus vérifié dans le contexte IT actuel. Mais qu’est-ce que le mythique homme-mois ?

Le mythique homme-mois ou le mythe du mois-homme ou encore loi de Brooks est une théorie mise en avant par Frederick Brooks et considérée comme un classique dans le domaine du génie logiciel. Dans sa théorie présentée en 1975, Brooks fait référence à une unité de coût de développement (l’homme-mois) qui traduit la quantité de travail d’un homme pendant un mois. Il explique dans sa théorie que si une personne doit travailler pendant n mois pour terminer un projet, ce n’est pas pour autant que n personnes seront capables de terminer le travail pendant un mois. Autrement dit, on ne peut pas diviser le temps de développement d’un projet en deux, juste en doublant l’effectif de l’équipe projet. Il illustre cela par le fait que « neuf femmes ne font pas un enfant en un mois », même si une femme est censée faire un enfant neuf mois après sa conception.

40 ans plus tard, la loi de Brooks semble encore valable, mais le CTO d’Electric Cloud pense que les architectures en microservices peuvent permettre de la réfuter.

L’idée de base des microservices est que certains types d’applications – notamment les applications d’entreprise, et les logiciels SaaS fournis sur Internet - sont plus faciles à construire et à maintenir quand ils sont décomposés en de plus petits composants. Chaque composant est pensé de sorte à être développé, déployé, exécuté et géré séparément des autres composants. L’application sera donc l’assemblage de chaque microservice. Cette approche est en contraste avec les applications traditionnelles monolithiques qui sont entièrement développées en une seule pièce. Les différents composants d’une architecture en microservices pourront donc communiquer entre eux via des API accessibles sur http, grâce à des outils et techniques familiers aux développeurs.

Parmi les avantages des microservices, on note la modifiabilité. Étant donné que le code d’un microservice est autonome de celui des autres, une mise à jour d’un composant n’impacte par les autres microservices. L’indépendance entre les différents services favorise surtout le développement de chaque composant en même temps, ce qui est beaucoup plus difficile avec les applications traditionnelles. Pour cette raison, Anders Wallgren pense que l’architecture en microservices est la solution pour accroître la vitesse de développement et de déploiement des applications. Il va plus loin pour affirmer qu’elle peut permettre de réfuter le mythique homme-mois, mais sous certaines conditions.

Il souligne en effet certaines difficultés qui se présentent dans la pratique. Wallgren estime que « les microservices ne sont pas une aubaine pour tout le monde ». L’architecture en microservices est plus facile à implémenter pour une application monolithique existante, mais beaucoup plus difficile à concevoir lorsqu’on part de zéro. Il ajoute aussi que certains types d’applications tels que les logiciels sur site « pourraient ne pas être bons pour les microservices, compte tenu de la coordination et l’infrastructure nécessaires pour déployer des applications microservices ». Au-delà de ces aspects techniques, les microservices passent par une véritable culture DevOps, avec des équipes de développement et d’exploitation qui travaillent en étroite collaboration pour supporter une application sur son cycle de vie.

Sources : The Enterprisers Project, opensource.com

Et vous ?

Que savez-vous de l’architecture en microservices et des difficultés liées à son implémentation ?

Pensez-vous que DevOps et l’architecture en microservices sont la clé pour accélérer le développement et le déploiement des applications ?

Forum ALM

[Haseo86]

DevOps, les architectures en micro-services, ça fait partie de ces bonnes, voire excellentes idées (comme le développement agile par exemple), qui tombent malheureusement souvent à l'eau parce que mises en place par des directeurs de projet qui ne les comprennent pas, et sont incapables de fait d'adopter des méthodes et une stratégie de développement adéquate.

[Neckara]

Personnellement, je trouve que cette affirmation ne ne semble pas très compatible avec une entreprise agile. On ne peut pas faire plusieurs itérations agiles en parallèle.
De plus, ce n'est pas parce qu'on met 50 personnes en réunion face à un client qu'on ira 50 fois plus vite à comprendre ses besoins.

Il y a aussi quelques limites, on ne peut pas faire certains types de tests avant que tout, ou certaines parties ne soient écrites.
Il faut aussi coordonner toutes ces équipes, écrire des specs, faire des réunions, etc.

[DonQuiche]

Les micro-services augmentent sans doute la scalabilité mais ils tendent aussi à augmenter le coût total de développement : il faut davantage de plomberie pour faire communiquer tout ce petit monde.

[gretro]

Les micro-services augmentent sans doute la scalabilité mais ils tendent aussi à augmenter le coût total de développement : il faut davantage de plomberie pour faire communiquer tout ce petit monde.

Ce qui m'inquiète aussi c'est l'évolution des ces services suite à un breaking change. Il faut souvent supporter plus d'une version à la fois et la coordination pour retirer les méthodes obsolète devient nettement plus complexe. C'est évidemment possible, mais c'est évident plus difficile qu'un seul produit mis à jour régulièrement.

Bref, je pense que c'est plus l'orientation au DevOps qui change la donne. Un gros produit qui est déployé régulièrement avec du CI et des scripts de déploiement en un click peut aussi faire une différence et peut être plus simple à gérer.

[el_slapper]

Les micro-services augmentent sans doute la scalabilité mais ils tendent aussi à augmenter le coût total de développement : il faut davantage de plomberie pour faire communiquer tout ce petit monde.

et puis tous les problèmes ne sont pas découpables en micro-services, hein. Le concept de routine existait déjà du temps de Fred Brooks. Et on pouvait découper le projet en routines, charge à chaque développeur de s'en coltiner une. Mais il y a une limite basse à la taille efficace des routines.

[Laurent 1973]

Personnellement, je trouve que cette affirmation ne ne semble pas très compatible avec une entreprise agile. On ne peut pas faire plusieurs itérations agiles en parallèle.
De plus, ce n'est pas parce qu'on met 50 personnes en réunion face à un client qu'on ira 50 fois plus vite à comprendre ses besoins.

Il y a aussi quelques limites, on ne peut pas faire certains types de tests avant que tout, ou certaines parties ne soient écrites.
Il faut aussi coordonner toutes ces équipes, écrire des specs, faire des réunions, etc.

Attention, ne confondons pas Agile et Scrum, qui est la méthode Agile la plus utilisée (parfois à tord).
Rappel, dans l'Agile Manifesto, nous avons:

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

Cela n'implique pas forcement d'avoir des itérations au sens Scrum, mais des cycles cours de livraison.
En livrant chaque fonctionnalités dès quelles sont "Done" on couvre bien ce principe => le microservice est dans cette logique.

Si tu t'organise plutôt en Kanban, ta logique est de livrer ta fonctionnalité dès qu'elle est fini, pas en fin d'une itération d'une durée imposée.
Dans une organisation Kanban, on pourrait très bien avoir cette logique de DevOps/Microservices justement pour développer rapidement chaque demande de modification/amélioration/correction indépendamment l'une de l'autre.

Plus qu'une équipe de 50 développeurs, je verrais plutôt 8 équipes de 6 développeurs pluridisciplinaires et organisées en Kanban.
Et a ce moment, on pourrait bien avoir plusieurs dizaines de demande en même temps, ayant des impacts indépendants, et pouvoir les développer et les déployer au plus vite.
Bien sur, cela nécessite des infrastructures techniques adaptées, je pense entre autre à une simplicité de créer des bac-à-sables pour les tests/validations.

[Saverok]

C'est de l'architecture SOA, rien de neuf et on commence déjà à avoir un certain recul dessus

Comme très bien dit par DonQuiche, côté infra, faut assurer car la tuyauterie entre chaque micro service peut entraîner de la latence réseau qui une fois cumulée, a un impact très significatif sur les perf.
Le versionning de chaque micro service peut également virer au casse tête.

[Neckara]

Cela n'implique pas forcement d'avoir des itérations au sens Scrum, mais des cycles cours de livraison.
En livrant chaque fonctionnalités dès quelles sont "Done" on couvre bien ce principe => le microservice est dans cette logique.

Ce que je veux dire c'est qu'on va livrer quelque chose, avoir des retours client, éventuellement modifier en conséquence ou s'apercevoir qu'on a mal compris le besoin client.

On ne peut pas modifier le produit selon les retours clients avant d'avoir un début de quelque chose à montrer au client et donc d'avoir eu ses premiers retours. Pire, si on fait trop de chose en même temps et qu'on s'aperçoit qu'on est complètement passé à côté du besoin client, c'est autant de ressources gaspillée.

[Luckyluke34]

l’architecture en microservices pourrait permettre de réfuter le mythe du mois-homme

Drôle de reformulation... étant donné que le mythe du mois-homme est déjà ce qui est réfuté dans le livre "The Mythical Man-Month" lui-même.

"Start to beat the Mythical Man Month" dans l'article d'origine veut dire vaincre le livre "The Mythical Man Month" et non pas vaincre le mythe. Et en plus, on commence (start) à le vaincre ou à le repousser mais il n'est pas réfuté de manière formelle.

[Laurent 1973]

Ce que je veux dire c'est qu'on va livrer quelque chose, avoir des retours client, éventuellement modifier en conséquence ou s'apercevoir qu'on a mal compris le besoin client.

Tu peux lui faire valider ton énoncer de tests pour confirmer des use-cases.
Tu peux aussi lui envoyer une copie d'écran dans le cas de validation d'interface graphique.
Qu'est ce qui t’empêche d'appeler le client pour lui faire faire un essai sur ton bac-à-sable avant la mise en prod?

On ne peut pas modifier le produit selon les retours clients avant d'avoir un début de quelque chose à montrer au client et donc d'avoir eu ses premiers retours. Pire, si on fait trop de chose en même temps et qu'on s'aperçoit qu'on est complètement passé à côté du besoin client, c'est autant de ressources gaspillée.

En Agilité, on cherche aussi a décomposer un développement en petites fonctionnalités, le but étant d'avoir très rapidement quelque chose à monter au client.
Je trouve justement que le microservice va tendre a n'avoir que plein de petites fonctionnalités assez indépendantes entre elles.
Joindre ces deux concepts devraient justement nous aider à ne pas risquer d'avoir ce soucis d'effet tunnel.

Entre le moment où on a la demande client et le moment où on livre, rien ne nous empêche de lui parler à notre client pour vérifier que l'on a tout bien compris comme il faut.
En Agilité, on conserve une interaction avec le client tout le long du processus de développement, pourquoi le microservice et le DevOps remettent en cause cela?

[Neckara]

Tu peux lui faire valider ton énoncer de tests pour confirmer des use-cases.
Tu peux aussi lui envoyer une copie d'écran dans le cas de validation d'interface graphique.
Qu'est ce qui t’empêche d'appeler le client pour lui faire faire un essai sur ton bac-à-sable avant la mise en prod?

Tu ne vas pas appeler ton client toutes les 5 minutes pour faire un essai, je présumes qu'il a aussi d'autres occupations/projets.

Si ton client met 1 semaine avant de venir en réunion (agenda, toussa), ce n'est pas en lui envoyant 50 invitations qu'il viendra plus vite.
S'il met 2 jours à répondre à tes e-mails parce qu'il va en parler un peu en interne, tu peux pas y faire grand chose, c'est du temps incompressible.

Et je vois mal comment tu pourrais améliorer l'interface graphique avant d'avoir eu le retour du client ou avant même d'avoir fait une première version de l'interface graphique. Je vois très mal comment tu pourrais paralléliser ces deux tâches.

En Agilité, on conserve une interaction avec le client tout le long du processus de développement, pourquoi le microservice et le DevOps remettent en cause cela?

Je ne parle pas de cela, mais de "réfuter le mythe du mois-homme" en utilisant le microservice.

Si tu décides de tout paralléliser au maximum, tu ne fais plus qu'un seul cycle. C'est qu'au final tu avais toutes les specs dès le début, c'est du cycle en V (ou autre), mais pas de l'agilité.

Si tu fais plusieurs cycles, tu ne peux plus réfuter le mythe du mois-homme vu que tu as une limite en nombre de cycle.

[Saverok]

Je ne parle pas de cela, mais de "réfuter le mythe du mois-homme" en utilisant le microservice.

Si tu décides de tout paralléliser au maximum, tu ne fais plus qu'un seul cycle. C'est qu'au final tu avais toutes les specs dès le début, c'est du cycle en V (ou autre), mais pas de l'agilité.

Si tu fais plusieurs cycles, tu ne peux plus réfuter le mythe du mois-homme vu que tu as une limite en nombre de cycle.

Tu fais de l'Agilité sur chaque microservice.
Chaque microservice étant indépendant, c'est un peu comme si c'était à chaque fois un miniprojet dédié.

Tu as le projet principal qui est l'orchestrateur de tes microservices (le BPM est idéal pour cela) puis une multitude de miniprojets internes parallélisés pour tes microservices.
Tu n'as pas besoin d'avoir l'intégralité de tes spec au démarrage mais uniquement les contrats de services de tous tes microservices.

[Neckara]

@Saverok Mais dans ce cas là, tu ne brises pas le mythe du mois-homme car tu conserves une granularité.

En 9 mois, avec 9 femmes, je peux avoir 9 enfants.
Mais en 1 mois, avec 81 femmes, tu ne peux pas avoir 9 enfants.

De plus, tu vas avoir des phases de tests qui vont nécessiter d'avoir tout ou partie des microservices, c'est aussi du temps difficilement compressible.
De même pour les réunions avec le client, on va peut-être faire une réunion par semaine, mais qu'on découpe le projet en 10 ou 50 micro-services on ne va pas pour autant nécessairement faire plus de réunions.

[Laurent 1973]

@Neckara:
- Tu n'as pas forcement 1 seul client.
- Pour une même entreprise client, tu peux aussi avoir des interlocuteurs différents: chaque microservice n'est pas forcement demandé par tout le monde.
- Comme chaque microservice est indépendant, donc tu les peux commencer, développer, valider, déployer indépendamment.
- Comme chaque microservice est indépendant, tu peux réaliser les tests indépendamment. C'est à dire que pour chaque miniprojet (comme l'évoque @Saverok) tu vas avoir ta propre logique de validation et ton propre environnement de tests (c'est pour cela que je parlais de bac-à-sable de tests, afin de multiplier ces environnements à volonté). Tu n'as nullement besoin de t'attendre entre microservice pour réaliser cette validation.
- Si tu es en attente d'un retour client, tu pourrais te permettre de dire (en le contractualisant avec le client avant) que tu gèles temporairements ce microservice: le ou les développeurs vont alors renforcer les autres mini-projets pendant ce temps.

C'est une autre façon de penser.

Par contre, là où en effet il faut modérer la théorie, certain changement d'échelle peuvent quand même provoquer des chamboulements.
De passer de 5 à 20 ou de 20 à 50 microservices développés en parallèle impact forcement les infrastructures ainsi que des éléments de management.

[Neckara]

En gros tu renommes un projet "microservice".

Donc il te faut 9 mois pour développer ton microservice.
Est-ce que tu peux le diviser en 9 "sous-microservice" ?


Ce que je veux dire c'est qu'on conserve quoiqu'il arrive une certaine granularité et parfois du temps incompressible.
On ne peut pas dire que chaque dev va taper une lettre, comme ça le logiciel sera fini en 1 seconde.
Quelque soit le nombre de dev, le temps de démarrer l'ordinateur, lancer l'IDE, se prendre le café du matin plus la réunion de 5 minutes du matin, cela prendra toujours autant de temps.

Je prend des exemples extrêmes.

Je suis d'accord pour dire que cela peut permettre de repousser le mythe mois-homme, mais pas de le "réfuter".

[Laurent 1973]

Donc il te faut 9 mois pour développer ton microservice.
Est-ce que tu peux le diviser en 9 "sous-microservice" ?

Ben a ce moment là, tu ne fais plus du "microservice" mais plutot du "nanoservice" voir du "picoservice"

Visiblement, tu évoque l'agilité, mais tu ne la pas vraiment expérimenté.
Moi, je comprend "microservice" un peu à la manière que l'on va décrire une "user-story" en Scrum: une fonctionnalité très atomique développable en quelque jours.
Dans la description de l'article, je verrais le microservice comme un miniprojet de 5-8 jours/homme maximum (analyse, développement, validation, déploiement inclus)

Un microservice de 9 mois n'en n'est pas un, c'est un projet complet.
Mais tout les projets ne sont pas découpable en microservice.
Comme toutes organisations n'est pas forcement faite pour Scrum (Kanban est trop souvent oublié )

[Neckara]

9 mois, 1 mois, 1 semaine, on s'en moque.
La question est de savoir si je met n fois plus de développeurs sur ce micro-service, est-ce que j'irais n fois plus vite ?
Si non, on a pas réfuté le mythe mois-homme. On peut parler de semaine-homme ou de jours-homme voir d'heure-homme, le principe reste le même.


De plus, si tu admets que tous les projets ne sont pas découpables en microservices, on voit bien qu'on ne considère qu'une sous-partie qui nous arrange parmi l'ensemble projets. On ne peut donc pas généraliser à l'ensemble des projets.

C'est comme si tu disais :

• Je prend un sous-ensemble e dans E où A est vrai.
• Je prouve que A est vrai dans e
• Donc A est vrai dans E.

Et si on apporte un contre exemple x, on prouve que x ne peut pas appartenir à e, donc on réfute le contre-argument ou on fait sortir x de l'ensemble e.

De plus, tu peux facilement construire un ensemble e en prenant des éléments de E indépendants.
Donc considérer qu'un ensemble de projets indépendant puissent constituer un seul projet.
Mais on prend des cas très particuliers.

[Luckyluke34]

La question est de savoir si je met n fois plus de développeurs sur ce micro-service, est-ce que j'irais n fois plus vite ?
Si non, on a pas réfuté le mythe mois-homme. On peut parler de semaine-homme ou de jours-homme voir d'heure-homme, le principe reste le même.

Oui, et je pense qu'il y a une raison pour que l'auteur de l'article ait mis start beating et non pas beat.

En effet, dire qu'on a une équipe par micro-service ne résout pas tout. Les nouveaux embauchés à l'occasion de la création d'un micro-service auront forcément une courbe d'apprentissage par rapport à l'entreprise, au technos, etc. et il faut bien que quelqu'un leur enseigne.
Qui ? Quelqu'un d'une autre équipe / micro-service ? perte de productivité pour celle-ci.

Autre grosse problématique qu'on évoque peu souvent : la coordination entre micro-services.
Tout comme les process métier d'une entreprise sont très souvent corrélés et réagissent les uns aux autres, les micro-services devront l'être. En l'absence d'une vision d'ensemble rigoureuse et d'une coordination entre les équipes qui écrivent ces micro-services, soit on risque d'oublier des liens, soit on va fortement coupler nos micro-services entre eux dans un enchevêtrement de liens qui seront pires que si on avait un bon gros système monolithique. Dans ce cadre, l'ajout d'un nouveau micro-service et de l'équipe qui correspond n'a pas un impact nul, il ajoute au travail de gestion de la communication et de coordination entre équipes.

[ddoumeche]

9 mois, 1 mois, 1 semaine, on s'en moque.
La question est de savoir si je met n fois plus de développeurs sur ce micro-service, est-ce que j'irais n fois plus vite ?
Si non, on a pas réfuté le mythe mois-homme. On peut parler de semaine-homme ou de jours-homme voir d'heure-homme, le principe reste le même.

C'est une vieille question et le mythical man month (que j'ai lu) répond de manière négative parce le nombre de relations de communication entre agents est de N! qui explose donc avec le nombre de développeurs.
En outre, il faut former les nouveaux développeurs ce qui pénalise encore l'équipe et réduit les délais de livraisons. Le pire pour un projet en retard est parfois donc d'embaucher de nouveaux développeurs.

Qu'est ce qu'une architecture micro-services ? des dizaines de wars avec un cycle de release différents ?