Cloud Migration Research 1

Se préparer à adopter le cloud : les 10 étapes pour migrer une application vers le cloud

Mis à jours 20 mars 2022 Impliqués dans le cloud computing depuis plus de 10 ans, de nombreux responsables informatiques ont travaillé pour transférer un grand nombre d’applications d’entreprise vers le cloud public. Plusieurs fois, ces équipes ont connu beaucoup de difficultés ou n’ont parvenu qu’à un succès limité dans leurs migrations vers le cloud. Cependant, ils n’ont jamais baissé leurs bras et ils ont pris des leçons dans le but d’améliorer leurs résultats lors de prochaines tentatives.

Si votre entreprise cherche à moderniser ses applications stratégiques et que vous voulez les migrer vers le cloud dans le cadre de ce processus, alors, vous ne souhaitez certainement pas répéter les mêmes erreurs que les autres. Cet article propose un checklist en 10 étapes des principaux domaines à prendre en compte et à traiter pour optimiser vos chances de réussir la migration vers le cloud.

Le checklist comprend :

  1. Établir le rôle d’architecte de migration
  2. Choisir votre niveau d’intégration au cloud
  3. Choisir un seul cloud ou optez pour le multi-cloud
  4. Établir des indicateurs de performance clés pour la migration vers le cloud
  5. Établir des critères de base de performance
  6. Prioriser les composants de la migration
  7. Effectuer toute refactorisation nécessaire
  8. Créer un plan de migration des données
  9. Basculer sur la production
  10. Examiner l’allocation des ressources de l’application

Étape 1 : Établir le rôle d’architecte de migration

1

Avant de commencer à migrer vers le cloud, il faut définir le rôle d’architecte de la migration pour diriger l’effort. L’architecte de migration est un poste d’architecte de systèmes d’information. Il est en charge de la planification et de la réalisation de tous les aspects de la migration.

Leur responsabilité principale devrait inclure la définition du refactoring nécessaire pour réussir la migration, la conception de stratégies de migration des données, la définition des exigences en termes de solution cloud et la détermination des priorités de migration et des mécanismes de basculement de la production.

Au cours d’un projet de migration de grande envergure, de nombreuses décisions et des plans techniques doivent être pris et faits, et la présence d’un architecte de la migration responsable de tous les aspects de la migration est essentielle pour réussir le projet.

Étape 2 : Choisir votre niveau d’intégration au cloud

2

Lorsque vous déplacez une application d’un centre de données sur site vers le cloud, il y a deux manières de migrer votre application :

  • une intégration cloud peu profonde
  • ou une intégration cloud profonde.

Pour une intégration cloud peu profonde (parfois appelée “lift-and-shift”), vous déplacez l’application sur site vers le cloud et n’apportez aucune modification – ou limitez les modifications – aux serveurs que vous instanciez dans le cloud afin d’exécuter l’application.

Toutes les modifications apportées à l’application doivent suffire à la faire fonctionner dans le nouvel environnement. Vous n’utilisez pas de services uniques au cloud. Ce modèle est également appelé « lift-and-shift », car l’application est levée « telle quelle est » et déplacée ou transférée vers le cloud.

Pour une intégration cloud profonde, vous modifiez votre application pendant le processus de migration pour tirer parti des principales fonctionnalités du cloud. Cela pourrait être moins compliqué que d’utiliser la mise à l’échelle automatique et l’équilibrage dynamique de la charge, ou être aussi sophistiqué que d’utiliser les fonctionnalités informatiques sans serveur, telles que AWS Lambda, pour les grandes parties de l’application. Cela peut également impliquer l’utilisation d’un magasin de données spécifique au cloud tel que Amazon S3 ou DynamoDB.

Étape 3 : Choisir un seul cloud ou opter pour le multi-cloud

3

Avant de commencer à migrer vers le cloud, répondez à la question suivante : Voulez-vous choisir un seul hébergeur cloud et migrer votre application afin qu’elle puisse s’exécuter de manière optimisée pour cet environnement unique ou souhaitez-vous que votre application s’exécute sur plusieurs fournisseurs cloud ?

Choix d’un seul hébergeur Cloud

Optimiser votre application pour travailler avec un hébergeur cloud spécifique est relativement simple. Les équipes de développement n’ont qu’un seul ensemble d’API cloud à apprendre. Puis, votre application peut tirer parti de tout ce que le fournisseur cloud vous propose.

L’inconvénient de ce modèle

L’inconvénient de cette approche est le verrouillage du fournisseur. Une fois que vous avez mis à jour votre application pour fonctionner avec ce seul fournisseur, transférer cette application vers un autre hébergeur cloud peut demander autant d’efforts que la migration vers le cloud ordinaire.

De plus, avoir un seul fournisseur cloud peut causer un impact négatif sur votre capacité à négocier des conditions importantes, telles que la tarification et les contrats de niveau de service, avec le fournisseur cloud.

Mais attendez, ça va devenir encore plus compliqué. Il existe plusieurs modèles d’utilisation de plusieurs hébergeurs cloud :

Une application dans un cloud; puis une autre application dans un cloud différent

L’approche multi-cloud la plus simple consiste peut-être à exécuter un ensemble d’applications chez un hébergeur cloud et un autre dans un autre. Cette approche vous permet de tirer davantage parti de votre activité auprès de plusieurs fournisseurs, tout en vous offrant une grande flexibilité quant à l’emplacement futur des applications.

Cela vous permet également d’optimiser chaque application pour le fournisseur sur lequel elle s’exécute.

Répartir votre application sur plusieurs fournisseurs cloud :

Certaines entreprises choisissent d’exécuter des parties d’une application dans un fournisseur cloud et d’autres parties dans un autre. Cette approche vous permet de profiter des principaux avantages offerts par chaque fournisseur (par exemple, un fournisseur peut disposer de meilleures capacités d’intelligence artificielle tandis qu’un autre a de meilleures vitesses de base de données).

Le risque est que votre application soit liée aux performances des deux fournisseurs, et tout problème avec l’un ou l’autre des fournisseurs pourrait provoquer une incidence sur l’expérience utilisateur de votre application.

Construire votre application pour qu’elle soit cloud-agnostique :

Certaines entreprises construisent leurs applications pour s’exécuter sur n’importe quel fournisseur cloud. Avec cette approche, vous pouvez exécuter votre application simultanément sur plusieurs fournisseurs ou répartir la charge de vos applications entre eux. Ce modèle vous permet d’avoir une meilleure flexibilité dans les négociations avec les fournisseurs, car vous pouvez facilement transférer des charges d’un fournisseur cloud à un autre.

L’inconvénient est qu’il est peut être difficile d’utiliser les principales fonctionnalités de chaque fournisseur cloud, ce qui ne vous permet pas de tirer parti de tous les avantages de l’hébergement de votre application dans le cloud. Cette approche peut également compliquer vos processus de développement d’application et de validation.

Étape n°4 : Établir des indicateurs de performance clés pour la migration vers le cloud

4

Les indicateurs de performance clés ou KPIs sont des indicateurs que vous établissez à partir de votre application ou votre service pour évaluer ses performances par rapport à vos attentes. Vous avez peut-être déjà défini des indicateurs de performance clés pour vos applications et services, mais est-ce toujours les bons indicateurs si votre application ou service est maintenant hébergé dans le cloud ?

Les meilleurs indicateurs de performance clés pour une migration vers le cloud devraient montrer les progrès de votre migration en cours puis soulignent les problèmes visibles ou invisibles qui peuvent se cacher au sein de votre application. P

lus important peut-être, les indicateurs de performance clés pour une migration vers le cloud peuvent vous aider à déterminer à quel moment la migration est terminée et réussie.

Il existe plusieurs catégories fondamentales de KPI pour la migration vers le cloud. Voici quelques exemples :

  • Expérience utilisateur: Temps de chargement des pages, Décalage, Temps de réponse, Durée de la session
  • Performance de l’application/de composants: Taux d’erreur, Débit, Disponibilité, Apdex ou Application Performance Index
  • Infrastructure : Utilisation du processeur (%), Performance du disque, Utilisation de la mémoire, Débit du réseau
  • Engagement des entreprises: Ajoutés au panier, Conversions et % de conversions, Taux d’engagement

Pour chaque catégorie, déterminez les métriques les plus importantes pour votre entreprise et celles qui seront les plus impactées par la migration vers le cloud.

Lisez les conseils de New Relic sur la planification de votre migration vers le cloud pour obtenir des conseils sur l’identification des métriques afin de définir vos indicateurs de performance clés.

Étape n°5 : Établir des critères de base de performance

5

Le baselining ou établissement des critères de base est le processus de mesure des performances actuelles (avant migration) de votre application ou service afin de déterminer si ses futures performances (après migration) sont acceptables.

Ces critères de base vous aident à déterminer la fin de votre migration et à valider les améliorations de performances que vous espériez obtenir après la migration. Vous pouvez également vous référer à ces critères de base pendant la migration vers le cloud pour diagnostiquer les éventuels problèmes.

Déterminez les durées

Définissez une métrique de base pour chaque indicateur de performance clé que vous avez décidé de mesurer. Déterminez pendant combien de temps vous allez collecter les données, pour déterminer le critère de base. Mettre une courte période comme référence (un jour, par exemple) vous permet de progresser plus rapidement, mais vous risquez de ne pas collecter un bon exemple de performance. Choisir une période de référence plus longue (un mois, par exemple) prend évidemment plus de temps, mais peut fournir des données plus fiables.

La collecte des données

Il faut également déterminer si vous souhaitez collecter uniquement des données de base moyennement fiables ou seulement représentatives, ou que vous souhaitiez inclure des données collectées pendant les périodes « critiques » ou « de pointe ». Par exemple, si vous êtes un site d’actualités, souhaitez-vous collecter des données pendant une journée ayant connu un niveau d’actualités très élevé ou souhaitez-vous éviter ce jour ?

Quel que soit le modèle de collecte de données adapté à votre secteur, il faut définir clairement le type de données que vous allez collecter et pendant quelle période.

Pour en savoir plus sur l’utilisation de New Relic pour créer des critères de base de votre application pour sa migration vers le cloud, lisez les tutoriels de New Relic sur comment planifier votre migration vers le cloud.

Étape n°6 : Prioriser les composants de la migration

6

Vous devez également décider si vous voulez migrer l’intégralité de votre application en une seule fois ou que vous voulez la migrer par composant vers le composant cloud ou de service vers service.

Tout d’abord, identifiez les connexions entre vos services, et quels services dépendent de quels autres services. Pour les applications plus grandes et plus complexes, utilisez une application de surveillance telle que New Relic APM, qui peut utiliser des services de mappages pour générer des diagrammes de dépendance.

Utilisez le diagramme de dépendance pour décider quels composants doivent être migrés et dans quel ordre. Il est souvent logique de commencer par les services qui ont le moins de dépendances. Dans ce cas, vous migrez d’abord vos services les plus internes, puis vous continuez avec vos services les plus externes, généralement ce sont ceux qui concernent le plus vos clients.

L’approche alternative consiste à commencer par les services qui concernent le plus vos clients – les services les plus externes – afin que vous puissiez mieux contrôler tout impact sur vos clients.

Les tutoriels de New Relic sur comment planifier votre migration vers le cloud offrent des conseils sur l’utilisation de New Relic pour hiérarchiser vos composants de migration.

Étape n°7 : Effectuer toute refactorisation nécessaire

8

Vous devriez peut-être faire quelque chose avec vos applications et services avant de les migrer afin qu’ils fonctionnent aussi efficacement que possible dans le cloud. Par exemple, vous devriez peut-être refactoriser votre application :

  • Ainsi, elle va fonctionner efficacement avec un nombre variable d’instances en cours d’exécution pour permettre une mise à l’échelle dynamique, ce qui peut vous faire économiser de l’argent sur les coûts des services cloud.
  • Ainsi, l’utilisation de vos ressources peut mieux tirer parti des fonctionnalités de cloud dynamique, telles que la possibilité d’allouer et de désallouer des ressources de manière dynamique, en fonction des besoins, plutôt que de les allouer statiquement à l’avance.
  • Pour passer à une architecture axée davantage sur les services avant la migration, afin de pouvoir déplacer plus facilement des services individuels vers le cloud.

Étape n°8 : Créer un plan de migration des données

7

La migration des données est l’un des aspects les plus délicats d’une migration vers le cloud. L’emplacement de vos données peut avoir un impact significatif sur les performances de votre application.

Migrer vos données vers le cloud alors que les méthodes d’accès aux données sont encore principalement sur site peut avoir un impact significatif sur les performances. Il en va de même si les données sont encore sur site, alors que le service pour y accéder est déjà dans le cloud.

Les options pour la migration des données comprennent :

  • L’utilisation d’un mécanisme de synchronisation bidirectionnelle entre vos bases de données sur site et celles dans le cloud. Une fois que vous avez déplacé tous les consommateurs de données vers le cloud, supprimez la base de données sur site.
  • Utilisez une base de données sur site avec une synchronisation unidirectionnelle vers une base de données dans le cloud et permettez aux consommateurs de se connecter uniquement à la version sur site. Lorsque la migration est faite, désactivez l’accès à la version sur site afin que la version dans le cloud devienne la base de données principale et permettez aux consommateurs dans le cloud d’accéder à la nouvelle base de données.
  • Utilisez un service de migration des données vers le cloud, tel que ceux disponibles à partir d’Amazon Web Services et Microsoft Azure.

Ne sous-estimez pas la complexité et l’importance du plan de migration des données. Ne pas prêter une attention particulière à votre plan de migration des données avant de commencer une migration vers le cloud peut conduire à l’échec des migrations, ou du moins, vous aurez des résultats qui ne répondent pas à vos attentes.

Votre architecte de migration doit être très impliqué dans le processus de planification de la migration des données.

Étape n°9 : Basculer sur la production

9

Quand et comment basculer le système de production de l’ancienne solution sur site vers la nouvelle version cloud ? La réponse dépend de la complexité et de l’architecture de votre application, et en particulier de l’architecture de vos banques de données et de vos données.

Il y a deux approches communes :

  • Faire tout à la fois : Patientez jusqu’à ce que vous avez terminé de migrer l’intégralité de l’application ou du service vers le cloud et que vous avez validé qu’elle ou il fonctionne correctement, puis basculez le trafic de la pile sur site vers la pile dans le cloud.
  • Faire petit à petit : Déplacez seulement quelques clients, vérifiez si tout fonctionne bien, puis déplacez-en un peu plus. Continuez ce processus jusqu’à ce que tous vos clients soient déplacés vers l’application dans le cloud.

Étape n°10 : Examiner l’allocation des ressources de l’application

10

Même si vous avez tout migré vers le cloud, il reste encore quelques points à vérifier. Le plus important est l’optimisation des ressources. Le cloud est optimisé pour l’allocation dynamique des ressources. Lorsque vous allouez des ressources (par exemple, des serveurs) de manière statique, vous ne tirez pas parti des atouts du cloud. Puisque vous avez migré vers le cloud, assurez-vous que vos équipes disposent d’un plan de répartition des ressources de votre application.

Si vous avez besoin d’allouer plus de ressources à une application dans le cloud, elles sont généralement disponibles auprès du fournisseur dans pratiquement la totalité des quantités que vous voulez et à tout moment. Cela signifie que vous pouvez de temps à autre compter sur le fait que vous pouvez mettre à l’échelle les ressources lorsque vous en avez besoin pour répondre à une demande très élevée, en supposant que vos équipes disposent de l’architecture des applications en place pour prendre en charge la mise à l’échelle dynamique.

Une dernière chose pour votre migration vers le cloud

11

Ce checklist couvre largement les différentes étapes de la migration vers le cloud, mais vous devez absolument prendre en compte d’autres éléments pendant la migration vers le cloud.

Créer et sécuriser un environnement cloud, par exemple, est évidemment un élément essentiel de toute migration vers le cloud. Heureusement, les principaux fournisseurs cloud offrent un outillage et des ressources considérables pour vous aider à créer et à maintenir votre système sécurisé.

En ce qui concerne les coûts du cloud, il existe deux règles de base concernant la tarification : le cloud est moins cher que la solution sur site et le cloud est plus cher que la solution sur site. Les deux peuvent être vrais ou faux, selon la situation.

Il est tout à fait possible de commencer à utiliser le cloud et de découvrir que votre facture d’infrastructure a en fait augmenté par rapport à ce que vous avez dépensé pour votre centre de données physique. Cela peut arriver pour plusieurs raisons :

Les coûts cachés

Premièrement, il existe des coûts cachés dans tous les systèmes d’infrastructure, et vous ne vous rendez peut-être pas compte de tous les coûts liés à l’exploitation de votre propre centre de données, tandis que la facture mensuelle que vous recevez de votre fournisseur cloud explique très clairement tous les coûts.

Le résultat ? Parfois, on finit par comparer des pommes à des oranges, ce qui donne l’impression que la solution de cloud computing est plus chère que celle utilisée sur site.

Les coûts des infrastructures

Deuxièmement, les coûts d’une infrastructure sur site sont principalement composés de dépenses en capital (CapEx), tandis qu’une infrastructure dans le cloud provient généralement de dépenses d’exploitation (OpEx). Selon la manière dont votre entreprise gère ses comptes, il peut être plus facile d’obtenir CapEx que OpEx, ou inversement.

Comprendre en quoi le coût des infrastructures dans le cloud diffère d’une infrastructure sur site et s’assurer que les modèles financiers de votre entreprise profitent de ces différences est essentiel pour reconnaître les améliorations des coûts liés au cloud.

Pour plus d’informations sur les coûts liés au cloud, consultez Comment calculer le coût d’une migration vers le cloud.

Enfin, je recommande à tous ceux qui envisagent de planifier une migration vers le cloud de se familiariser avec des sujets tels que la conception des applications modernes à partir de services et de microservices, en particulier les applications à douze facteurs, et d’utiliser les méthodes et procédures DevOps comme meilleures pratiques pour créer et exécuter des services et des applications dans le cloud.

Et surtout, n’oubliez pas d’optimiser votre expérience client une fois que vous avez entièrement migré vers le cloud.

Aina Strauss

À lire aussi

debian 11

Comment installer Docker Swarm sur Debian 11?

Mis à jours 7 novembre 2022 Docker Swarm est une orchestration de conteneurs qui est …