Build 2021 : Microsoft prêche sa vision de Java sur Azure

Java oui, mais sur Azure

Si le géant du cloud se proposait déjà d’accueillir des applications Java sur ses serveurs, la croissance d’Azure, les rachats de LinkedIn et de Mojang, le studio de développement à l’origine de Minecraft, ont nécessité le renforcement des services et des outils indispensables à l’exécution de ce framework. Microsoft gérerait 500 000 JVM en interne, selon George Adams, Senior Program Manager chez Azure.

Stratégiquement, la firme de Redmond a conscience que le support de Java favorise les migrations vers le cloud et donc la consommation de ressources qu’elle propose. Bon nombre d’entreprises, dont la Société Générale, Daimler ou Adobe ont recours à ce langage pour développer et maintenir leurs applications sur Azure. D’autres envisagent sûrement des migrations de leurs applications Java et s’interrogent sur le choix du fournisseur, car Oracle, AWS et Google Cloud sont également à l’affût.

Microsoft trace les chemins de migration pour JBoss EAP et WebSphere

C’est pour cette raison que Microsoft entretient des partenariats avec VMware, Red Hat et IBM. L’année dernière, Microsoft avait annoncé la disponibilité générale d’Azure Spring Cloud, sa version managée du framework open source Spring Boot. Lors de ce Build 2021, le géant du cloud a présenté le fruit de son partenariat avec Red Hat pour porter JBoss Enterprise Application Platform (JBoss EAP), compatible avec Java EE et Jakarta EE, sur Azure.

 Microsoft accueille désormais la plateforme d’exécution de serveurs d’applications sur son Azure Marketplace. Les développeurs peuvent déployer JBoss EAP 7 sur des machines virtuelles Red Hat Enterprise Linux (RHEL) 8. Deux options s’offrent à eux : déployer la plateforme sur des clusters de VM ou sur des Virtual Machine Scale Sets (VMSS), des machines virtuelles dotées d’une capacité d’autoscaling.

Les deux partenaires présentent les modèles de licence comme un moyen de favoriser les migrations des stacks Java/RHEL sur le cloud, mais il faudra avoir un œil attentif sur la tarification. JBoss EAP 7 dépend d’un modèle « Bring Your Own Souscription » (BYOS), tandis que l’utilisation des images RHEL 8 est facturée à la demande (Pay as you Go), à l’heure. Les entreprises ayant souscrit à Red Hat Cloud Acess disposent, elles, d’un mode BYOS pour ces mêmes images.

À cela, il faut ajouter les « coûts normaux de calcul, de réseau et de stockage », précise la fiche produit présente sur Azure Marketplace. En réalité, il s’agit de l’offre la moins managée du catalogue, mais sans doute la moins risquée, techniquement parlant, dans le cadre d’une migration lift and shift.

Dans un billet de blog, Microsoft présente JBoss EAP sur Azure RHEL comme une offre « IaaS ». Elle octroierait davantage de « flexibilité et de contrôle » sur la gestion des applications personnalisées. Seule l’administration du réseau est du ressort du fournisseur de cloud, ce qui intime de comparer les coûts d’infrastructure et d’exécution par rapport à un déploiement sur site. L’offre IaaS de Red Hat et de Microsoft comprend toutefois des templates pour faciliter la création de ressources Azure. De plus, Red Hat propose des outils « gratuits » pour organiser la migration rassemblée sous l’appellation « Migration Toolkit for Applications ».

Il existe une édition « containerisée » (Containered PaaS, dixit Microsoft) nommée JBoss EAP sur Azure Red Hat OpenShift (ARO), tandis qu’une distribution PaaS en préversion publique de la plateforme est disponible sur Azure App Service depuis octobre 2020.

Par ailleurs, Microsoft a présenté le support WebSphere Application Server Traditional d’IBM sur ses machines virtuelles Linux. L’idée est d’offrir un chemin de migration de WebSphere vers WebSphere Liberty ou Open Liberty, cette fois-ci hébergé sur des clusters Azure Kubernetes Service (AKS) ou sur ARO. Ce support émane d’un accord avec la maison mère de Red Hat, IBM.

« Dans le cadre de ce partenariat, nous avons déjà publié des instructions pour l’exécution de WebSphere Liberty et Open Liberty sur ARO en décembre 2020. Nous avons également édité des conseils pour l’exécution de WebSphere Liberty et Open Liberty sur AKS en mars 2021. Toutes ces offres permettent une intégration plus poussée avec des services tels que les bases de données (Db2, Azure SQL, Azure PostgreSQL, Azure MySQL), Azure App Gateway, Azure Active Directory et ELK », précise Microsoft dans un billet de blog.

Ici, le contrat dépend d’un mode « Bring Your Own Licence » (BYOL), les clients « sont responsables de l’usage des ressources Azure », comme avec JBoss EAP sur RHEL.

L’OpenJDK repeint aux couleurs de Microsoft

Microsoft ne se limite pas à tracer les chemins de migration pour JBoss EAP et WebSphere. Outre une collection d’outils pour Visual Studio Code (IntelliCode pour Java, dépôts Maven, extensions pour Red Hat, Spring Boot, Microprofile, Tomcat, Jetty, support de Quarkus, etc.), le géant du cloud a annoncé la disponibilité générale de Microsoft Build of OpenJDK.

Il s’agit de sa « version gratuite et open source » de l’implémentation de référence de Java SE (Microsoft maintient l’usage de la licence GPLv2 avec l’exception ClassPath). Cette édition LTS (Long Term Support), x64, versée au Java Engineering Group inclut des binaires pour Java 11 basés sur OpenJDK 11 011 +9 pour serveurs et ordinateurs Windows, Linux, et macOS. Microsoft Build of OpenJDK profitera de mises à jour trimestrielles et s’accompagne d’images Docker pour Ubuntu 20.04 et CBL-D (une distribution Debian concoctée par Microsoft).

Le fournisseur évoque également une préversion pour Java 16 sur Linux et Windows sur ARM s’appuyant sur la release OpenJDK 16.0.1 +9. Microsoft l’emploie déjà en interne pour exécuter les versions mobiles et tablettes de Minecraft. Les clients disposant d’un plan d’assistance Azure pourront bénéficier d’une prise en charge complète s’ils déploient la version Microsoft d’OpenJDK.

Attention toutefois, car il s’agit bien là d’une fourche du kit de développement maintenu par Oracle. Les binaires « peuvent contenir des corrections et des améliorations que nous jugeons importantes pour nos clients et nos utilisateurs internes, mais qui n’ont pas été (et ne seront peut-être pas) incorporées dans le projet OpenJDK en amont en raison de décisions indépendantes de la volonté de Microsoft », prévient George Adams dans un billet de blog.

Les différences entre le standard « Upstream » et la version de Microsoft seront signalées dans la documentation Azure. Bref, la firme de Redmond s’appuie largement sur ses développements internes et défend ici sa vision de son doudou (ou son précieux, c’est selon) Java.