Microservices et .NET : une intimité récente

Vers des microservices

L’approche « microservices » découle en partie de celle de SOA, mais elle suit des pratiques et poursuit des objectifs sensiblement différents. SOA tendait à créer des « macro-services » avec une certaine volonté de vivre avec - et de faire évoluer - l’existant.

L’approche « microservices » est, elle, totalement inspirée par le Cloud et ses contraintes. Elle mène aux développements de services légers, hautement indépendants, auto-suffisants, avec un couplage lâche, déployables individuellement (le plus souvent sous forme de conteneur), que l’on va faire évoluer et que l’on va instancier selon la montée en charge, indépendamment des autres services.

Ils répondent mieux aux besoins de dispersion géographique, de continuous delivery, d’évolution des développements agiles, d’alignement des développements sur les scénarios métiers et d’optimisation des ressources (en vue de réduire les coûts) dont ont besoin les entreprises.

D’une manière générale, un microservice encapsule une fonctionnalité bien déterminée, développée par une petite équipe dans le langage et avec les outils de son choix, s’inscrivant ainsi dans une démarche d’agilité.

L’inconvénient de cette approche est qu’elle peut conduire à une grande quantité de services induisant une complexité d’administration non négligeable, ainsi qu’une empreinte lourde sur la bande passante réseau.

Il faut donc trouver la bonne granularité pour limiter ces inconvénients.

L‘arrivée de « .NET Core »

Autant le framework « .NET » s’inscrivait bien dans l’approche SOA, autant il n’était pas forcément le mieux adapté aux microservices. Microsoft l’a senti assez vite et entamé sa réécriture totale à l’origine connue sous le nom de « .NET 5 ».

L’objectif était, au départ, d’obtenir une version bien plus modulaire du framework. Sous l’impulsion de Satya Nadella, autant que sous celle des 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 ».

Le site www.microsoft.com/net/core explique ainsi en détail comment installer ce dernier sur Windows, Linux (RedHat, Ubuntu, Mint, Debian, Fedora, CentOS, Orale, openSUSE), Mac et Docker.

« .NET Core » reprend bien des fonctionnalités du « .NET Framework » mais se focalise sur les applications côté-serveur. Il est si compact que Microsoft le voit aussi s’installer au cœur des IoTs : il sert d’ailleurs de fondation au développement sous les Smart TV de Samsung (Tizen OS) et a été décliné sous Raspberry Pi.

La version « 1.0 » introduite il y a un an se focalisait sur la concrétisation d’un framework cross-plateforme modulaire et compact. La version « 1.1 », récemment introduite, s’évertue à rendre plus élégante et fluide l’écriture de microservices sous « .NET Core ».

Il existe également des technologies tierces pour simplifier et booster le travail des développeurs de microservices en .NET. C’est le cas de Nancyfx, un framework open source qui prend en charge toute la plomberie nécessaire à la création de Web services. Dans un esprit un peu différent mais complémentaire, on peut citer OWIN (Open Web Interface for .NET) qui permet de découpler l’application Web du serveur Web.

.NET Core, Linux & Docker

Les architectures en microservices ont connu un véritable coup d’accélérateur avec l’arrivée de Docker. L’idée est de déployer chaque microservices au sein de son propre conteneur afin d’en simplifier le déploiement, l’isolation et l’instanciation.

Depuis la sortie de la version 1.0, Microsoft s’est évertué à faire de l’ensemble «.Net Core + ASP.Net Core » un framework particulièrement adapté aux conteneurs, veillant à booster les performances de démarrage et à publier dans le repository Docker des images optimisées prêtes à l’emploi.

L’éditeur a également développé un ensemble d’outils, les Docker Tools, pour Visual Studio 2015, désormais intégrés dans Visual Studio 2016. On notera au passage que les premières versions des Docker Tools ciblaient uniquement les conteneurs Docker sous Linux.

Les microservices dans un univers 100% Microsoft

Mais ce qui est vrai sous Linux est aussi vrai sous Windows. « .NET Core » est ainsi supporté par Windows Server Nano (la version ultra-minimaliste et 100% en ligne de commandes de Windows Server 2016).

La compacité de .Net Core et de Windows Server Nano permet de construire et d’exécuter des microservices au sein de conteneurs Windows très peu consommateurs en ressources. Ces conteneurs sont alors déployables aussi bien dans une infrastructure interne (« On Premises ») que dans le Cloud et plus particulièrement dans le Cloud Azure.

Azure Container Services permet de rapidement définir un cluster de serveurs pour accueillir vos multiples services et leurs multiples instances en production. Il héberge aussi bien des conteneurs Linux que des conteneurs Windows.

En outre, le service laisse le choix dans l’orchestrateur de services que vous souhaitez utiliser : Marathon+Mesos DC/OS, Docker Swarm ou Kubernetes. Toutefois, seul ce dernier supporte actuellement indifféremment des conteneurs Linux et Windows.

Azure Service Fabric

Pour terminer, il nous paraît important d’évoquer rapidement Azure Service Fabric, bien que cette plateforme ne soit pas directement liée à .NET et expose son modèle d’application à tous les frameworks y compris Java ou Node.JS.

Azure Service Fabric est la plateforme de microservices signée Microsoft. Contrairement à ce que son nom suggère, elle est gratuite et peut être déployée OnPrem sur des serveurs Windows Server 2016 ou Linux, dans le Cloud sous Azure, mais également dans n’importe quel Cloud à commencer par Amazon AWS.

Azure Service Fabric fournit à la fois un modèle de programmation (avec d’ailleurs des modèles de microservices stateless ou stateful clés en main pour Visual Studio) mais également une plateforme (Service Fabric Cluster) pour déployer et surtout orchestrer les microservices avec une gestion complète du cycle de vie des applications.

Autrement dit, c’est une plateforme PaaS dans un esprit proche de Clound Foundry associée à un système d’orchestration des services (un peu façon Kubernetes ou Marathon).

Azure Service Fabric introduit la notion de « Datacenter on your machine » qui permet aux développeurs de s’assurer que l’environnement de développement est identique à celui d’Azure. Et donc de s’assurer d’un comportement identique des services entre la machine de développement, un déploiement On Premises ou un déploiement dans Azure.