L'Opportunité De La Modernisation Des Applications

La situation

La modernisation des applications est désormais un mot à la mode similaire à Devops ou SRE ou Cloud Native. Le mot signifie différentes choses pour différentes personnes. Demandez à un ingénieur de plate-forme et il vous expliquera que la modernisation consiste à faire passer les machines virtuelles du cloud privé au cloud public.

Demandez à un développeur et il se référera à la modernisation comme à la conteneurisation des applications legacy. Un architecte logiciel peut définir la modernisation comme la refactorisation d'une application en microservices à 12 facteurs / 15 facteurs.

Tous les principaux fournisseurs d'entreprise sont dans une course folle pour aider les entreprises à moderniser leurs workloads sur toutes les couches de la pile IaaS, CaaS et PaaS. Comment décomposer cette opportunité de marché ?

Il existe plusieurs conditions de marché en jeu qui déclenchent la refactorisation et la mise à niveau des applications vers le Cloud Native et le cloud.

1. Middleware legacy

Un pourcentage important du parc d'applications client est constitué d'applications natives legacy non cloud s'exécutant avec des frameworks non microservices sur des serveurs d'applications propriétaires. Ces applications peuvent être des applications Struts monolithiques massives avec une logique de backend s'exécutant sur WebSphere ou WebLogic.

L'enquête Jakarta EE Developer Survey a indiqué que 85% des utilisateurs utilisent un modèle de programmation d'il y a plus de 3 ans. Près de 50% sur un de 7 ans et plus. Les applications monolithiques sur les serveurs legacy ralentissent les versions de nouvelles fonctionnalités et augmentent considérablement le délai de mise en œuvre.

Les développeurs sont fatigués d'attendre le redémarrage d'une application qui prend entre 1 et 5 minutes et une expérience de développement en boucle interne qui les lie à d'anciens frameworks JavaEE et bibliothèques de serveurs d'applications. Le problème de redémarrage et d'empreinte de l'application a été en grande partie résolu dans les variantes modernes de tous les serveurs d'applications. Cependant, la migration des applications existantes vers la dernière version d'Eclipse Glassfish ou OpenLiberty prend du temps.

Source de l'image : Jakarta EE Developer Survey 2020

Les serveurs d'applications propriétaires représentent un coût et des systèmes vitaux pour une entreprise. Les spécialistes des serveurs d'applications ont laissé les entreprises aux niveaux Infrastructure et Développeur. Trouver du personnel IT pour maintenir ces systèmes devient coûteux. Les systèmes et les versions du serveur d'applications et du JDK ne sont pas mis à jour, ce qui pose des problèmes d'audit et de gouvernance. Les applications Java construites à l'aide d'anciens frameworks J2EE tels que Struts, EJB, JAX-RPC, etc. sont difficiles à mettre à niveau et ont accumulé une dette technique. Les applications utilisent également des services sous-jacents ou des frameworks personnalisés qui ont été développés en interne pour intégrer ces applications.

2. Java Legacy

La plupart des applications d'entreprise sont toujours sur Java 8, Java 7 et Java 6 et en cours de migration vers Java 11/14. Les clients ont besoin de notre aide pour migrer leurs applications vers Java 11 et Java 14 afin de tirer parti du support de conteneurisation fournis par les versions ultérieures de Java. Les anciennes versions de Java empêchent les mises à niveau de la plate-forme et ne sont généralement pas compatibles avec les conteneurs du point de vue de la mémoire. Les anciennes versions de Java sont également une source de failles de sécurité.

Source de l'image : Jakarta EE Developer Survey 2020

3. Spring Legacy

Spring Framework et Spring Boot sont les frameworks n° 1 dans l'entreprise pour les microservices Java. Le manque de pratiques CI / CD et de gouvernance de l'architecture des applications a conduit à des applications utilisant des versions plus anciennes de Spring Framework (<5) et Spring Boot (<2). Les entreprises ont besoin d'aide pour mettre à niveau et corriger leurs versions de Spring. C'est un problème qui se posera lorsque Spring Boot 2.1.x sera EOL le 1er novembre 2020 et Spring Boot 1.x est déjà EOL depuis le 1er août 2019. Les entreprises qui ont une posture de sécurité rigoureuse voudront mettre à niveau dès que possible les versions prises en charge de Spring et Spring Boot. Une ancienne version de Spring et Spring Boot empêche les entreprises d'utiliser les derniers frameworks tels que spring-cloud et d'autres projets Spring qui accélèrent le développement de microservices.

Source de l'image : Stack Overflow Trends

Il existe une opportunité d'automatiser le travail de migration du framework et des composants Spring Boot pour les applications Spring existantes. Au lieu de lire et d'implémenter un guide de plusieurs pages, les développeurs peuvent exécuter un linter Spring pour mettre à niveau leurs composants du framework.

4. Monolithes vers microservices et microservices vers monolithes modulaires

Des enquêtes récentes menées auprès des développeurs par Jetbrains et Jakarta EE confirment que les microservices sont la principale architecture pour la mise en œuvre de systèmes Java dans le cloud. Domain Driven Design et des techniques de modélisation comme SWIFT, Wardley Maps, Bounded Context Canvas ont fourni les heuristiques techniques et commerciales pour la création de microservices. Il y a cependant un contrecoup émergeant de la complexité des microservices et une impulsion pour évoluer vers des architectures de déploiement plus simples comme les monolithes modulaires. Voir Après Les Microservices, Retour Au Monolithe.

Il existe des lacunes importantes que les bibliothèques et les frameworks peuvent combler en générant un backlog et de mise en œuvre à partir d'events storming ou de la décomposition de monolithes. Générer un backlog de user stories et d'epics à partir d'event storming est une œuvre d'art et nécessite une forte facilitation car DDD Is Broken. Il est difficile de diviser les fonctionnalités métier en sous-fonctionnalités métier et les microservices candidats nécessitent un jugement d'expert avant leur mise en œuvre. Les outils et les frameworks d'observabilité qui aident à comprendre les métadonnées d'exécution d'application existantes associées à un profiler disposent en théorie des informations nécessaires pour faire des recommandations sur les points de départ de la décomposition des monolithes. Un outil qui a commencé à se pencher sur ce problème est vFunction.

Sources des images : JetBrains Developer Survey, Jakarta EE Developer Survey 2020

La combinaison de l'instrumentation de profilage, des métriques CI / CD et des mesures SLO peut guider la rationalisation des microservices en analysant des métriques telles que le taux d'échec des modifications. Il s'agit d'un processus qui est lourd et conduit par des ateliers comme le "Should That Be A Microservice ? ".

5. Fragmentation dans Java EE, Jakarta EE et Eclipse MicroProfile

Eclipse et Oracle ne sont pas parvenus à s'entendre sur les conditions relatives à l'espace de noms du package javax et aux marques déposées. En conséquence, toutes les applications JavaEE doivent désormais migrer vers Jakarta EE. Les fournisseurs de serveurs d'applications se précipitent pour ajouter la prise en charge de Jakarta EE à leurs serveurs d'applications. Jakarta EE Is Taking Off. Les applications codées sur l'espace de noms javax peuvent s'exécuter sans modification sur TomEE, OpenLiberty et d'autres avec eclipse transformer qui réécrit les références Jakarta EE 8 à Jakarta EE 9 en modifiant le bytecode et les plugins de patch qui fournissent une transformation du bytecode supplémentaire basée sur ASM pour gérer les cas extrêmes. L'autre option consiste à recoder les applications à l'aide des API Jakarta EE et d'outils tels que tomcat-Jakarta EE-migration.

Pour les entreprises conservatrices, la transition de Java EE vers Jakarta EE nécessite un effort de test de non régression et le déploiement sur les nouveaux serveurs d'applications des fournisseurs et tout un tas de réécriture de bytecode magique OU de réécriture de code pour résoudre la confusion créée par Oracle. Les entreprises ont d'autres choses dans lesquelles investir au lieu de s'inquiéter de la compatibilité fonctionnelle et de la régression avec une nouvelle version de Jakarta EE. Cela présente une opportunité pour des outils et / ou des produits supplémentaires dans cet espace.

