Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Otras consideraciones
Hasta ahora, hemos discutido el uso de API Gateway y contenedores de Windows para modernizar sus servicios web de ASP.NET heredados. AWS Estas son algunas otras consideraciones que se deben tener en cuenta:
-
Seguridad
-
Remodelación de los dominios de los servicios
-
Secuenciar las actualizaciones de los servicios web cuando hay muchos servicios que modernizar
En las próximas secciones se ofrece información sobre esto.
Autenticación y autorización
Los modernos APIs suelen utilizar los estándares de autenticación y autorización basados en tokens (JSON Web Token o JWT), como OAuth 2.0 y OpenID Connect, mientras que los servicios web de ASP.NET tradicionales se basaban tradicionalmente en la autenticación básica o en la autenticación integrada en Windows para un dominio de Windows Active Directory. Como práctica recomendada, en los casos en que los enfoques de autenticación y autorización antiguos y nuevos sean incompatibles, le recomendamos que actualice estos mecanismos de seguridad antes de modernizar su servicio web. AWS Intentar mapear identidades o intentar transferir de forma segura el estado de seguridad entre los sistemas antiguos y nuevos puede no ser un esfuerzo significativo, pero podría introducir vulnerabilidades de seguridad.
Diseño basado en el dominio
Al dividir un monolito en servicios individuales, el diseño basado en dominios (DDD) es una buena práctica que se suele utilizar para modelar los sistemas en dominios empresariales cohesivos. El DDD es un enfoque para desarrollar software para necesidades complejas que conecta la implementación con un modelo en evolución de los conceptos empresariales principales. Su premisa es centrar principalmente el proyecto en el dominio principal y en la lógica del dominio, y basar los diseños de los sistemas en un modelo que refleje el negocio. Si utiliza el DDD al modernizar una aplicación monolítica existente, debe trabajar en sentido inverso a partir de las funciones y los flujos de usuarios del monolito. Puede utilizar el DDD en combinación con el patrón estrangulador para guiar el proceso de romper el monolito y determinar qué servicios estrangular, de ahí el término diseño basado en dominios.
Estados provisionales y estado objetivo
Al modernizar más de unos pocos servicios web de ASP.NET AWS, se recomienda definir primero cuál será el estado de la arquitectura de destino una vez que se hayan modernizado todos los servicios. Sin embargo, la arquitectura de estado objetivo no es necesariamente el estado final o final, ya que los contextos empresariales cambian con frecuencia y el estado objetivo del sistema debe actualizarse según sea necesario para mantener la coherencia con los objetivos empresariales. Cuando haya definido el estado objetivo, podrá trabajar en sentido inverso para definir arquitecturas provisionales que se adapten gradualmente a la visión del estado objetivo. Puedes pensar en estas arquitecturas de estado provisional como la progresión de la higuera estranguladora hacia arriba del árbol a medida que choca con partes importantes del árbol anfitrión y las envuelve. Las arquitecturas de estado provisional suelen introducir construcciones temporales o superpuestas que no formarán parte de la arquitectura de estado final para facilitar la evolución hacia el estado de destino. La modernización del servicio web ASP.NET basado en SOAP es un ejemplo de ello: se introduce temporalmente un contenedor basado en Windows para cerrar la brecha entre los sistemas de llamadas que dependen del servicio anterior hasta que puedan actualizarse a la nueva API REST.
