Comment se préparer à la migration de Cloud à Cloud

Oh oui. Ça arrive. Envisagez d’en faire une partie de votre stratégie cloud globale pour rendre le processus moins pénible.

Qu'ont en commun les éléments suivants ? Saumon, oies canadiennes, papillons monarques et applications.

Si vous avez deviné que toutes ces choses migrent d’un endroit à un autre, félicitez-vous.

En général, lorsque nous parlons de migration vers le cloud, nous parlons de passer d'un environnement sur site à un environnement hors site. Avec raison. Il existe de nombreuses données ( y compris les nôtres ) qui indiquent une augmentation de l’adoption du cloud public. Ce dont on ne parle presque jamais, c’est la migration qui se produit 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 le pense.

Par exemple:

42 % des répondants ayant adopté une IaaS publique en production ont indiqué qu’ils avaient « l’intention de migrer de leur stratégie actuelle, soit dans les quatre prochaines années, soit dans le cadre d’un processus continu ». 70 % d’entre eux « prévoyaient de passer à un cloud hybride plutôt que de passer exclusivement à une solution de cloud privé ». 

La raison ? Le facteur le plus courant était la réduction des coûts (67 %), suivi de la sécurité et de la stabilité. C'est ce que confirment des histoires comme celle sur la migration de Pubmatic du cloud public vers le cloud privé . Les coûts ont été un facteur déterminant.

Mais d’autres migrent dans la direction opposée, comme nous l’avons tous entendu. Beaucoup. 57 % des utilisateurs d'une plateforme IaaS privée « ont l'intention de migrer vers un cloud public ou hybride, et 77 % des répondants indiquent qu'ils prévoient d'adopter une approche hybride ».

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

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

La réalité est que la plupart des organisations ne sont ni une entreprise de « cloud public » ni une entreprise de « cloud privé uniquement ». Ils sont multi-cloud , même après avoir déplacé des applications dans les deux sens. La réalité peut être prouvée en examinant les tendances de développement, comme celles rapportées par Cap Gemini dans son rapport « Cloud Native Comes of Age » qui note que « Un sixième (15 %) des nouvelles applications des entreprises interrogées sont aujourd'hui construites dans un environnement cloud natif. »

Or, si 15 % sont natifs du cloud, cela implique que les 85 % restants ne le sont pas. Cela inclut probablement les mainframes. Et client-serveur. Et des applications Web à trois niveaux. Oh, et les microservices dans les environnements conteneurisés aussi.

L’organisation d’entreprise moderne n’est pas seulement multi-cloud, elle est multigénérationnelle en termes d’architectures d’application.

Ce qui signifie que les chances que vous migriez une sorte d'application sur site (privée) vers hors site (publique) ou vice-versa sont plutôt bonnes, car il y en a plus que d'applications cloud natives. Ce qui est important, c’est d’intégrer ce principe dans votre stratégie cloud. En d’autres termes, vous devez comprendre ce que vous pouvez faire en amont pour rendre le processus (peut-être inévitable) moins douloureux.

Préparation à la migration de Cloud à Cloud

L’une des premières choses à prendre en compte est la durée de vie prévue de l’application que vous déplacez. Si c’est à long terme, c’est un candidat pour une migration cloud-cloud dans le futur. Si ce n’est pas le cas – parce qu’il s’agit d’une campagne promotionnelle, marketing ou événementielle – vous pouvez passer directement à la fin de cette liste et la déployer. 

Maintenant que vous avez déterminé que l’application aura une durée de vie plus longue, vous devez réfléchir à la manière dont vous allez faire évoluer et sécuriser l’application.

La réponse rapide (et facile) si l’application est native du cloud est « nous utiliserons les services du fournisseur de cloud ». C’est une option valable, tout comme « nous utiliserons ce que nous avons toujours utilisé » est une option valable si l’application doit vivre dans un cloud privé sur site. Cependant, ces deux options comportent des risques potentiels en aval : vous risquez de ne pas pouvoir migrer en douceur les services et/ou les politiques d’un cloud vers un autre. Il est temps d’examiner attentivement ce que vous utilisez actuellement en termes d’évolutivité et de sécurité et de déterminer si ces services d’application peuvent migrer avec votre application, dans les deux sens.

Étant donné que les entreprises utilisent en moyenne 16 services d’application pour fournir et sécuriser leurs applications, il s’agit d’un domaine qui peut considérablement entraver votre capacité à prendre en charge les applications susceptibles de migrer, sans parler de leur prise en charge dans un monde multicloud. Notez que certains de ces 16 services devront être des services cloud natifs. Fondamentalement, si vous considérez votre chemin de données comme étant composé de services d’application partagés d’entreprise et de services par application, vous pouvez commencer à voir que la division architecturale correspond étroitement à celle de la ligne tracée par les fournisseurs de cloud public au niveau de la couche d’infrastructure. Ce n'est pas une division parfaite, mais elle fournit une séparation logique qui offre des indications sur les services qui doivent être « multi-cloud » et sur ceux sur lesquels vous pouvez compter : services cloud natifs ou services de centre de données traditionnels.

Plus les services d’application que vous utilisez dans les différents clouds sont cohérents, plus il est facile de migrer entre les deux (ou trois, quatre ou plus), car vous êtes moins limité. Cette approche présente l’avantage supplémentaire d’étendre les efforts d’automatisation pour atteindre le cloud public et soulager l’entreprise, au moins, des coûts opérationnels associés au maintien d’un personnel et de procédures opérationnels distincts.

Le nuage était inévitable. Il en va de même pour le multicloud. Ce qui signifie en fin de compte qu’il y aura des migrations entre eux. Être attentif aux dépendances et utiliser des services d’application inter-cloud avant de prendre la décision initiale sur l’endroit où l’application doit être déployée peut rendre le processus moins pénible.

Intégrez au moins l’idée de migration de cloud à cloud à votre stratégie cloud de haut niveau. Être préparé peut vous éviter une migration ultérieure douloureuse (et coûteuse).