Découvrons Azure

Un microservice est avant tout une unité fonctionnelle. Il correspond à une fonctionnalité précise, logique et cohérente du système. Un microservice est donc autonome vis à vis de la fonctionnalité qu’il réalise. Il a son propre code, gère ses propres données et ne les partage pas, pas directement en tout cas, avec d’autres services. L’approche nécessite un effort de conception pour faire émerger des unités fonctionnelles autonomes.

Pour parvenir à un résultat cohérent au niveau du service en lui-même et au niveau global du SI (vision de l’urbaniste) plusieurs idées :

• Séparer la complexité fonctionnelle et technique : le service répond à un besoin fonctionnel, pas applicatif !
• Eviter le couplage entre services. S’il y en a trop le contexte est peux être mal délimité !
• Trouver un équilibre entre macroservices et nanoservices.

Pour arriver à ce résultat,  nous pouvons utiliser l’approche Domain Driven Design d’Eric Evans qui a largement fait ces preuves. DDD, proposé par Evans dès 2003, est une manière de penser la conception autour du code, de collaborer et de communiquer (via un langage commun et clairement définis) avec les experts fonctionnels et d’avoir une implémentation centrée sur le métier. Le besoin de cohérence fonctionnelle très forte au niveau du découpage de microservices  se recoupe très bien avec l’approche DDD.

Cette approche nous permettra de découper notre SI en domaine fonctionnel, en accord avec le métier et de ces domaines nous bâtirons nos différents microservices !

Pour une vision plus complète du sujet, consulter : https://cdiese.fr/domain-driven-design-en-5-min/ (il vous faudra plus que 5min pour lire cet article !) et docs.microsoft.com.

 Le choix du type de service : WCF vs Web API

WCF est un Framework  de communication de Microsoft. Une application WCF permet de bâtir et de faire communiquer des services basés sur le protocole SOAP. Il succède au service de type ASMX. Les services WCF permettent également de mettre en œuvre une architecture REST mais Microsoft propose depuis 2012 un nouveau type d’application : les Web API.

ASP.Net WebAPI est apparu avec ASP.Net MVC 4. C’est la solution proposée par Microsoft pour permettre aux développeurs de construire rapidement des services web REST. La principale différence entre WebAPI et MVC est que l’un possède des vues alors que l’autre retourne des données sérialisées (JSON/XML).

Avec l’avènement de .NET Core, Microsoft a fusionné les produits ASP.Net MVC et ASP.Net WebAPI. Les classes a manipuler pour développer des projets de type WEB API ou MVC sont maintenant les mêmes !

MSDN nous indique : « Utilisez WCF pour créer des services Web dignes de confiance et sécurisés accessibles via un large éventail de transports. Utilisez l’API Web ASP.NET pour créer des services HTTP qui sont accessibles à partir d’une large gamme de clients.

Utilisez l’API Web ASP.NET si vous créez et concevez de nouveaux services REST. Bien que WCF prenne en charge l’écriture de services REST, la prise en charge de REST dans l’API Web ASP.NET est plus complète et toutes les futures améliorations des fonctionnalités REST seront apportées dans l’API Web ASP.NET. »

Bien sûr au sein d’un SI ilest tout à fait possible d’utiliser les deux approches suivant les besoins propres au projet. WCF est historiquement lié au service SOAP et bien qu’apte à l’implémentation de service REST il me parait trop lourd pour la réalisation de micrososervices.

Le choix du langage : .Net Core ou .Net

Sous l’impulsion de Satya Nadella, et les nécessités d’un cloud Azure ouvert à tous les OS et à tous les langages, le projet « .NET 5 » s’est transformé en un runtime cross-plateforme et open-source connu sous le nom de « .NET Core ».

Pour des soucis de performances .Net Core semble mieux indiqué de pars sa légèreté et facilité de déploiement.

Microsoft nous propose :

« Utilisez .NET Core pour votre application serveur quand :

• Vous avez des besoins multiplateformes ;
• Vous ciblez des microservices ;
• Vous utilisez des conteneurs Docker ;
• Vous avez besoin de systèmes scalables et hautes performances.
• Vous avez besoin de versions .NET côte à côte par application.

Utilisez .NET Framework pour votre application serveur quand :

• Votre application utilise le .NET Framework (nous vous recommandons de privilégier l’extension à la migration).
• Votre application utilise des packages NuGet ou des bibliothèques .NET tiers non disponibles pour .NET Core.
• Votre application utilise des technologies .NET non disponibles pour .NET Core.
• Votre application utilise une plateforme qui ne prend pas en charge .NET Core. »

Parenthèse sur le projet .Net Standart : Il s’agit d’une spécification pour garantir qu’une librairie de code .Net fonctionne sur toutes les plateformes. .Net Standart est donc un jeu d’API que les implémentations .Net (.Net Framework / .Net Core / Xamarin) doivent respecter pour garantir la portabilité de la librairie développée. Ce projet s’inscrit bien sûr dans la volonté de Microsoft de s’ouvrir aux autres plateformes : Linux, MacOs, Android et iOS.

Pour pouvoir développer en .Net Core sur les plateformes autre que Windows, Microsoft nous propose un nouvel IDE, léger, modulaire et OpenSource : https://code.visualstudio.com/. En contrepartie, ces fonctionnalités sont bien plus limitée que Visual Studio 2017.

Pour le développement de microservices en .Net la combinaison optimale me semble donc être Web API REST + .Net Core. Ce duo convient parfaitement aux besoins de légèreté, rapidité et modularité de notre architecture !

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.

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.

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 !

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 :

La réponse :

La documentation au format wsdl :

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

• 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.

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é

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

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 SOAP

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