Source de l'image : Transition de Java EE vers Jakarta EE

Eclipse MicroProfile évolue à un rythme plus rapide que Jakarta EE. Six versions majeures de MicroProfile avec seize releases de composants en moins de deux ans alors que JavaEE / Jakarta EE évolue au rythme du consensus entre les organismes de normalisation. Il semble que la plupart des innovations dans le domaine des normes se produiront d'abord dans MicroProfile, puis se répercuteront dans Jakarta EE. Dans un avenir prévisible, Eclipse MicroProfile sera séparé et construit sur Jakarta EE. Kevin Sutter - le codirecteur d'Eclipse MicroProfile et membre du PMC d'EE4J a écrit un article intitulé What's next for MicroProfile and Jakarta EE?

Jusqu'à ce que Jakarta EE ait démontré un processus de spécification permettant les aspects rapides et innovants du projet MicroProfile, MicroProfile maintiendra sa propre dynamique de projet distincte des projets EE4J.

Source de l'image : What's next for MicroProfile and Jakarta EE? (Newsletter Eclipse)

La fragmentation de l'API entre les frameworks Jakarta EE et Eclipse MicroProfile avec des rythmes de changement différents offre une opportunité de simplification.

6. VM vers conteneurs et Kubernetes (V2C / V2K)

C'est le Saint Graal des vendeurs Kubernetes. Un outil qui crée automatiquement des conteneurs à partir de VM. Pas seulement des conteneurs système, mais des conteneurs au niveau de l'application qui connaissent le middleware sous-jacent. Un outil capable de découvrir, d'analyser et de reconditionner les applications existantes pour tirer parti de l'élasticité, de la tolérance aux pannes, de la densité et des mises à jour / patchs offerts par le cloud. Un outil qui comprend des frameworks spécifiques aux applications et aux langages pour conteneuriser et créer la bonne couche de conformité OCI mettant en cache des images efficaces. Un tel outil s'apparente à une licorne magique.

Il existe une variété d'outils qui aident à créer des images en toute sécurité à partir de la source, tels que S2I , Cloud Native Buildpacks et les plugins Maven tels que les tâches et les objectifs jib et maven/gradle build-image ; cependant, ceux-ci nécessitent une sorte d'intervention manuelle. La modernisation ascendante axée sur l'infrastructure adore gérer les workloads sans parler aux développeurs avec de préférence zéro changement de code avec le moins de risques. Les ingénieurs de plate-forme rêvent d'un produit VM2containers ou VM2kubernetes qui répond aux besoins de l'équipe Infrastructure, leur permettant une transformation massive des workloads avec une intervention minimale des développeurs. Google Anthos Migrate et Docker ont fait de vaillants efforts pour résoudre ce problème. Amazon a également récemment rejoint la partie et introduit une multitude d'outils dans cet espace comme AWS app2container, docker2aws et co-pilot qui aident à la conteneurisation des applications pour les distribuer sur ECS et EKS.

Capture de la valeur

Comment les fournisseurs peuvent-ils tirer parti de ces vents favorables en créant une suite de produits qui répondent aux besoins non satisfaits et aux défis auxquels sont confrontés les développeurs lors de modernisation d'applications aujourd'hui ? Quels produits peuvent permettre aux développeurs de migrer leurs applications vers une architecture Cloud Native et des microservices plus rapidement et atténuer les problèmes décrits ci-dessus.

1. Livre de recettes (Cookbooks)

