.Net Core, le pari stratégique de Microsoft

Microsoft a toujours représenté un univers à part dans la sphère informatique. Son OS est très différent de ceux de Linux ou Unix. Cela plaît au regard de la proportion de desktop utilisant Windows. Même au niveau serveur, il n’est pas rare de retrouver cette OS. Cependant Windows est pour moi la marque de l’isolement de Microsoft, heureusement la firme change de stratégie et cherche à s’ouvrir au monde extérieur et c’est tant mieux. Son arme ? .NETCore. Un écosystème lancé en juin 2016 pour tous les terminaux, PC, tablettes et serveurs. Un virage audacieux de la part de Microsoft afin de pouvoir s’adapter aux évolutions numériques. Mais qu’est-ce que le .NETCore exactement ? Et en quoi est-il intéressant d’utiliser cette technologie ? Découvrons ensemble ce que nous apporte ce nouvel arrivant et comment en tirer parti.

Alors qu’est-ce qui a changé me direz-vous ? Beaucoup. Jugez plutôt : avant le Framework .NET était déployé par Microsoft et était fortement dépendant de Windows. Par exemple, les mises à jour étaient déployées via les Windows update. Avec .NETCore, place au déploiement modulaire. Dans la pratique, cela signifie que l’on passe par NuGet pour déployer les outils nécessaires au fonctionnement des composants logiciel utilisant cette technologie. Je vais me montrer insistant mais je parle bien de TOUS les outils. En d’autres termes, un déploiement .NETCore d’une application F# embarquera également la librairie fsharp.core. Une petite révolution.

.NETCore = flexibilité + portabilité

Ce qui est très intéressant c’est la flexibilité donnée au déploiement. Pas besoin de se soucier de la version du dernier framework installé pour savoir si les nouveaux feature fonctionnent, puisque tout est livré dans l’ensemble. Ce dernier point, et non des moindres, est certainement un des problèmes les plus fréquemment rencontrés par les développeurs .NET classiques, moi y compris. Par ailleurs la rétrocompatibilité est assurée via la redirection de version. A cela ajoutons que le .NETCore est compatible avec Mono et avec le Framework classique grâce au .NET standard (ECMA 335).

Autre différence entre .NET et .NETCore, la portabilité. Avec .NETCore, il est désormais possible de développer des outils ciblant Linux et Mac OS. C’était déjà le cas avec Mono me direz vous. C’est vrai mais Mono ne couvrait pas tout le Framework et même si le .NETCore ne le couvre pas complètement non plus, il embarque bien plus de fonctionnalités. Je le redis encore une fois, Mono est compatible avec le .NETCore donc le travail déjà effectué avec Mono n’est pas perdu.

De l’open source à la limite du Linux

On notera aussi que le .NETCore est un projet open source. Il est distribué sous une licence MIT. Chacun peut contribuer à son développement, pourvu que la pull request soit accepté par Microsoft. Et bien qu’il soit open source, il bénéficie du support de Microsoft. La firme de Redmond ne nous avait jamais habitués à cela.

Au niveau des outil de développement, on peut bien entendu utiliser Visual Studio – même sous Mac OS, oui oui – mais avec une disposition des menus similaire à Mono Develop. Mais on peut également utiliser Visual Code ou encore Sublime Text, ce que je fais volontiers pour pratiquer le F#, le OCaml et le Haskel, et même VIM. En fait, les compilateurs sont même accessibles via les bash. On se retrouve donc rapidement plongé dans un vrai environnement Linux comme c’est le cas pour Java par exemple. Personnellement, je trouve que c’est une belle entrée dans cet univers que nous offre Microsoft.

Voici le lien vers le github de l’ASP.NETCore. Nous sommes actuellement en version 2.0 depuis l’annonce par Microsoft le 14 Août de la release de cette nouvelle version. Et voici le lien vers le Github du .NETCore. Vous trouverez la feuille de route du développement de l’ASP.NETCore ici. Il permet d’avoir une bonne visibilité sur ce qu’il reste à faire pour arriver à  une version très complète. Le post annonçant l’arrivée du .NETCore est également riche en enseignement sur que proposait la première version ?

Ce qui n’est pas encore disponible avec .NETCore

Dans la version 1.0 de .NETCore, toutes les fonctionnalités du framework n’étaient pas disponibles. Sa version 2.0 augmente ses capacités et permet désormais à plus gros projet de basculer sans difficulté du framework classique vers le .NETCore. Passons en revue ce qui n’est pas encore porté :

• les web form ASP.NET,
• les services WCF, bien qu’il existe une librairie permettant de consommer des services WCF, il est impossible aujourd’hui d’en implémenter,
• les WinForms et WPF, les premiers étant directement liés à l’API Windows. Il n’est pas prévu de les porter en .NETCore actuellement,
• la prise en charge linguistique bien qu’il soit prévu qu’elle soit portée.

Mais si toutes ces fonctionnalités ne sont pas encore disponibles, il est tout à fait possible de créer une application complète en profitant de fonctionnalités comme la Task Parallel Library (TPL), la réflexion, LINQ ou encore Entity framework. S’agissant des librairies extérieures, il faudra prendre soin de vérifier leur compatibilité. On pourra aussi trouver sur Internet des exemples de librairie a utiliser dans le cadre de .NETCore, comme Dapper avec ASP.NET, qui peuvent être utilisés conjointement avec la commande bash dotnet test (destinée à lancer les tests unitaires). On peut également trouver des exemples d’utilisation conjointes du Framework standard et du .NETCore comme ici. L’implémentation de SignalR pour ASP.NET, était prévu pour le ASP.NETCore en version 2.1. On peut cependant trouver sur github son implémentation ici.

