IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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
19 commentaires

147PARTAGES

1  1 
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

Une erreur dans cette actualité ? Signalez-nous-la !

19 commentaires
Commenter Signaler un problème
Luckyluke34
Avatar de 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.
5  0 
DonQuiche
Avatar de 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.
3  0 
Laurent 1973
Avatar de 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.
2  0 
Saverok
Avatar de 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.
2  0 
Laurent 1973
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 08/10/2015 à 10:28
Citation Envoyé par Neckara Voir le message

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é )
2  0 
Neckara
Avatar de Neckara
Inactif https://www.developpez.com
Le 08/10/2015 à 12:42
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.
2  0 
Luckyluke34
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 08/10/2015 à 16:47
Citation Envoyé par Neckara Voir le message
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.
2  0 
el_slapper
Avatar de 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.
1  0 
Laurent 1973
Avatar de 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?
1  0 
Neckara
Avatar de Neckara
Inactif https://www.developpez.com
Le 07/10/2015 à 17:59
@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.
1  0 
Commenter Signaler un problème