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

Le , par Michael Guilloux, Chroniqueur Actualités
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Haseo86 Haseo86 - Membre éclairé https://www.developpez.com
le 06/10/2015 à 19:51
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.
Avatar de Neckara Neckara - Expert éminent sénior https://www.developpez.com
le 06/10/2015 à 22:05
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.
Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 06/10/2015 à 22:56
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.
Avatar de gretro gretro - Membre actif https://www.developpez.com
le 07/10/2015 à 0:03
Citation Envoyé par DonQuiche Voir le message
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.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 07/10/2015 à 11:13
Citation Envoyé par DonQuiche Voir le message
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.
Avatar de Laurent 1973 Laurent 1973 - Membre chevronné https://www.developpez.com
le 07/10/2015 à 11:22
Citation Envoyé par Neckara Voir le message
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:
Citation Envoyé par Principe N°3
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.
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 07/10/2015 à 11:32
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.
Avatar de Neckara Neckara - Expert éminent sénior https://www.developpez.com
le 07/10/2015 à 12:20
Citation Envoyé par Laurent 1973 Voir le message
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.
Avatar de Luckyluke34 Luckyluke34 - Membre émérite https://www.developpez.com
le 07/10/2015 à 14:20
Citation Envoyé par Michael Guilloux Voir le message
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.
Avatar de Laurent 1973 Laurent 1973 - Membre chevronné https://www.developpez.com
le 07/10/2015 à 16:33
Citation Envoyé par Neckara Voir le message
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?

Citation Envoyé par Neckara Voir le message

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?
Contacter le responsable de la rubrique Accueil