Rationalisation du cloud

La rationalisation du cloud est le processus d’évaluation des ressources pour déterminer la meilleure façon de migrer ou de moderniser chaque ressource dans le cloud. Pour plus d’informations sur le processus de rationalisation, consultez Présentation d’un patrimoine numérique.

Contexte de rationalisation

Les cinq R de rationalisation répertoriées dans cet article constituent un excellent moyen d’étiqueter un état futur potentiel pour toute charge de travail considérée comme candidate au cloud. Placez ce processus d’étiquetage dans le contexte approprié avant de tenter de rationaliser un environnement. Pour fournir ce contexte, passez en revue les mythes suivants :

Mythe : Il est facile de prendre des décisions de rationalisation dès le début du processus

Une bonne rationalisation nécessite une connaissance approfondie de la charge de travail et des ressources associées, telles que les applications, l’infrastructure et les données. Plus important encore, de bonnes décisions de rationalisation prennent du temps. Nous vous recommandons d’utiliser un processus de rationalisation incrémentiel.

Mythe : l’adoption du cloud doit attendre que toutes les charges de travail soient rationalisées

Lorsqu’un portefeuille informatique entier ou même un centre de données unique est rationalisé, il peut retarder la réalisation de la valeur métier par mois ou même par années. Évitez la rationalisation complète lorsque cela est possible. Au lieu de cela, utilisez l’approche Power of 10 pour la planification des sorties afin de prendre des décisions judicieuses sur les 10 prochaines charges de travail prévues pour l’adoption du cloud.

Mythe : La justification métier doit attendre que toutes les charges de travail soient rationalisées

Pour développer une justification métier pour un effort d’adoption du cloud, effectuez quelques hypothèses de base au niveau du portefeuille. Lorsque les motivations sont alignées sur l’innovation, supposez une réarchitecture. Si elles sont alignées sur la migration, on suppose qu’un réhébergement est nécessaire. Ces hypothèses peuvent accélérer le processus de justification métier. Pendant la phase d’évaluation du cycle d’adoption de chaque charge de travail, les hypothèses sont ensuite remises en cause et les budgets sont affinés.

Passez maintenant en revue les cinq R suivantes de rationalisation pour vous familiariser avec le processus à long terme. Lors du développement de votre plan d’adoption du cloud, choisissez l’option qui correspond le mieux à vos motivations, résultats métier et environnement d’état actuel. L’objectif de la rationalisation du patrimoine numérique est de définir une base de référence, et non de rationaliser chaque charge de travail.

Les 5 R de la rationalisation

Les cinq R suivantes de rationalisation décrivent les options les plus courantes pour la rationalisation.

Réhébergement

Également appelé migration lift-and-shift , un effort de réhébergement déplace une ressource d’état actuelle vers le fournisseur de cloud choisi avec une modification minimale de l’architecture globale.

Les motivations fréquentes peuvent être les suivantes :

• Réduire les dépenses d’investissement.
• Libérer de l’espace dans un centre de données.
• Rentabiliser rapidement l’investissement dans le cloud.

Les facteurs d’analyse quantitative sont les suivants :

• Taille de machine virtuelle, y compris le processeur, la mémoire et le stockage.
• Dépendances, comme le trafic réseau.
• Compatibilité des ressources.

Les facteurs d’analyse qualitative sont les suivants :

• Tolérance au changement.
• Priorités commerciales.
• Événements métier critiques.
• Dépendances du processus.

Réorganiser

Les options PaaS (Platform as a Service) peuvent réduire les coûts opérationnels associés à de nombreuses applications. Il est judicieux de refactoriser légèrement une application en fonction d’un modèle PaaS.

La refactorisation fait également référence au processus de développement d'applications qui consiste à refactoriser le code pour permettre à ces applications de saisir de nouvelles opportunités commerciales.

Les pilotes fréquents peuvent inclure :

• Mises à jour plus rapides et plus courtes.
• Portabilité du code.
• Amélioration de l’efficacité du cloud pour aider les ressources, la vitesse, le coût et les opérations gérées.

Les facteurs d’analyse quantitative sont les suivants :

• Taille des ressources d’application, telles que l’UC, la mémoire et le stockage.
• Dépendances, comme le trafic réseau.
• Le trafic utilisateur, tel que les affichages de page, l’heure sur la page et les heures de chargement.
• Plateformes de développement, telles que les langages, les plateformes de données et les services de niveau intermédiaire.
• Base de données qui comprend le processeur, la mémoire, le stockage et la version.

Les facteurs d’analyse qualitative sont les suivants :

• Investissements commerciaux continus.
• Options de bursting ou chronologies.
• Dépendances de processus métier.

Réarchitecture

Certaines applications vieillissantes ne sont pas compatibles avec les fournisseurs de cloud. Cette incompatibilité est due aux décisions architecturales qui ont été prises lors de la création de l’application. Dans ces cas, l’application peut avoir besoin d’être réarchisée avant la transformation.

Dans d’autres cas, les applications compatibles avec le cloud, mais pas natives du cloud, peuvent créer des économies et une efficacité opérationnelle en réarchisant la solution en une application native cloud.

Les facteurs les plus courants sont les suivants :

• Mise à l’échelle et agilité de l’application.
• Adoption plus facile des nouvelles fonctionnalités cloud.
• Combinaison d'empilements technologiques.

Les facteurs d’analyse quantitative sont les suivants :

• Taille des ressources d’application, telles que l’UC, la mémoire et le stockage.
• Dépendances, comme le trafic réseau.
• Le trafic utilisateur, tel que les affichages de page, l’heure sur la page et les heures de chargement.
• Plateformes de développement, telles que les langages, les plateformes de données et les services de niveau intermédiaire.
• Base de données qui comprend le processeur, la mémoire, le stockage et la version.

Les facteurs d’analyse qualitative sont les suivants :

• Pour développer des investissements commerciaux.
• Coûts opérationnels.
• Boucles de rétroaction potentielles et investissements DevOps.

Regénération

Dans certains scénarios, le delta qui doit être surmonté pour transférer une application peut être trop important pour justifier un investissement supplémentaire. Ce problème est particulièrement vrai pour les applications qui répondent précédemment aux besoins d’une entreprise, mais qui ne sont désormais pas prises en charge avec les processus métier actuels. Pour résoudre le problème, créez une base de code pour vous aligner sur une approche cloud-native.

Les facteurs courants sont les suivants :

• Accélérer l’innovation.
• Créer des applications plus rapidement.
• Réduire les coûts d’exploitation.

Les facteurs d’analyse quantitative sont les suivants :

• Taille des ressources d’application, telles que l’UC, la mémoire et le stockage.
• Dépendances, comme le trafic réseau.
• Le trafic utilisateur, tel que les affichages de page, l’heure sur la page et les heures de chargement.
• Plateformes de développement, telles que les langages, les plateformes de données et les services de niveau intermédiaire.
• Base de données qui comprend le processeur, la mémoire, le stockage et la version.

Les facteurs d’analyse qualitative sont les suivants :

• Baisse de la satisfaction des utilisateurs finaux.
• Processus métier limités par les fonctionnalités.
• Coût potentiel, expérience ou gains de revenus.

Remplacer

Les solutions sont généralement implémentées à l’aide des meilleures technologies et approches disponibles à l’heure actuelle. Parfois, les applications SaaS (Software as a Service) peuvent fournir toutes les fonctionnalités nécessaires pour l’application hébergée. Dans ces scénarios, une charge de travail peut être planifiée pour un remplacement futur, ce qui le supprime de l’effort de transformation.

Les facteurs courants sont les suivants :

• Se standardiser sur les meilleures pratiques du secteur.
• Accélérez l’adoption des approches pilotées par les processus métier.
• Réallouer les investissements de développement dans des applications qui assurent une longueur d’avance sur la concurrence ou procurent d’autres avantages.

Les facteurs d’analyse quantitative sont les suivants :

• Réductions générales des coûts d’exploitation.
• Taille de machine virtuelle, y compris le processeur, la mémoire et le stockage.
• Dépendances, comme le trafic réseau.
• Ressources à mettre hors service.
• Base de données qui comprend le processeur, la mémoire, le stockage et la version.

Les facteurs d’analyse qualitative sont les suivants :

• Analyse des avantages du coût de l’architecture actuelle par rapport à une solution SaaS.
• Mappages de processus métier.
• Schémas de données.
• Processus personnalisés ou automatisés.

Étapes suivantes

Vous pouvez appliquer ces cinq R de rationalisation à un patrimoine numérique pour vous aider à prendre des décisions de rationalisation sur l’état futur de chaque application.

Qu’est-ce qu’un patrimoine numérique