Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Red Hat publie Mandrel, une distribution Java qui compile les applications Java directement en code machine natif
Pour un démarrage plus rapide en utilisant moins de mémoire

Le , par Bill Fassinou

212PARTAGES

10  0 
Red Hat et la communauté GraalVM ont conjointement mis en place une nouvelle distribution Java en aval de GraalVM, appelé Mandrel. Selon la société, cette distribution alimentera la version Red Hat de Quarkus, un framework Java natif de Kubernetes pour la JVM et la compilation native. Quarkus fournit une solution efficace pour l'exécution d'applications Java sans serveur, de microservices, de conteneurs, de Kubernetes, de FaaS ou de cloud. Mandrel est open source et est disponible sur GitHub, mais il ne présente pas encore de distribution binaire.

Selon une note de Mark Little, directeur principal de l'ingénierie de Red Hat, Mandrel peut être décrit comme une distribution d'un OpenJDK standard avec une image native GraalVM spécialement packagée. L’objectif principal derrière l'introduction de Mandrel par Red Hat est d'améliorer la vitesse et l'efficacité du framework Quarkus. Il s’agit d’un framework qui offre à la fois un développement local avec un rechargement rapide et une distribution conteneurisée ou sans serveur aux fournisseurs de cloud computing.

Quarkus met l'accent sur la capacité de construire des exécutables natifs qui démarrent plus rapidement et qui réduisent aussi les coûts et les ressources opérationnels du cloud. En effet, Red Hat a expliqué que pour Quarkus, l'élément important de GraalVM est sa fonction d'image native qui produit des exécutables natifs, ce qui est une caractéristique clé pour rendre Java compétitif dans les charges de travail natives du cloud. Ainsi, Mandrel permet d'avoir GraalVM en plus de l'OpenJDK 11 dans Red Hat Enterprise Linux et d'autres distributions de l'OpenJDK 11.


Selon Red Hat, la différence pour l'utilisateur est minime, mais pour la maintenabilité, l'alignement en amont avec OpenJDK 11 et GraalVM est essentiel. « Avec Mandrel, les clients Red Hat et la communauté GraalVM bénéficient d'un développement réellement ouvert, et Red Hat peut soutenir ses clients avec des mécanismes éprouvés tout en redonnant aux communautés en amont sur lesquelles elle compte pour continuer à faire progresser l'état de l'art de l'informatique à source ouverte », a déclaré la société parlant de Mandrel.
Sur le plan des performances, GraalVM se distingue par un temps de démarrage 50 fois plus rapide et une utilisation de la mémoire 5 fois plus faible.

Ces différents tests ont été faits en utilisant une version précédente du framework Quarkus contre le mode HotSpot de Java. Bien que cette amélioration nécessite un temps de compilation plus long, elle peut être utilisée parallèlement au déploiement des fonctions Lambda et Azure de Quarkus. En outre, le référentiel GitHub de Mandrel n’offre pas encore de distribution binaire. À défaut, les utilisateurs compilent eux-mêmes le JDK en suivant les instructions à propos. Par ailleurs, James Ward, développeur logiciel, a évalué en détail GraalVM et a présenté ses avantages sur l'amélioration des performances ainsi que certains gotchas, tels que les applications qui reposent sur la réflexion.

Selon lui, cela crée un problème pour les images natives de GraalVM parce que la réflexion se produit au moment de l'exécution, ce qui rend difficile pour un compilateur AOT (Ahead-of time) de déterminer les chemins d'exécution. En ce qui concerne les applications qui n'ont pas besoin de réflexion, la page d'accueil de Quarkus vise directement l’avantage : 12 Mo de RAM contre 73 Mo (une diminution de 83 %) et 0,016 seconde à la première réponse contre 0,943 (une diminution de 98 %). Les développeurs peuvent maintenant utiliser Mandrel avec leur propre build, ou peuvent s'appuyer sur la communauté GraalVM ou toute distribution du JDK 11 et supérieure. Selon d’autres avis, ces frameworks natifs de Java ne fonctionnent pas vraiment et ne devraient pas devenir une norme dans l'industrie.

Selon eux, il ne s'agit pas d'une technologie d'usage général où l'on peut prendre une application Java existante et la rendre native. Cela ne fonctionnera pas, même pour les applications que l'on écrit en choisissant une bibliothèque dans le vaste écosystème Java. Ces derniers estiment que plusieurs fournisseurs de frameworks parient sur le fait que la plupart des applications Java sont des applications HTTP/ORM/JSON, avec en plus des mesures et de la sécurité, etc. Donc, si le framework fournit une fermeture transitive de ces bibliothèques et fournit une configuration pour compiler en natif, cela fonctionnera. Mais malheureusement, cela ne fonctionne pas, car il y a beaucoup d'autres dépendances qui ne rentrent pas dans le cadre ci-dessus.

Sources : Référentiel GitHub de Mandrel, James Ward

Et vous ?

