Recommandations sur l’hébergement Azure pour les applications web ASP.NET Core

  • Article

Conseil

Ce contenu est un extrait du livre électronique, Architect Modern Web Applications with ASP.NET Core and Azure (Architecturer des applications web modernes avec ASP.NET Core et Azure), disponible dans la documentation .NET ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.

Télécharger le PDF

Architect Modern Web Applications with ASP.NET Core and Azure eBook cover thumbnail.

« Les leaders métier ne passent plus par les départements informatiques pour obtenir des applications du cloud (également appelées SaaS) et les paient comme ils paient un abonnement à un magazine. Quand ils n’ont plus besoin du service, ils peuvent annuler l’abonnement sans se retrouver avec du matériel inutilisé dans un coin. »
– Daryl Plummer, analyste chez Gartner

Quels que soient les besoins et l’architecture de votre application, Microsoft Azure peut la prendre en charge. Vos besoins d’hébergement peuvent être aussi simples que ceux d’un site web statique ou aussi complexes que ceux d’une application sophistiquée constituée de dizaines de services. Pour les applications ASP.NET Core monolithiques et les services qui les prennent en charge, il existe plusieurs configurations connues qui sont recommandées. Les suggestions présentées dans cet article sont regroupées en fonction du type de ressource à héberger, qu’il s’agisse d’applications complètes, de processus individuels ou de données.

Applications web

Les applications web peuvent être hébergées avec :

  • App Service Web Apps

  • Conteneurs (plusieurs options)

  • Machines virtuelles (VM)

Entre tous, App Service Web Apps constitue l’approche recommandée pour la plupart des scénarios, y compris les applications conteneur simples. Pour les architectures de microservices, envisagez une approche basée sur les conteneurs. Si vous avez besoin de contrôler davantage les machines qui exécutent votre application, envisagez le service Machines virtuelles Azure.

App Service Web Apps

App Service Web Apps offre une plateforme entièrement managée, optimisée pour l’hébergement d’applications web. Il s’agit d’une offre de plateforme PaaS qui vous permet de vous concentrer sur votre logique métier, tandis qu’Azure fournit l’infrastructure nécessaire pour exécuter et mettre à l’échelle l’application. Voici quelques fonctionnalités clés d’App Service Web Apps :

  • Optimisation de DevOps (intégration et livraison continues, environnements multiples, tests A/B, prise en charge des scripts).

  • Échelle globale et haute disponibilité.

  • Connexions aux plateformes SaaS et à vos données locales.

  • Sécurité et conformité.

  • Intégration Visual Studio.

Azure App Service est le meilleur choix pour la plupart des applications web. Le déploiement et la gestion sont intégrés à la plateforme, les sites peuvent rapidement gérer des volumes importants de trafic et le gestionnaire d'équilibrage de charge et de trafic assurent une haute disponibilité. Vous pouvez déplacer facilement des sites existants vers Azure App Service avec un outil de migration en ligne. Vous pouvez utiliser une application open source à partir de la galerie d’applications web ou créer un site à l’aide de l’infrastructure et des outils de votre choix. La fonctionnalité WebJobs facilite l’ajout du traitement de travaux en arrière-plan à votre application web App Service. Si vous disposez d’une application ASP.NET existante hébergée localement à l’aide d’une base de données locale, il existe un chemin d’accès clair à migrer. Vous pouvez utiliser l’application web App Service avec une base de données Azure SQL (ou un accès sécurisé à votre serveur de base de données local, le cas échéant).

Recommended migration strategy for on-premises .NET apps to Azure App Service

Dans la plupart des cas, le déplacement d’une application ASP.NET hébergée localement vers une application web App Service est un processus simple. Peu, voire aucune, modification de l’application proprement dite devraient être nécessaires, et elle peut rapidement commencer à tirer parti des nombreuses fonctionnalités offertes par Azure App Service Web Apps.

En plus des applications qui ne sont pas optimisées pour le cloud, Azure App Service Web Apps est une excellente solution pour de nombreuses applications monolithiques (non distribuées) simples, telles que de nombreuses applications ASP.NET Core. Avec cette approche, l’architecture est simple à comprendre et à gérer :

Basic Azure architecture

Un petit nombre de ressources dans un seul groupe de ressources suffit généralement pour gérer une telle application. Les applications qui sont généralement déployées en tant qu’unité unique, plutôt que celles constituées de nombreux processus distincts, sont de bonnes candidates pour cette approche architecturale de base. Bien que simple d’un point de vue architectural, cette approche permet quand même d’effectuer un scale up (plus de ressources par nœud) et un scale out (plus de nœuds hébergés) de l’application hébergée afin de répondre à toute augmentation de la demande. Avec la mise à l’échelle automatique, l’application peut être configurée pour ajuster automatiquement le nombre de nœuds qui l’hébergent en fonction de la demande et de la charge moyenne entre les nœuds.

App Service Web Apps for Containers

