Choisir un service de calcul Azure pour votre application

Azure offre de nombreuses manières d’héberger votre code d’application. Le terme calcul fait référence au modèle d’hébergement des ressources de calcul utilisées par votre application. L’organigramme suivant vous aidera à choisir un service de calcul pour votre application.

Si votre application comprend plusieurs charges de travail, évaluez-les séparément. Une solution complète peut incorporer deux services de calcul ou plus.

Choisir un service candidat

Utilisez l’organigramme suivant pour sélectionner un service de calcul candidat.

Arbre de décision des services de calcul Azure

Définitions :

  • « lift-and-shift » qualifie une stratégie de migration de charge de travail vers le cloud sans reconception de l’application ou modification de 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.

Le résultat de cet organigramme est un point de départ à prendre en considération. Ensuite, effectuez une évaluation plus détaillée du service pour voir s’il répond à vos besoins.

Cet article comprend plusieurs tableaux susceptibles de vous aider à prendre ces décisions. Sur la base de cette analyse, il se peut que vous constatiez que le candidat initial n’est pas adapté à votre application ou charge de travail particulière. Dans ce cas, élargissez votre analyse pour inclure d’autres services de calcul.

Notes

Apprenez-en davantage sur la révision de votre configuration informatique requise pour l’adoption du cloud dans le Microsoft Cloud Adoption Framework pour Azure.

Comprendre les fonctionnalités de base

Si vous n’êtes pas familiarisé avec le service Azure sélectionné à l’étape précédente, consultez la documentation de présentation pour comprendre les principes de base du service.

  • 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 Spring Cloud. Service géré conçu et optimisé pour l’hébergement d’applications Spring Boot.
  • Azure Kubernetes Service (AKS). Service Kubernetes géré pour l’exécution d’applications en conteneur.
  • Batch. Service géré qui permet d’exécuter des applications de calcul haute performance (HPC) et parallèles à grande échelle.
  • Container Instances. Façon la plus simple et rapide d’exécuter un conteneur dans Azure, sans devoir approvisionner des machines virtuelles ou adopter un service de niveau supérieur.
  • Fonctions. Service FaaS géré.
  • Service Fabric. Plateforme de systèmes distribués qui peut s’exécuter dans de nombreux environnements, dont Azure ou localement.
  • Machines virtuelles. Déployez et gérez des machines virtuelles à l’intérieur d’un réseau virtuel Azure.

Comprendre les modèles d’hébergement

Les services Cloud, y compris les services Azure, appartiennent généralement à trois catégories : IaaS, PaaS ou FaaS. (Il existe également la catégorie SaaS, software as a service, qui sort du cadre de cet article.) Il est utile de comprendre les différences.

L’infrastructure as a service (IaaS) vous permet de configurer des machines virtuelles individuelles avec les composants de mise en réseau et de stockage associés. Ensuite, vous déployez les logiciels et les applications dont vous souhaitez disposer sur ces machines virtuelles. Ce modèle est le plus proche d’un environnement local traditionnel, à ceci près que l’infrastructure est gérée par Microsoft. Vous continuez de gérer les différentes machines virtuelles.

La fonctionnalité 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 est un service PaaS.

La fonctionnalité Functions as a Service (FaaS) se révèle encore plus complète en vous évitant d’avoir à vous soucier de l’environnement d’hébergement. Dans un modèle FaaS, vous déployez simplement votre code et le service l’exécute automatiquement. Azure Functions est un exemple de service FaaS.

Notes

Azure Functions est une offre de calcul Azure serverless. Vous pouvez lire l’article Choisir les services d’intégration et d’automatisation appropriés dans Azure pour avoir une comparaison de ce service avec d’autres offres Azure serverless, par exemple Logic Apps qui fournit des workflows serverless.

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é de mise à l’échelle automatique n’est pas strictement PaaS, mais il s’agit du type de fonctionnalité de gestion que l’on trouve dans des services PaaS.

En général, 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. Les services PaaS se situent entre les deux.

Critères Virtual Machines App Service Azure Spring Cloud Service Fabric Azure Functions Azure Kubernetes Service Container Instances Azure Batch
Composition de l’application Sans dépendance Applications, conteneurs Applications, microservices Services, exécutables invités, conteneurs Fonctions Containers Containers Scheduled jobs
Densité Sans dépendance Plusieurs applications par instance via des plans App Service Plusieurs applications par instance de service Plusieurs services par machine virtuelle Serverless 1 Plusieurs conteneurs par nœud Aucune instance dédiée Plusieurs applications par machine virtuelle
Nombre minimal de nœuds 1 2 1 2 5 3 Serverless 1 3 3 Aucun nœud dédié 1 4
Gestion de l'état Sans état ou avec état Sans état Sans état Sans état ou avec état Sans état Sans état ou avec état Sans état Sans état
Hébergement web Sans dépendance Intégré Intégré Sans dépendance Non applicable Sans dépendance Sans dépendance Non
Peut être déployé vers le réseau virtuel dédié ? Prise en charge Pris en charge5 Prise en charge Prise en charge Pris en charge 5 Pris en charge Pris en charge Prise en charge
Connectivité hybride Prise en charge Pris en charge 6 Prise en charge Prise en charge Pris en charge 7 Prise en charge Non pris en charge Prise en charge

Notes

  1. Avec utilisation d’un plan de consommation. Si vous utilisez un plan App Service, les fonctions sont exécutées sur les machines virtuelles allouées dans le cadre de votre plan App Service. Voir Choisir le plan de service approprié pour Azure Functions.
  2. SLA supérieur avec deux instances ou plus.
  3. Recommandé pour les environnements de production.
  4. Peut revenir au point d’origine une fois la tâche terminée.
  5. Nécessite un environnement App Service Environment (ASE).
  6. Utiliser les connexions hybrides d’Azure App Service.
  7. Nécessite un plan App Service ou un plan Premium Azure Functions.

DevOps

Critères Virtual Machines App Service Azure Spring Cloud Service Fabric Azure Functions Azure Kubernetes Service Container Instances Azure Batch
Débogage local Sans dépendance IIS Express, autres 1 Visual Studio Code, Intellij, Eclipse Cluster de nœuds local CLI Visual Studio ou Azure Functions Minikube, autres Runtime de conteneurs local Non pris en charge
Modèle de programmation Sans dépendance Applications web et API, WebJobs pour les tâches en arrière-plan Spring Boot, Steeltoe Invité exécutable, modèle de service, modèle d’acteur, conteneurs Fonctions avec déclencheurs Sans dépendance Sans dépendance Application de ligne de commande
Mise à jour d’application Aucune prise en charge intégrée Emplacements de déploiement Mise à niveau propagée, déploiement bleu-vert Mise à niveau propagée (par service) Emplacements de déploiement Mise à jour propagée Non applicable

Notes

  1. Les options incluent IIS Express pour ASP.NET ou node.js (iisnode) ; le serveur web PHP ; le kit de ressources Azure pour IntelliJ et le kit de ressources Azure pour Eclipse. App Service prend également en charge le débogage à distance de l’application web déployée.
  2. Voir Fournisseurs, régions, schémas et versions d’API du Gestionnaire des ressources.

Extensibilité

Critères Virtual Machines App Service Azure Spring Cloud Service Fabric Azure Functions Azure Kubernetes Service Container Instances Azure Batch
Mise à l’échelle automatique Groupes identiques de machines virtuelles Service intégré Service intégré Groupes identiques de machines virtuelles Service intégré Mise à l’échelle automatique de pod1, mise à l’échelle automatique de cluster2 Non pris en charge N/A
Équilibrage de charge Azure Load Balancer Intégré Intégré Azure Load Balancer Intégré Azure Load Balancer ou Application Gateway Aucune prise en charge intégrée Azure Load Balancer
Limite d’échelle3 Image de plateforme : 1 000 nœuds par groupe identique, image personnalisée : 600 nœuds par groupe identique 30 instances, 100 avec App Service Environment 500 instances d’application dans Standard 100 nœuds par groupe identique 200 instances par application de fonction 100 nœuds par cluster (limite par défaut) 20 groupes de conteneurs par abonnement (limite par défaut). Limite de 20 cœurs (limite par défaut).

Notes

  1. Consultez Mettre à l’échelle les pods automatiquement.
  2. Consultez Mise à l’échelle automatique d’un cluster pour répondre aux demandes applicatives d’Azure Kubernetes Service (AKS).
  3. Consultez l’article Abonnement Azure et limites, quotas et contraintes de service.

Disponibilité

Critères Virtual Machines App Service Azure Spring Cloud Service Fabric Azure Functions Azure Kubernetes Service Container Instances Azure Batch
Contrat SLA Contrat SLA pour les machines virtuelles Contrat SLA pour App Service SLA pour Azure Spring Cloud Contrat SLA pour Service Fabric Contrat SLA pour Azure Functions SLA pour AKS Contrat SLA pour Container Instances Contrat SLA pour Azure Batch
Basculement multirégion Traffic Manager Traffic Manager Traffic Manager, cluster multirégion Azure Front Door Traffic Manager Non pris en charge Non pris en charge

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é et la visibilité disponibles pour chaque service

Autres critères

Critères Virtual Machines App Service App Spring Cloud Service Fabric Azure Functions Azure Kubernetes Service Container Instances Azure Batch
SSL Configuré au niveau de la machine virtuelle Prise en charge Prise en charge Prise en charge Prise en charge Contrôleur d’entrée Utilisez le conteneur side-car Prise en charge
Coût Windows, Linux Tarification d’App Service Tarification d’Azure Spring Cloud Tarification de Service Fabric Tarification d’Azure Functions Tarification d’AKS Tarification Container Instances Tarification d’Azure Batch
Styles d’architecture compatibles Multiniveau, Big Compute (HPC) Web-File d’attente-Worker, Multiniveau Spring Boot, Microservices Microservices, architecture basée sur les événements Microservices, architecture basée sur les événements Microservices, architecture basée sur les événements Microservices, automatisation des tâches, programmes de traitement par lots Big Compute (HPC)

Le résultat de cet organigramme est un point de départ à prendre en considération. Ensuite, effectuez une évaluation plus détaillée du service pour voir s’il répond à vos besoins.

Considérer les limites et les coûts

Effectuez une évaluation plus détaillée, en examinant les aspects suivants du service :

Étapes suivantes