Partager via

Planifier des plateformes d’application modernes

  • Article

La Méthodologie de planification du Cloud Adoption Framework permet de créer un plan d’adoption global du cloud pour guider les programmes et les équipes impliqués dans votre transformation numérique basée sur le cloud. Ce guide fournit des modèles pour créer votre backlog et vos plans pour la création de compétences nécessaires dans vos équipes, le tout basé sur ce que vous essayez de faire dans le cloud.

L’application de la méthodologie de planification se concentre sur les cinq R de la rationalisation de vos ressources numériques. Le chemin le plus courant vers le cloud est axé sur la vitesse, l’efficacité et la répétabilité des processus de migration et de modernisation. En vertu des cinq R de la rationalisation, la planification hiérarchise généralement les options de réhébergement avec une prise en charge parallèle limitée des options de réarchitecture et de régénération.

Patrimoine numérique

Lors de la planification de vos ressources numériques, vous souhaiterez collecter des données d’inventaire et rationaliser vos ressources. Dans un plan d’adoption de conteneur, il est vital que toutes les ressources, telles que les machines virtuelles, les données et les applications, soient regroupées par la charge de travail qu’elles prennent en charge. Une fois le regroupement et la rationalisation de base terminés, vous pouvez évaluer ces charges de travail pour déterminer le package et les options de réhébergement ou de réarchitecture.

Le modèle de plan d’adoption cloud standard compte les types de travail requis dans un effort d’adoption de cloud typique. Toutefois, vous devrez ajouter des tâches à votre plan pour empaqueter la charge de travail dans les conteneurs et organiser l’approvisionnement des conteneurs.

Attention

Cet article part du principe que le lecteur suit déjà les meilleures pratiques décrites dans la série d’articles sur la création d’un plan d’adoption du cloud dans Azure DevOps. Si vous suivez votre plan d’adoption du cloud dans une feuille de calcul ou un autre outil de suivi de projet, les sections suivantes sont toujours applicables, mais les étapes actionnables d’ajout de données à votre plan doivent être ajustées.

Avertissement

L’incorporation d’une stratégie de plateforme d’application moderne dans des processus de migration standard (ou une fabrique de migration) nécessite une implémentation aboutie des tâches associées à la conception des architectures de charge de travail avant la migration. La poursuite de cette stratégie sans ces tâches retardera l’effort de migration et pourrait conduire à de piètres décisions d’architecture pour les hôtes de conteneur déployés et la prise en charge des charges de travail.

Identifier les charges de travail candidates

Dans le scénario de plateforme d’application moderne, les retours à plus long terme qui nécessitent un investissement initial plus important, prennent le pas sur des processus de migration plus efficaces. Les investissements à plus long terme sont représentés dans des parties spécifiques du plan comme une focalisation accrue sur l’activation de l’innovation et de la rationalisation des opérations pour des groupes de charges de travail spécifiques.

Pour commencer à aligner la stratégie et le plan, identifiez les charges de travail susceptibles d’être affectées par l’ajout de plateformes d’application modernes dans votre stratégie d’adoption du cloud. Ces hypothèses seront validées avant l’implémentation de toute modification technique. Pour faciliter l’identification des candidats potentiels, recherchez les critères suivants dans votre portefeuille de charges de travail :

  • Investissements dans le développement actif ou le DevOps : un pourcentage de charges de travail de production fera l’objet d’un développement actif. Il se peut même que certaines soient gérées par le biais de pratiques de DevOps continu.
  • Portabilité des charges de travail : certaines charges de travail sont affectées par des contraintes de conformité, de protection des données ou opérationnelles qui peuvent nécessiter une portabilité dans un cloud privé, en périphérie, voire entre plusieurs fournisseurs de cloud public.
  • Consolidation des charges de travail : de nombreuses charges de travail (notamment les charges de travail peu utilisées) peuvent être candidates à une consolidation sur des hôtes de conteneur, ce qui entraîne l’utilisation d’un petit nombre de serveurs/machines virtuelles et des coûts d’exploitation réduits.
  • Charges de travail héritées : des charges de travail héritées peuvent bloquer les mises à jour des systèmes d’exploitation, voire empêcher la migration vers le cloud. Les charges de travail héritées qui ne sont pas compatibles avec les fonctionnalités Azure peuvent être candidates à une migration sur un hôte de conteneur.