Outre la prise en charge de l’hébergement direct d’applications web, App Service Web Apps for Containers peut être utilisé pour exécuter des applications en conteneur sur Windows et Linux. À l’aide de ce service, vous pouvez facilement déployer et exécuter des applications en conteneur capables d’évoluer avec votre entreprise. Les applications disposent de toutes les fonctionnalités d’App Service Web Apps mentionnées plus haut. En outre, Web Apps pour conteneurs prend en charge le CI/CD rationalisé avec Docker Hub, Azure Container Registry et GitHub. Vous pouvez utiliser Azure DevOps pour définir des pipelines de génération et de déploiement qui publient des modifications dans un registre. Ces modifications peuvent ensuite être testées dans un environnement intermédiaire et être déployées automatiquement en production à l’aide d’emplacements de déploiement, ce qui permet d’effectuer des mises à niveau sans temps d’arrêt. La restauration vers des versions précédentes est possible tout aussi facilement.

Il existe quelques scénarios dans lesquels Web Apps pour conteneurs est le plus judicieux. Si vous avez des applications que vous pouvez mettre en conteneur, que ce soit dans des conteneurs Windows ou Linux, vous pouvez les héberger facilement à l’aide de cet ensemble d’outils. Publiez simplement votre conteneur, puis configurez Web Apps pour conteneurs pour extraire la dernière version de cette image à partir de votre registre de choix. Il s’agit d’une approche « lift and shift » de la migration à partir de modèles d’hébergement d’applications classiques vers un modèle optimisé pour le cloud.

Migrate containerized on-premises .NET application to Azure Web Apps for Containers

Cette approche fonctionne également bien si votre équipe de développement est capable de basculer vers un processus de développement basé sur conteneur. La « boucle interne » du développement d’applications avec conteneurs comprend la création de l’application avec des conteneurs. Les modifications apportées au code, ainsi qu’à la configuration du conteneur, sont envoyées au contrôle de code source, et une build automatisée est responsable de la publication des nouvelles images de conteneurs vers un registre tel que Docker Hub ou Azure Container Registry. Ces images sont ensuite utilisées comme base pour les tâches de développement supplémentaires, ainsi que pour les déploiements en production, comme indiqué dans le diagramme suivant :

End to End Docker DevOps Lifecycle Workflow

Le développement avec des conteneurs offre de nombreux avantages, notamment quand les conteneurs sont utilisés en production. La même configuration de conteneur est utilisée pour héberger l’application dans chaque environnement dans lequel elle s’exécute, de l’ordinateur de développement local pour générer et tester des systèmes en production. Cette approche réduit considérablement la probabilité de défauts résultant des différences de configuration de machine ou de versions logicielles. Les développeurs peuvent également utiliser les outils avec lesquels ils sont les plus productifs, y compris le système d’exploitation, car les conteneurs peuvent s’exécuter sur n’importe quel système d’exploitation. Dans certains cas, l’exécution sur un seul ordinateur de développement d’applications distribuées impliquant de nombreux conteneurs peut être très gourmande en ressources. Dans ce scénario, il peut être judicieux d’utiliser plutôt Kubernetes et Azure Dev Spaces, qui sont décrits dans la section suivante.

À mesure que les différentes parties des applications de grande taille sont divisées en leurs propres microservices plus petits et indépendants, vous pouvez recourir à des modèles de conception supplémentaires pour améliorer le comportement de l’application. Au lieu de travailler directement avec chacun des services, vous pouvez utiliser une passerelle API pour simplifier l’accès et découpler le client de son back-end. Disposer de back-ends de services distincts pour différents front-ends permet également aux services d’évoluer de concert avec leurs consommateurs. Les services communs sont accessibles par le biais d’un conteneur sidecar distinct, qui peut inclure des bibliothèques de connectivité client courantes avec le modèle ambassadeur.

Microservices sample architecture with several common design patterns noted.

Apprenez-en davantage sur les modèles de conception à prendre en compte lors de la création de systèmes basés sur des microservices.

Azure Kubernetes Service

Azure Kubernetes Service (AKS) gère votre environnement Kubernetes hébergé, accélérant et facilitant ainsi le déploiement et la gestion des applications conteneurisées sans expertise d’orchestration de conteneur. Il élimine aussi les contraintes liées aux opérations et à la maintenance continues en provisionnant, en mettant à niveau et en mettant à l’échelle les ressources à la demande, sans déconnecter vos applications.

AKS permet de réduire la complexité et la surcharge opérationnelle de la gestion d’un cluster Kubernetes en déléguant une grande partie de cette responsabilité à Azure. En tant que service Kubernetes hébergé, Azure gère pour vous des tâches critiques telles que l’analyse de l'intégrité et la maintenance. Par ailleurs, vous payez uniquement pour les nœuds d’agent de vos clusters, pas pour les maîtres. En tant que service Kubernetes géré, AKS fournit :

  • Des mises à niveau de version et des mises à jour correctives Kubernetes automatisées.
  • Une mise à l’échelle simplifiée des clusters.
  • Un plan de contrôle hébergé avec auto-réparation (maîtres).
  • Une réduction des coûts : vous payez uniquement pour les nœuds de pool d’agents qui s’exécutent.

