Simplicité de mise en œuvre, coûts maîtrisés et accès à l’élasticité horizontale du cloud : le replatforming s’impose souvent comme la solution de choix pour porter une application métier vers le cloud. Reste à voir selon quels principes organiser sa migration pour réduire la dépendance de l’application à la plateforme et maximiser les bénéfices de la démarche.
La séparation entre le code et son environnement d’exécution n’a pas toujours été la règle en matière de développement, ce qui ne va pas sans poser quelques problèmes dès que l’on
souhaite changer de système d’exploitation ou migrer vers une autre infrastructure.
L’une des ambitions du cloud consiste précisément à réduire la dépendance entre l’application et l’architecture qui l’héberge. C’est cette séparation qui rend possible la création
d’infrastructures flexibles et scalables, au sein desquelles on peut ajouter des ressources, faire évoluer des composants ou procéder à des mises à jour de sécurité sans altérer le code ou son
bon fonctionnement.
Parmi les différentes stratégies de modernisation pour le cloud, le replatforming regroupe l’ensemble des techniques utilisées pour réinstaller l’application au sein d’un nouvel environnement en l’isolant
autant que possible des aspects liés à la configuration et à la résilience de la pile d’exécution. L’objectif est donc double : couper les liens avec la plateforme, mais aussi avec l’instanciation.
Voici les principales adaptations à envisager pour y parvenir.
Automatiser les processus
Le passage au cloud implique de pouvoir déployer vite, fréquemment et de façon sécurisée. Deux approches peuvent être mises en œuvre, de manière séparée ou conjointe, pour atteindre cet
objectif : la robotisation des processus d’installation ou de configuration et la conteneurisation.
La robotisation ou automatisation vise à remplacer les étapes d’un déploiement manuel par un ensemble de processus définis et validés à l’avance. On sélectionnera le ou les outils adéquats
(Ansible, Chef, Terraform…) en fonction des contraintes de la chaîne industrielle de production et de l’environnement de destination.
L’automatisation élimine les risques d’erreur humaine et contribue à accélérer les déploiements. Elle renforce ainsi le processus de production, qui peut donc plus facilement entrer dans une démarche
de livraison continue. Il profite par ailleurs de ressources supplémentaires grâce à l’effort économisé sur les phases de validation. La mise en place d’un processus end to end sert par ailleurs les exigences
de qualité et de time to market : au sein d’une chaîne automatisée, les tests vont pouvoir être effectués plus tôt et plus souvent.
La conteneurisation offre quant à elle la possibilité de créer une image intégrant à la fois l’application et son contexte d’exécution. Le conteneur ainsi créé se révèle
extrêmement portable, ce qui permet de le déployer à la demande sur des environnements différents. Il devient ainsi possible d’optimiser au maximum l’utilisation des ressources disponibles, pour peu que l’approche
conteneur s’appuie sur un dispositif robotisé de bout en bout. En pratique, l’articulation exacte entre conteneurisation et robotisation dépend bien sûr du projet et de la structure de l’application.
Garantir la résilience de l’architecture
Le passage à une architecture cloud réduit dans le même temps la dépendances aux instances localisées : plutôt que de chercher à garantir à tout prix le bon fonctionnement d’un composant, on
va prévoir son remplacement en cas de défaillance. L’objectif n’est plus de tendre vers un idéal de fiabilité ou de robustesse, mais plutôt de garantir la résilience de l’architecture. L’application
est exécutée plusieurs fois en parallèle sur des dispositifs différents, chacun d’entre eux étant apte à traiter l’ensemble des flux entrants. Cette haute disponibilité est très coûteuse
à mettre en place et maintenir sur des architectures dédiées, mais elle se révèle nettement plus accessible dans le cloud, y compris pour des applications déjà existantes.
Elle implique de travailler sur les traitements synchrones pour leur permettre de profiter d’une infrastructure multi-instanciée, élastique et capable d’opérer elle-même la reprise d’activité en cas
de défaillance. Dans ce contexte, des répartiteurs de charge pilotent la distribution des tâches et la scalabilité, en s’appuyant sur des données de contexte stockées à l’extérieur
du système, par exemple dans une base NoSQL dédiée.
Ordonnancement et services périphériques
D’un point de vue architectural, ce découplage amène à repenser la façon dont sont gérées les données liées à l’identité ou aux droits ainsi que l’identifiant permettant
de se lier à l’éventuelle session métier traitée en base de données. Cette intégration, réalisée au moyen du JSON Web Token, conduit aussi à retravailler la logique applicative globale
pour stocker et traiter les données de résultats intermédiaires de façon indépendante du back-end. Dans un processus moderne, le cheminement page par page d’un formulaire métier n’est plus directement
piloté par le serveur applicatif : il est exécuté dans le navigateur, ce qui favorise et simplifie la mise en œuvre du principe de scalabilité horizontale.
La modernisation suppose par ailleurs une réflexion sur la façon dont l’architecture va gérer les traitements asynchrones, qui permet la création de files d’attente et le lissage dans le temps de l’exécution.
La plupart des applications métier complexes intègrent déjà l’ordonnancement par le biais d’une base de données partagée entre plusieurs instances. Le modèle est conservé et même
optimisé dans un environnement cloud, puisque la gestion des instances dédiées au traitement peut être asservie à la taille des files d’attente. La capacité s’adapte ainsi au besoin.
Des adaptations sont également nécessaires pour les exécutions de type batch, qui demandent de traiter un important volume de données similaires dans un temps défini. Ici, on cherche à capitaliser sur la flexibilité
du cloud, en ne mobilisant l’infrastructure nécessaire que sur la stricte durée du traitement pour réduire les coûts, ce qui implique une transformation du processus d’ordonnancement et la mise en place d’un
service de stockage hors instance.
Cette logique s’étend à l’ensemble des dispositifs périphériques qui sont indispensables au fonctionnement de l’application mais ne contribuent pas directement à générer la valeur métier.
Ces composants doivent dès que possible être remplacés par des services managés au sein desquels les tâches d’opération, de mise à jour ou de sauvegarde sont automatisées et robotisées.
Dégager le projet de ces tâches coûteuses et génératrices de délais c’est lui donner plus de capacité pour le traitement spécifique métier tout en améliorant la qualité
de service et la robustesse générale de l’architecture.