Documenter les charges de travail candidates

Remarque

La liste de considérations ci-après ne doit être documentée que pour les candidates à la migration identifiées par les critères ci-dessus.

Lors de l’élaboration d’un plan d’adoption du cloud, chaque charge de travail est documentée conformément aux instructions de l’article Définir et hiérarchiser les charges de travail. Toute charge de travail candidate pour le scénario de plateforme d’application moderne nécessite des informations supplémentaires pour guider l’exécution du plan. Cet article souligne l’importance de documenter les entrées commerciales et techniques pour définir la charge de travail. Pour une charge de travail candidate pour la plateforme d’application moderne, les points de données suivants doivent être ajoutés à la définition de la charge de travail.

Entrées opérationnelles

Voici les points de données liés à l’entreprise qui peuvent influencer la décision d’inclure une charge de travail dans la stratégie de plateforme d’application moderne.

  • Facteurs de conformité : quels critères de conformité spécifiques conduisent à envisager d’héberger cette charge de travail dans un cloud privé ?
  • Facteurs de protection des données : quelles mesures de protection des données conduisent à envisager d’héberger cette charge de travail dans un cloud privé ?
  • Contraintes opérationnelles : quelles contraintes opérationnelles conduisent à envisager d’héberger cette charge de travail dans un cloud privé ?
  • Résultats pour une plateforme d’application moderne : parmi les propositions suivantes, laquelle constitue un facteur permettant d’évaluer cette charge de travail comme candidate pour faire office de conteneur ? DevOps, portabilité, consolidation, héritage ou plusieurs de ces facteurs.
  • Modèle d’exploitation : cette charge de travail sera-t-elle gérée de manière centralisée (par une équipe informatique centrale ou un centre d’excellence du cloud), de manière décentralisée (par une équipe de charge de travail) ou avec des opérations d’entreprise (opérations spécifiques de support et de charge de travail centralisées) ?

Entrées techniques

Les éléments suivants sont des points de données des équipes technologiques qui peuvent influencer la décision d’inclure une charge de travail dans la stratégie de plateforme d’application moderne.

Considérations relatives à l’emplacement :

Considérations relatives à l’emplacement où la charge de travail sera hébergée.

  • Exigence d’hébergement dans un cloud public : existe-t-il une contrainte technique spécifique associée à l’exigence d’hébergement dans un cloud public ?
  • Exigence d’hébergement dans un cloud privé : existe-t-il une contrainte technique spécifique associée à l’exigence d’hébergement dans un cloud privé ?
  • Exigence d’hébergement en périphérie : existe-t-il une contrainte technique spécifique associée à l’exigence d’hébergement en périphérie ?
  • Exigence de portabilité : existe-t-il une contrainte technique spécifique associée à l’exigence de portabilité cloud ?

Considérations relatives aux opérations :

Considérations relatives aux opérations de la plateforme, des hôtes et des charges de travail.

  • Plateforme cloud principale : les organisations doivent définir une plateforme cloud principale pour fournir les outils de gestion des opérations. Certaines organisations peuvent avoir plusieurs plateformes cloud principales pour gérer différents types d’opérations. Quelle est la plateforme cloud principale pour l’exécution de cette charge de travail ?
  • Plateformes d’opérations supplémentaires : cette charge de travail sera-t-elle également gérée par des plateformes d’opérations supplémentaires ?
  • Exigences d’hébergement dans le cloud : cette charge de travail requiert-elle une stratégie spécifique d’hébergement dans le cloud ? Cloud public, cloud privé ou portabilité cloud
  • Plateforme d’orchestration standardisée : si l’entreprise dispose d’une solution standard pour l’orchestration de conteneur, incluez le nom de la plateforme standardisée à prendre en compte. Exemples : Azure Kubernetes Service (AKS), moteur AKS ou Kubernetes.
  • Considérations relatives à l’orchestration personnalisée : une plateforme d’orchestration de conteneur non standard est-elle requise ? Dans ce cas, expliquez cette exigence.
  • Opérations d’hôte standardisées : il est supposé que les charges de travail sont non hostiles et peuvent être hébergées sur des conteneurs partagés pris en charge par des opérations d’hôte standardisées. Cette charge de travail est-elle compatible avec cette approche ?
  • Considérations relatives aux opérations d’hôte personnalisées : si la charge de travail n’est pas compatible avec les opérations standardisées, quelles sont les exigences spécifiques à prendre en compte lors de la mise en place de pratiques d’opérations d’hôte pour cette charge de travail ?

