Introduction
Selon une étude Gartner, les dépenses mondiales consacrées aux services de cloud public devraient atteindre 304,9 milliards de dollars en 2021, contre 257,5 milliards de dollars en 2020. D'ici 2024, plus de 45% des dépenses informatiques passeront de solutions traditionnelles vers le cloud.
Malgré des dépenses aussi importantes pour le cloud, une organisation sur trois ne réalise pas ses avantages. 33% des organisations n'ont constaté aucune ou une légère amélioration de leur efficacité après l'adoption du cloud, selon le rapport du baromètre Unisys Cloud Success. La migration vers le cloud est une affaire complexe et coûteuse. Alors, comment éviter l'échec d'un projet cloud ?
La réponse réside dans une planification appropriée et dans la sélection de la bonne stratégie de migration vers le cloud pour vos actifs informatiques. Effectivement, pour préparer à une migration vers le cloud, il est essentiel que votre équipe IT conserve une vue complète de tous les composants de l'infrastructure et des options disponibles pour migrer chaque charge de travail. Mieux vous comprenez avec quoi vous travaillez, plus la planification et l'exécution du projet deviennent faciles.
La migration de systèmes informatiques complexes doit se faire progressivement. L'inventaire de vos systèmes et applications en cours d'utilisation est la première étape du développement de votre plan de migration vers le cloud exploitable. Ensuite, vous devez identifier les types spécifiques de migration vers le cloud à effectuer avec chaque élément.
Cet article vise à vous donner une meilleure compréhension d'une stratégie de migration vers le cloud appropriée pour vous aider à créer un chemin de migration et à effectuer une transition vers le cloud. Commençons d'abord par comprendre la migration vers le cloud.
Qu'est -ce que la migration vers le cloud ?
La migration vers le cloud ne consiste pas seulement à migrer vers le cloud, il s'agit en effet d'un processus itératif d'optimisation pour réduire les coûts et atteindre le plein potentiel du cloud. Il a un impact sur tous les aspects organisationnels, y compris les personnes, les processus et les technologies. Mais avec des modèles de consommation et de tarification flexibles, le cloud peut prendre en charge une évolutivité, des performances, une agilité, un travail à distance et une rentabilité élevés.
Le parcours vers le cloud est différent pour chaque organisation, car il n'existe pas de plan de migration unique. Chaque actif informatique à migrer est unique en matière de coût, de performances et de complexité. Vous ne pouvez donc pas déplacer tous les composants vers le cloud avec une méthode commune. Faire une feuille de route pour la migration répondra aux questions de quoi, comment et dans quel ordre déplacer ces composants. C'est là que les stratégies de migration vers le cloud entrent en jeu.
Largement connues sous le nom de "6 R" de la migration cloud, ces stratégies répondent essentiellement à la question de savoir comment migrer vos actifs informatiques vers le cloud. Une explication de chaque stratégie avec des cas d'utilisation est donnée ci-dessous.
Les 6 R de la stratégie de migration vers le cloud
Les 6 stratégies de migration d'applications les plus courantes que nous voyons sont:
Rehosting (Réhébergement)
Le réhébergement, autrement connu sous le nom de "lift-and-shift" est l'une des stratégies de migration vers le cloud la plus rapide et la plus simple qui déplace les données sans modification au niveau du code.
Cela signifie que vous transférez les applications, les machines virtuelles et les systèmes d'exploitation de serveur de l'environnement d'hébergement actuel à l'infrastructure de cloud public sans aucun changement.
Il s'agit d'une méthode de migration à faible résistance qui peut être automatisée à l'aide d'outils tels que CloudEndure Migration et AWS VM Import/Export, mais vous pouvez également opter pour une implémentation manuelle pour gagner en maturité cloud.
En choisissant le lift-and-shift, vous devez savoir que son gain rapide présente un inconvénient qui est une utilisation limitée de l'efficacité du cloud. Le simple réhébergement d'une charge de travail d'application dans le cloud public n'utilise pas de fonctionnalités natives du cloud, telles qu'une automatisation CI/CD efficace, une mise à l'échelle automatique, des systèmes de surveillance avancés, une récupération et une autoréparation automatisées, etc...
Cependant, vous pourrez toujours réduire les efforts consacrés à l'administration du système et gagner du temps pour recentrer les technologues sur la résolution des problèmes commerciaux et l'optimisation des produits.
Ce type de migration vers le cloud peut également être un point de départ pour des projets d'optimisation à grande échelle lorsque les organisations cherchent à déplacer leur infrastructure sur site dans un court laps de temps. Par exemple, le bail de votre centre de données expire et vous avez besoin d'un réhébergement rapide de vos charges de travail actuelles. Une fois ces charges de travail dans le cloud, d'autres optimisations de la base de code sous-jacente seront plus faciles à réaliser.
Cas d'utilisation
Utilisez la stratégie rehost si vous êtes :
- Nouveau dans le cloud
- Migration d'applications standard
- Migrer avec une date limite
Replatforming (Restructuration)
Le réhébergement, autrement connu sous le nom de "lift-tinker-and-shift" ou "lift-and-optimize" est une stratégie qui vous permet d'apporter quelques modifications de configuration aux applications pour mieux s'adapter à l'environnement cloud sans changer leur architecture de base afin d'obtenir des avantages tangibles.
Le replatforming implique de modifier la façon dont les applications interagissent ensemble. Vous cherchez par exemple à réduire le temps que vous passez à gérer les instances de base de données en migrant vers une plateforme de base de données en tant que service comme Amazon RDS (Relational Database Service) ou Google CloudSQL.
En conséquence, vous pouvez tirer parti de plus d'avantages du cloud, remodeler l'environnement d'approvisionnement et le rendre compatible avec le cloud, affiner les fonctionnalités de l'application et éviter le travail de post-migration.
Avant de mettre en œuvre certaines améliorations du produit, il est important de garder à l'esprit que la base de code sous-jacente sera modifiée. Cela signifie que même des modifications insignifiantes nécessitent un nouveau test approfondi des performances de votre application. Une fois que vous avez mis en œuvre les ajustements et la mise à niveau planifiés, l'application peut être déplacée vers la plate-forme optimisée et les serveurs cloud.
La stratégie de re-plateforme se situe quelque part entre un simple lift-and-shift et une réarchitecture plus profonde de l'application. Ainsi, les modifications dans la base de code sont plus susceptibles d'être mineures et ne sont pas censées modifier les fonctionnalités de base de l'application.
Cas d'utilisation
Utilisez la stratégie Replatform si vous êtes :
- migrer avec un manque de temps
- tirer parti des avantages du cloud sans refactoriser l'application
- migrer une application sur site complexe avec des ajustements mineurs pour les avantages du cloud
Refactoring/Re-architecting (Refactoriser/Ré-architecturer)
Cette approche est motivée par un fort désir d'améliorer votre produit et représente le contraire de la migration lift-and-shift. Il est supposé qu'un objectif commercial spécifique sera défini dès le départ, par exemple en termes de disponibilité ou de fiabilité des performances de l'application. Parfois, cela signifie que vous devez repenser complètement la logique de votre application et développer la version cloud native à partir de zéro pour la rendre native au cloud.
En optant pour ce modèle de migration vers le cloud, vous devez tenir compte du fait qu'il peut nécessiter plus de ressources en raison de la complexité accrue de sa mise en œuvre. D'autre part, il permet d'exploiter pleinement les avantages du cloud natif, tels que la reprise après sinistre ou la conteneurisation de l'environnement applicatif.
Cette approche est aussi la plus coûteuse, la plus gourmande en ressources et la plus longue par rapport aux autres, mais elle s'avérera la plus intéressante à long terme. Certains autres défis auxquels vous pourriez être confronté peuvent être le manque de compétences en matière de cloud, la livraison de projets et de programmes complexes, ou une interruption d'activité potentiellement importante.
La clé est de hiérarchiser les petits morceaux de votre application monolithique en tant que microservices, puis de les refactoriser. Autorisez également les applications héritées à s'exécuter sur site pendant que vous reconstruisez dans le cloud pour éviter les interruptions.
Cas d'utilisation
Utilisez la stratégie refactor si vous êtes :
- L'application tirera le meilleur parti du cloud
- Il existe une forte volonté commerciale d'ajouter de l'évolutivité, de la vitesse et des performances
- Pour une application sur site non compatible avec le cloud
Repurchasing (Rachat)
Le rachat, également connu sous le nom de stratégie "drop and shop", remplace l'application sur site par un logiciel fourni par le fournisseur natif du cloud. Cela signifie, que dans cette stratégie, vous modifiez l'application propriétaire utilisée pour la nouvelle plate-forme ou le nouveau service basé sur le cloud.
Souvent, cela signifie que vous abandonnez le contrat de licence existant (ou qu'il expire) et optez pour une nouvelle plate-forme ou un nouveau service à sa place. Par exemple, vous pouvez choisir de passer de votre ancien système CRM à un nouveau CRM SaaS qui répond mieux aux exigences de votre organisation.
La nouvelle version cloud mise à niveau vous offre un meilleur rapport qualité-prix avec une efficacité accrue, des économies sur le stockage des applications et les coûts de maintenance. Cependant vous pourriez être confronté à certains obstacles qui peuvent apparaître lors du rachat qui sont la formation de votre personnel au nouveau logiciel ou au verrouillage du fournisseur. Les plates-formes SaaS offrent une personnalisation et un contrôle limités en comparaison. Vous pourriez donc ressentir de perdre une solution personnalisée sur site hautement adaptée.
Cas d'utilisation
Utilisez la stratégie rachat si vous êtes :
- Vous remplacez un logiciel pour des fonctions standard comme la finance, la comptabilité, le CRM, la GRH, l'ERP, la messagerie électronique, le CMS, etc.
- Une ancienne application n'est pas compatible avec le cloud
Retire (retirer)
Dans cette stratégie, vous vous débarrassez des applications qui ne sont plus nécessaires ou productives pour votre portefeuille informatique. En effet, pour de nombreuses applications et environnements complexes, certains composants de l'infrastructure peuvent être facilement désactivés sans aucune diminution de productivité ou perte de valeur pour les consommateurs finaux.
Ceci est réalisé en mettant hors service ou en archivant les pièces inutiles tout en remplaçant leurs fonctionnalités par d'autres services et composants. En conséquence, vous pouvez réduire considérablement la complexité de votre IT, de votre architecture, de votre stockage, de vos licences et de votre sauvegarde, ce qui rend votre infrastructure plus légère.
Bien que cela semble facile, la mise hors service des applications est un processus complexe et essentiel pour décider quelles applications retirer. Cela doit être fait dans les premières étapes de la planification afin que vous puissiez migrer des applications ou des services essentiels, réduire la portée des applications à migrer et économiser des ressources.
Cas d'utilisation
Utilisez la stratégie retire si vous êtes :
- Archivez les applications qui contiennent des données utiles.
- Supprimez les applications avec des capacités de duplication pour réduire les coûts.
- Retirez les applications dont les fonctionnalités peuvent être ajoutées à une autre via des microservices.
Retain (Retenir)
Dans cette stratégie également appelée "re-visite", consiste à revisiter certaines applications/parties critiques de vos actifs numériques qui nécessitent une refactorisation importante avant de les migrer vers le cloud.
En effet, certains composants de votre infrastructure informatique peuvent être conservés sur votre infrastructure existante. Une organisation peut souhaiter conserver certaines charges de travail et bases de données autonomes en raison de problèmes de sécurité, d'exigences de latence, de conformité ou de contraintes réglementaires, ou ce n'est tout simplement pas rentable.
Par exemple, vous devrez peut-être vous conformer aux exigences réglementaires régissant les emplacements dans lesquels certaines informations sont stockées. Lors de la catégorisation de la charge de travail pour ce type de migration, vous créez une infrastructure hybride dans laquelle certaines charges de travail sont hébergées dans le cloud et certaines charges de travail sont conservées sur site.
Cette stratégie est souvent utilisée dans le déploiement de cloud hybride par les organisations pour assurer la continuité des activités lors de migrations à grande échelle qui prennent plusieurs années.
Cas d'utilisation
Utilisez la stratégie retain si vous êtes :
- Vous adoptez un modèle de cloud hybride lors de la migration
- Une application héritée n'est pas compatible avec le cloud et fonctionne bien sur site
- Vous décidez de revisiter une application plus tard
Conclusion
Lorsque vous évaluez lequel des "6 R" convient aux besoins de migration de votre organisation, gardez à l'esprit que chaque migration vers le cloud est unique.
Les types de migration vers le cloud mentionnés ci-dessus ne sont pas des solutions toutes faites pour chaque organisation. Ces options doivent servir de base à l'élaboration de la stratégie finale, qui sera adaptée aux besoins spécifiques de votre entreprise. Pour développer une stratégie de migration réussie , il est recommandé d'examiner le processus de migration d'un point de vue centré sur l'application plutôt que sur l'infrastructure.
Bonne migration cloud à tous 💪😎☁️