Java 8 en production, petit manuel de persuasion.

Un développeur, un architecte, proposant une nouvelle stack logicielle, Java 8 au lieu de Java 6, AMQP au lieu de JMS, Python 3 au lieu de Python 2.6, Teamcity au lieu de Jenkins, est souvent considéré comme une fashion victim.

Au delà des anecdotes que nous pourrions citer, il y a des pratiques imposées pour s’adresser à une cellule d’architecture ou à une équipe d’infrastructure réfractaire à l’idée d’une migration. Cela demande parfois un peu de gestion de changement, pas mal de persuasion et des pré-requis. Nous vous proposons un petit tour des pratiques et techniques permettant de convaincre une hiérarchie de mettre à jour une stack logicielle, au travers des évolutions de Java et notamment de Java 8.

Quelles sont les raisons invoquées pour ne pas utiliser Java 8 ?

• La production est difficile à mettre à jour
• Nous n’avons pas de recul sur son utilisation en production
• Il est possible de tout réaliser en Java 6
• Java 8 était sorti avec des bugs

Si nous transposions, nous pourrions appliquer ces remarques à tous types de stacks logicielles. Le cas de Java 8 n’est pas isolé.

La production est difficile à mettre à jour

Certains environnements de production sont difficiles à mettre à jour pour de bonnes raisons. Tout le monde n’a pas le temps d’automatiser l’installation de serveurs; cela ne se condamne pas, surtout dans les vieilles structures. Et puis après tout, ce n’est pas une honte, même en 2015.

Toutefois, la difficulté n’est pas une justification à l’abandon; essayons de résoudre ensemble la problématique d’une mise à jour de Java.

Les JRE Oracle ont pour avantage, le plus souvent, de ne pas contenir de dépendances sur d’autres paquets du système d’exploitation.

Dans le cas de la JRE Oracle, il suffit de prendre le tar et de le décompresser.

Dans le cas OpenJDK, il y a pas mal de dépendances sur d’autres paquets du système, parmi lesquelles alsa cpio cups zip which, xorg, etc.

• Soit le système supporte une version à jour, pas de problème donc.
• Soit le système ne supporte pas une version à jour, Il est possible de pratiquer une installation from source et de builder le paquetage à la main. La bonne pratique est alors de créer son propre repository RPM/APT pour pouvoir partager ses paquets.

Réaliser le build à la main est même plus sûr puisque cela assure une compatibilité optimale avec les autres logiciels (librairies, etc) installés en production.

Souvent des repositories tous prêts existent et sont mis à jour avec soin. C’est le cas par exemple des redhat channels.

Pour réaliser l’installation sur vos serveurs de production, il faut réussir à instiller un jeu de bonnes pratiques :

• Utiliser dés que possible un outil d’Infrastructure As A Code. A titre personnel je recommande Ansible car SSH suffit pour le faire fonctionner,
• Installer plusieurs versions de java sur un même serveur est tout à fait possible et même recommandé pour optimiser son infrastructure,
• Utiliser des liens symboliques pour réaliser la mise à jour transparente de votre JRE,
• Utiliser les alternatives afin de sélectionner le java par défaut.

Enfin, je préfère recommander l’utilisation du JDK Oracle afin de pouvoir disposer régulièrement de mise à jour de sécurité et d’une version de Java certifiée par Oracle.

Soyez réaliste: cultiver des choix conservateurs n’aura pour conséquence que le vieillissement de votre Système d’Information.

Nous n’avons pas de recul sur son utilisation en production

Là encore, pas de panique. On considère que les briques backends (workers, services web) peuvent être migrées sans risques sur une version récente de Java.
Pour un portail, susceptible d’être exploité par un nombre important d’utilisateurs la prudence est de mise, sans paranoïa toutefois.

Il est d’ailleurs courant que les bugs applicatifs constatés à l’occasion d’une migration soient dus à une mauvaise conception ou à une qualité de code insuffisante.

De manière générale, afin de porter un projet sur une version de Java il suffit de :

1. Migrer le JDK
2. Lancer la suite de tests unitaires/d’intégration.
3. Réaliser une recette complète de l’application.
4. Corriger les bugs et itérer à l’étape 2/ jusqu’à ce que le projet soit reconnu fonctionnel.

De plus, Java 8 augmente le niveau de sécurité d’une manière notable et ce pour plusieurs raisons :

• Des améliorations de la cryptographie dans le cadre du projet de modernisation de la cryptographie de la NSA
• Amélioration des Keystores
• Meilleure gestion de l’entropie de nombres aléatoires.

Je peux tout réaliser avec Java 6/5/4, etc

C’est bien évidemment faux. Pas de scala, pas de performance, pas de frameworks récents, pas de lambdas.

Prenons en compte les innombrables améliorations de syntaxe, de fonctionnalités :

Java 7 :

• Support du diamond operator,
• Le multicatch,
• Le support de JSR 292 pour améliorer la performance des langages dynamiques.
• NIO 2,
• l’API fork/join.

À ce titre cette version de Java offre un certain gain de productivité. C’était le but du projet Coin sur lequel nous ne reviendrons pas.

Java 8 :

• Le support des lambdas tant au sein du langage que de l’API (collections, etc),
• Les streams,
• Les collectors.

À ce titre Java 8 offre aussi un gain de productivité, mais en introduisant des fonctionnalités innovantes comme lambda, streams et collectors, ce qu’il est impossible de réaliser simplement avec Java 6.

C’était sans compter les performances du nouveau garbage collector G1 et de la suppression de la permanent generation en Java 8. À l’heure du big data, de la haute volumétrie, ces deux optimisations paraissent indispensables.

Une version de Java aussi récente que la 8 vous permettra donc d’améliorer la vélocité de votre équipe de développement et d’élargir le champ des possibles.

Java 8 était sorti avec des bugs

On entends souvent dire : Java 8 était buggué dés sa sortie. Cela nous fait peur.

C’est un peu oublier que Java 6 et 7 ont aussi leurs propres anomalies de sécurité. Dans le cas de Java 6 c’est même pire puisque cette version de java n’est plus maintenue, elle est EOL (end of life). Ce sera le cas bientôt pour Java 7 qui ne sera plus mis à jour à partir de Avril 2015.

Enfin, Java 8 était buggué dés sa sortie pour une excellente raison ; dans une communauté d’utilisateurs aussi importante que celle de Java, les bugs sont détectés et remontés très rapidement.
Avoir une communauté aussi importante est au contraire un véritable gage de qualité.

Conclusion

Nous espérons vous avoir aidé à construire des arguments en faveur de la gestion du cycle de vie de votre environnement de production.

Être capable de s’adapter et d’aider les équipes de R&D à innover est l’un des buts du mouvement DevOps, car bien souvent, il est constaté que la difficulté à adapter régulièrement un environnement de production est le résultat d’un manque de collaboration entre équipes de réalisation et d’infrastructure.

Augmenter le niveau de collaboration entre vos équipes de développement et de production est considéré comme la première réponse à donner à ce qui apparait, avant tout, comme un problème de collaboration et de gestion du changement.