Comme Azure gère la gestion des nœuds de votre cluster AKS, vous n’avez plus besoin d'effectuer les tâches manuellement, notamment les mises à niveau du cluster. Comme Azure gère ces tâches de maintenance critiques à votre place, AKS ne fournit pas d’accès direct (comme avec SSH) au cluster.

Les équipes qui tirent parti d’AKS peuvent également tirer parti d’Azure Dev Spaces. Grâce à Azure Dev Spaces, les équipes peuvent se concentrer sur le développement et l’itération rapide de leur application de microservices en exploitant directement leur architecture complète de microservices ou une application en cours d’exécution dans AKS. Azure Dev Spaces permet également de mettre à jour de façon indépendante certaines parties de votre architecture de microservices, sans affecter le reste du cluster AKS ou d’autres développeurs.

Azure Dev Spaces workflow example

Azure Dev Spaces :

  • Limite le temps et les ressources nécessaires pour configurer l’ordinateur local.
  • Permet aux équipes d’effectuer une itération plus rapidement.
  • Réduire le nombre d’environnements d’intégration requis par une équipe
  • Supprimer la nécessité de simuler certains services dans un système distribué lors du développement/test

En savoir plus sur Azure Dev Spaces

Machines virtuelles Azure

Si vous avez une application existante qui nécessite des modifications substantielles pour s’exécuter dans App Service, vous pouvez choisir Machines virtuelles afin de simplifier la migration vers le cloud. Cependant, la configuration, la sécurisation et la gestion des machines virtuelles nécessitent beaucoup plus de temps et d’expertise en informatique comparé à Azure App Service. Si vous envisagez d’utiliser Machines virtuelles Azure, veillez à prendre en compte le travail continu de maintenance nécessaire pour appliquer les correctifs, mettre à jour et gérer votre environnement de machines virtuelles. Machines virtuelles Azure est une infrastructure IaaS, tandis qu’App Service est une plateforme Paas. Vous devez également déterminer si le déploiement de votre application comme conteneur Windows dans Web App pour conteneurs est une option viable pour votre scénario.

Processus logiques

Les processus logiques individuels qui peuvent être dissociés du reste de l’application peuvent être déployés indépendamment sur Azure Functions de manière « serveless ». Azure Functions vous permet de simplement écrire le code dont vous avez besoin pour un problème donné, sans se préoccuper de l’application ou de l’infrastructure pour l’exécuter. Vous pouvez choisir parmi une variété de langages de programmation, notamment C#, F#, Node.js, Python et PHP, ce qui vous permet de choisir le langage le plus productif pour la tâche à traiter. Comme la plupart des solutions cloud, vous payez seulement pour la durée de votre utilisation, et vous pouvez faire confiance à Azure Functions pour monter en puissance au fil des besoins.

Données

Azure propose un large éventail d’options de stockage des données, afin que votre application puisse utiliser le fournisseur de données approprié pour les données en question.

Pour les données transactionnelles relationnelles, les bases de données Azure SQL Database sont la meilleure option. Pour de hautes performances avec les données qui sont principalement en lecture, un cache Redis s’appuyant sur une base de données Azure SQL Database est une bonne solution.

Les données JSON non structurées peuvent être stockées de différentes manières, de colonnes SQL Database aux objets blob ou tables du Stockage Azure vers Azure Cosmos DB. Parmi ceux-ci, Azure Cosmos DB offre la meilleure fonctionnalité d’interrogation et est l’option recommandée pour un grand nombre de documents JSON qui doivent prendre en charge l’interrogation.

Les données basées sur des commandes ou des événements transitoires pour orchestrer le comportement des applications peuvent utiliser Azure Service Bus ou Stockage File d’attente Azure. Azure Service Bus offre plus de flexibilité et est le service recommandé pour la messagerie non triviale au sein et entre les applications.

Suggestions en matière d’architecture

Les exigences de votre application doivent dicter son architecture. Il existe de nombreux services Azure différents. Aussi, il est important de choisir le bon. Microsoft propose une galerie d’architectures de référence pour aider à identifier des architectures classiques optimisées pour les scénarios courants. Vous pouvez adopter une architecture de référence qui correspond de près aux exigences de votre application ou qui constitue au moins un point de départ.

La figure 11-1 montre un exemple d’architecture de référence. Ce diagramme décrit une approche recommandée pour l’architecture d’un site web de système de gestion de contenu Sitecore optimisé pour le marketing.

Figure 11-1

Figure 11-1 : Architecture de référence d’un site web de marketing Sitecore.

Informations de référence : recommandations sur l’hébergement Azure

Précédent