Rationalisation du cloud

La rationalisation du cloud est le processus qui consiste à évaluer des ressources dans le but de déterminer la meilleure manière de migrer ou de moderniser chaque ressource présente dans le cloud. Pour plus d’informations sur le processus de rationalisation, consultez Qu’est-ce qu’un patrimoine numérique.

Contexte de la rationalisation

Les cinq R de la rationalisation mentionnés dans cet article constituent un excellent moyen d'étiqueter un état futur potentiel pour toute charge de travail considérée comme candidate à un transfert vers le cloud. Placez ce processus d’étiquetage dans le contexte approprié avant d’essayer de rationaliser l’environnement. Pour déterminer ce contexte, passez en revue les mythes suivants :

Mythe : Il est facile de prendre des décisions de rationalisation en début de processus

Une bonne rationalisation nécessite une connaissance approfondie de la charge de travail et des ressources associées (applications, infrastructure et données). Plus important encore, une prise de décisions efficace pour la rationalisation prend 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

Quand l’ensemble du portefeuille informatique ou même un centre de données est rationalisé, cela peut retarder la création de valeur commerciale de plusieurs mois, voire de plusieurs années. Évitez une rationalisation complète dans la mesure du possible. Appliquez plutôt l’approche Puissance 10 de la planification de la mise en production pour prendre des décisions judicieuses sur les 10 prochaines charges de travail destinées à 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, émettez quelques hypothèses de base au niveau du portefeuille. Lorsque les motivations sont alignées sur l’innovation, on suppose qu’une réarchitecture est nécessaire. 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 remises en question et les budgets affinés.

Examinez à présent les cinq R de rationalisation suivants pour vous familiariser avec le processus à long terme. Lors du développement de votre plan d’adoption du cloud, choisissez l’option qui convient le mieux à vos motivations, aux résultats pour l’entreprise et à l’environnement actuel. L’objectif de la rationalisation du patrimoine numérique est de définir une ligne de base, et non pas de rationaliser chaque charge de travail.

Les 5 R de la rationalisation

Les 5 R suivants de la rationalisation décrivent les options de rationalisation les plus courantes.

Réhéberger

Également appelé migration lift-and-shift, l’effort de réhébergement déplace une ressource dans son état actuel vers le fournisseur de cloud choisi, avec un changement minimum d’architecture générale.

Les facteurs courants sont les suivants :

• 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 :

• Taille VM (processeur, mémoire et stockage).
• Dépendances, comme le trafic réseau.
• Compatibilité des ressources.

Les facteurs d’analyse qualitative sont :

• Tolérance au changement.
• Priorités de l’entreprise.
• Événements commerciaux stratégiques.
• Dépendances des processus.

Refactorisation

Les options PaaS (Platform as a service) permettent de réduire les coûts d’exploitation associés à de nombreuses applications. Il est judicieux de refactoriser légèrement une application pour qu’elle corresponde à un modèle PaaS.

La refactorisation s’applique également au processus de développement d’applications, dans lequel du code est refactorisé pour permettre à une application de répondre à de nouvelles opportunités commerciales.

Les facteurs les plus courants sont les suivants :

• Accélération des mises à jour.
• Portabilité du code.
• Plus grande efficacité du cloud pour de meilleures performances en termes de ressources, de vitesse, de coût et d’opérations managées.

Les facteurs d’analyse quantitative sont :

• Taille des ressources d’application (processeur, mémoire et stockage).
• Dépendances, comme le trafic réseau.
• Trafic utilisateur (vues de page, temps passé sur une page et temps de chargement).
• Plateformes de développement (langages, plateformes de données et services de couche intermédiaire).
• Base de données (processeur, mémoire, stockage et version).

Les facteurs d’analyse qualitative sont :

• Poursuite des investissements.
• Options de bursting ou chronologies.
• Dépendances des processus d’entreprise.

Réarchitecture

Certaines applications vieillissantes ne sont pas compatibles avec les fournisseurs de cloud. Cette incompatibilité est due aux décisions architecturales prises au moment de la génération de l’application. Dans ce cas, l’application doit subir une réarchitecture avant d’être transformée.

Dans d’autres cas, les applications qui sont compatibles avec le cloud mais qui ne sont pas natives dans le cloud peuvent entraîner des problèmes d’efficacité et de coût si vous les réarchitecturez pour en faire des applications natives du cloud.

Les facteurs les plus courants sont les suivants :

• Scaling et agilité des applications.
• Simplification de l’adoption des nouvelles fonctionnalités cloud.
• Piles de technologies mixtes.

Les facteurs d’analyse quantitative sont :

• Taille des ressources d’application (processeur, mémoire et stockage).
• Dépendances, comme le trafic réseau.
• Trafic utilisateur (vues de page, temps passé sur une page et temps de chargement).
• Plateformes de développement (langages, plateformes de données et services de couche intermédiaire).
• Base de données (processeur, mémoire, stockage et version).

Les facteurs d’analyse qualitative sont :

• Pour augmenter les investissements de l’entreprise.
• Coûts opérationnels.
• Boucles de rétroaction et investissements DevOps potentiels.

Reconstruire

Dans certains scénarios, les efforts nécessaires à la réarchitecture d’une application peuvent être trop importants pour justifier tout investissement supplémentaire. Ce problème est particulièrement vrai pour les applications qui répondaient autrefois aux besoins de l’entreprise, mais qui ne sont plus prises en charge par les processus métier actuels. Pour résoudre ce problème, créez une base de code favorisant l’alignement sur l’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 :

• Taille des ressources d’application (processeur, mémoire et stockage).
• Dépendances, comme le trafic réseau.
• Trafic utilisateur (vues de page, temps passé sur une page et temps de chargement).
• Plateformes de développement (langages, plateformes de données et services de couche intermédiaire).
• Base de données (processeur, mémoire, stockage et version).

Les facteurs d’analyse qualitative sont :

• Baisse de la satisfaction de l’utilisateur final.
• Processus métier limités dans leur fonctionnalité.
• Amélioration potentielle des coûts, de l’expérience ou du chiffre d’affaires.

Replace

Les solutions sont généralement implémentées à l’aide de la technologie et de l’approche les mieux adaptées sur le moment. Parfois, les applications SaaS peuvent fournir toutes les fonctionnalités nécessaires à l’application hébergée. Dans ces scénarios, une charge de travail peut être planifiée pour être remplacée à l’avenir, ce qui l’exclut de l’effort de transformation.

Les facteurs courants sont les suivants :

• Appliquer les meilleures pratiques du secteur.
• Accélérer l’adoption des approches basées sur 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 :

• Réduction des coûts opérationnels généraux.
• Taille VM (processeur, mémoire et stockage).
• Dépendances, comme le trafic réseau.
• Ressources à mettre hors service.
• Base de données (processeur, mémoire, stockage et version).

Les facteurs d’analyse qualitative sont :

• Analyse coûts-avantages de l’architecture actuelle par rapport à une solution SaaS.
• Diagrammes de processus d’entreprise.
• Schémas de données.
• Processus personnalisés ou automatisés.

Étapes suivantes

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

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