BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités L'Architecture basée sur les Services comme alternative à l'Architecture Microservice

L'Architecture basée sur les Services comme alternative à l'Architecture Microservice

Favoris

Neal Ford, directeur de ThoughtWorks, a affirmé dans un récent discours que les transitions d’organisations se font plus facilement d'une architecture monolithique vers une architecture basée sur les services, que vers une architecture microservices. A UberConf 2016, Ford a parlé des architectures axées sur les services, un juste milieu entre l'architecture orientée services et les microservices. Les diapositives sont disponibles (PDF).

Les architectures microservices ont de nombreux avantages, et Ford les recommande pour des nouveaux projets. Mais pour les organisations qui ont déjà une architecture monolithique, il y a de nombreux obstacles à surmonter lors du passage aux microservices : briser le code, probablement briser une base de données monolithique, l’adoption des pratiques Devops, le monitoring, la gestion du réseau, les transactions distribuées, etc. Le passage vers une architecture basée sur les services ne nécessite pas autant de changements. Il suffit de découper le monolithe en 8 ou 15 morceaux de code qui son simplement centrés sur les domaines. Les architectures basées sur les services consistent à des dizaines de services déployables, plutôt que des centaines ou des milliers préconisés par les promoteurs des microservices. Ces services peuvent avoir des datastores séparés, ou peuvent encore partager un seul datastore monolithique. Ford en a fait l'élément différentiateur clé, vu qu'il voit la difficulté de briser un schéma d’une grande base de données comme l'une des parties les plus compliquées de la transition vers les microservices. Mais les avantages d'une architecture microservice se concrétisent seulement si chaque microservice possède la propriété exclusive de ses données, et a de préférence son propre datastore.

Ford a souligné que les microservices apportent aussi une certaine complexité dans la compréhension de la chaîne d'appel qui se produira pour toute demande donnée, et les conséquences sur les performances de tous les appels réseaux supplémentaires. Un seul microservice peut être petit et facile à comprendre, à la fois en matière de domaine d'activité et en termes de performance. Par contre, une constellation de microservices ne l’est pas. Les architectures basées sur les services limitent le nombre d'appels de réseau en regroupant ensemble beaucoup plus de gros morceaux de code par domaine. Cela devrait aboutir à une meilleure performance. Ce qui aurait été un graphe d'appel d'une douzaine de microservices liés devient des appels de méthode au sein d'un seul service.

Cette approche implique des compromis à moyen terme. L’architecture microservices permet d’optimiser la vitesse de livraison et d'évolutivité, grâce à l'adoption des pratiques Devops et le découpage d’une partie du code en très petites unités déployables. Une architecture basée sur les services fournit plus de vitesse de livraison qu’une architecture monolithe ou une qu'une architecture orientée services (SOA) en découpant le code séparément sur la base de domaines centrés comme préconisé par les microservices et les promoteurs de DDD. SOA préconise de briser l'architecture en couches plutôt que par domaine. Cela finit par signifier qu’un simple changement de point de vue business est plus susceptible de se propager à travers de multiples couches, nécessitant beaucoup de tests pour la livraison. Une architecture centrée domaine augmentera la vitesse de livraison par rapport à une architecture monolithe ou SOA en diminuant la surface de test à un seul composant à délivrer. Plus le composant est petit, plus la surface de test est petite - point optimisé par les microservices. Mais une architecture basée sur les services devrait encore accélérer la livraison de l’effort logiciel.

Ford a conclu en comparant les différentes architectures selon d'autres axes. Il a conseillé le recours à SOA pour l'intégration dans des environnements lourds, l’architecture microservice pour tous les nouveaux projets, et l'architecture axée sur les services comme une cible pour la migration de l'architecture monolithique. Il ne recommande pas l'architecture monolithique comme un état final. Mark Richards, un autre architecte d'entreprise chevronné, a également donné une conférence sur l'architecture basée sur les services à UberConf, pour laquelle ses diapositives sont disponibles (PDF). Ensemble, ils ont produit une vidéo disponible via O'Reilly dans laquelle ils couvrent les mêmes sujets, mais plus en profondeur.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

  • Cohesion forte, couplage faible...

    by Sorgnard Sorgnard,

    Ce message a été marqué comme possible SPAM. Un modérateur le relira et le publiera sans notification dans les 24 heures. Merci.

    Les notion de "cohésion forte et de couplage faible" restent fondamentaux... Dommage que cela ne soient pas assez souvent rappelé; ce n'est pas nouveau.

  • SOA préconise de briser l'architecture en couches plutôt que par domaine.

    by slim ouertani,

    Ce message a été marqué comme possible SPAM. Un modérateur le relira et le publiera sans notification dans les 24 heures. Merci.

    SOA est une orientation entreprise avec un ensemble de principes tels que l'autonomie: serviceorientation.com/serviceorientation/servi...

    Les Microservices sont un sous-modèle SOA identifié: soapatterns.org/design_patterns/microservice

    De Microservices SOA (servicetechmag.com/I91/0715-1)

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT