Migration dans le cloud AWS : six façons d’aborder un projet de transformation d'application

Après avoir réalisé une étude de faisabilité et mis en place un Centre d’Excellence Cloud (CCoE), la prochaine étape consiste à définir ce qui se passera avec chaque worklaod. La beauté de l’infrastructure cloud AWS réside dans le fait que vous pouvez associer des services capables de répondre aux besoins de votre entreprise et de ses clients. Mais il est utile de comprendre les différentes approches et leur application éventuelle.

Pour aider à classer ces options, l’industrie du cloud utilise les «6 R» :

MigrerAWSLes6R.png

1. Rehosting (ou Lift & shift, ou réhébergement)
Le plus simple de tous les modèles de migration dans le Cloud, mais aussi le plus susceptible de poser des problèmes, augmente les coûts et aliène les principales parties prenantes.
Le Rehosting (également appelé «Lift and Shift»), réplique simplement un système existant sur une infrastructure cloud public.

Cette approche a l’avantage d’être simple et rapide, mais elle signifie également que toute inefficacité ou défaillance est également transférée dans le cloud. Un grand nombre des expériences négatives rapportées à propos de projets de migration dans le Cloud sont dues au fait que les entreprises ont choisi de ré-héberger sans évaluer pleinement l'impact de cette décision.

2. Replaftoming (changement de plateforme)
Le Replatforming implique un certain degré d’analyse afin d’identifier les processus et les services susceptibles d’être retirés de vos opérations.
Faire appel à des experts du cloud permet de réduire les coûts et les frais d’opérations, ainsi que de tirer pleinement parti de technologies qui sont probablement peu connues ou mal comprises.

Le passage à des services managés accélère la migration vers le cloud AWS sans avoir à restructurer lourdement l’application et/ou les worklaods. C'est pourquoi ce "R" est parfois appelé "Lift and Tweak".

3. Repurchasing (rachat)
Comme son nom l'indique, il vous suffit de racheter la version SaaS d'une application existante.

Le mode SaaS possède de nombreux avantages désormais reconnus : avec un modèle de licence généralement par utilisateur et pat mois, vous basculez d’un modèle de dépenses CapEx à OpEx et ne payez que ce vous utilisez. Deuxièmement, les applications sur site pèsent sur les ressources internes, mais passez au SaaS et il incombe au fournisseur d’applications cloud de maintenir les systèmes en état de fonctionnement. En d'autres termes, vous pouvez générer des économies de coûts significatives en supprimant ces frais généraux de gestion d'infrastructure.

4. Refactoring (réorganisation)
Le Refactoring, qui est l’approche la plus avancée et la plus coûteuse au départ, consiste à restructurer les applications et les processus pour tirer pleinement parti des technologies cloud public. Au lieu de créer un serveur virtuel hébergé pour exécuter une application, vous conteneurisez le logiciel et / ou le connectez à des services natifs cloud.

Vous devez redévelopper votre application, mais cette approche garantit que l'utilisation des ressources cloud AWS est optimisée, pour un meilleur contrôle de la facturation. Cela vous permet également de mieux adapter l'application et les services et ensembles de données associés sans les frais généraux liés au management d'une batterie de serveurs virtualisés.

5. Retain (conservation)
Dans certaines circonstances, il n’ya aucune raison impérieuse de migrer un système vers le cloud. Cela peut être dû aux conditions de licences existantes (telles que les clés de licence matérielle) ou à une incompatibilité générale avec les plates-formes d'exploitation Cloud.

Dans ces cas, vous conservez l'application telle quelle et vous pouvez vous concentrer sur les applications éligibles à la migration dans le cloud.

6. Retire (mise hors service)
Peut-être l'un des aspects les plus satisfaisants des migrations dans le cloud public. C’est là que vous mettez enfin hors tension certains systèmes qui phagocytent les budgets et les ressources alors qu’ils ne sont plus nécessaires.

Les systèmes rachetés constituent des candidats évidents à la retraite. Fondamentalement, tout ce qui n'est plus utilisé peut enfin être mis hors tension et éliminé.

Mélanger !
Vous devrez probablement utiliser une combinaison de ces approches pour démarrer votre processus de migration dans le Cloud. Le Rehosting des infrastructures lancera le mouvement, mais il ne génèrera pas des économies et de l’efficacité à long terme. Le Refactoring constituera probablement un investissement important, à répartir sur plusieurs années en fonction des fonds disponibles.

Ce qui nous amène à l'importance de comprendre votre système IT actuel et son utilisation. Ce n’est qu’alors que vous pourrez spécifier correctement comment (ou si) migrer chaque application et service pour un effet maximal.

Points clés :

  • Le Rehosting est l'option la plus rapide. Cette approche ne convient que dans un petit nombre de cas spécifiques.
  • Le Replatforming vous permet de réduire l’infrastructure et de commencer la transition vers un modèle financier OpEx.
  • Dans certains cas, le Repurchasing de versions Cloud de systèmes existants présente un intérêt.
  • Le Refactoring des applications coûte cher au départ, mais l'ingénierie du nouveau modèle d'infrastructure cloud apportera des avantages considérables à long terme.
  • Parfois, vous devrez peut-être conserver d'anciens systèmes existants, ce qui peut être une bonne chose.
  • Le but ultime du Cloud est de le réorganiser pour éliminer les applications et les systèmes indésirables. Restez concentrés sur la réalisation de cet objectif.

Voir notre offre de Cloud Maturity Assessment