Avec l'adoption croissante du déploiement dans le cloud, les services informatiques consomment moins de serveurs physiques, moins d'énergie électrique et contribuent finalement à atténuer le changement climatique en réduisant les émissions de carbone. Les architectures cloud y contribuent, car elles n'ont pas besoin de maintenir des ressources de calcul cloisonnées, mais permettent plutôt de partager efficacement les ressources disponibles sur le cloud où elles se trouvent et quand elles en ont besoin pour assurer le fonctionnement de leurs services métier.

Cependant, ces avantages du mouvement du cloud n'ont pas eu d'impact significatif sur les émissions de dioxyde de carbone en peu de temps. Cela est dû au fait que la vitesse d'adoption du cloud est beaucoup plus rapide que le passage à des infrastructures sans carbone. Par exemple, Google Cloud est aujourd'hui neutre en carbone, mais ils essaient de faire plus d'efforts pour devenir des systèmes de cloud computing sans carbone et durables.

En attendant, les développeurs et les architectes continuent de déployer des efforts maximaux pour optimiser les performances des applications en termes d'images de conteneurs plus petites, de temps de démarrage et de réponse plus rapides et de moindres empreintes mémoire. Ils pensent que cela permet à terme de réduire la consommation de calcul dans la couche application.

Java conçu pour une autre époque

Java est né il y a 27 ans pour exécuter des services métier avec une variété d'avantages tels qu'un débit réseau élevé, des processus de longue durée et un comportement dynamique pour les systèmes mutables. Il y a des décennies, il s'agissait d'excellentes fonctionnalités permettant aux développeurs d'écrire des applications flexibles et riches sur Internet, puis de les exécuter sur plusieurs serveurs d'applications à travers l'infrastructure, des serveurs physiques aux machines virtuelles.

Cependant, les choses ont changé depuis que les conteneurs Kubernetes et Linux se sont déchaînés sur le monde. Cela nous a apporté un nouveau paradigme pour réorganiser les applications existantes qui devraient être traitées comme cattle over cats sur le cloud. Les principales caractéristiques des nouvelles applications sont la portabilité, l'immuabilité et l'évolutivité rapide.

Malheureusement, la nature dynamique de Java n'est pas un grand avantage dans cette nouvelle ère. Néanmoins, les entreprises conservent encore de nombreuses applications métier critiques basées sur la pile Java, ce qui pourrait constituer un obstacle à la levée et au transfert des charges de travail vers les plates-formes cloud. Cela fait également perdre aux entreprises des opportunités de réduire les émissions de dioxyde de carbone, car elles doivent conserver les applications monolithiques sur l'infrastructure traditionnelle en dépensant plus d'argent.

Ironiquement, Java est toujours le 3ème langage de programmation le plus populaire selon l'Index TIOBE. En ce qui concerne cette tendance, de nombreux projets et outils open source (par exemple, Shenandoah GC) sont sortis pour optimiser les performances de Java en termes de gestion du débit pour monter en charge, état éphémère et empreintes mémoire réduites sur des systèmes immuables. Malheureusement, ces efforts n'ont pas suffi à décourager les développeurs de laisser les applications Java sur les clusters Kubernetes plutôt que de prendre des alternatives telles que Javascript et Python.

Serverless avec Java

Dans le cadre d'efforts sans fin pour réduire les ressources de calcul sur le cloud computing, de nombreuses entreprises ont réalisé que tous les services métier n'étaient pas tenus de fonctionner en permanence (par exemple, 24 x 7 x 365) en surveillant périodiquement les charges de travail des applications ainsi que l'utilisation des ressources.

Par exemple, certains services (par exemple, un service de commande) ne sont visités que par moins de 10 % de l'ensemble des services par les utilisateurs finaux et les tiers. Dans ce cas, l'architecture serverless vous permet de réduire automatiquement l'application à zéro lorsqu'il n'y a pas de trafic réseau vers l'application pendant une certaine période de temps (par exemple, 5 minutes ou 30 secondes).

En fait, le comportement serverless peut être appliqué non seulement aux microservices basés sur HTTP, mais également aux services de diffusion en continu distribués à partir des appareils périphériques de l'Internet des objets (IoT) et des serveurs de messages Kafka.

Voici votre question en tant que développeur Java : "Comment Java gère-t-il une architecture serverless ?". La grande question est "Java peut-il même s'intégrer dans le développement d'applications serverless ?" Traditionnellement, les développeurs avaient tendance à ne pas exécuter d'applications Java sur AWS Lambda selon l'enquête NewRelic en raison du package lourd et du comportement dynamique, comme illustré à la figure 1.

Figure 1. Pour l'amour du serverless

C'est la raison pour laquelle davantage de développeurs aimeraient intégrer les applications Node.Js et Python dans des plates-formes serverless et Function as a service (FaaS) plutôt que de faire évoluer les applications Java existantes. N'abandonnez pas vos compétences Java ! Vous découvrirez comment rendre vos applications Java plus adaptées à l'architecture serverless dans la section suivante.

Java natif nativement

La création d'une application Java exécutable native apporte non seulement d'énormes avantages, tels qu'un démarrage et un temps de réponse plus rapides avec une empreinte mémoire réduite, mais résout également les défis ci-dessus de la pile Java traditionnelle. Examinons un peu plus en détail le fonctionnement de l'exécutable natif ! L'exécutable natif est construit à l'aide d'un compilateur ahead-of-time (AOT) qui crée une image native autonome avec des classes d'application, des bibliothèques de dépendances et des runtimes. Vous pouvez comprendre qu'il est similaire aux images de conteneur Linux qui contiennent tout ce qui est nécessaire pour exécuter une application sur tous les runtimes de conteneur et Kubernetes également.

Avec les exécutables natifs, vous n'avez plus besoin d'une machine virtuelle Java (JVM) pour exécuter vos applications Java. Au lieu de cela, l'image native peut être exécutée sur une machine virtuelle Substrate qui est les composants d'exécution (par exemple, le ramasse-miettes, la planification des threads) dans GraalVM.

La compilation native pour Java permet également aux développeurs de rester fidèles aux applications Java pour les charges de travail serverless, car les exécutables natifs peuvent réduire le temps de démarrage pour le démarrage à froid, ce qui est l'un des plus grands défis lorsque de nombreuses entreprises souhaitent adopter l'architecture serverless.

Voici un guide de démarrage rapide sur la façon d'installer la bibliothèque C et les dépendances nécessaires pour compiler une image exécutable native pour vos applications Java sur votre système d'exploitation.

Installer les bibliothèques C

Pour être pris en charge pour une compilation native en C, vous devez également installer GCC et les bibliothèques pertinentes à l'aide des commandes suivantes :

• Distributions Fedora :

$ sudo dnf install gcc glibc-devel zlib-devel libstdc++-static

• Distributions Debian :

$ sudo apt-get install build-essential libz-dev zlib1g-dev

• macOS

$ xcode-select --install

Pour plus d'informations sur l'installation de GraalVM, visitez ce site Web.

Configurer GraalVM

Définissez la variable d'environnement GRAALVM_HOME en fonction de votre système d'exploitation :

• Linux

$ export GRAALVM_HOME=$HOME/Development/graalvm/

• macOS

$ export GRAALVM_HOME=$HOME/Development/graalvm/Contents/Home/

Installez l'outil native-image :

${GRAALVM_HOME}/bin/gu install native-image

Si vous ne l'avez pas déjà fait, définissez la variable d'environnement JAVA_HOME à l'aide de la commande suivante :

$ export JAVA_HOME=${GRAALVM_HOME}

