Comment optimiser sa migration vers le cloud ?

Tout d’abord, commençons pat féliciter ces intervenants, car ils sont venus voir par eux-mêmes ce qu’est le Cloud”, en vrai, sur un salon pro. C’est vraiment utile pour nouer le dialogue et se confronter à ce qui se fait, commencer ou approfondir son acculturation. Tout commence par là. Ils avaient aussi eu le droit à quelques demos ou POC. Sur un salon, on peut assister à d’autres démos, découvrir des uses cases auquel on ne pense pas, des Retex, mais aussi découvrir les offres de financement des Cloud Providers permettant de réduire le TCO (Total Cost of Ownership).

L’indicateur TCO, dont la méthode de calcul n’est pas universelle, comptabilise l’ensemble des coûts directs et induits par la plateforme cible.

Dans le cadre d’une migration, il faut prendre en compte l’ensemble des études réalisées an amont ainsi que le coût de la migration proprement dite. Il ne s’agit pas que du coût de run. La prise en charge d’une partie de ce coût par le Cloud Provider permet cependant d’en limiter l’impact.    

Si on veut optimiser sa migration vers le Cloud, une des étapes principales, passe par l’acculturation et la formation. Comprendre la migration vers le Cloud c’est avant tout apprendre à reconnaitre ce qui a un intérêt à être migré et ce qui n’a aucun intérêt à l’être. Il est donc crucial de savoir ce en quoi une infra Cloud est similaire à une infra On Premise, et ce en quoi elle diffère, tout autant qu’il est primordial de déterminer ce qui est assimilable à de l’OPEX dans son SI ou ses produits. In fine, dans la très grande majorité des cas, l’infrastructure finale sera une Infrastructure Hybride.

L’optimisation passe par cet investissement culturel et il sera largement compensé par la suite. En général, passer dans le Cloud c’est raisonner Opex et plus exclusivement Capex. Cette approche basée sur l’optimisation de l’usage a un impact environnemental et peut entrer dans une démarche de Green IT. Cette démarche est d’ailleurs mise en avant par les Cloud Providers.

Une ou plusieurs personnes doivent porter le projet de migration, évangéliser, convaincre comme tout projet de transformation.

D’un point de vue technique, au départ, la migration vers le Cloud peut être vue comme une extension de son infra vers un autre Data center. C’est un bon début pour optimiser sa migration dans le Cloud : faire des parallèles avec ce que l’on sait déjà faire et estimer ce qu’il reste à acquérir pour faire ou faire faire. En effet, certaines problématiques seront similaires : il faut accepter d’avoir recours à des interconnexions et de prévoir un coût d’échange de données entre l’infra On Premise et l’infra dans le Cloud : un coût pour le transfert du storage et du compute pour la migration proprement dite, puis le coût d’échange de données de production après la migration. Ce coût de trafic est intégré au TCO.

Entre ces deux modes de fonctionnement, il y aura une phase hybride dans laquelle une partie de l’infra (de plus en plus petite) sera toujours On Premise. Il en sera de même pour l’acquisition et l’exploitation de tous les services. Il peut même y avoir des situations où, temporairement, la migration requiert la possession de la même ressource à la fois on Premise et dans le Cloud (cas d’une base de données ou d’application soumise à licence). Cela a alors encore un impact sur le TCO. Réduire ces couts dupliqués peut vouloir signifier la fermeture temporaire de services ou d’accès à des applications. L’optimisation doit alors prendre en compte des impacts bien au-delà du Cloud. 

Partant de cette observation, on se rend rapidement compte qu’il convient de planifier la migration, l’ordonnancer et l’étudier. On ne migre pas une base de données comme un serveur web, un ERP comme une application de Marketplace.

Commençons par un audit : qui et quoi inclure ? Comment identifier les impacts ?

La réponse est résumée en 3 lettres : CAF (Cloud Adoption Framework). Il s’agit de guides à suivre et d’étapes à respecter pour réussir sa migration vers le Cloud. Il en existe plusieurs ; les Cloud Providers en proposent souvent un seul, le leur.