Que pensez-vous de Mandrel ?

Voir aussi

GraalVM permet de transformer une application Java en binaire natif de 7 Mo qui s'exécute en moins de 30 ms et tourne sur 4 Mo de RAM

GraalVM : Oracle annonce une machine virtuelle polyglotte conçue pour supporter plusieurs langages sans sacrifier la performance

EdgeDB : un nouveau système de gestion de base de données relationnelle-objet open source bientôt disponible en préversion technologique

Microsoft présente Azure Sphere, sa solution pour sécuriser l'IdO qui comporte un système d'exploitation basé sur un noyau Linux personnalisé

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Madmac
Membre expérimenté https://www.developpez.com
Le 04/07/2020 à 3:05
Citation Envoyé par P_Avril Voir le message
Suis-je un sysadmin isolé lorsque j'affirme craindre pour mon job? .
Je ne crois pas que cette technologie va représenté une menace pour toi. Par contre, la manoeuvre d'Amazon et Google pour s'accaparer le marché des gîtes d'hébergement de site. En détruisant la compétition, en cassant les prix, me préoccupe beaucoup plus.
4  0 
Avatar de sebi2706
Futur Membre du Club https://www.developpez.com
Le 05/07/2020 à 12:04
Citation Envoyé par P_Avril Voir le message
Je me sens concerné car cette architecture "serverless" visant a déployer des applis probablement très efficientes vont mettre les gars comme moi au chômage.

Nous étions les "dieux" il y a dix ans, via nos privilèges root; etc. Le bon fonctionnement d'une appli était tributaire de serveurs sains et correctement infogérés.

C'est automatisé à présent et m’enorgueillir d'administrer un parc de serveurs n'a plus rien de valorisant.

Je n'ai pas choisi ce métier pour écrire et dérouler des scripts via des plateformes d'automatisation (HPSA, etc.). J'aimais les aléas.
Je comprends ta crainte meme si par default une appli Quarkus n'est pas forcement serverless et peut se déployer sur du bon vieux bare metal avec l'aide indispensable d'un sysadmin.

De manière plus générale, votre métier ne va disparaitre, il evolue je pense. Prends le cas de Kubernetes, plus que jamais on a besoin de sysadmin qui nous prépare des clusters aux petits oignons, avec des teintes de noeuds qui répondent aux besoins, ("Tiens ce noeud là à du SSD et du GPU, je vais le teinter de telle sorte pour tel et tel déploiement de cette nouvelle appli de machine learning". La gestion des resources et limites aussi : "combien de CPUs, RAM je vais donner à ce namespace qui est pour la QA des devs ?"

La gestion de la sécurité, droits d'accès, service account et plus importante que jamais et c'est vous que pouvait mettre en place ces pratiques ...

Toute la partie monitoring : Mise en place de prometheus, Graphana etc ...

Le service mesh,la encore c'est vous qui pouvait prendre la main dessus ...

Bref pleines de choses passionnante qui arrive et on besoin de vous plus que jamais
1  0 
Avatar de Mubelotix
Membre actif https://www.developpez.com
Le 03/07/2020 à 17:26
Mouais ça reste pas ouf
0  0 
Avatar de
https://www.developpez.com
Le 03/07/2020 à 22:17
Suis-je un sysadmin isolé lorsque j'affirme craindre pour mon job?

Et comment rester à la page?

Font déjà parti de mon quotidien:

Les devs qui foutent la merde tout partout avec des privilèges admin (pour ensuite venir pleurer le weekend, à trois heures du matin, lors d'un reboot KO). Dixit = Ça môrche pas via Jenkins.

Les clients ayant approvisionné en trois clicks une appli dans le "mauvais" vlan, exigeant une rectification immédiate, parce que l’immédiat est à la mode, tandis que nos FW sont bien réels.

Etc...

A force d'évincer le "personnel technique" au profit d'un modèle "clefs en mains" je commence à être dégoûté de mon job.

Le monde était bien plus Dev-Ops, au sens "intelligent" lorsque nous discutions entre admins, TMA/MCO ainsi qu'avec les gens du métiers, en d'autre terme: lorsque nous avions des tunes.

Personnellement je crois que le modèle ITIL, ces RFC et sécurisations de tous bords on toujours une carte à jouer.

La plupart des utilisateurs d'une appli souhaitent davantage que les fonctionnalités historiques soient préservées, plutôt que de voir poindre des outils bling bling comme c'est la mode.

Edit: Il ne faut pas se tromper! On flingue aujourd’hui le métier de sysadmin, demain celui de développeur d'applis. C'est dans l'ordre des choses.
1  1 
Avatar de Madmac
Membre expérimenté https://www.developpez.com
Le 04/07/2020 à 2:55
Citation Envoyé par Mubelotix Voir le message
Mouais ça reste pas ouf
Bien tu devrais peut-être faire quelque recherches sur GraalVM, parce que ce truc boost les performances de plusieurs langages de programmation. En Ruby, c'est comme ajouté un turbo et du NOX au langage. Et je crois que pour les amateurs de Python, il y a également des gains intéressants à faire.

Mais je trouve le plus intéressant. Est que cela pourrait se traduire par la possibilité de distribuer des binaires sans devoir imposer l'installation de Java au client.
1  1 
Avatar de redcurve
Membre éclairé https://www.developpez.com
Le 04/07/2020 à 13:23
Citation Envoyé par P_Avril Voir le message
Suis-je un sysadmin isolé lorsque j'affirme craindre pour mon job?

Et comment rester à la page?

Font déjà parti de mon quotidien:

Les devs qui foutent la merde tout partout avec des privilèges admin (pour ensuite venir pleurer le weekend, à trois heures du matin, lors d'un reboot KO). Dixit = Ça môrche pas via Jenkins.

Les clients ayant approvisionné en trois clicks une appli dans le "mauvais" vlan, exigeant une rectification immédiate, parce que l’immédiat est à la mode, tandis que nos FW sont bien réels.

Etc...

A force d'évincer le "personnel technique" au profit d'un modèle "clefs en mains" je commence à être dégoûté de mon job.

Le monde était bien plus Dev-Ops, au sens "intelligent" lorsque nous discutions entre admins, TMA/MCO ainsi qu'avec les gens du métiers, en d'autre terme: lorsque nous avions des tunes.

Personnellement je crois que le modèle ITIL, ces RFC et sécurisations de tous bords on toujours une carte à jouer.

La plupart des utilisateurs d'une appli souhaitent davantage que les fonctionnalités historiques soient préservées, plutôt que de voir poindre des outils bling bling comme c'est la mode.

Edit: Il ne faut pas se tromper! On flingue aujourd’hui le métier de sysadmin, demain celui de développeur d'applis. C'est dans l'ordre des choses.
Je déteste le devops passer des journées à remplir des fichiers yaml (format à la con) ou docker compose j'ai vraiment autre chose à faire
0  0 
Avatar de sebi2706
Futur Membre du Club https://www.developpez.com
Le 04/07/2020 à 17:09
Citation Envoyé par P_Avril Voir le message
Suis-je un sysadmin isolé lorsque j'affirme craindre pour mon job?

Et comment rester à la page?

Font déjà parti de mon quotidien:

Les devs qui foutent la merde tout partout avec des privilèges admin (pour ensuite venir pleurer le weekend, à trois heures du matin, lors d'un reboot KO). Dixit = Ça môrche pas via Jenkins.

Les clients ayant approvisionné en trois clicks une appli dans le "mauvais" vlan, exigeant une rectification immédiate, parce que l’immédiat est à la mode, tandis que nos FW sont bien réels.

Etc...

A force d'évincer le "personnel technique" au profit d'un modèle "clefs en mains" je commence à être dégoûté de mon job.

Le monde était bien plus Dev-Ops, au sens "intelligent" lorsque nous discutions entre admins, TMA/MCO ainsi qu'avec les gens du métiers, en d'autre terme: lorsque nous avions des tunes.

Personnellement je crois que le modèle ITIL, ces RFC et sécurisations de tous bords on toujours une carte à jouer.

La plupart des utilisateurs d'une appli souhaitent davantage que les fonctionnalités historiques soient préservées, plutôt que de voir poindre des outils bling bling comme c'est la mode.

Edit: Il ne faut pas se tromper! On flingue aujourd’hui le métier de sysadmin, demain celui de développeur d'applis. C'est dans l'ordre des choses.
Désolé mais c'est quoi le rapport avec Mandrel/GraalVM/Quarkus ?
0  0 
Avatar de
https://www.developpez.com
Le 04/07/2020 à 18:18
Citation Envoyé par sebi2706 Voir le message
Désolé mais c'est quoi le rapport avec Mandrel/GraalVM/Quarkus ?
Je me sens concerné car cette architecture "serverless" visant a déployer des applis probablement très efficientes vont mettre les gars comme moi au chômage.

Nous étions les "dieux" il y a dix ans, via nos privilèges root; etc. Le bon fonctionnement d'une appli était tributaire de serveurs sains et correctement infogérés.

C'est automatisé à présent et m’enorgueillir d'administrer un parc de serveurs n'a plus rien de valorisant.

Je n'ai pas choisi ce métier pour écrire et dérouler des scripts via des plateformes d'automatisation (HPSA, etc.). J'aimais les aléas.
0  0 
Avatar de
https://www.developpez.com
Le 04/07/2020 à 18:41
Citation Envoyé par Madmac Voir le message
Je ne crois pas que cette technologie va représenté une menace pour toi. Par contre, la manoeuvre d'Amazon et Google pour s'accaparer le marché des gîtes d'hébergement de site. En détruisant la compétition, en cassant les prix, me préoccupe beaucoup plus.
Totalement d'accord.
0  0