Mis à jours 23 février 2020 Faites appel à ces boîtes à outils open source pour créer des microservices fiables et légers sur la machine virtuelle Java qui a fait ses preuves en situation difficile.
Le voyage a été long pour Java, un langage qui a commencé comme la lingua franca de la boîte au-dessus du téléviseur à l’époque où la télévision n’était pas livrée avec Roku ou Chromecast intégré. Ensuite, Java allait s’approprier le World Wide Web en animant le navigateur avant que JavaScript ne vienne le mettre à l’écart.
Java a fini par trouver un créneau dans les parcs de serveurs où il existait jadis suffisamment d’architectures de puces et de systèmes d’exploitation différents pour rendre la « promesse d’écriture unique et exécutable n’importe où ». Et dans ces parcs de serveurs, Java a toujours vécu, un favori des boutiques d’informatique d’entreprise accro à la fiabilité et aux développeurs qui adorent le typage puissant.
Pendant ce temps, JavaScript en général et Node.js en particulier ont défié Java sur le serveur, utilisant leur débit élevé et leur vitesse sans thread pour prendre en charge une énorme partie du trafic sur le Web. Node a capturé l’imagination des plus récents programmeurs côté serveur en offrant non seulement la rapidité et l’efficacité des ressources, mais également la simplicité du code qui s’exécute à la fois sur le client et sur le serveur.
Pourtant, malgré la montée de la concurrence, Java continue non seulement à survivre, mais à exceller. De nombreuses équipes chargées de développer des architectures de microservices continuent à utiliser Java. Une des raisons majeures est sans doute le fait que la technologie a fait l’objet de tests contradictoires au fil des ans, lors de l’analyse de requêtes HTTP. Sun a créé une machine virtuelle à toute épreuve et Oracle continue de la nourrir et de la prendre en charge.
Une autre raison doit être l’évolution continue de langage. Java 8 offre un support solide pour les langages fonctionnels tels que Scala et Kotlin. La JVM (Machine virtuelle Java) constitue désormais la base de bon nombre de meilleures expériences de développement du langage informatique. Des dizaines de nouveaux langages peuvent compiler en code octet Java et se lier les uns aux autres pour faire fonctionner des projets complexes. La plupart des piles fonctionnant sans à-coups sur une machine virtuelle Java peuvent être créées à l’aide d’un mélange de Java et de plusieurs autres langages.
La plus grande raison, cependant, doit être la pure inertie. Au moment où cet article est écrit, 371 emplois pour les programmeurs COBOL sont répertoriés sur Dice. Il y a beaucoup, beaucoup plus d’emplois avec le langage Java chez eux. Est-il surprenant que les équipes intelligentes examinent leurs énormes vieilles piles de code Java et pensent que la solution la plus simple consiste simplement à ajouter une porte latérale qui crache les données sous forme de structures de données JSON ? Voilà. L’ancien code continue à fonctionner, mais il agit comme un microservice moderne sur ces portes latérales.
Toutes ces options et bien d’autres encore garantissent que Java continue de jouer un rôle important et vital dans la révolution des microservices. Et il n’est pas surprenant que la communauté open source Java continue à être suivi et crée de nombreuses nouvelles options pour les programmeurs Java qui doivent apprendre à leur code Java à parler comme un microservice.
Voici une liste de 13 options open source que les développeurs Java utilisent pour créer des solutions qui constituent le fondement des architectures de microservice, où qu’elles se trouvent.
Spring Boot
Le monde Java construit des applications Spring depuis longtemps. Spring Boot est une version particulière de Spring qui facilite grandement le processus en gérant pour vous la plupart des détails de la configuration. Spring Boot a été créé pour automatiser le démarrage de projets Spring, quels qu’ils soient, et pas seulement de microservices. Pour rendre les choses encore plus simples, une fois que vous avez terminé avec l’application, Spring Boot se mélange à un serveur Web et crache un fichier JAR qui correspond à presque tout ce dont vous avez besoin à l’exception de la JVM. Considérez-le comme le conteneur d’origine de Docker.
Toute cette intelligence est appréciée par de nombreuses personnes chargées de la création de microservices, car toute la configuration devient agaçante lorsque vous devez le faire encore et encore pour chacun des 12 microservices. Si Spring Boot peut l’automatiser, créer plusieurs dizaines de microservices est beaucoup plus facile.
Les microservices développés avec Spring suivent la même philosophie MVC que les applications macro Web que nous développons depuis des années. L’infrastructure bénéficie de toutes les connexions profondes construites au cours des années de développement Java, y compris l’intégration avec tous les magasins de données majeurs et mineurs, les serveurs LDAP et les outils de messagerie tels qu’Apache Kafka. Il existe également des dizaines de petites fonctionnalités pour le maintien d’une collection de serveurs en fonctionnement, telles que Spring Vault, un outil permettant de conserver les secrets, les mots de passe et les informations d’identification nécessaires aux serveurs en production. Tous ces avantages montrent pourquoi les programmeurs Java ont rejoint la communauté depuis de nombreuses années.
Eclipse MicroProfile
En 2016, quelques-uns des fans de la communauté Java Enterprise ont analysé et ont décidé de nettoyer tous les éléments inutiles de Java Enterprise Edition afin de permettre aux utilisateurs de créer de simples microservices avec les composants classiques. Ils ont jeté un nombre surprenant de bibliothèques, mais ont conservé du code pour le traitement des demandes REST, l’analyse JSON et la gestion de l’injection de dépendances. Ce qu’ils ont fini par baptiser Eclipse MicroProfile, qui était simple et rapide.
Depuis lors, la communauté MicroProfile a conclu un pacte pour la publication de nouvelles versions tous les trimestres tout en ajoutant un nouveau code permettant aux microservices de fonctionner de manière fluide et sécurisée. Le processus de développement et la structure du code seront très familiers à quiconque a vécu dans le monde Java EE, mais les problèmes de configuration sans fin ont été réglés. C’est la preuve que vous pouvez apprendre de nouvelles choses aux anciens développeurs.
Dropwizard
Lorsque Dropwizard est apparu en 2011, les développeurs Java Enterprise ont compris à quel point il leur fallait vraiment peu de code. Le framework Dropwizard a fourni un modèle de développement très simple avec de nombreuses décisions importantes prises pour vous, et il a continué à suivre cette voie. Vous ajoutez un logique métier et pratiquement tout le reste est configuré pour vous conformément à la convention. Il en résulte des petits fichiers JAR que les utilisateurs louent pour le démarrage rapide.
La plus grande limitation peut être le manque d’injection de dépendance. Si vous souhaitez utiliser l’injection de dépendances pour que votre code soit propre et peu couplé, vous devez ajouter les bibliothèques vous-même. Dropwizard ne peut pas le faire, contrairement au monde de Spring. Cependant, la plupart des autres articles de luxe sont désormais pris en charge, notamment la journalisation, les contrôles de l’état et le code fournissant la résilience. Vous n’aurez pas besoin de faire trop de sacrifices.
WildFly Thorntail
Les employés de Red Hat ont créé leur propre version de MicroProfile avec un outil de configuration astucieux. Le framework s’appelait à l’origine WildFly Swarm, mais il a ensuite été renommé Thorntail. Le site Web Thorntail vous aide à créer votre propre fichier de construction Maven en spécifiant simplement les fonctionnalités dont vous avez besoin. Maven se charge ensuite de tout assembler.
Thorntail détectera également les principaux composants dont vous aurez besoin en analysant votre code, mais vous pouvez le remplacer par un fichier de nomenclature (BOM ou bill of materials). Lorsque tout est en cours d’exécution, Thorntail supprime les parties de Java Enterprise Edition qui ne sont pas utilisées et crée un petit fichier JAR prêt à être déployé avec une seule commande, une fonctionnalité simple qui permet au projet Thorntail de l’appeler Uber-JAR. C’est une autre approche à suivre dans la tradition de Java Enterprise Edition sans garder tous les éléments lourds.
Helidon
Helidon n’est sorti que depuis quelques mois depuis les communiqués de presse et le premier engagement dans le référentiel GitHub, mais le framework attire déjà le type d’attention garanti par le support fourni par Oracle. Bien que l’univers Java soit immense, il tourne toujours autour d’Oracle.
Les architectes d’Helidon ont suivi un bon nombre des mêmes thèmes qui sont répétés dans les autres projets présentés ici. Supprimez cruellement la Java Enterprise Edition et conservez le noyau léger basé sur les servlets qui a gagné la confiance du monde. Dans le cas de Helidon, les développeurs ont démarré avec Netty et ont ajouté juste assez de code pour effectuer du routage et la gestion des erreurs. Pour rendre les choses intéressantes, ils ont adopté deux modèles de base pour le code, les versions dites SE et MP.
Helidon SE semblera très familier aux programmeurs de Node.js avec les longues chaînes d’appels de fonctions reliées par des points. Helidon MP semblera plus familier aux programmeurs Java qui utilisent JAX-RS. Il existe également des outils utiles et bien appréciés pour vérifier la santé des serveurs ou pour suivre le flux de données à travers une forêt de microservices. Ce sont des raisons impérieuses d’explorer le potentiel, même sans le support d’Oracle.
Cricket
Cricket est un autre framework pour le développement rapide d’API. Le cricket est petit malgré l’inclusion de plusieurs extras comme un magasin de données de valeurs-clés pour vous éviter de connecter une base de données et un planificateur pour contrôler le traitement répétitif en arrière-plan. Il n’existe aucune autre dépendance qui ajoute des complications ou un verrouillage, il est donc très facile d’ajouter votre code à Cricket et de démarrer un microservice indépendant.
Jersey
L’une des approches standard du développement d’un service Web est l’API Java pour les services Web RESTful (JAX-RS), une spécification générale mise en œuvre dans le framework Jersey. L’approche dépend fortement de l’utilisation des annotations pour spécifier le mappage de chemin et les détails de retour. Tout le reste de l’analyse des paramètres et de l’emballage du JSON est géré par Jersey.
L’avantage principal de Jersey est qu’il met en œuvre le standard JAX-RS, une fonctionnalité qui est suffisamment souhaitable pour que certains développeurs associent Jersey à Spring Boot pour profiter des deux.
Play
L’un des meilleurs moyens de faire l’expérience de la puissance multilingue de la machine virtuelle Java consiste à utiliser le framework Play, une pile de code Scala qui se connecte à Java ou à l’un des autres langages de la machine virtuelle Java. La base est très moderne, avec un modèle asynchrone et sans état qui ne surcharge pas le serveur avec une infinité de threads essayant de garder une trace des utilisateurs et de leurs données de session. Un certain nombre de fonctionnalités supplémentaires peuvent également être utilisées pour étoffer un site Web, notamment OpenID, la validation et la prise en charge du téléchargement de fichiers.
La base de code Play évolue depuis plus de dix ans. Vous retrouverez ainsi des échos de périodes fort oubliées telles que la prise en charge de XML. Le jeu est à la fois mature et souple, une combinaison qui peut être rare à l’état sauvage.
Swagger
Construire une API peut sembler aussi simple que d’écrire du code qui écoute sur un port et fournit des réponses, mais les développeurs de Swagger demandent différemment. Ils ont créé un langage de spécification d’API complet, appelé OpenAPI, que vous pouvez utiliser pour préciser ce que votre API fera. Cela peut sembler une étape supplémentaire, mais l’équipe Swagger a également fourni un code qui transforme cette spécification en tests automatisés, en documentation, etc.
La description simple et presque spartiate d’une API dans le fichier de configuration Swagger est intégrée au code Java pour implémenter l’interface, documenter son comportement et fournir un ensemble d’outils permettant de tester le code généré en dessous. Il existe même un mécanisme de gouvernance des API pour que vous puissiez travailler avec les masses non nettoyées qui vont bientôt frapper à la porte de votre API et attendre des réponses.
Swagger est un écosystème pour les API et ne se limite pas à Java. Si votre équipe passe à Node.js ou à l’un des douzaines d’autres langages, un module Swagger Codegen attend de convertir votre spécification OpenAPI en une implémentation dans ce langage.
Restlet
L’une des plus grandes différences entre les divers frameworks est le nombre de connexions à d’autres services et bibliothèques. Le projet Restlet propose l’une des plus vastes collections de fonctionnalités et de connexions. Il est déjà intégré à des bibliothèques telles que JavaMail, au cas où votre microservice devra parler POP, IMAP ou SMTP à un serveur de messagerie et Lucene/Solr, au cas où vous souhaiteriez créer des index interrogeables de gros morceaux de texte et des métadonnées qui l’entourent.
Les possibilités dans Restlet continuent à exister, car cette pile supporte généralement plusieurs options différentes pour chaque partie. Par exemple, vous n’avez pas besoin d’utiliser JSON, car le code gérera les formats XML, CSV, YAML et quelques autres fichiers. Vous disposez également de plusieurs options différentes pour les modèles afin de structurer votre réponse. Le client Restlet, qui vous permet de tester vos API à partir du navigateur Chrome, est l’une des fonctionnalités les plus utiles.
Squash
Le débogage de microservices est souvent un véritable défi, car les pièces sont très faiblement couplées et il est difficile de suivre le flux de données à travers toutes les couches du système. Squash vous permet de définir des points d’arrêt dans votre code s’exécutant sur un cluster Kubernetes, puis de recevoir toutes les données dans votre IDE comme s’il s’agissait d’un code s’exécutant localement. Squash s’intègre également aux environnements d’exécution Node.js et Python dans le cas où votre collection de microservices n’est pas exclusivement Java.
Telepresence
Une autre option de débogage consiste à utiliser Telepresence pour créer un proxy local pour un microservice sur un cluster Kubernetes distant. Vos appels pour ce service seront redirigés vers la version locale où vous pourrez configurer des points d’arrêt ou faire tout ce que vous pouvez imaginer sur votre ordinateur local.
Zipkin
Zipkin est un mécanisme permettant de consigner des événements sur différents microservices, puis de les mettre en corrélation, de sorte que les problèmes puissent être isolés et étudiés à mesure qu’ils se répercutent dans la collection de machines. Une implémentation Zipkin pour Java ainsi que pour au moins six autres langages permet de s’attaquer aux systèmes multilingues. Certains des frameworks les plus sophistiqués comme Spring ont déjà Zipkin intégré sous une forme ou une autre.
