Autres considérations

Jusqu'à présent, nous avons discuté de l'utilisation d'API Gateway et de conteneurs Windows pour moderniser vos anciens services Web ASP.NET surAWS. Voici quelques autres considérations à prendre en compte :

Les détails correspondants sont présentés dans les sections suivantes.

Authentification et autorisation

Les API modernes s'appuient généralement sur des normes d'authentification et d'autorisation basées sur des jetons (JSON Web Token ou JWT) telles que OAuth 2.0 et OpenID Connect, alors que les anciens services Web ASP.NET reposaient traditionnellement sur une authentification de base ou une authentification intégrée à Windows pour un domaine Windows Active Directory. À titre de bonne pratique, dans les cas où les anciennes et les nouvelles approches d'authentification et d'autorisation sont incompatibles, nous vous recommandons de mettre à niveau ces mécanismes de sécurité avant de moderniser votre service Web surAWS. Tenter de cartographier les identités ou de transférer en toute sécurité l'état de sécurité entre l'ancien et le nouveau système peut ne pas représenter un effort important, mais cela peut introduire des failles de sécurité.

Conception axée sur le domaine

Lorsqu'il s'agit de scinder un monolithe en services individuels, la conception pilotée par domaine (DDD) est une bonne pratique souvent utilisée pour modéliser les systèmes dans des domaines commerciaux cohérents. DDD est une approche visant à développer des logiciels pour des besoins complexes en connectant la mise en œuvre à un modèle évolutif des concepts commerciaux fondamentaux. Son principe est de mettre l'accent principal du projet sur le domaine principal et la logique du domaine, et de baser la conception des systèmes sur un modèle qui reflète l'entreprise. Si vous utilisez DDD lorsque vous modernisez une application monolithique existante, vous devez revenir en arrière par rapport aux fonctionnalités et aux flux d'utilisateurs du monolithe. Vous pouvez utiliser le DDD en combinaison avec le modèle d'étranglement pour guider le processus de rupture du monolithe et déterminer les services à étrangler, d'où le terme de conception axée sur le domaine.

États intérimaires et État cible

Lorsque vous modernisez plusieurs services Web ASP.NET surAWS, il est recommandé de définir d'abord quelle sera votre architecture d'État cible une fois tous les services modernisés. Cependant, l'architecture de l'état cible n'est pas nécessairement l'état final ou l'état final, car les contextes commerciaux changent souvent et l'état cible du système doit être mis à jour selon les besoins pour rester aligné sur les objectifs commerciaux. Lorsque vous avez défini l'état cible, vous pouvez revenir en arrière à partir de là pour définir des architectures d'états intermédiaires qui répondent progressivement à la vision de l'état cible. Vous pouvez considérer ces architectures intérimaires comme la progression du figuier étrangleur le long de l'arbre au fur et à mesure qu'il rencontre et engloutit une grande partie de l'arbre hôte. Les architectures d'états intermédiaires introduisent souvent des constructions temporaires ou superposées qui ne feront pas partie de l'architecture de l'état final afin de faciliter l'évolution vers l'état cible. La modernisation du service Web ASP.NET basé sur SOAP en fournit un exemple : un conteneur Windows est introduit temporairement pour combler le fossé entre les systèmes d'appel qui dépendent de l'ancien service jusqu'à ce qu'ils puissent être mis à niveau vers la nouvelle API REST.