Les architectures de services : Microservices

Nous avons présenté deux façons d’implémenter une architecture de services dans une entreprise, la première basée sur le protocole de communication SOAP est de moins en moins utilisée au détriment de la seconde basée sur REST. Une dernière implémentation est apparue récemment, adaptée aux contraintes d’agilité des systèmes d’information et à l’émergence du Cloud : les microservices.

« In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are builtaround business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

Martin Fowler

Les architectures Microservices introduites par Martin Fowler dans son article : https://martinfowler.com/articles/microservices.html vont nous permettre dans un premier temps de relever les grandes idées derrière le terme de « microservice » :

  • Un composant logiciel correspondant à un besoin fonctionnel précis, définis et délimité.
  • Un composant autonome au niveau du déploiement et de l’exécution.

Un microservice est donc une unité de service fonctionnelle qui se développe, se déploie, s’exécute et gère ses données indépendamment des autres services du système.

Avec une application « monolithique », si on veut déployer une application sur un nouveau serveur il faut tout dupliquer. Avec une application en microservices, vous pouvez déployer chaque service sur 1 ou n serveurs, indépendamment des autres.

art4 - Les architectures de services : Microservices

Avantages

  • Code base indépendant : Les services sont plus simples à appréhender à développer et à repenser.
  • Les services peuvent être développés et déployés de façon plus indépendante et plus rapide.
  • Les services démarrent et s’arrêtent rapidement, ce qui réduit le temps de déploiement et améliore la productivité des développeurs.
  • Il est plus simple de mettre uniquement les composants nécessaires à l’échelle de façon dynamique pour répondre à la demande.
  • Le système tolère mieux les pannes pour une disponibilité plus élevée.
  • Les microservices peuvent être mis à niveau individuellement, en temps réel et sans interrompre le service.
  • Indépendances et agilité technologiques entre microservices.
  • Séparation des responsabilités.

La contrepartie logique de cette architecture c’est le développement, le déploiement et l’administration d’une grande quantité de services. Ainsi, si chaque service est plus simple, le système dans son ensemble est plus complexe !

Inconvénients

    • Augmentation de la complexité du SI.
    • Intégration et déploiements plus nombreux.
    • Tests plus difficiles si il y a des appels entre microservices.
    • Hausse nombre d’éléments à développer, surveiller, livrer.
    • Augmentation du trafic réseau et latence des appels HTTP.
    • Les microservices peuvent être très hétérogènes ce qui peut rendre leur implémentation plus complexe.

Si dans la théorie un microservice est un composant logiciel plutôt simple, sa mise en œuvre suscite bon nombre de questions que nous détaillerons plus tard. Dans tous les cas un certains nombres de besoins sont déjà identifiable.

Prérequis

    • Provisionnement de serveurs rapide.
    • Solution de monitoring de services.
    • Gestion des logs.
    • Maturité DevOps.
    • Gestion de configuration.
    • Tests
    • Load balancing.

3 2 300x207 - Les architectures de services : Microservices

Si nous prenons un peu de recul, on se rend compte qu’au-delà de certaines idées novatrices, la scalabilité et l’isolation des composants notamment, bon nombre des caractéristiques d’une architecture microservices se retrouvent dans une architecture de services plus classique.

Ainsi beaucoup n’hésite pas à qualifier les microservices de « buzzword » car en fin de compte on parle toujours de la même chose : une architecture de services qui s’adapte aux évolutions de l’IT au niveau du développement, des solutions d’infrastructure et même du management :

  • La SOA a mis en avant les avantages de l’approche services en entreprise.
  • L’agile et le lean startup ont fourni les modèles d’organisation des équipes pour des projets toujours plus nombreux.
  • L’industrialisation des déploiements diminue les coûts de mise en production et d’exploitation pour des mises à jours régulières.
  • L’essor du Cloud déporte les infrastructures hors du SI modifie les modèles DevOps.

Toutes ces évolutions ont selon moi aboutis à cette notion de microservices que nous mettrons bientôt en pratique !

Les architectures de services : SOA vs WOA

Après cette présentation de SOA et WOA, dans les deux précédents articles, la grande question est : Quand doit-on choisir l’un ou l’autre ?

Les deux approches, SOA et WOA, sont envisageables pour la mise en œuvre d’une architecture de services, et présentes toute deux des points forts mais également des points faibles et possèdent en fin de compte une utilisabilité propre à des environnements différents.

Tout d’abord, pour bien comprendre les avantages et inconvénients présentés plus bas voici un exemple d’appel à un webservice qui expose une méthode d’addition :

REST

Requête : GET https://mondomaine.com/sum?a=2&b=2

Réponse : 4

Documentation : La ressource « sum» est la somme de deux paramètres
a et b.

SOAP

Requête :

requete - Les architectures de services : SOA vs WOA

La réponse :

reponse - Les architectures de services : SOA vs WOA

La documentation au format wsdl :

doc - Les architectures de services : SOA vs WOA

Comparons maintenant les deux approches.

Les avantages de REST

  • Simplicité d’utilisation et de développement.
  • Opérations CRUD « native ».
  • Consommable par tous supports puisque basé sur HTTP.
  • Souplesse.

Les avantages de SOAP

  • Sécurité et fiabilité du protocole.
  • Contrats formels et rigide entre le client et le serveur.
  • Opérations avec état : partage de transaction possible.
  • Possibilité de communiquer avec un autre protocole que HTTP (TCP/IP).

De façon synthétique, REST propose une mise en œuvre simple de développement et d’utilisation, basé sur des standards connus de tous. SOAP en revanche sera utile si les contraintes de sécurité sont importantes et que le contrat entre client et services doit être absolu et strict. En 2018 la part des entreprises qui utilisent des Web API REST est de plus en plus importante.

Dans les deux cas, l’utilisation du framework .Net et du langage C# est adapté à ce besoin d’écriture de service. Le type de projet sera en revanche bien différent suivant votre choix, j’y reviendrais dans un prochain article.

Les architectures de services : WOA

Les architectures des gros noms du Web, souvent basées sur le style REST, sont, dans l’implémentation, bien différente  des SOA d’entreprises, majoritairement basées sur SOAP. Mais les APIs REST sont une forme de SOA, dont l’objectif est d’utiliser HTTP comme moyen de communication. On parle alors d’architectures orientées Web : WOA.

L’objectif de cette architecture est de proposer une version plus simple de la SOA, utilisant les caractéristiques et les standards du Web, plutôt que de chercher à les abstraire. L’architecture REST utilise les spécifications originelles du protocole HTTP, plutôt que de réinventer une surcouche comme SOAP :

  • L’URI comme identifiant des ressources.
  • Les verbes HTTP comme identifiant des opérations.
  • Les réponses HTTP comme représentation des ressources.

REST est donc fortement recommandé pour des cas simples où on cherche à effectuer des actions sur un contenu, comme lister, créer, modifier, supprimer des ressources. Pour toutes ces actions on utilisera la commande HTTP adéquat :

  • Lire une ressource, ou une collection de ressources (GET).
  • Modifier une ressource existante (PUT).
  • Créer une ressource (POST).
  • Supprimer une ressource (DELETE).

Exemple :

  • Un GET http://www.mondomaine.com/clients signifie que je souhaite récupérer la liste des clients disponibles.
  • Un GET http://www.mondomaine.com/clients/2  signifie que je souhaite récupérer les informations du client dont l’identifiant est 2.
  • Au même titre, un DELETE http://www.mondomaine.com/clients /2 doit supprimer le client 2.

Spécificités REST

Les propriétés d’une API REST sont :

Uniformité : Chaque ressource est identifiée de façon unique par son URL. L’interface est uniforme à tous les niveaux. Tous les éléments communiquent en utilisant la même interface.

Sans état : Une API REST ne doit pas maintenir de session. Cela garantis des appels idempotents.

Mise en cache : Il doit être possible d’utiliser les implémentations standards de cache HTTP.

Client / Serveur : Separation of Concerns : L’API REST n’est pas concernée par l’affichage, les interactions utilisateur et la session.

Layered : La présence de “connecteurs” intermédiaires doit être implicite pour le client et le serveur (composant de cache / sécurité etc…).

RESTFUL

En se basant sur le travail de Roy Fielding, Leonard Richardson a établi un modèle de maturité des services web REST appelé Richardson Maturity Model (RMM). Ce modèle est composé de quatre niveaux permettant d’évaluer une API par rapport aux contraintes REST.

1 1 300x177 - Les architectures de services : WOA

  • Niveau 0 : Le protocole HTTP est utilisé uniquement à des fins de transport du message. L’ensemble des données transitent par un seul et unique point d’entrée.
  • Niveau 1 : Introduction de la notion de ressources. Il y a donc désormais plusieurs endpoint (URI) par ressource.
  • Niveau 2 : Apparition de la notion d’action et d’état, ce qui correspond aux verbes, GET, POST, PUT, DELETE et aux codes http (200, 404, 500…).
  • Niveau 3 : Ultime et dernière notion de REST : HATEOAS (Hypertext As The Engine Of Application State). Notre API est « autodocumentée », c’est-à-dire que l’on peut passer d’une action à une autre via des URL transmises par l’API dans les réponses.

Une API RESTful est une API qui respecte toutes les contraintes REST. La très grande majorité du temps, les API sont au niveau 2 du RMM.

Les architectures de services : SOA

Un service est un composant logiciel distribué, exposant les fonctionnalités d’un domaine métier. Cette définition, la plus synthétique possible d’un service, peux être accompagnée de ces 8 caractéristiques proposées par Thomas Erl dans son livre « SOA Principles of Service Design » :

  • Contrat standardisé
  • Couplage lâche
  • Abstraction
  • Réutilisabilité
  • Autonomie
  • Sans état
  • Découvrabilité
  • Composabilité

1 300x284 - Les architectures de services : SOA

Le but de ce style d’architecture apparu dans les années 2000 est de fournir au système d’information un cadre d’écriture de composant logiciel :

  • Réutilisable
  • Évolutif
  • Urbanisé autour de domaines fonctionnels
  • Modulaire

2 1 300x118 - Les architectures de services : SOA

Pour mettre en œuvre cette architecture SOA, les entreprises ont rapidement adoptés le format Webservices au travers du protocole SOAP et du langage de description WSDL. Celui-ci permet la description des services et SOAP définit le protocole d’échange entre un client et un fournisseur de service, le plus souvent au-dessus du protocole HTTP.

Présentation de SOAP3 1 207x300 - Les architectures de services : SOA

SOAP (Simple Object Access Protocol) est un protocole définit à l’origine par Microsoft, puis standardisé par le W3C, utilisant la notation XML et permettant de définir les mécanismes d’échanges d’information entre des clients et des fournisseurs de services web.

Présentation de WSDL

Le standard WSDL (Web Service Description Language) est un langage reposant sur la notation XML permettant de décrire les services web. WSDL permet ainsi de décrire l’emplacement du service web ainsi que les opérations (méthodes, paramètres et valeurs de retour) que le service propose.

Les principaux avantages de ce protocole sont :

  • L’indépendance vis à vis du langage de programmation.
  • L’indépendance vis à vis de la plateforme où ils sont déployés.
  • Son extensibilité.
  • L’utilisation du standard XML pour l’échange des messages.
  • Contrat personnalisé entre le fournisseur et le consommateur du service.
  • SOAP est indépendant de la couche de transport puisqu’il l’a redéfini. HTTP est le protocole de transport le plus largement utilisé par SOAP.

Cette façon de mettre en œuvre une SOA s’est souvent faite en utilisant un composant central de médiation entre clients et services : l’ESB, Entreprise Service Bus. Le rôle de ce composant est de :

  • Découpler consommateurs et fournisseurs de services : abstraction des protocoles de communications, des langages.
  • Tracer les échanges.
  • Agréger les services.
  • Mutualiser les accès : gestion des droits, transformation des données.

Cette façon d’implémenter une SOA est majoritaire en entreprise mais la complexité de la mise en œuvre de SOAP et la verbosité du protocole, entre autre, ont favorisé l’apparition d’une autre façon d’implémenter une SOA, basée sur les travaux de Roy Fielding.

Sa thèse « Architectural Styles and the Design of Network-based Software Architectures. » publié en 2000 et notamment son travail sur REST ont favorisé l’émergence d’une nouvelle manière de mettre en œuvre une architecture de service que je vous présente dans cet article :

Les architectures de services : WOA

Meetup Azure Service Fabric

Le 05 juin 2018 je vous propose une présentation de la plateforme Azure Service Fabric dans le cadre du MUG .Net Nantes !

Azure Service Fabric est la plateforme de déploiement et de gestion de microservices dans Azure. Je la présenterais ici en détails très prochainement !

En attendant pour assister à ce talk, vous pouvez vous inscrire ici : meetup.com 

asf 300x154 - Meetup Azure Service Fabric