Considérations relatives à l’application :

Considérations spécifiques concernant la façon dont l’application est développée et continuera de l’être.

  • Runtime de PaaS (platform as a service) : les fournisseurs de cloud public produisent des runtimes d’application cohérents, souvent appelés offres PaaS (platform as a service). Dans Azure, les runtimes PaaS sont fournis par Azure App Service. Cette application peut-elle fonctionner sur un runtime PaaS ? Quel Runtime est le plus compatible ?
  • Runtime standardisé : si l’application n’est pas compatible avec un runtime PaaS, existe-t-il un runtime standardisé fourni par l’organisation ? Sur quel runtime cette charge de travail sera-t-elle basée ?
  • Considérations relatives au runtime personnalisé : quelles considérations spécifiques requièrent un runtime personnalisé pour cette charge de travail ?
  • Contraintes de runtime  : le runtime choisi impose-t-il des contraintes sur l’application ?
  • Dépendances d’application : cette charge de travail dépend-elle de systèmes existants résidant dans un emplacement spécifique (public ou privé) ? Les exemples incluent un système ERP comme SAP s’exécutant dans une solution spécifique.
  • Gravité des données : cette charge de travail dépend-elle d’une source de données résidant dans un emplacement spécifique (public ou privé) ? Il peut s’agir, par exemple, d’une dépendance des données résidant dans SAP ou d’autres sources de données centralisées.
  • Considérations relatives à la liste approuvée : les considérations relatives aux opérations personnalisées sont-elles approuvées pour une utilisation au sein de votre plateforme cloud ? Quels services approuvés doivent être inclus dans le déploiement ?

Considérations pour les conteneurs initiaux

L’empaquetage de vos charges de travail dans des conteneurs est le premier corps de travail qui doit être planifié et examiné. Le deuxième est la planification de l’hébergement de ces conteneurs.

Solutions PaaS pour les runtimes, l’orchestration et les opérations standardisés

Certaines charges de travail sont très autonomes et ne bénéficient pas nécessairement des contrôles avancés et des exigences d’infrastructure fournis avec une plateforme de grande taille, telle que Kubernetes. Ce n’est pas parce que votre charge de travail est mise en conteneur qu’elle doit être déployée sur Kubernetes. Azure fournit diverses solutions pour exécuter des charges de travail au sein de votre portefeuille qui ne nécessitent pas le niveau de gestion et d’infrastructure requis par AKS. Les solutions suivantes suivent cette approche de la planification :

Envisagez d’utiliser une solution plus légère pour vos conteneurs incluant des charges de travail qui ne sont pas supposées devenir plus complexes, et qui sont alignées sur les objectifs et les limites de ces solutions.

Orchestration standardisée avec des runtimes et des opérations personnalisés dans le cloud public

Pour les charges de travail qui ne peuvent pas s’exécuter sur une plateforme PaaS complètement managée et qui doivent compter sur les contrôles au niveau de l’infrastructure, utiliser des fonctionnalités de déploiement avancées, telles que celles offertes par les orchestrateurs de conteneurs, ou s’attendre à l’augmentation de la complexité modulaire, activez Azure Kubernetes Service (AKS). AKS résout les problèmes d’hébergement de conteneur et fournit également des options d’architecture, de SRE, de sécurité, de déploiement, de surveillance et d’infrastructure étendues.

