5 conseils pour réarchitecturer vos applications pour le cloud

S’il est certes techniquement possible de migrer presque n’importe quelle application vers le cloud public, ce n’est pourtant pas toujours un choix judicieux ou rentable. Pour que cela en vaille la peine, il est nécessaire de concevoir de nouvelles applications, ou de refondre l’architecture des applications existantes, afin de tirer parti de l’ensemble des spécificités du cloud.

Pour ceux qui ont besoin de réorganiser leurs applications existantes, voici cinq éléments à garder à l’esprit.

1.   Équilibrer les composants applicatifs et les workflows

L’approche « Lift and Shift » n’est souvent qu’une première étape dans une phase de migration vers le cloud. Pour moderniser les applications cloud, il est généralement préférable de les décomposer en plusieurs composants. Vous devez héberger chaque composant indépendamment, au sein de machines virtuelles ou dans des conteneurs, ce qui augmente les coûts. Il faut également coupler ces composants applicatifs à des workflows en assurant les bonnes connexions réseau, ce qui peut également coûter plus cher. Avant de commencer, listez les avantages et évaluez si le coût en vaut la peine.

Si c’est le cas, l’étape suivante consiste à déterminer si certaines fonctions de l’application sont utilisées et dimensionnées ensemble ou séparément. Si elles fonctionnent de concert, il est peu probable que leur transformation en composants applicatifs distincts augmente la résilience ou l’évolutivité. Il est donc préférable de les déployer dans le cloud de manière monolithique.

Si en revanche leurs utilisations diffèrent, demandez-vous si vous pouvez recomposer des applications à partir de ces fonctions et si les différences en matière de dimensionnement et de résilience sont significatives.

En général, un nombre réduit de composants – conforme aux bonnes pratiques de mise à l’échelle et de résilience – est la meilleure réponse, et la moins chère. À la faveur de la conteneurisation et de la standardisation des architectures de microservices, les développeurs sont trop souvent tentés de multiplier les composants. Outre des problèmes évidents de coût, cela peut complexifier la gestion de ces éléments et engendrer des problèmes de sécurité.

2.   La scalabilité et la résilience du cloud ne sont pas automatiques

La capacité de migrer (burst) une workload du datacenter vers le cloud, d’améliorer les performances en ajoutant de nouvelles instances et de remplacer les composants défaillants sont autant d’avantages connus du cloud. Mais cela nécessite une conception minutieuse de l’application. La plupart des applications sont « stateful », ce qui signifie qu’elles traitent des demandes qui contiennent plusieurs étapes. Si vous exécutez une nouvelle application ou une copie d’un composant, il se peut que cette instance ne sache pas de quelle étape il s’agit. Cela peut provoquer des défaillances ou donner des résultats incorrects.

Contrôler cet état est l’une des parties les plus difficiles, lorsque l’on réarchitecture des applications pour le cloud. Assurez-vous de gérer les transactions à partir de l’interface graphique utilisateur. Cela vous donne un contrôle total sur la scalabilité et la résilience. Si cela ne fonctionne pas – à cause de la nature de l’application –, sauvegardez l’état dans une base de données et partagez-le lorsque vous avez besoin de répliquer ou de remplacer des composants de l’application. Vous pouvez également évaluer les microservices et les fonctionnalités serverless de votre fournisseur de cloud pour vous aider – mais là encore, attention au coût.

En clair, il convient de mettre en place les bons outils de supervision pour s’assurer de la disponibilité, de la redondance, de l’efficacité des protocoles de sauvegarde et de restauration et de mise à l’échelle automatique, si vous activez cette fonctionnalité.

3.   Préparez-vous à l’hybride et au multicloud

En raison de la conformité et des politiques de gouvernance, la plupart des applications cloud doivent se connecter au datacenter de l’entreprise pour mettre à jour les bases de données qui ne peuvent pas migrer vers le cloud. C’est d’ailleurs un passage obligé au lancement d’une migration vers le cloud : l’application en cours de migration existera à la fois sur site et dans le cloud, le temps d’opérer la bascule.

Pour cela, de nombreux utilisateurs du cloud public mettent en place une stratégie multicloud afin de réduire les risques d’indisponibilité. Il est toutefois nécessaire de concevoir une application pour l’une ou l’autre de ces architectures, hybrides ou multicloud, ou potentiellement faire face à des problèmes de coût, de performance et de fiabilité.

Les applications hybrides ou multicloud accentuent les problèmes de workflow et de scalabilité, car presque tous les fournisseurs de cloud facturent le trafic sortant au sein de leur cloud. Cela signifie que si vous avez besoin de dimensionnement ou de remplacer des composants applicatifs qui exploitent plusieurs fournisseurs, il vous faudra engager de nouveaux coûts. Évaluez donc les capacités de votre fournisseur, afin de contrôler au mieux le coût et la performance globale des applications.

Normalement, les applications en cloud hybride fonctionnent mieux si leur front-end est hébergé dans le cloud et si le traitement des transactions et les mises à jour de la base de données se trouvent dans le datacenter. Cela peut vous servir de point de repère pour débuter la refonte de vos applications.

4.   Utiliser les services des fournisseurs de cloud de manière réfléchie

Les fournisseurs de cloud proposent des centaines de services, dont certains peuvent radicalement simplifier et refaçonner les applications qui migrent vers le cloud. Services de stockage objet, d’hébergement de VM, de mise en cache, bases de données à la demande, PaaS… Les catalogues des fournisseurs se sont considérablement enrichis en quelques années.

D’un autre côté, ces services peuvent également augmenter les dépenses, voire dissimuler des coûts liés à la migration des workflows et des connexions réseau.

Lorsque vous évaluez ces services, il convient de catégoriser votre application. En général, les applications cloud sont soit des services front-end qui prennent en charge les mécanismes proposés aux utilisateurs, soit des applications liées à des événements en provenance de systèmes IoT, par exemple. Les fournisseurs de cloud ont des services pour gérer ces deux modèles, mais vous pouvez aussi les comparer à des outils middleware afin d’évaluer les possibilités de développement à façon. Dans de nombreux cas, le coût unique de ces outils middleware sera inférieur aux frais permanents des services cloud. S’appuyer sur des technologies tierces permet, en outre, de se prémunir contre l’enfermement propriétaire. Si la plupart des services cloud sont développés à partir de technologies open source, certains ajustements effectués par les fournisseurs peuvent complexifier la portabilité d’une charge de travail sur un autre cloud. Cet aspect est d’autant plus important à étudier si vous optez pour une stratégie multicloud.

5.   Rechercher la cohérence dans la plateforme de développement

Lorsque vous réarchitecturez des applications pour le cloud, la version de l’OS ou des outils middleware que vous sélectionnez influencera le comportement des applications – et influencera certainement vos pratiques de développement. Si vous ne sélectionnez pas les versions, il peut être difficile de maintenir des niveaux de version compatibles, ce qui peut entraîner des défaillances.

Le contrôle de version pour les composants partagés est particulièrement délicat. Si vous décomposez une application et prévoyez de réutiliser ces composants dans plusieurs applications, les versions des outils middleware seront dans ce cas clé. Cela impliquera d’avoir à mettre à jour davantage de composants que dans un environnement plus traditionnel.

Outre les problèmes de performance ou d’arrêt de service que cela peut engendrer, il faut anticiper les risques de cybersécurité. Si, dans la plupart des cas, les fournisseurs cloud assurent un meilleur niveau de service en la matière qu’une organisation responsable d’un centre de données, une application cloud peut toujours faire l’objet d’attaques. Ces attaques seront d’autant plus effectives si la gestion des composants et de leurs dépendances n’est pas maîtrisée.

Pour ces deux raisons, le renforcement de la chaîne logistique logicielle, la révision des pratiques de tests, la mise en place d’un SBOM, ainsi que l’automatisation d’une partie des vérifications de versions avant déploiement sont des chantiers à mener en parallèle d’une refonte des applications en cloud.