« Nous changeons un peu de nature de JEE, nous passons dans un écosystème ouvert avec une gouvernance communautaire et une neutralité de la part des contributeurs. Pour nous c’était très important », déclare Olivier Mikeladze, directeur avant-vente architecte solutions chez Red Hat.
« Nous changeons un peu de nature de JEE, nous passons dans un écosystème ouvert avec une gouvernance communautaire et une neutralité de la part des contributeurs. »
Olivier MikeladzeRed Hat
Techniquement, il s’agit de maintenir les efforts pour adapter Jakarta EE à l’approche cloud native. Et Red Hat se veut le représentant de cette tendance.
Ainsi, JBoss EAP 7.3 intègre le support de Jakarta EE 8 en plus de Java EE 8. Red Hat apporte également des améliorations de sécurité bienvenues. Le système de messagerie Message Driven Beans a été revu pour optimiser la diffusion des événements issus des applications Java qui sont uniquement diffusés quand les groupes de livraison associés sont actifs. L’éditeur a configuré la topologie des messages eux-mêmes pour réduire la consommation de RAM. Le pont Java Messaging Service bénéficie également des rapports de métriques avancées.
Par ailleurs, Red Hat a effectué des modifications pour améliorer les performances de la version containérisée de JBoss EAP sur OpenShift. Un nouvel opérateur est associé à des outils de configuration pour réduire les capacités nécessaires au fonctionnement d’une image EAP et automatiser leur génération. L’éditeur fait également des ajustements pour configurer la mémoire des JVM placés sur des containers Linux et pour exécuter des scripts JBoss CLI en tant qu’élément d’une image EAP sur OpenShift.
Les spécifications MicroProfile améliorent l’observabilité de Jboss EAP
Selon Olivier Mikeladze, la grosse nouveauté de cette mise à jour Jboss EAP est préversion de plusieurs spécifications Eclipse MicroProfile.
« JEE est un gros consortium avec des standards, des spécifications, des processus d’approbation assez longs. Ce cycle long n’est pas adapté aux demandes des développeurs qui doivent itérer plus rapidement. MicroProfile permet de s’abstraire de la complexité des process JEE et d’avoir des cycles de vie beaucoup plus agressifs dans les évolutions des spécifications » vante Olivier Mikeladze.
« MicroProfile permet de s’abstraire de la complexité des process JEE et d’avoir des cycles de vie beaucoup plus agressifs dans les évolutions des spécifications. »
Olivier MikeladzeRed Hat
En d’autres termes, le projet open source Eclipse MicroProfile vise en premier à optimiser Java Enterprise pour les architectures microservices en standardisant des API, des fonctionnalités pour ensuite les proposer à la communauté et les faire valider rapidement.
Ainsi JBoss EAP intègre cinq spécifications MicroProfile à l’essai en vue d’améliorer l’observabilité des composants applicatifs. La première, MicroProfile Config, permet l’externalisation des configurations de microservices pour faciliter leur portabilité à travers différents environnements cloud ou sur site. Le REST Client, construit sur des API client JAX-RS 2.0 assure une sécurisation des services RESTFul via HTTP. MicroProfile Metrics utilise l’extension SmallRye pour rassembler des métriques sur les instances EAP. L’API OpenTracing automatise la collecte de traces de requêtes à travers divers services d’une application JAX-RS. Red Hat utilise ces deux spécifications dans le cadre de son projet Quarkus. Health Checks permet d’automatiser l’initialisation de containers et leur redémarrage au besoin en vérifiant s’ils sont fonctionnels ou non.
Dans le but de s’adapter à ces changements induits par Jakarta EE, Red Hat a modifié les configurations Maven et divers éléments de configuration. L’éditeur a mis à jour son « Migration Toolkit » qui doit identifier les éléments à changer pour migrer les applications Spring Boot vers Red Hat Runtimes et les applications vers les serveurs EAP. L’outil de migration prend également en charge le passage d’Oracle JDK à Red Hat OpenJDK et la containerisation des applications.
« La version 9 de Jakarta EE sera intéressante parce qu’elle a vocation à faire de Java la plateforme de référence pour la productivité des développeurs dans le cloud. »
Olivier MikeladzeRed Hat
Justement, Jakarta EE est au centre des préoccupations de Red Hat. « La version 9 de Jakarta EE sera intéressante parce qu’elle a vocation à faire de Java la plateforme de référence pour la productivité des développeurs dans le cloud. De plus, Jakarta EE 9 va standardiser la connexion entre les serveurs d’applications et les bases de données NoSQL », affirme Olivier Mikeladze.
Du fait que les éditeurs de solutions NoSQL comme MongoDB, Couchbase ou DataStax (Cassandra) misent sur une approche cloud native, « les développeurs ont tendance à les adopter », selon l’architecte solutions chez Red Hat. « Le point de connexion MongoDB, c’était NodeJS dans JEE. Dans Jakarta EE, l’idée est de reproduire ce qui a été fait avec les connecteurs JDBC et JPA pour faciliter les migrations et accélérer les performances ».
Red Hat, un porte-étendard de Java dans le cloud
De manière générale, Red Hat croit en la pertinence de l’écosystème Java pour le développement d’architecture de microservices et la containerisation d’applications. Chez l’éditeur, cela passe par une évolution de l’offre Red Hat Runtimes.
« Nous constatons que les développeurs veulent être dans un monde polyglotte. Ils veulent choisir le bon langage pour un cas d’usage particulier. Avec Red Hat Runtimes, nous proposons une usine à logiciels ». Ainsi, les spécifications MicroProfile pourraient faire partie de cette boîte à outils à l’avenir.
Par ailleurs, Red Hat rappelle son attachement au projet Quarkus, un framework open source de développement de microservices Java containérisés dans le cloud. Ce projet doit réduire la quantité de RAM nécessaire au fonctionnement des JVM et accélérer leur démarrage pour, in fine, adapter Java au serverless. « Nous participons activement au projet Knative pour déployer, exécuter et gérer des composants serverless », rappelle Olivier Mikeladze.
Tous ces outils visent favoriser le développement d’applications cloud natives tout en permettant l’approche hybride. OpenShift, qui s’exécute sur site ou dans le cloud, est là pour ça. De même, Ansible doit assurer l’automatisation d’un bon nombre de processus de déploiement. L’éditeur ne fait pas une croix sur la VM, comme le prouve les évolutions du projet container-native virtualization, dont le but est d’héberger des machines virtuelles dans des containers.
Si la plupart des clients de Red Hat choisissent les nouveaux projets pour adopter l’approche cloud native, d’autres font le choix de migrer ou d’hybrider leurs architectures logicielles.
« JEE s’exécute très bien dans les plateformes de containers. Le véritable enjeu provient du fait que les clients n’ont pas tous des architectures modulaires et des usages qui ne sont pas adaptés aux containers. Ils sont tout de même nombreux à adopter ce paradigme, parce que ces clients misent d’abord sur une modernisation de leurs applications qu’ils optimiseront par la suite », conclut Olivier Mikeladze.
Pour approfondir sur Middleware et intégration de données