L’ensemble de fonctionnalités de la plateforme est fourni avec une exigence d’apprentissage de la plateforme aux niveaux de l’opérateur de cluster et de la charge de travail. Fractionnez l’éducation de vos équipes d’exploitation, équipes d’architecture et équipes d’ingénierie de charge de travail dans des chronologies de migration. En outre, AKS étant une plateforme, assurez-vous que les équipes de charge de travail comprennent la séparation des responsabilités au sein de cette plateforme par rapport à leur organisation d’hébergement actuelle. Elle peut être similaire de certaines façons, mais elle sera probablement nouvelle dans d’autres.

Orchestration, runtimes et opérations personnalisés dans le cloud public

Pour des charges de travail très spécialisées ou des exigences organisationnelles spécifiques, Azure propose deux autres plateformes majeures dans l’espace d’orchestration de conteneur.

  • Azure Red Hat OpenShift
  • Azure Service Fabric

Si vous avez des raisons d’explorer des alternatives, assurez-vous que du temps est alloué à la compréhension des avantages et des inconvénients de toutes les options de plateforme. La solution par défaut d’Azure est AKS et cette documentation suppose qu’AKS est la technologie choisie.

Standardiser des opérations sur des plateformes cloud

Souvent, des clients déploient différents orchestrateurs de conteneurs dans des environnements de cloud privé, de périphérie et de cloud public. Pour standardiser les opérations sur ces plateformes cloud disparates, les clients peuvent intégrer une approche d’opérations unifiées en étendant leurs outils d’opérations cloud à plusieurs plateformes cloud.

Dans Azure, les organisations peuvent standardiser des opérations dans différents orchestrateurs en intégrant des hôtes de conteneur disparates dans Azure Arc pour Kubernetes. Cet outil garantit la cohérence du monitoring, des opérations et de la gouvernance sur chaque hôte de conteneur.

Runtimes d’application dans des environnements de cloud privé et de périphérie

Quand des charges de travail doivent être exécutées dans un environnement de cloud privé ou de périphérie, alors qu’elles seraient prises en charge de manière optimale par un runtime PaaS, quelques outils permettent aux développeurs de s’appuyer sur des runtimes PaaS cohérents en utilisant Azure App Service :

  • Azure Stack HCI : permet d’héberger Azure App Service en mode natif sur Azure Stack géré par l’opérateur Azure Stack.
  • Azure Stack HCI pour AKS : permet l’hébergement de runtimes personnalisés s’exécutant sur AKS dans Azure Stack, gérés par des opérateurs Azure Stack et AKS pour permettre la portabilité vers d’autres solutions Kubernetes.
  • Azure App service sur Kubernetes avec Azure arc : permet à n’importe quel hôte Kubernetes de fournir des services d’application dans Azure. Tous les hôtes deviennent une petite instance d’Azure App Service. Chaque hôte étant également intégré dans Azure Arc, il peut aussi être géré par le biais d’opérations d’hôte cohérentes basées sur le cloud.

Plan de préparation de la plateforme d’application moderne

Outre le plan de qualification pour l’adoption du cloud, les équipes en charge de l’adoption du cloud peuvent avoir besoin d’acquérir des compétences liées au conteneur et à Kubernetes avant d’exécuter votre plan :

Assurez-vous que du temps est accordé aux équipes de charge de travail pour documenter et tester des plans de migration. L’application existante ou le système externe (dépendances et systèmes qui dépendent de cette charge de travail) doit peut-être être modifié avec une flexibilité supplémentaire pour prendre en charge l’effort de migration. Cela est vrai pour les environnements de préproduction et de production.

Étape suivante : Passer en revue l’environnement ou la zone d’atterrissage Azure

La liste d’articles suivante vous aidera à trouver des conseils sur des points spécifiques du parcours d’adoption du cloud pour réussir dans le scénario d’adoption du cloud.