Cependant, produire une image native nécessite de fournir au préalable de nombreuses informations sur votre application. La réflexion ne fonctionnera que si une classe ou une méthode a été explicitement enregistrée. Cela obligera les développeurs Java à convertir toutes les applications existantes pour enregistrer la réflexion avant de créer une image exécutable native.

Premiers pas avec Kubernetes Java natif : Quarkus

Si vous pouviez continuer à développer vos microservices cloud natifs sans passer trop de temps à gérer la réflexion, avez-vous simplement besoin de créer une image exécutable native avant de la déployer sur le cluster Kubernetes ? Je suis presque sûr que ce serait formidable pour les développeurs Java.

Quarkus est un projet open source qui vise à fournir une pile Java standard qui permet aux développeurs Java non seulement de créer une application axée sur le conteneur sur OpenJDK, mais également pour compiler un exécutable natif à exécuter sur le cluster Kubernetes avec les avantages suivants :

• Déplacez autant de chose que possible dans la phase de build
• Minimiser les dépendances d'exécution
• Maximiser l'élimination du code mort
• Introduire des contrats de métadonnées clairs
• Améliorer l'expérience des développeurs (par exemple, DEV UI, Dev Services, Command Line)

Quarkus fournit également une extension, Funqy, qui vise à écrire des fonctions serverless portables sur des plates-formes serverless telles que OpenShift serverless, Knative, AWS Lambda, Azure Functions et Google cloud platform.

Voici un guide rapide sur la façon de créer une nouvelle fonction serverless avec une compilation exécutable native à l'aide de Quarkus.

Créer un nouveau projet Java serverless

Échafaudons un nouveau projet Quarkus pour créer une fonction à l'aide de l'outil de ligne de commande Quarkus :

$ quarkus create quarkus-serverless-example -x funqy-http

Cette commande vous permet de télécharger l'extension Funqy pour activer les fonctionnalités de Quarkus Funqy. La sortie devrait ressembler à ceci :

Creating an app (default project type, see --help).
-----------
selected extensions: 
- io.quarkus:quarkus-funqy-http

applying codestarts...
  java
  maven
  quarkus
  config-properties
  dockerfiles
  maven-wrapper
  funqy-http-codestarts

-----------

[SUCCESS] ✅ quarkus project has been successfully generated in:

--> /Users/USERNAME/quarkus-serverless-example
-----------

Explorer la fonction

Accédez au répertoire racine où vous avez créé le projet, puis ouvrez le fichier MyFunctions.java dans le répertoire src/main/java/org/acme. Une méthode de fonction simple (fun) est générée par défaut pour renvoyer un message d'accueil. L'annotation @Funq fait de la méthode générale une fonction à laquelle vous pouvez accéder par une API RESTful.

@Funq
public String fun(FunInput input) {
  return String.format("Hello %s!", input != null ? input.name : "Funqy");
}

Vous pouvez ajouter votre logique métier avec une nouvelle fonction ou une existante. Laissons le code par défaut pour le moment.

Créer et déployer un exécutable natif sur Kubernetes

Quarkus fournit une extension OpenShift pour créer l'application, puis la déployer sur le cluster Kubernetes. Exécutez la ligne de commande Quarkus suivante pour ajouter l'extension :

$ cd quarkus-serverless-example
$ quarkus ext add openshift

La sortie devrait ressembler à ceci :

Looking for the newly published extensions in registry.quarkus.io

[SUCCESS] ✅ Extension io.quarkus:quarkus-openshift has been installed

Ajoutez les configurations suivantes pour le déploiement Kubernetes au fichier application.properties dans le répertoire src/main/resources. Vous devrez remplacer YOUR_NAMESPACE par un espace de noms (par exemple, doh-dev) où vous déployez la fonction.

quarkus.container-image.group=YOUR_NAMESPACE
quarkus.container-image.registry=image-registry.openshift-image-registry.svc:5000
quarkus.kubernetes-client.trust-certs=true
quarkus.kubernetes.deployment-target=knative
quarkus.kubernetes.deploy=true
quarkus.openshift.build-strategy=docker
quarkus.openshift.expose=true