Des livres de recettes comme appmod-recipes et le framework well-architected, qui ont rassemblés au fil des années passées de la matière concernant la migration d'applications peuvent servir de multiplicateur de force en ce qui concerne l'adoption et la productivité des développeurs. La documentation des patterns qui aide les architectes cloud dans la migration avec une approche bien structurée de la modernisation des applications avec un livre de recettes solide de migration d'applications conduira les développeurs à ne pas s'égarer dans le débordement de pile et à augmenter la productivité de la migration par les grands intégrateurs système. L'investissement dans le livre de recettes sur la transformation des applications par un rédacteur dédié, associé à l'expertise du domaine de l'équipe de modernisation des applications, conduira à une accélération de la qualité et de la quantité de transformations, ce qui permettra aux développeurs de migrer facilement des applications vers le Cloud Native sans une lourde charge de consultation. Un ensemble de recettes de haute qualité cataloguant la migration des composantes legacy servira également de blueprint pour l'outillage de transformation.

2. Super (Rewrite) Linters

Un outil en ligne de commande packagé sous forme de linter ou d'exécutable en ligne de commande qui fournit un moteur de réécriture et un DSL pour la transformation de code. L'outil de réécriture agit comme un super linter qui automatise la transformation des applications legacy et réduit la dette technique. Le Rewrite Linter modifie directement les fichiers source, y compris Java, XML et YAML à l'aide d'une bibliothèque JavaParser pour analyser les fichiers sources Java. Des modifications sont apportées directement à l'arbre de syntaxe abstraite, de sorte que le résultat est toujours syntaxiquement correct et sérialisé pour la persistance et la provenance. L'intention est d'automatiser le travail de transformation vers des frameworks de microservices modernes et de laisser l'application dans un état compilable. Un outil qui commence à mettre en œuvre ce concept est open rewrite.

3. Interopérabilité contradictoire

Il s'agit d'une technique exploitée par les fournisseurs de cloud hyperscale pour offrir des API spécifiques à un domaine ou à un produit, comme pour Cassandra ou Mongo, mais dont l'implémentation sous-jacente est fournie par des produits natifs. Par exemple, Azure Cosmos DB fournit une API pour MongoDB tirant parti de la compatibilité du protocole MongoDB. Les frameworks peuvent utiliser ce type de mécanisme. Par exemple, Quarkus fournit une couche de compatibilité pour l'injection de dépendance Spring sous la forme de l'extension spring-di. La compatibilité de l'API Quarkus Spring inclut Spring DI, Spring Web et Spring Data JPA. Des API Spring supplémentaires sont prévues comme Spring Security et Spring Config. Consultez Quarkus For Spring Developers.

Résumé

Le développeur consacre en moyenne 13,5 heures par semaine à rembourser la dette technique. [Source - enquête Stripe ]. La double pression de la maintenance des applications exécutées en production et de leur modernisation vers le cloud met à rude épreuve les équipes de développement et de plateforme. La modernisation des applications doit évoluer et être rendue efficace grâce à la documentation, aux produits et aux frameworks. Il est temps que les fournisseurs se mobilisent et que les entreprises investissent dans la migration et la transformation en tant que Service pour accélérer la modernisation partielle ou complète des applications vers le cloud. Les entreprises qui se concentrent sur l'intégration des workloads dans le cloud s'attaqueront à leurs menaces concurrentielles en améliorant la productivité des développeurs, en réduisant la dette technique et en utilisant la rentabilité et la flexibilité du cloud.

A propos de l'auteur

Rohit Kelapure est un expert de la migration des applications vers le cloud et de la modernisation des systèmes critiques. Rohit a formulé des stratégies GTM, marketing et produit pour la modernisation des applications. Rohit améliore continuellement ses offres et ses systèmes pour aider les ventes, la livraison et les communautés open source à générer les bons résultats pour les clients. Rohit blogue activement sur la fonderie de cloud, les kubernetes, la refactorisation des monolithes et les stratégies de modernisation des applications. Les webinaires récents de Rohit incluent des sujets aussi divers que la modernisation du middleware, la migration du mainframe et des outils et recettes pour restructurer les applications monolithiques sur le cloud moderne. Rohit est un expert des technologies Spring et Java EE et a couvert ces deux sujets en détail sur ses blogs WebSphere and All Things Cloud. Toutes les opinions sont les miennes et non celles de mon employeur.