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.
Ce diagramme fait référence à ces deux stratégies de migration :
- L’opération « lift-and-shift » est une stratégie visant à migrer une charge de travail vers le cloud sans reconcevoir l’application ou modifier le code. Elle est également appelée ré-hébergement. Pour plus d’informations, consultez le Centre de modernisation et de migration Azure.
- Optimisé pour le cloud est une stratégie visant à migrer vers le cloud par la refactorisation d’une application, pour tirer parti des fonctionnalités cloud natives.
La sortie de cet organigramme est votre point de départ. Ensuite, évaluez le service plus en détail 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 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 métier automatisés.
- Azure Functions. Service FaaS (Function as a Service) managé.
- Azure Kubernetes Service (AKS). Service Kubernetes géré pour l’exécution d’applications en conteneur.
- Azure Container Apps. Un service managé basé sur Kubernetes, qui simplifie le déploiement d’applications conteneurisées dans un environnement serverless.
- Azure Container Instances. Ce service constitue un moyen rapide et simple d’exécuter un conteneur dans Azure. Vous n’avez pas besoin de provisionner des machines virtuelles ou d’adopter un service de niveau supérieur.
- Azure Red Hat OpenShift. Un cluster OpenShift entièrement géré 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, dont Azure ou localement.
- Azure Batch. Service géré pour 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 en tant que service (IaaS) vous permet de provisionner des machines virtuelles avec les composants réseau et de stockage associés. Vous déployez ensuite 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 et vous continuez à gérer les machines virtuelles.
Platform-as-a-Service (PaaS) offre un environnement d’hébergement managé dans lequel vous pouvez déployer votre application sans avoir à gérer les machines virtuelles ou les 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, les machines virtuelles Azure peuvent automatiquement être mises à l’échelle à 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 provisionner, 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 de plans 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.
- 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 au 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 un environnement App Service Environment (ASE).
- 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 pris 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 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 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 | SLA pour AKS | Azure Traffic Manager, Azure Front Door et cluster multirégion |
| Azure Container Apps | SLA pour Azure 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 Azure 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.
Auteurs principaux :
- 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 afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Services cloud principaux - Options de calcul Azure Ce module Microsoft Learn explore la manière dont les services de calcul peuvent résoudre des besoins métier courants.