Vous pouvez également créer une image exécutable native à l'aide d'un environnement d'exécution de conteneur (par exemple, Docker ou Podman) lorsque vous définissez la configuration suivante :

quarkus.native.container-build=true

Notez que vous pouvez trouver le dépôt de la solution ici.

Pour déployer la fonction, vous pouvez utiliser votre propre cluster Kubernetes (par exemple, minikube) mais je vous encourage pour utiliser le Developer Sandbox for Red Hat OpenShift qui fournit un cluster Kubernetes partagé lorsque vous vous inscrivez pour un compte gratuit. Le bac à sable vous permet de lancer un nouveau cluster Kubernetes en 10 minutes sans aucune installation ni configuration sur votre système de fichiers local.

Exécutez la ligne de commande Quarkus suivante pour créer et déployer la fonction sur le cluster Kubernetes :

$ quarkus build --native --no-tests

La sortie doit se terminer par le message ​​BUILD SUCCESS.

Lorsque vous accédez à la vue Topology dans la console de développement OpenShift, votre fonction Java (par exemple, quarkus-serverless-example-00001) est déjà déployée. La fonction peut être réduite à zéro puisque le service Knative est défini par défaut sur 30 secondes lorsque la fonction s'arrête s'il n'y a pas de trafic réseau vers le module de fonction, comme illustré à la figure 2.

Figure 2. Fonction dans la vue Topology

Notez que vous pouvez ajouter une nouvelle étiquette à REV et KSVC pour afficher le pod en tant que fonction Quarkus, ce qui vous permet de différencier facilement les autres pods dans la vue Topology. Utilisez la ligne de commande oc comme ci-dessous :

• Ajouter une étiquette Quarkus à REV

oc label rev/quarkus-serverless-example-00001 app.openshift.io/runtime=quarkus --overwrite

• Ajouter une étiquette de fonction à KSVC

oc label ksvc/quarkus-serverless-example boson.dev/function=true --overwrite

Copiez l'URL Route puis collez la ligne de commande CURL suivante pour accéder à la fonction. Par exemple, la route ressemble à https ://quarkus-serverless-example- doh-dev.apps.sandbox.x8i5.p1.openshiftapps.com.

$ curl --header "Content-Type: application/json" \
  --request POST \
  --data '{"name":"Daniel"}' \
 YOUR_ROUTE_URL/fun 

La sortie devrait ressembler à ceci :

Hello Daniel!

Lorsque vous revenez à la vue Topology, vous verrez que le pod function monte automatiquement en une seconde, comme illustré à la figure 3.

Figure 3. Fonction mise à l'échelle

Lorsque vous affichez les journaux du pod, vous constatez que la fonction serverless Java s'exécute en tant qu'image native. Il a également fallu 17 millisecondes pour démarrer, comme le montre la figure 4.

Figure 4. Temps de démarrage d'un exécutable natif

Quelle application supersonique et subatomique ! Désormais, ces nouvelles fonctions Java serverless permettent d'optimiser les performances des ressources et de réduire les émissions de dioxyde de carbone sur Kubernetes.

Conclusion

Cet article vous explique comment les applications Java serverless peuvent aider vos organisations à réduire les émissions de dioxyde de carbone grâce à une densité de ressources plus élevée que tout autre langage de programmation sur la plate-forme de conteneurs (par exemple, Kubernetes), comme illustré à la figure 5.

Figure 5. Densité des ressources de plusieurs applications sur une plate-forme de conteneurs

Les développeurs peuvent également créer une image native pour l'application Java en choisissant l'une des trois distributions GraalVM, Oracle GraalVM Community Edition (CE), Oracle GraalVM Enterprise Edition (EE) et Mandrel. En savoir plus sur les différences entre GraalVM et Mandel ici. Pour continuer votre parcours Java Kubernative natif , visitez ce site Web.