Une migration se découpe schématiquement en quatre grandes phases « Think », « Build », « Migrate », « Run ». Elle est déclinée sous d’autres dénominations par chaque Cloud Provider. Par exemple, AWS parle de « Assess », « Mobilize », « Migrate », « Run ». Les frontières entre les 2 premières phases ne sont pas forcément strictes entre les CAFs, mais globalement ils suivent les mêmes chemins et valident les mêmes étapes.  

Ils respectent donc tous globalement les mêmes étapes, qui ne sont d’ailleurs pas que techniques. Il est certes possible de ne pas suivre ces phases mais la démarche est alors plus bien plus risquée. Pour optimiser sa migration dans le Cloud, il est préférable de s’approprier le modèle CAF, c’est-à-dire l’adapter à ses besoins réels. Mais comment procéder ?

• Pourquoi ne pas demander conseil à ceux dont c’est le métier ?
• Pourquoi ne pas essayer d’appliquer ou de faire appliquer cette démarche CAF sur une partie limitée et non risquée de l’infra ?

Optimiser sa migration vers le Cloud, c’est prendre le temps d’investir en amont – phase « Think » – et de procéder à des études qui permettent de répondre, globalement, à 3 questions.

• Est-ce que je suis prêt à migrer ? (Migration Readiness Assessment)
• Qu’est-ce qui est « migrable » dans le Cloud ? (Cloud Readiness Assemment)
• Comment (avec quels outils) est-ce que je vais migrer vers le Cloud (Outils d’Assessment, Infra As Code, Devops, Gestion de configuration, Patch management, ITSM) ?

Ces trois questions font partie de la phase “Think” ou “Assess” selon les types de CAF.

Think

“Think” ou “Assess” ne veulent donc pas simplement dire qu’on parle technique, il est aussi important de prendre en compte d’autres critères, comme l’adoption de la migration vers le Cloud par tous les métiers et acteurs de l’entreprise : mesurer l’impact sur le business, la gouvernance, les équipes qui vont utiliser des ressources désormais hébergées dans le Cloud. Les ressources seront, dans l’idéal, mises à disposition à la demande et facturées également à la demande par les utilisateurs.

Optimiser sa migration dans le Cloud, c’est aussi faire en sorte que l’ensemble des utilisateurs soient responsabilisés et sensibilisés à la frugalité en termes de consommation de ressources Cloud. L’optimisation ne s’arrêtera pas non plus avec la fin de la migration, elle devra se poursuivre avec l’adoption de démarches FinOps, à savoir auditer les usages, les coûts et rationaliser les usages, et ce, de façon régulière. Être économe dans la conception et la réalisation de la migration vers le Cloud n’est pas une fin en soi et n’a d’intérêt que si cela s’inscrit dans une démarche d’amélioration continue. Néanmoins, la démarche Finops peut être externalisée. Son coût est prévisible, mais n’est pas nul. Il peut lui aussi être optimisé.

L’ensemble de ces études doit permettre d’établir une cartographie de l’existant et de déterminer un périmètre de parc et/ou services à migrer. Pour y parvenir, il sera nécessaire de réaliser des workshops avec les différentes parties prenantes, afin d’identifier les particularités, passer en revue l’architecture existante, ses limites et ses atouts. Des outils de collecte de donnée (fournis par les Cloud Providers) sur le parc permettront d’aider au dimensionnement des ressources cibles. Cependant, disposer d’un historique significatif des métriques de monitoring du parc peuvent suffire à collecter les mêmes informations et peut représenter un gain de temps non négligeable pour réaliser le flavouring (qui sera réalisé en début de la phase « Build »)

Les grandes lignes de l’architecture cible et ses prérequis des services cibles peuvent alors être définis (interconnexion VPN/liaison privée, IaaS/Paas, SLA, RPO/RTO…). À ce stade, on n’est pas forcément lié avec un choix de Cloud Provider. C’est ce qui va permettre, dans la phase suivante, d’optimiser les coûts en rendant possible la comparaison des offres. Il convient de noter que des contraintes juridiques ou organisationnelles peuvent conduire au choix d’un Cloud Souverain. Dans ce cas, l’optimisation sera plus limitée.

On peut disposer, à ce stade, d’un « High Level Design », qui résume les besoins globaux à couvrir et les services à remplir par la zone cible, à savoir l’iso-fonctionnalité avec l’infra originelle dans la plupart des cas.

Build

Une fois cette démarche théorique « Think » fixée, place à la phase “Build”. De la même façon que l’on a pris conscience qu’un serveur web ne se migra pas comme une base de données, on applique cette prise de conscience à toutes les ressources à migrer. C’est le but de la phase « Build » : déterminer plus finement les besoins, dimensionner les ressources, connaître l’étendue réelle de l’infrastructure à migrer, découper l’infrastructure en “business cases”, “domaines applicatifs”… Cela permet de fixer des priorités, identifier des risques et les traiter avec les mêmes méthodes que tout autre projet. Cela permet aussi d’affiner le TCO, surtout pour les coûts de run.

Cette étape est aussi le moment de réfléchir au niveau d’optimisation vers lequel on veut pousser la migration.

En effet, migrer est aussi le moment propice pour réfléchir à la transformation du SI et/ou des applications. Cela n’est pas indispensable, mais recommandé. On peut appliquer la démarche des « 5R de Gartner » pour définir sa stratégie, machine par machine, service par service, application par application (Rehost / Refactor / Replatform / Rebuild / Replace).

Sans passer forcément par cette phase des 5R, réaliser du « right sizing » des ressources permet déjà d’agir sur le TCO : on peut identifier des ressources surdimensionnées et les adapter sur l’architecture cible cible  

On identifiera aussi des patterns de migration, c’est-à-dire lier les bonnes pratiques de chaque cas, ses limitations, ses impacts et décider la stratégie au plus proche de ces bonnes pratiques. Il peut y avoir plusieurs patterns possibles pour un usage/une configuration applicative. Par stratégie, on peut par exemple définir si les VM Windows seront migrés sur des cibles dont la licence est ou non payée à l’usage.

De la même façon que l’on apprend en marchant, migrer des parties de l’infra bien identifiées, avec prudence, permet d’acquérir les meilleures practices et l’expérience qui permet ensuite d’aller plus vite et plus loin. Comme très souvent, le “big bang” n’est pas la façon optimale de réussir. On peut ainsi s’autoriser à changer de pattern de migration et en choisir un autre mieux qui s’avère mieux adapté.

Appliquer la démarche « 5R », c’est se donner l’occasion de planifier l’optimisation : avant, pendant et après la migration, car l’optimisation fait partie de la migration, et elle continuera après.

En fonction du coût annoncé par un Cloud Provider pour chaque pattern, on pourra, après cette étude, choisir le Cloud Provider qui répond le mieux à son besoin. L’optimisation, c’est aussi cela : choisir le fournisseur le mieux adapté à la bonne cible.

Le budget de migration peut s’avérer élevé. En effet, la bande passante disponible pour migrer les données peut avoir un impact significatif sur le coût de transfert, la durée de transfert et les contraintes de sécurité liées au transfert des données. On peut choisir d’intervenir en dehors des heures ouvrées ou de migrer les données “par la route”, via des services spécialisés. Des coûts et des contraintes existent. Ils doivent être prise en compte et statués avant la migration afin d’éviter de s’en rendre compte le jour de la migration.

Optimiser sa migration dans le Cloud dans la phase “Build”, c’est aussi identifier concrètement la manière dont on va appliquer le SMSI et commencer par mettre en place toutes les ressources nécessaires dans le Cloud avant de commencer à migrer. On peut appliquer une stratégie de modèle de sécurité Zero Trust Cloud. Il s’agit de définir sa topologie réseau, définir l’ensemble des services prérequis pour sécuriser et déployer une « zone » cible qui permettra de faire « atterrir les VMs et services à migrer. On parle alors de Landing Zone. Plusieurs modèles existent. Azure les appelle « BluePrints ». Les Cloud Providers ont chacun le leur, mais, globalement, ils répondent aux mêmes problématiques. Cette partie du « Build » permet la réalisation d’un dossier « Low Level Design ».

Avant de migrer quoi que ce soit, il est aussi primordial de déployer l’outillage nécessaire au monitoring des ressources, de former (ou recruter) les personnes qui seront chargées d’intervenir en run et de formaliser au plus juste les process d’intervention, et ce, afin de continuer à fournir un niveau de qualité de service suffisant.

Au terme de cette phase de « Build », la Landing zone est déployée ainsi que tous ses services, via les outils définis (par exemple Terraform et Ansible pour l’infra as Code) et la méthode de déploiement (CI/CD).  

Ces deux phases ont consisté majoritairement à investir, ce qui, a priori, peut apparaître contraire à l’idée d’optimisation. Ce qu’il faut retenir, c’est qu’il est nécessaire de commencer par investir et planifier pour avoir un impact majeur, mesurable dans le temps, quantifiable et argumentable sur l’optimisation des coûts (financiers, temporels et humains) d’une migration vers le Cloud.

Pendant ces 2 phases « Think » et « Build », il aura aussi été possible de réfléchir à l’outillage à mettre en place après la migration et éventuellement aux changements envisagés pour faire évoluer l’existant. On peut migrer sans être complétement au maximum de l’optimisation financière. Il est parfois opportun d’attendre l’évolution des usages, une fois la migration réalisée, pour mieux identifier les axes d’optimisation.

Le déploiement des ressources nécessaires, comme vu précédemment, peut être réalisé à l’aide d’Infra As Code, ce qui implique un autre investissement dans ce domaine. Ce type de déploiement est fortement recommandé. Cependant, il a un coût non négligeable.

De même, la réalisation de runbooks, qui décrivent les prérequis à remplir pour pouvoir migrer une ressource, ainsi que les états qui permettent de valider le bon fonctionnement après déploiement, est un passage indispensable, tout comme cela l’était déjà lors d’une migration hors Cloud. Cependant, ils représentent aussi un coût.

Migrate

Enfin vient la phase « Migrate » où débute la migration à proprement parler. Une fois que tout est clarifié, calculé et adapté à la réalité et des besoins, il est possible de dérouler le plan du projet. Si tout est bien décrit et documenté conformément dans les étapes « Think » et « Build », il est possible de sous-traiter une partie « technique » de la migration, surtout si le volume est important. Pour en estimer le coût, on peut se servir d’abaques pour évaluer le coût de migration. Plus le volume de ressources à migrer est important, plus on va se rapprocher de quelque chose de fiable – à considérer que le fait de migrer une ressource représente plusieurs mois du coût du run de cette ressource. Plus on aura investi sur la compréhension et la description du périmètre à migrer, plus on pourra affiner ce coût et réduire son risque.

La migration en tant que telle est alors essentiellement technique. Il y a peu d’optimisation à rechercher pendant cette phase.

Une fois que l’infra est migrée, lot après lot, une démarche d’amélioration continue permet de maintenir l’effort d’optimisation, notamment, en appliquant la démarche « 5R Gartner ». On va alors chercher à utiliser des service Cloud managés (Azure parle de PaaS), comme la containerisation d’application (CaaS), le recours à des bases de données managées (DBaaS), puis évoluer, quand c’est possible, vers des services Serverless (Function as a Service, Database Serverless). L’optimisation est un process continu, tant sur le plan technique, qu’organisationnel et humain. Aller vers des services PaaS ou Serverless permet de ne plus être responsable des actions de run automatisables ou peu valorisantes, mais les transférer au Cloud Provider.

Enfin une fois que l’on a réussi sa migration vers “le Cloud”, en réalité, sa migration vers “1 Cloud Provider”, optimiser signifie aussi que l’on se réserve le droit de recourir à un second Cloud Provider et de migrer de Cloud Provider à Cloud Provider.

Ce que l’on peut retenir

Migrer vers le Cloud est un processus complexe qui requiert de mobiliser des ressources financières, techniques et humaines. Un investissement conséquent est requis pour pouvoir optimiser son cheminement vers la réussite. Le changement induit doit être accompagné et conduit avec méthode, aussi bien sur le plan financier, technique, qu’humain.