Publié par

Il y a 5 ans -

Temps de lecture 4 minutes

State of the art in Microservices (par Adrian Cockcroft)

Le monde de l’IT ne cesse de s’accélérer. Alors que Docker n’était présent sur aucune feuille de route 2014, il le sera sur toutes en 2015. Pourquoi ? Ce mécanisme de containeur léger est agréable à utiliser en développement et facilite la chaîne de déploiement, et contrairement à une machine virtuelle, c’est extrêmement rapide. Et la vitesse, c’est addictif !

Aujourd’hui, des startups sont capables de rivaliser et prendre des parts de marché d’acteurs historiques. Elles sont souvent plus souples, plus agiles et arrivent à mieux satisfaire leurs clients rapidement, et ceux à travers le monde, tout en étant rentable en maitrisant leurs coûts notamment grâce au Cloud.

Adrian a longtemps travaillé chez Netflix. Il est maintenant consultant pour apporter ses recettes d’audaces technologiques et de challenges à destinations des grandes entreprises conscientes de ce changement économique imminent.

Son plan en quatre points ressemble beaucoup au PDCA :

  • Observe : nécessite des idées et une capacité d’innovation,
  • Orient : valider les idées par A/B testing,
  • Decide : être capable de prendre des décisions rapidement,
  • Act : il faut déployer rapidement cette nouvelle idée partout (cloud to scale).

Pour pouvoir agir rapidement et efficacement, il faut changer les organisations en silos, faire tomber des barrières.

Pour Adrian, l’architecture microservice est liée avec la notion d’équipe produit. Cela permet d’obtenir des petites équipes autonomes et légitimes sur un produit. Cette autonomie est la clé pour agir rapidement et efficacement sur un marché concurrentiel.
Alors qu’il y a quelques temps, un slogan disait « you build it, you run it », on peut maintenant dire « you build it, you run it, you support it ». À Devops, Adrian préfère « Business Dev Ops » car l’intérêt premier est de servir un besoin d’utilisateurs, du début à la fin.

Pour arriver à ce type d’organisation, qui a fait de Netflix ce qu’il est aujourd’hui, voici les différents points à regarder.

Inverse of Conway’s law

La loi de Conway est bien connue. Elle stipule que l’architecture d’un projet est fortement liée au schéma d’organisation des équipes qui l’ont créé. Adrian s’en sert en retournant la loi : constitue des équipes comme tu souhaiterais que soit l’architecture de ton projet. C’est à dire, faiblement couplé et fortement cohérente !

Centralized database schema

Il y aurait de trop forts couplages entre les modules si tous devaient utiliser la même base. Il faut oublier le schéma de données universel. Le mot qui revient souvent avec « microservice » est « bounded-context ». Cette notion issue de « Domain Driven Design » permet de découper un projet en un ensemble de groupements fonctionnels, isolés les uns des autres.

Car un microservice répond surtout à un découpage fonctionnel et non technique. Il est différent d’un simple « bounded-context » car un microservice a en plus toutes les caractéristiques d’un système fonctionnel, OS, Log, Déploiement… C’est en quelque sorte un « running bounded-context ».

Entreprise Service Bus

Microservice n’est pas sans rappeler les architectures SOA. La grande différence ? Alors que les architectures SOA misaient fortement sur l’Entreprise Service Bus, cette nouvelle approche  est basée sur le concept de « dumb-pipe, smart endpoint ».
Fini les bus de messages intelligents voués à contenir de la logique métier pour le routage, filtrage et regroupement des données. L’approche microservice quant à elle place ces besoins dans le code. Ainsi, le bus reste le plus simple possible.

Selon Adrian, Docker accélère les développements et permet la mise en place de microservices très rapidement. Il évoque d’ailleurs « develop at the speed of Docker »

Des innovations comme Amazon Lambda viennent encore accélérer tout cela. Cette fonctionnalité permet de faire exécuter à Amazon un code donné pour une requête précise. Aujourd’hui, il est ainsi possible de faire exécuter 1 Million de requêtes par mois gratuitement chez AWS. Avec le cloud, une entreprise pouvait gérer ses coûts à l’heure, nous changeons ici d’échelle car la granularité descend à 100ms !

Et la data alors ? Dans son portefeuille de projets open-source, Netflix propose pléthore d’outils à ce sujet. Ils sont aujourd’hui basés sur l’idée de « store éphémère ». Le seul élément persisté et répliqué est un journal de log, comme dans l’approche d’EventSourcing. Ensuite, toutes les autres bases de données ne sont que des vues matérialisées, reconstruites à la volée si nécessaire et détruites lorsqu’elles ne sont plus utiles. Voilà de quoi bien changer notre vision du SI de demain!

Une petite lecture pour la fin : The Phoenix project book

Publié par

Publié par Xavier Bucchiotty

Software Engineer Scala Fanboy FP constant learner Akka trainer

Commentaire

10 réponses pour " State of the art in Microservices (par Adrian Cockcroft) "

  1. Publié par , Il y a 5 ans

    La vague des microservices sera l’occasion de remettre au gout du jour les préoccupation initiales des architectures orientées services (SOA) à savoir un SI faiblement couplé qui ne rime pas nécessairement avec ESB.

    Le marketing du milieux des année 2000 a galvaudé la SOA au point de la faire rimer systématiquement avec les plateformes ESB lesquels ont fini par porter de la composition métier alors que ce n’était pas leur rôle. Une composition qui a contribué à rendre rigide la plateforme sensée rendre le SI plus agile (plus faiblement couplé).

    Cela dit, l’approche microservices ne va permettre de répondre à la préoccupation d’agilité que si elle est accompagnée par une démarche d’architecture d’entreprise (EA). Ce n’est généralement pas la tasse de thé d’amateurs de techniques de ce blog mais c’est nécessaire au même titre que les plans d’urbanisation d’une ville.

    Pourquoi une approche d’EA ?

    Parce qu’il y a deux échelles antinomiques de « besoins métier » : les besoin métier de type use case (situé à la frontière du SI) et les besoin métier type processus transverses.

    Le premier type à tendance à s’implémenter en silo métier et donc à laisser proliférer de la redondance de services applicatifs, notamment si on lui met entre les mains une solution agile comme le microservices. Le second à tendance à pousser dans le sens inverse en factorisant les services métiers et donc a imposer une contrainte de standardisation.

    L’approche d’EA va permettre d’équilibrer ces deux phénomènes antinomiques en cohérence avec la stratégie de l’entreprise et son schéma directeur. A défaut, on assistera à une prolifération de services redondants et des surcoûts conséquents.

    Les architectes qui contribuerons à la fabrication des microservices devraient être très attentifs à ce phénomène en évitant de refaire des services déjà existants en collaborant très étroitement avec leur cellule d’EA.

  2. Publié par , Il y a 5 ans

    Bonjour Anas, merci de ta remarque. C’est évidemment mieux quand la démarche microservices est poussée par un architecte d’entreprise, sauf que ces derniers ont souvent une approche macroscopique, orientée SI, là où le métier nécessite un découpage fin, un cycle de vie réactif et un développement moins monolithique. C’est ainsi que travailler avec eux va probablement nécessiter qu’ils s’intéressent un petit peu plus aux besoins du métier et collaborent en égal en égal avec les équipes de réalisation. De cette manière, un architecte d’entreprise capable de sortir de sa tour d’ivoire et d’aider opérationnellement les équipes de réalisation est une denrée très précieuse et une chance pour l’entreprise.

    A bientôt

  3. Publié par , Il y a 5 ans

    « […] qu’ils s’intéressent un petit peu plus aux besoins du métier […] »

    Le quel des besoins métier ? le besoin métier transverse ou le besoin métier spécifique ?

    C’est justement le dilemme des EA car les deux sont antinomiques. Et ça c’est important que les architectes MOE le comprennent. Sinon c’est le festival de la redondance et des incohérences … et donc du dé-commissionnement à la clef voir des abandons en cours de route.

    Il faut sortir du raisonnement « moi j’réponds au besoin quitte à ce qu’il soit incohérent avec un autre ».

    La construction d’un service est soumise au le même principes que le monde du bâtiment, il faut des contraintes qui assurent la cohérence globale même si ça ne plait pas au propriétaire qui fait son cahier des charge sur mesure selon sa vision individuelle. Si on déroge au standards ça donne un bidonville.

  4. Publié par , Il y a 4 ans

    Anas,

    note bien que je n’ai pas mis besoin métier spécifique et besoin métier transverse en opposition. Je dis simplement qu’un projet a son équipe, sa vie propre, ses règles, sa cohésion. Pour que le besoin métier transverse puisse s’harmoniser avec des attentes à court terme des équipes de réalisation, il faut faire preuve de souplesse, de bon sens, accompagner les équipes, et ainsi faire en sorte que besoins transversaux et spécifiques s’harmonisent.

    SI deux besoins sont incohérents, c’est aussi, peut-être parce qu’ils sont tout simplement différents. C’est là finalement qu’entre en jeu la Maitrise d’Ouvrage qui aura le loisir d’aligner les visions de tout le monde, au cas où les architectes d’entreprise n’adhérent pas à la conception de la MOE.

    Toutefois, je pense que l’approche micro-services, qui justement a pour effet de rapprocher la SOA des équipes de réalisation, va permettre d’extraire les services à forte valeur ajoutée et de les exposer d’une manière transverse. Cela permet aussi de partager des services, de mettre en place une communauté de pratique, et enfin d’inscrire le rôle de l’architecte d’entreprise dans un système collaboratif.

    Au plaisir.

  5. Publié par , Il y a 4 ans

    Merci pour cette remarque.

    Tout d’abord, microservice n’est pas applicable partout. En effet, un des points qui reste flou avec les architectures microservices, est le passage à l’échelle de l’entreprise. Et il y a plusieurs réponses possibles, chacune s’adaptant à l’entreprise et sa culture. Le rôle d’architecte d’entreprise est effectivement une des réponses possibles. Un autre modèle d’organisation qui pourrait correspondre est celui des feature team.
    L’idée d’avoir une équipe responsable (verticalement) d’une feature, c’est à dire à travers plusieurs strates, métier, dev, ops… La coordination se fait alors à travers des groupes des personnes transverses, pour éviter les doublons et favoriser le partage.

  6. Publié par , Il y a 4 ans

    Merci pour cette info Anas :-)

    Il y avait une session lors de Microxchg qui proposait de comparer microservices et RPC ainsi que l’application des principes SOLID dans ce contexte.

    http://microxchg.io/2015/slides/01_11_SOLIDServices.pdf
    http://microxchg.io/2015/talk/ondrej_krajicek_microservices_or_solid_services.html

    De mon point de vue, RPC est un concept technique alors que microservice à une notion plus fonctionnelle. Microservice se rapproche de la vision « Bonded-Context » en Domain Driven Design pour créer un module fonctionnel qui ait une cohérence forte et un faible couplage. En plus de cette cohésion fonctionnelle, microservice impose que ce module soit exploitable en production.
    Comment les modules communiquent ensemble? On peut voir alors une approche RPC entre modules. Cela dit, basé sur des framework asynchrones récents, le client n’est plus obligé d’être bloqué lors de l’attente de la réponse.

  7. Publié par , Il y a 4 ans

    Oui, RPC n’est qu’une manière technique d’implémenter l’appel d’un service. RPC est le plus souvent implémenté en synchrone, mais il existe des implémentations asynchrones (depuis longtemps, mais oubliées ou mises au placard).

    L’approche microservice étant plutôt fonctionnelle, quid de la gouvernance des services ?

    … vaste programme :-)

  8. Publié par , Il y a 4 ans

    Est ce que tu as lit cet livre « Building Microservices  » auteur : Sam Newman

  9. Publié par , Il y a 4 ans

    Bonjour,

    Non pas encore mais l’auteur était présent lors de cette journée. Sa présentation était très bien donc je ne doute pas que son livre soit une bonne source de conseils sur le sujet. Si tu l’as lu, j’ai hâte d’avoir ton retour.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.