Choisissez votre stratégie parmi les « 7 R » pour réussir votre migration vers le Cloud

Lorsque vous lancez votre programme Cloud et vos premières vagues de migration, vous vous apprêtez implicitement à mettre à niveau les solutions autrefois développées et à définir des normes de développement pour les nouvelles solutions Cloud. C’est une étape inévitable de votre parcours, qui nécessite de trouver le juste équilibre entre l’efficacité de la migration à court terme et l’efficacité opérationnelle à long terme.

La méthode des « 7 R » est devenue une référence dans le Cloud pour déterminer la stratégie de gestion des changements architecturaux la plus adaptée à toute solution concernée par votre migration vers le Cloud. Bien qu’il existe des différences subtiles entre les fournisseurs de Cloud lorsqu’on étudie la conception cible d’une solution, s’agissant de votre planification et du lancement de tout processus de refonte, les choix d’architecture cible sont pour la plupart indépendants du Cloud.

La façon dont vous allez migrer ou concevoir votre application Cloud et son infrastructure affectera votre solution tout au long de son cycle de vie

En optant simplement pour la méthode « Lift and Shift » associée à deux des stratégies de la méthode « 7 R », à savoir « Rehost » et « Re-Platform », vous risquez de créer un dangereux précédent pour l’avenir de votre Cloud. Pourquoi ? Parce qu’implicitement, vous faites le choix de ne pas saisir aujourd’hui :

• des opportunités d’optimisation du Cloud auprès de votre fournisseur Cloud ;
• des opportunités d’apprentissage (et de déploiement d’outils) du Cloud en amont entre plusieurs équipes, qui seraient ainsi capables de prendre en charge vos futures optimisations Cloud (par exemple, des conceptions optimisées réutilisables).

Vous consacrez également de manière explicite les anciennes inefficacités de conception (par exemple, dans vos solutions, vos opérations, votre personnel et vos compétences). Pire encore, les mêmes inefficacités que vous avez pu autoriser sur site sont susceptibles d’être plus coûteuses une fois répliquées dans votre Cloud.

Si le Cloud offre de nombreux avantages en termes de coûts pour les solutions optimisées, il ne pardonne pas une conception inefficace résultant du choix d’une architecture cible et d’une stratégie « R » médiocres pour une solution donnée

Aujourd’hui, nombreuses sont les entreprises à regretter par la suite d’avoir eu recours à la méthode « Lift and Shift » dans le cadre d’une migration massive, en se demandant pourquoi elles n’obtiennent pas les réductions de coûts escomptées dans le Cloud.

Les choix de conception cible que vous faites au début de vos migrations se répercuteront à long terme sur la maturité et l’efficacité opérationnelle de vos solutions Cloud. Vous devez donc en priorité vous renseigner sur les meilleures pratiques d’optimisation du Cloud et les mettre en œuvre – y compris la méthode des « 7 R » – dès le début de votre parcours de migration. Si vous ne le faites pas, vous reporterez indéfiniment de nombreux avantages en termes d’optimisation et emprunterez une voie bien plus sinueuse, à la fois techniquement et en termes de compétences, pour arriver au bout de votre parcours de migration.

Ce qui nous amène aux stratégies « R » que vous pouvez appliquer dans votre migration, et à ce qu’elles impliquent pour votre solution, vos équipes et vos objectifs FinOps.  Voici un aperçu de chacune de ces stratégies (avec le détail de la planification dans le tableau ci-dessous) :

• Re-Platform (« Lift and Reshape ») – Il s’agit de déplacer une solution vers le Cloud (ou une nouvelle plateforme Cloud) en effectuant quelques modifications mineures pour obtenir une base de plateforme similaire (par exemple entre deux Clouds).
• Re-Architect – Il s’agit de reconcevoir ou de restructurer une solution au niveau de ses modules ou services pour tirer pleinement parti des services Cloud choisis.
• Re-Factor – Il s’agit de procéder à une refonte plus complète dans une optique d’optimisation du Cloud, pouvant consister notamment à apporter d’importantes modifications au code.
• Re-Host (« Lift and Shift ») – Il s’agit de déplacer une solution « telle quelle » vers le Cloud, ce qui revient à transférer l’infrastructure en tant que service (IaaS) de la configuration sur site vers le Cloud.
• Re-Purchase (« Drop and Shop ») – Il s’agit de s’éloigner de la conception actuelle pour aller vers une nouvelle solution dotée de fonctions et de fonctionnalités comparables (par exemple, une solution de type Software-as-a-Service).
• Rationalize – il s’agit de conserver la solution dans un premier temps, en prévoyant de la rationaliser grâce à d’autres options actuellement disponibles dans l’entreprise.
• Retain/Retire – Il s’agit de conserver la solution telle quelle, au même emplacement, et d’y revenir plus tard (par exemple pour la mise hors service).

La première question à laquelle vous devez répondre pour votre solution candidate à la migration est la suivante : dans quelle mesure est-elle adaptée au Cloud ? Si la réponse est « hautement adaptée », alors votre solution est déjà structurée pour des services Cloud de type Platform-as-a-Service (PaaS) efficaces, et n’a pas besoin d’une transplantation d’infrastructure (IaaS) dans le Cloud.

Une solution « hautement adaptée au Cloud » est généralement écrite dans un langage moderne, conçue par modules ou orientée services pour permettre l’intégration de nouveaux services, et les composants clés (par exemple, la base de données) peuvent utiliser d’autres options de « plug-in » (comme la DBaaS). Si la solution à migrer est « hautement adaptée au Cloud », vous disposez de plus de choix parmi les stratégies « R » pour définir une conception cible plus efficace. Mais si votre solution n’est pas adaptée au Cloud, elle aura besoin d’être « mise à niveau » sur le plan technique pour s’intégrer dans le Cloud. Il existe une troisième catégorie, « non applicable », pour les solutions qui sont vouées à être rationalisées ou abandonnées.

Une fois que vous avez identifié la catégorie à laquelle appartient votre solution candidate, vous devez réfléchir aux efforts et aux dépenses que vous serez prêt à consentir, en fonction des économies potentiellement réalisées. C’est à cette étape que vous allez choisir la stratégie « R » la plus pertinente pour l’architecture et la conception cibles de votre solution. Le graphique ci-dessus peut vous aider à déterminer précisément quelle stratégie « R » vous allez mettre en œuvre pour votre solution. À partir de cette stratégie, vous allez procéder à des analyses plus poussées (des analyses comparatives de rentabilité par exemple) pour définir la conception cible finale (qui peut d’ailleurs provenir d’un ensemble réutilisable de conceptions cibles approuvées et pré-optimisées, que vous devriez développer au fil du temps).

Vous l’aurez compris, les décisions stratégiques en matière d’architecture et d’ingénierie prises dès la première étape de conception cible pour le Cloud ont des effets durables en termes de rentabilité et de performance, qu’ils soient positifs ou négatifs. C’est la raison pour laquelle la plupart des approches « Lift and Shift » disparaissent, à juste titre.

Compte tenu des coûts élevés généralement associés à la configuration, l’exécution et la mise à l’échelle, qui peuvent croître plus rapidement dans le Cloud que dans les infrastructures traditionnelles sur site, il est essentiel que votre entreprise mette en place et développe des capacités, des processus et des compétences d’optimisation lors des étapes de planification, de conception, de migration/développement et d’exploitation de vos solutions Cloud.

Une stratégie d’optimisation du Cloud doit être appliquée à toutes les étapes du cycle de vie du développement logiciel (SDLC)

Une stratégie Cloud bien conçue intègre une approche et un processus d’optimisation, qui prennent en compte les besoins de plusieurs parties prenantes et sont mis en œuvre dès l’étape d’élaboration du plan de migration de la solution candidate (et de sa conception cible, définie selon la stratégie « R » retenue).

Une stratégie Cloud doit être proactive et s’inscrire dans une démarche d’optimisation, ou bien elle est incomplète. C’est malheureusement le cas de la plupart des migrations massives qui suivent la méthode « Lift and Shift »

Pour une adoption et un déploiement réussis du Cloud, toute stratégie Cloud efficace doit comprendre une phase initiale (pendant la migration) et un processus continu d’optimisation des performances et des avantages en termes de coûts. Cette démarche favorisera l’adoption et renforcera les effets de l’optimisation, à mesure que les parties prenantes en percevront les bénéfices.

Au-delà de votre SDLC, dans lequel les étapes de migration (ou de développement) se déroulent juste après les étapes de planification et de conception, vos équipes CloudOps voudront faire l’expérience de l’agilité opérationnelle, de l’efficacité et de la transparence procurées par les nouveaux services et outils Cloud dans leurs activités régulières. Et vos équipes Finance/FinOps, qui font partie des parties prenantes du Cloud, voudront régulièrement constater des économies de coûts comme promis par la stratégie Cloud.

Si vous ne consentez aucun effort d’optimisation dès la phase de migration, vous n’obtiendrez pas les économies ou les gains d’efficacité attendus. À l’inverse, plus tôt vous intégrerez une approche d’optimisation dans vos solutions, de préférence dès leur mise en œuvre, meilleures seront vos chances de profiter de ces avantages et de les maximiser. Si vous pensez que vous pourrez y remédier plus tard, ce que beaucoup ont essayé de faire, votre stratégie Cloud échouera probablement, tant dans sa perception que dans la réalité.