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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

ALM Discussion :

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


Sujet :

ALM

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    juillet 2013
    Messages
    2 513
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 513
    Points : 78 711
    Points
    78 711
    Billets dans le blog
    2
    Par défaut DevOps : l’architecture en microservices pourrait permettre de réfuter le mythe du mois-homme
    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éclairé
    Ingénieur de recherche
    Inscrit en
    novembre 2008
    Messages
    227
    Détails du profil
    Informations professionnelles :
    Activité : Ingénieur de recherche

    Informations forums :
    Inscription : novembre 2008
    Messages : 227
    Points : 822
    Points
    822
    Par défaut
    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.

  3. #3
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    9 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 9 013
    Points : 22 975
    Points
    22 975
    Par défaut
    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.

  4. #4
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    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.

  5. #5
    Membre averti
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2009
    Messages
    98
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2009
    Messages : 98
    Points : 306
    Points
    306
    Par défaut
    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.

  6. #6
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 677
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 677
    Points : 30 973
    Points
    30 973
    Par défaut
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #7
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 149
    Points
    2 149
    Par défaut
    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.

  8. #8
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    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.

  9. #9
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    9 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 9 013
    Points : 22 975
    Points
    22 975
    Par défaut
    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.

  10. #10
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 912
    Points
    2 912
    Par défaut
    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.

  11. #11
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 149
    Points
    2 149
    Par défaut
    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?

  12. #12
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    9 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 9 013
    Points : 22 975
    Points
    22 975
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    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.

    Citation Envoyé par Laurent 1973 Voir le message
    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.

  13. #13
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    Citation Envoyé par Neckara Voir le message
    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.

  14. #14
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    9 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 9 013
    Points : 22 975
    Points
    22 975
    Par défaut
    @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.

  15. #15
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 149
    Points
    2 149
    Par défaut
    @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.

  16. #16
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    9 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 9 013
    Points : 22 975
    Points
    22 975
    Par défaut
    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".

  17. #17
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 149
    Points
    2 149
    Par défaut
    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é )

  18. #18
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    9 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 9 013
    Points : 22 975
    Points
    22 975
    Par défaut
    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.

  19. #19
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 912
    Points
    2 912
    Par défaut
    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.

  20. #20
    Membre extrêmement actif Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    octobre 2007
    Messages
    1 545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 545
    Points : 1 942
    Points
    1 942
    Par défaut
    Citation Envoyé par Neckara Voir le message
    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 ?
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

Discussions similaires

  1. [Stage] Quand le stage pourrait nuire à l'emploi
    Par Sphax dans le forum Stages
    Réponses: 26
    Dernier message: 04/08/2005, 17h56
  2. Réponses: 7
    Dernier message: 18/12/2003, 11h23

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo