Comment préparer une migration de cloud à cloud

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Eh oui. C’est en train d’arriver. Envisagez de l’intégrer à votre stratégie cloud globale afin de rendre le processus moins pénible.

Quel est le point commun entre les éléments suivants ? Les saumons, les bernaches du Canada, les papillons monarques et les applications.

Si vous avez deviné que tous ces éléments migrent d’un endroit à un autre, vous pouvez vous féliciter.

En général, lorsque nous parlons de migration vers le cloud, il s’agit de passer d’une infrastructure sur site à une infrastructure hors site. Et ce n’est pas sans raison. De nombreuses données (y compris les nôtres) indiquent une hausse de l’adoption du cloud public. En revanche, nous ne parlons presque jamais de la migration en sens inverse. J’entends déjà les cris d’« Hérésie ! », mais soyons réalistes : cela arrive, et plus souvent qu’on ne pourrait le penser.

Par exemple :

42 % des personnes interrogées ayant adopté une IaaS publique en production ont indiqué qu’« elles avaient l’intention d’abandonner leur stratégie actuelle, soit au cours des quatre prochaines années, soit dans le cadre d’un processus continu ». Parmi elles, 70 % « prévoyaient de migrer vers un cloud hybride plutôt que d’opter exclusivement pour une solution de cloud privé ».

La raison ? Le facteur le plus souvent cité était la réduction des coûts (67 %), suivie de la sécurité et de la stabilité. Cela est corroboré par des témoignages comme celui-ci, sur la migration de Pubmatic d’un cloud public vers un cloud privé. Les coûts ont joué un rôle déterminant.

Mais d’autres migrent dans la direction opposée, comme nous l’avons tous beaucoup entendu dire. Parmi les utilisateurs d’une plateforme IaaS privée, 57 % « ont l’intention de migrer vers un cloud public ou hybride, 77 % d’entre eux indiquant qu’ils prévoient d’adopter une approche hybride. »

Leur motivation ? L’évolutivité (71 %), suivie de près par la flexibilité. Les coûts arrivent en troisième position, cités par 50 % des répondants.

L’évolutivité pousse les entreprises vers le cloud public, tandis que les coûts à long terme semblent les ramener vers un cloud privé.

En réalité, la plupart des organisations ne misent ni sur le « cloud public » ni exclusivement sur le « cloud privé ». Elles adoptent une stratégie multicloud, même après avoir transféré leurs applications dans un sens puis dans l’autre. Cette réalité est confirmée par l’analyse des tendances en matière de développement, comme celles présentées par Capgemini dans son rapport « Cloud Native Comes of Age » qui indique que « Aujourd’hui, un sixième (15 %) des nouvelles applications des entreprises interrogées sont développées dans un environnement cloud natif. »

Si 15 % des applications sont cloud-native, cela signifie que les 85 % restantes ne le sont pas. Cela inclut probablement les applications sur mainframe, les applications client-serveur et les applications web à trois niveaux. Sans oublier les microservices dans des environnements conteneurisés.

L’entreprise moderne n’est pas seulement multicloud : ses architectures applicatives couvrent également plusieurs générations.

Cela signifie qu’il est fort probable que vous migriez une application d’une infrastructure sur site (privée) vers une infrastructure hors site (publique), ou inversement, car ces applications sont plus nombreuses que les applications cloud natives. Il est donc important d’intégrer ce constat à votre stratégie cloud. En d’autres termes, vous devez déterminer en amont les mesures à prendre pour rendre ce processus, peut-être inévitable, moins pénible.

Se préparer à une migration d’un cloud à un autre

L’un des premiers éléments à prendre en compte est la durée de vie prévue de l’application que vous déplacez. Si elle est destinée à être utilisée à long terme, elle pourra faire l’objet d’une migration de cloud à cloud à l’avenir. Dans le cas contraire — parce qu’elle est liée à une promotion, à une campagne marketing ou à un événement — vous pouvez passer directement à la fin de cette liste et procéder au déploiement.

Maintenant que vous avez déterminé que l’application sera utilisée plus longtemps, vous devez réfléchir à la manière dont vous allez la faire évoluer et la sécuriser.

La réponse rapide (et facile), si l’application est cloud native, consiste à dire : « Nous utiliserons les services du fournisseur de cloud. » C’est une option valable, tout comme « Nous utiliserons ce que nous avons toujours utilisé » si l’application est destinée à être hébergée dans un cloud privé sur site. Toutefois, ces deux options comportent un risque potentiel important : vous pourriez ne pas être en mesure de migrer facilement les services et/ou les politiques d’un cloud à un autre par la suite. Il est temps d’examiner attentivement les solutions que vous utilisez actuellement pour assurer l’évolutivité et la sécurité, et de déterminer si ces services applicatifs peuvent migrer avec votre application, dans les deux sens.

Étant donné que les entreprises utilisent en moyenne 16 services applicatifs pour fournir et sécuriser leurs applications, il s’agit d’un domaine susceptible d’entraver considérablement votre capacité à prendre en charge les applications amenées à migrer, sans même parler de leur prise en charge dans un environnement multicloud. Notez que certains de ces 16 services devront être des services cloud natifs. En résumé, si vous considérez que votre chemin de données se compose de services applicatifs d’entreprise partagés et de services propres à chaque application, vous constaterez que cette séparation architecturale correspond étroitement à celle établie par les fournisseurs de cloud public au niveau de la couche d’infrastructure. Cette séparation n’est pas parfaite, mais elle offre une distinction logique permettant de déterminer quels services doivent être « multicloud » et pour lesquels vous pouvez vous appuyer sur des services cloud natifs ou des services de centre de données traditionnels.

Plus les services applicatifs que vous utilisez sont cohérents d’un cloud à l’autre, plus il est facile de migrer entre deux clouds (ou trois, quatre, voire davantage), car les contraintes sont moindres. Cette approche présente également l’avantage d’étendre les efforts d’automatisation au cloud public et d’épargner ainsi à l’entreprise, au moins, les coûts opérationnels liés au maintien d’équipes et de procédures d’exploitation distinctes.

Le cloud était inévitable. Le multicloud l’est tout autant. Ce qui signifie qu’à terme, des migrations auront lieu entre les différents clouds. Prêter attention aux dépendances et utiliser des services applicatifs interclouds avant de décider où déployer l’application peut rendre le processus moins pénible.

Intégrez au moins le principe d’une migration d’un cloud à un autre dans votre stratégie cloud globale. Une bonne préparation peut vous éviter par la suite une migration pénible (et coûteuse).

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie