Azure propose de nombreux moyens d'héberger le code de vos applications. Le terme calcul fait référence au modèle d’hébergement des ressources utilisées par votre application. Cet article vous aide à choisir un service de calcul pour votre application.
Choisir un service candidat
Utilisez l’organigramme suivant pour sélectionner un service de calcul candidat.
Téléchargez un fichier Visio de cet arbre de décision.
Ce diagramme fait référence à deux stratégies de migration :
- Lift-and-shift : stratégie de migration de charge de travail vers le cloud sans reconception de l’application ni modification de code. Elle est également appelée ré-hébergement. Pour plus d’informations, consultez le Centre de modernisation et de migration Azure.
- Optimisation pour le cloud : stratégie de migration vers le cloud consistant à refactoriser une application afin de tirer parti des fonctionnalités et capacité natives Cloud.
La sortie de cet organigramme est votre point de départ. Ensuite, évaluez le service pour voir s’il répond à vos besoins.
Cet article comprend plusieurs tableaux qui peuvent vous aider à choisir un service. Le candidat initial de l’organigramme peut ne pas convenir à votre application ou charge de travail. Dans ce cas, élargissez votre analyse pour inclure d’autres services de calcul.
Si votre application comprend plusieurs charges de travail, évaluez-les séparément. Une solution complète peut intégrer deux services de calcul ou plus.
Comprendre les fonctionnalités de base
Si vous n’êtes pas familiarisé avec le service Azure sélectionné dans la section précédente, consultez cette documentation de présentation :
- Machines virtuelles Microsoft Azure : service dans lequel vous déployez et gérez des machines virtuelles à l’intérieur d’un réseau virtuel Azure.
- Azure App Service : service géré pour l’hébergement d’applications web, de serveurs principaux d’applications mobiles, d’API RESTful ou de processus d’entreprise automatisés.
- Azure Functions : fonction managée en tant que service.
- Azure Kubernetes Service (AKS) : service Kubernetes managé pour l’exécution d’applications conteneurisées.
- Azure Container Apps : service géré basé sur Kubernetes, qui simplifie le déploiement d’applications conteneurisées dans un environnement serverless.
- Azure Container Instances : ce service constitue un moyen simple et rapide d’exécuter un conteneur dans Azure. Vous n’avez pas besoin d’approvisionner des machines virtuelles ni d’adopter un service de niveau supérieur.
- Azure Red Hat OpenShift : cluster OpenShift complètement managé pour l'exécution de conteneurs en production avec Kubernetes.
- Azure Spring Apps : service géré conçu et optimisé pour l’hébergement d’applications Spring Boot.
- Azure Service Fabric : plateforme de systèmes distribués qui peut s’exécuter dans de nombreux environnements, y compris sur Azure ou localement.
- Azure Batch : service géré qui permet d’exécuter des applications de calcul haute performance (HPC) et parallèles à grande échelle.
Comprendre les modèles d’hébergement
Pour les modèles d’hébergement, les services cloud se répartissent en trois catégories :
Infrastructure as a service (IaaS) : vous permet d’approvisionner des machines virtuelles ainsi que les composants de mise en réseau et de stockage associés. Ensuite, vous pouvez déployer les logiciels et les applications dont vous souhaitez disposer sur ces machines virtuelles. Ce modèle se rapproche le plus d’un environnement local traditionnel. Microsoft gère l’infrastructure Vous continuez à gérer les machines virtuelles.
Platform as a Service (PaaS) : offre un environnement d’hébergement géré, dans lequel vous pouvez déployer votre application sans avoir à gérer de machines virtuelles ni de ressources réseau. Azure App Service et Azure Container Apps sont des services PaaS.
Functions-as-a-Service (FaaS) : vous permet de déployer votre code sur le service, qui l’exécute automatiquement. Azure Functions est un exemple de service FaaS.
Notes
Azure Functions est une offre de calcul Azure serverless. Pour avoir une comparaison de ce service avec d’autres offres Azure serverless, telles que Logic Apps, qui fournit des workflows serverless, consultez Choisir les services d’intégration et d’automatisation appropriés dans Azure.
Il existe toute une gamme de services entre IaaS et le modèle PaaS pur. Par exemple, des machines virtuelles Azure peuvent se mettre à l’échelle automatiquement à l’aide de groupes de machines virtuelles identiques. Cette fonctionnalité n’est pas strictement PaaS, mais il s’agit du type de fonctionnalité de gestion que l’on trouve dans PaaS.
Il existe un compromis entre le contrôle et la facilité de gestion. IaaS offre un maximum de contrôle, de flexibilité et de portabilité, mais vous devez approvisionner, configurer et gérer les machines virtuelles et les composants réseau que vous créez. Les services FaaS gèrent automatiquement presque tous les aspects de l’exécution d’une application. PaaS se situe entre les deux.
| Service | Composition de l’application | Densité | Nombre minimal de nœuds | Gestion de l'état | Hébergement web |
|---|---|---|---|---|---|
| Machines virtuelles Azure | Sans dépendance | Sans dépendance | 1 2 | Sans état ou avec état | Sans dépendance |
| Azure App Service | Applications, conteneurs | Plusieurs applications par instance à l’aide d’un plan App Service | 1 | Sans état | Intégré |
| Azure Functions | Fonctions, conteneurs | Serverless 1 | Serverless 1 | Sans état ou avec état 6 | Non applicable |
| Azure Kubernetes Service | Conteneurs | Plusieurs conteneurs par nœud | 3 3 | Sans état ou avec état | Sans dépendance |
| Azure Container Apps | Conteneurs | Sans serveur | Sans serveur | Sans état ou avec état | Sans dépendance |
| Azure Container Instances | Conteneurs | Aucune instance dédiée | Aucun nœud dédié | Sans état | Sans dépendance |
| Azure Red Hat OpenShift | Conteneurs | Plusieurs conteneurs par nœud | 6 5 | Sans état ou avec état | Sans dépendance |
| Azure Spring Apps | Applications, microservices | Plusieurs applications par instance de service | 2 | Sans état | Intégré |
| Azure Service Fabric | Services, exécutables invités, conteneurs | Plusieurs services par machine virtuelle | 5 3 | Sans état ou avec état | Sans dépendance |
| Azure Batch | Scheduled jobs | Plusieurs applications par machine virtuelle | 1 4 | Sans état | Non |
Remarques
- Si vous utilisez un plan Consommation. Pour un plan App Service, les fonctions s’exécutent sur les machines virtuelles allouées dans le cadre de votre plan App Service. Consultez Choisir le plan de service approprié pour Azure Functions.
- Contrat de niveau de service (SLA) supérieur avec deux instances ou plus.
- Recommandé pour les environnements de production.
- Peut revenir au point d’origine une fois la tâche terminée.
- Trois pour les nœuds principaux et trois pour les nœuds Worker.
- Lors de l’utilisation de Durable Functions.
Mise en réseau
| Service | Intégration du réseau virtuel | Connectivité hybride |
|---|---|---|
| Machines virtuelles Azure | Prise en charge | Prise en charge |
| Azure App Service | Pris en charge 1 | Pris en charge 2 |
| Azure Functions | Pris en charge 1 | Pris en charge 3 |
| Azure Kubernetes Service | Pris en charge | Prise en charge |
| Azure Container Apps | Prise en charge | Prise en charge |
| Azure Container Instances | Pris en charge | Pris en charge |
| Azure Red Hat OpenShift | Pris en charge | Prise en charge |
| Azure Spring Apps | Prise en charge | Prise en charge |
| Azure Service Fabric | Prise en charge | Prise en charge |
| Azure Batch | Prise en charge | Prise en charge |
Notes
- Nécessite App Service Environment.
- Utiliser les connexions hybrides d’Azure App Service.
- Nécessite un plan App Service ou un plan Premium Azure Functions.
DevOps
| Service | Débogage local | Modèle de programmation | Mise à jour d’application |
|---|---|---|---|
| Machines virtuelles Azure | Sans dépendance | Sans dépendance | Aucune prise en charge intégrée |
| Azure App Service | IIS Express, autres 1 | Applications web et API, WebJobs pour les tâches en arrière-plan | Emplacements de déploiement |
| Azure Functions | CLI Visual Studio ou Azure Functions | Serverless, basé sur les événements | Emplacements de déploiement |
| Azure Kubernetes Service | Minikube, Docker, autres | Sans dépendance | Mise à jour propagée |
| Azure Container Apps | Runtime de conteneurs local | Sans dépendance | Gestion des révisions |
| Azure Container Instances | Runtime de conteneurs local | Sans dépendance | Non applicable |
| Azure Red Hat OpenShift | Minikube, Docker, autres | Sans dépendance | Mise à jour propagée |
| Azure Spring Apps | Visual Studio Code, Intellij, Eclipse | Spring Boot, Steeltoe | Mise à niveau propagée, déploiement bleu-vert |
| Azure Service Fabric | Cluster de nœuds local | Invité exécutable, modèle de service, modèle d’acteur, conteneurs | Mise à niveau propagée (par service) |
| Azure Batch | Non prise en charge | Application de ligne de commande | Non applicable |
Notes
- Les options incluent IIS Express pour ASP.NET ou node.js (iisnode), serveur web PHP, Azure Toolkit for IntelliJ et Azure Toolkit for Eclipse. App Service prend également en charge le débogage à distance de l’application web déployée.
Extensibilité
| Service | Mise à l’échelle automatique | Équilibrage de charge | Limite d’échelle3 |
|---|---|---|---|
| Machines virtuelles Azure | Groupes identiques de machines virtuelles | Azure Load Balancer | Image de plateforme : 1 000 nœuds par groupe identique, image personnalisée : 600 nœuds par groupe identique |
| Azure App Service | Service intégré | Intégré | 30 instances, 100 avec App Service Environment |
| Azure Functions | Service intégré | Intégré | 200 instances par application de fonction |
| Azure Kubernetes Service | Mise à l’échelle automatique de pod1, mise à l’échelle automatique de cluster2 | Azure Load Balancer ou Azure Application Gateway | 5000 nœuds lors de l’utilisation du Contrat de niveau de service de durée de bon fonctionnement |
| Azure Container Apps | Règles de mise à l'échelle4 | Intégré | 5 environnements par région, 20 applications conteneur par environnement, 30 réplicas par application de conteneur |
| Azure Container Instances | Non pris en charge | Aucune prise en charge intégrée | 20 groupes de conteneurs par abonnement (limite par défaut) |
| Azure Red Hat OpenShift | Mise à l’échelle automatique de pod, mise à l’échelle automatique de cluster | Azure Load Balancer ou Azure Application Gateway | 60 nœuds par cluster (limite par défaut) |
| Azure Spring Apps | Service intégré | Intégré | 500 instances d’application dans Standard |
| Azure Service Fabric | Groupes identiques de machines virtuelles | Azure Load Balancer | 100 nœuds par groupe de machines virtuelles identiques |
| Azure Batch | Non applicable | Azure Load Balancer | Limite de 20 cœurs (limite par défaut) |
Notes
- Consultez Mettre à l’échelle les pods automatiquement.
- Consultez Mise à l’échelle automatique d’un cluster pour répondre aux demandes applicatives d’Azure Kubernetes Service (AKS).
- Consultez l’article Abonnement Azure et limites, quotas et contraintes de service.
- Voir Définir des règles de mise à l’échelle dans Azure Container Apps.
Disponibilité
| Service | Contrat SLA | Basculement multirégion |
|---|---|---|
| Machines virtuelles Azure | Contrat SLA pour les machines virtuelles | Azure Traffic Manager, Azure Front Door et Azure Load Balancer inter-régions |
| Azure App Service | Contrat SLA pour App Service | Azure Traffic Manager et Azure Front Door |
| Azure Functions | Contrat SLA pour Azure Functions | Azure Traffic Manager et Azure Front Door |
| Azure Kubernetes Service (AKS) | SLA pour AKS | Azure Traffic Manager, Azure Front Door et cluster multirégion |
| Azure Container Apps | Contrat SLA pour Container Apps | Azure Traffic Manager et Azure Front Door |
| Azure Container Instances | Contrat SLA pour Container Instances | Azure Traffic Manager et Azure Front Door |
| Azure Red Hat OpenShift | SLA pour Azure Red Hat OpenShift | Azure Traffic Manager et Azure Front Door |
| Azure Spring Apps | Contrat de niveau de service pour Azure Spring Apps | Azure Traffic Manager, Azure Front Door et cluster multirégion |
| Azure Service Fabric | Contrat SLA pour Service Fabric | Azure Traffic Manager, Azure Front Door et Azure Load Balancer inter-régions |
| Azure Batch | Contrat SLA pour Batch | Non applicable |
Pour une formation guidée sur les garanties de service, consultez Services cloud principaux – Architecture Azure et garanties de service.
Sécurité
Examinez et comprenez les contrôles de sécurité disponibles et la visibilité pour chaque service
- Machine virtuelle Windows Azure
- Machine virtuelle Linux Azure
- Azure App Service
- Azure Functions
- Azure Kubernetes Service
- Azure Container Instances
- Azure Spring Apps
- Azure Service Fabric
- Azure Batch
Autres critères
Considérer les limites et les coûts
En plus des tableaux de comparaison précédents, effectuez une évaluation plus détaillée des aspects suivants du service candidat :
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants :
- Ayobami Ayodeji | Responsable de programme senior
- Jelle Druyts | Ingénieur service principal
- Martin Gjoshevski | Ingénieur service senior
- Phil Huang | Architecte de solutions cloud senior
- Julie Ng | Ingénieur de service senior
- Paolo Salvatori | Ingénieur des services principaux
Pour voir des profils LinkedIn privés, connectez-vous à LinkedIn.
Étapes suivantes
Services cloud principaux - Options de calcul Azure Ce module Learn explore la manière dont les services de calcul peuvent résoudre des besoins métier courants.