Mais alors pourquoi ??

Quels sont donc les cas d’utilisation du .NETCore. Comme nous l’avons dit si l’on cible les systèmes Mac OS, Linux ou Unix, le .NETCore se révèle être le meilleur choix. Les conteneurs d’application sont également un bon cas d’utilisation de ce framework. Le déploiement sous Docker est certainement une des cibles de ce framework. Il est ensuite possible d’héberger les conteneurs sous des infrastructures Linux ou Windows ou encore sur Azure.

L’architecture en microservices est un cas idéal également. D’abord parce qu’elle se marie bien avec les conteneurs d’application, mais aussi parce qu’elle nécessite un déploiement léger. A ce titre l’utilisation du .NETCore et de son déploiement allégé est tout à fait indiqué. Ce type d’architecture vise aussi à une meilleur scalabilité, dans le cas du .NETCore, on peut facilement utiliser des infrastructures mixtes (Windows, Linux, Cloud).

Dans les technologies liées à internet, la demande d’une scalabilité optimale et de performances raisonnable est classique. Or Microsoft annonce que le ASP.NET Core surpasse le ASP.NET classique d’un facteur 10. On trouve d’ailleurs des post attestant d’un gain conséquent. Les équipes Microsoft assurent que les performances du .NETCore surpassent les technologies actuelles utilisées dans les microservices (node.js, Go et Java servlet). Nous n’avons pas pu le vérifier mais il est facile de trouver sur internet différents tests comparant les différentes implémentations existantes de .NET (comme ici).

Finalement, il est possible de faire coexister différentes versions de framework dans .NETCore. Microsoft garantit d’ailleurs une installation à 100% de chacune des versions sur un même ordinateur/serveur. De quoi permettre l’utilisation de service parfaitement adapté à chaque version déployée.

La stratégie de Microsoft

En créant ce projet open source, multi-plateforme, Microsoft ouvre la voie à l’utilisation du .NET dans des utilisations jusqu’alors inaccessibles (Linux+Apache+MySql par exemple). Mais on peut se demander légitimement pourquoi ? Cette solution n’est pas monétisable dans l’immédiat. Il n’y a aucune licence à vendre en l’état. On peut raisonnablement avancer que Microsoft y songe à l’avenir. C’est en tout cas ce qu’avance différentes analyses que j’ai lues sur la stratégie de Microsoft. En réalité je crois que Microsoft a bien compris que l’open source est un réservoir infini d’innovations. Et c’est vrai, c’est le meilleur moyen de garder un framework au goût du jour. C’est d’ailleurs certainement une des plus importantes leçons à tirer de l’aventure Mono. Sans compter que les meilleures librairies open source peuvent facilement être reprises sous l’égide du support Microsoft encourageant d’autant leur utilisation.

Personnellement je pense que Microsoft va plus loin. D’abord parce que le portage de SQL server sous Linux peut lui aussi faire baisser les revenus en licence de Microsoft. Songez qu’aujourd’hui il faut une licence Microsoft server pour faire tourner un serveur SQL de Microsoft. Je pense en réalité qu’il s’agit d’abord d’un pari sur le cloud. Azure permet d’utiliser des projet Apache, d’utiliser des conteneurs Docker et encore bien d’autres choses. Quand on se place du point de vue d’une entreprise, il est risqué de mettre tous ses oeufs dans le même panier, en l’espèce Microsoft. Or, quand il s’agit de choisir des technologies Cloud, il est alors recommandé de pouvoir se déployer sur un maximum de plateforme et de Cloud. En utilisant .NETCore,il est plus simple pour une entreprise d’utiliser un mix AWS/Azure en matière de cloud que d’utiliser Java, par exemple.

De plus, il est important pour la survie de ses technologies de séduire la nouvelle génération de développeurs. Je pense que chacun d’entre nous connaît au moins une personne refusant catégoriquement d’utiliser quoi que ce soit venant de Microsoft car ça n’est compatible qu’avec Windows. C’est un point de vue assez facile à défendre. Enfin jusqu’à maintenant… C’est donc également sur son image que Microsoft souhaite influer, il s’agit de la rajeunir, de la rendre “cool”. Cette stratégie c’est d’abord celle d’Apple, mais aussi celle des start up, elle est dans l’air du temps et Microsoft semble bien vouloir s’y inscrire durablement.

Survivre, c’est être capable de s’adapter. C’est vrai pour les animaux. Il me semble que cela le soit aussi pour les entreprises. Avec .NETCore, Microsoft démontre sa capacité à innover tout en gardant son image de marque auprès de ses fidèles. Ce n’est pas un “breaking change”, mais une continuité dans la technologie et une extension du champ des possibles. Sans compter que la firme de Redmond ne semble pas vouloir s’arrêter là.  Ainsi Microsoft supporte le projet LLILC (LLVM based MSIL Compiler) qui comme son nom l’indique vise à permettre l’utilisation de LLVM pour compiler de façon puissante du .NET. Rien de moins. Là encore Microsoft ne vise rien de moins que la portabilité du .NET et son efficacité.