Partager via

Matrice de décision de migration Azure Cloud Services

Cet article fournit une matrice de décision permettant d’évaluer les options de migration d’une solution Azure actuellement basée sur cloud Services. La matrice compare différentes technologies de plateforme Azure pour vous aider à guider vos décisions de réarchitecture.

Matrice décisionnelle

Critères / Option Service Fabric Azure Functions Azure Web Apps Azure App Service (Container Apps, Logic Apps, etc.) Azure Kubernetes Service (AKS) Ensembles de mise à l'échelle de machines virtuelles Machines virtuelles Azure
Complexité de la migration Modéré à élevé. Nécessite une réarchitecture des rôles pour les services avec état/sans état. Souvent, une courbe d’apprentissage pour la gestion et l’orchestration de l’état. Faible à moyenne. Idéal pour les tâches légères événementielles. Remaniement significatif si l’application n’est pas conçue pour serverless. Faible à moyenne. Souvent similaire à la structure actuelle du rôle web. Révision minimale requise Faible à moyenne. La complexité de la migration varie selon le service, mais elle est bien prise en charge avec les outils de migration. Élevée. La conteneurisation de votre application nécessite une compréhension approfondie des microservices et de l’orchestration. Moyenne. Plus proche du modèle de services de cloud, facilitant la migration avec des capacités d'autoscaling. Élevée. Le lift-and-shift peut être plus simple, mais il ne tire pas parti des avantages natifs du cloud.
Scalabilité et performances Élevée. Conçu pour les microservices complexes et peut mettre à l’échelle efficacement les charges de travail avec état/sans état. Élevée. Mise à l’échelle automatique basée sur les événements, mais peut être soumise à des démarrages à froid. Modéré à élevé. Fonctionnalités de mise à l’échelle intégrées, mais peut avoir besoin d’une configuration manuelle pour les scénarios avancés. Élevée. Mise à l’échelle automatisée avec différents déclencheurs (requêtes HTTP, basées sur des événements, planification). Très haut. L’orchestration de conteneurs permet une mise à l’échelle et une résilience affinées. Élevée. Mise à l’échelle automatique basée sur des métriques, avec des fonctionnalités de mise à l’échelle automatique prédictive. Limitée. La scalabilité dépend de la mise à l’échelle manuelle et de la taille/configuration des machines virtuelles.
Contrôle &Personnalisation Élevée. Contrôle total sur l’orchestration des services et la gestion de l’état. Limitée. Service géré avec des limites de l'exécution et un environnement d'exécution contraint. Moyenne. Plateforme managée avec certaines options de configuration ; moins de contrôle sur l’infrastructure sous-jacente. Moyenne. Plus de flexibilité que Web Apps avec prise en charge des conteneurs, mais toujours contraintes PaaS. Élevée. Contrôle maximal sur l’orchestration des conteneurs et l’environnement d’exécution. Élevée. Contrôler la configuration, la mise en réseau et l’équilibrage de charge des machines virtuelles, avec des stratégies de mise à l’échelle automatique. Très haut. Contrôle complet du système d’exploitation, du middleware et du runtime.
Surcharge opérationnelle Moyenne. Nécessite la gestion de l’intégrité du cluster, des mises à niveau et des services avec état. Faible. Le service managé extrait l’infrastructure, ce qui réduit la surcharge opérationnelle. Faible. Microsoft gère la plateforme, bien que certains problèmes spécifiques à l’application restent. Faible. Service géré avec une gestion minimale de l’infrastructure requise. Élevée. Nécessite une expertise opérationnelle approfondie (surveillance, mises à jour, mise en réseau, etc.). Moyenne. Gère automatiquement la mise à l’échelle des instances, mais nécessite la maintenance et les mises à jour des images de machine virtuelle. Élevée. Responsabilité totale pour la maintenance, la mise à jour corrective et la sécurité.
Intégration de l’écosystème Robuste. S’intègre bien à l’écosystème orienté service d’Azure, mais peut nécessiter une configuration supplémentaire. Forte. Intégré en mode natif à Event Grid, aux applications logiques et à d’autres services serverless d’Azure. Forte. Intégration de haut niveau avec CI/CD, surveillance, et autres services Azure. Très forte. Conçu pour fonctionner avec d’autres services Azure avec une configuration minimale. Robuste Fonctionne bien avec les outils DevOps modernes, bien que la complexité de l’intégration augmente avec les microservices. Forte. S’intègre à Azure Load Balancer, Application Gateway et Azure Monitor. Variable. Bien que l’intégration soit possible, il nécessite souvent un développement plus personnalisé.
Adéquation au cas d’usage Idéal pour les applications nécessitant un contrôle précis sur les microservices, y compris les services d'état. Idéal pour les charges de travail pilotées par les événements, le traitement par lots et l’endroit où la latence est acceptable. Adapté aux applications web et aux API avec modèle de demande/réponse standard. Convient pour les charges de travail mixtes combinant des scénarios web, de back-ends mobiles, de logique d’intégration et d’API. Excellent pour les microservices et les charges de travail en conteneur qui nécessitent une haute disponibilité et une scalabilité. Adapté aux applications sans état avec des modèles de charge variables et des exigences IaaS. Convient pour les applications héritées qui nécessitent des modifications minimales, mais moins optimisées dans le cloud.

Considérations supplémentaires

  • Systèmes hérités vs. reconçus :
    Si vous envisagez de moderniser votre architecture au-delà d’un lift-and-shift, les options telles que Service Fabric, AKS ou même une approche serverless avec Functions peuvent offrir de meilleurs avantages à long terme malgré des coûts de réarchitecture initiale plus élevés.

  • Compétences et expertises en équipe :
    Évaluez la familiarité de votre équipe avec les microservices (Service Fabric, AKS) par rapport aux solutions serverless ou PaaS (Web Apps, Functions). Les courbes d’apprentissage et d’adoption peuvent influencer votre décision.

  • Implications sur les coûts :
    Les services managés (Functions, Web Apps) peuvent réduire les coûts opérationnels par rapport à la gestion de vos propres clusters de conteneurs (AKS) ou machines virtuelles, mais les modèles tarifaires (consommation et instances réservées) peuvent varier considérablement.

  • Vérification future :
    Réfléchissez à la façon dont chaque option s’aligne sur la stratégie de produit à long terme. Par exemple, AKS et les architectures conteneurisées gagnent en popularité pour leur portabilité et leur facilité d’intégration avec les pipelines CI/CD.

  • Exigences en matière de performances et de latence :
    Certaines charges de travail peuvent tirer parti du contrôle granulaire proposé par Service Fabric ou AKS, tandis que d’autres peuvent être bien servies par les fonctionnalités de facilité d’utilisation et de mise à l’échelle automatique de Functions ou Web Apps.

Étapes suivantes

Évaluez vos charges de travail :
Identifiez les composants de votre solution qui conviennent le mieux à chaque architecture : tenez compte des composants liés au calcul et avec état.

Migration de prototype :
Envisagez de créer une preuve de concept pour les deux ou trois options supérieures. Cela peut aider à découvrir des défis imprévus et à mieux estimer la complexité de la migration.

Analyse des avantages économiques :
Incluez non seulement l’effort de migration et la surcharge opérationnelle, mais également des avantages à long terme, tels que la facilité de mise à jour, la résilience et l’extensibilité.

Révision des parties prenantes :
Partagez la matrice de décision avec votre équipe et d’autres parties prenantes pour obtenir des commentaires et aligner sur les priorités.

Passez en revue les guides de migration :

  • Last updated on