maciek905 - Fotolia

Microservices et .NET : une intimité récente

Bien des entreprises sont attachées à Visual Studio et à « .NET » pour leurs développements métiers. Elles peuvent aujourd’hui exploiter ce savoir tout en adoptant des approches agiles et architecturer leurs applications sous forme de microservices.

Le développement d’applications est un processus en perpétuelle évolution. Longtemps, l’approche très monolithique issue des mainframes et des mini-ordinateurs a défini l’organisation des développements, avant que le déploiement massif de la micro-informatique ne vienne imposer le modèle client-serveur.

Les débuts de l’internet ont fait évoluer le modèle vers du multi-tiers et une volonté de séparer le codage de l’interface utilisateur, de la logique métier et de l’accès aux données.

Le Web 2.0 a initié la notion de services et a mené à l’approche SOA (avec une volonté de basculer l’existant sous forme de services). Le Cloud, DevOps et les besoins d’une montée en charge souple et économe, amène désormais les architectes à privilégier une approche « microservices ».

Parallèlement, bien des entreprises ont fait évoluer leurs pratiques et leurs méthodes en suivant les transformations des outils de développement sous Windows et plus particulièrement de Visual Studio. L’arrivée du « .NET Framework » en 2001 les a encouragées à passer de DCOM à une approche plus multi-tiers et modulaire. Dès 2004, « .NET » a été l’une des premières plateformes utilisées pour construire des applications en services s’appuyant sur SOAP.

Dès lors bien des entreprises ayant opté pour l’approche SOA ont construit leurs services en se basant sur le framework de Microsoft.

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.

Pour approfondir sur Outils de développement

- ANNONCES GOOGLE

Close