Lire en anglais

Partager via


Choisir l’option d’hébergement Azure appropriée

Cert article évoque les aspects à prendre en compte et compare les différents choix qui s’offrent à vous lorsque vous migrez vos applications .NET Framework existantes sur site vers Azure.

Les zones fondamentales à prendre en considération lors de la migration d’applications .NET existantes vers Azure sont les suivantes :

  1. Choix de calcul
  2. Choix de la base de données
  3. Considérations relatives au réseau et à la sécurité
  4. Considérations relatives à l’authentification et à l’autorisation

Choix de calcul

Lorsque vous migrez des applications .NET Framework existantes vers Azure, plusieurs choix s’offrent à vous. Toutefois, étant donné que .NET Framework dépend de Windows, les choix suivants sont limités aux services de calcul basés sur Windows.

Le tableau suivant comporte plusieurs comparaisons et recommandations qui vont vous aider à choisir le chemin de migration de calcul adapté à votre application .NET. existante.

Machines virtuelles Azure Azure App Service Conteneurs Windows
Quand utiliser
  • L’application dépend fortement des installations .msi en local et sur le serveur.
  • Vous recherchez le chemin de migration d’application le plus simple qui soit
L’application ne dispose d’aucune dépendance sur le serveur. Il s’agit simplement d’une application web ASP.NET propre (MVC, Web Forms) ou d’une application multiniveau (API web, WCf) accédant à un serveur de base de données.
  • L’application possède des dépendances sur le serveur d’origine, mais ces dernières peuvent être incluses dans l’image Windows Docker.
Avantages
  • Le chemin de migration le plus simple
  • Un environnement familier. L’environnement de déploiement est une machine virtuelle similaire à celle se trouvant sur les serveurs locaux.
La maintenance PaaS continue est la façon la plus simple de gérer et de mettre à l’échelle des applications dans Azure.
  • Une application évolutive, compatible avec Cloud DevOps dotée de dépendances incluses dans les conteneurs de l’application.
  • Il n’est quasiment pas nécessaire de refactoriser le code .NET /C#.
Inconvénients Il s’agit d’une IaaS. La maintenance est coûteuse. Vous devez gérer l’infrastructure de la machine virtuelle concernant la mise en réseau, l’équilibreur de charge, le scale-out, la gestion IIS, etc.
  • Toutes les applications ne sont pas prises en charge.
  • Certaines applications peuvent nécessiter une refactorisation et même une légère restructuration pour une prise en charge d’Azure App Service.
  • Courbe d’apprentissage des compétences de Docker
  • Modification de certains paramètres de configuration d’application et de code
Configuration requise Machine virtuelle Windows Server avec la même configuration que l’application pour un environnement local Exigences d’Azure App Service spécifiées dans les vérifications de préparation.
Comment migrer Voir Migrate to Azure Virtual Machines (Migrer vers des machines virtuelles Azure) Voir Migrate Azure App Service (Migrer Azure App Service) Suivez les considérations, les scénarios et les procédures pas à pas évoqués dans le livre électronique sur la modernisation des applications .NET existantes avec des conteneurs Azure et Windows

L’organigramme suivant montre un arbre de décision lors de la planification d’une migration vers Azure pour vos applications .NET Framework existantes. Si elle est viable, essayez d’abord l’option A, mais l’option B est le chemin le plus simple à suivre.

Flowchart showing hosting decision tree

Choix de la base de données

Lorsque vous migrez des bases de données relationnelles vers Azure, plusieurs choix s’offrent à vous. Consultez Migrer votre base de données SQL Server vers Azure SQL Database pour vous aider à choisir le chemin de migration de base de données adapté pour votre application .NET existante.

Considérations relatives au réseau et à la sécurité

Lors du déploiement d’applications dans un cloud public comme Microsoft Azure, vous souhaiterez peut-être isoler et sécuriser certains réseaux en créant des DMZ de réseau, comme un DMZ entre Azure et l’environnement local ou un DMZ entre Azure et Internet. Les DMZ peuvent être implémentés avec un réseau virtuel Azure.

Grâce aux réseaux virtuels Azure vous pouvez :

  • Créer une infrastructure hybride que vous contrôlez
  • Utiliser vos propres adresses IP et serveurs DNS
  • Sécuriser vos connexions avec un VPN IPsec ou ExpressRoute
  • Profiter d’un contrôle granulaire du trafic entre les sous-réseaux
  • Créer des topologies réseau sophistiquées avec les appliances virtuelles
  • Vous bénéficiez d’un environnement isolé et très sécurisé pour vos applications

Pour commencer à créer votre propre réseau virtuel, consultez la documentation relative au réseau virtuel Azure.

Considérations relatives à l’authentification et à l’autorisation lors de migration vers Azure

La sécurité est la priorité de toute organisation migrant vers le cloud. La plupart des entreprises ont beaucoup investi en termes de temps, d’argent et d’ingénierie dans la conception et le développement d’un modèle de sécurité et il est important qu’elles soient en mesure de tirer parti des investissements existants, tels que des magasins d’identités et des solutions à authentification unique.

Nombreuses sont les applications B2E .NET d’entreprise existantes s’exécutant sur site à utiliser Active Directory pour l’authentification et la gestion des identités. Azure AD Connect permet d’intégrer vos répertoires locaux à Azure Active Directory. Pour commencer, consultez Intégrer vos répertoires locaux à Azure Active Directory.

Consultez Identity requirements for your hybrid identity solution (Exigences relatives à l’identité pour votre solution d’identité hybride) pour améliorer la planification relative à Azure Active Directory.

Les autres choix de protocole d’authentification sont OAuth et OpenID, qui sont courants dans les applications destinées aux consommateurs. Lorsque vous utilisez des bases de données d’identité autonomes, par exemple une base de données ASP.NET Identity SQL encapsulée par IdentityServer4 utilisant OAuth, aucune connectivité aux bases de données ou répertoires locaux n’est généralement requise.

Étapes suivantes