Otras consideraciones

Hasta ahora, hemos hablado sobre el uso de API Gateway y contenedores de Windows para modernizar sus servicios web antiguos de ASP.NET enAWS. Estas son algunas otras consideraciones a tener en cuenta:

• Seguridad

• Remodelación del dominio del servicio

• 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

Las API modernas suelen aprovechar 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 tradicionales de ASP.NET se basaban tradicionalmente en la autenticación básica o en la autenticación integrada en Windows en un dominio de Windows Active Directory. Como práctica recomendada, en los casos en que los métodos de autenticación y autorización antiguos y nuevos sean incompatibles, le recomendamos que actualice estos mecanismos de seguridad antes de modernizar su servicio webAWS. 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 puede introducir vulnerabilidades de seguridad.

Diseño basado en dominios

Al dividir un monolito en servicios individuales, el diseño basado en dominios (DDD) es una de las mejores prácticas que se suelen utilizar para modelar sistemas en dominios empresariales cohesivos. El DDD es un enfoque para desarrollar software para necesidades complejas mediante la conexión de la implementación con un modelo en evolución de los conceptos comerciales principales. Su premisa es situar el enfoque principal del proyecto en el dominio central y la lógica del dominio, y basar los diseños de los sistemas en un modelo que refleje el negocio. Si utiliza DDD para modernizar una aplicación monolítica existente, tendrá que trabajar al revés desde las funciones y los flujos de usuarios del monolito. Puedes usar 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.NETAWS, se recomienda definir primero cuál será la arquitectura del estado objetivo una vez que se hayan modernizado todos los servicios. Sin embargo, la arquitectura del estado objetivo no es necesariamente el estado final o el estado final, ya que los contextos empresariales cambian con frecuencia y el estado objetivo del sistema debe actualizarse según sea necesario para mantenerse alineado con los objetivos empresariales. Cuando haya definido el estado objetivo, puede ir retrocediendo desde allí para definir arquitecturas de estados provisionales que cumplan gradualmente la visión del estado objetivo. Se puede pensar en estas arquitecturas estatales provisionales como la progresión de la higuera estranguladora hacia arriba del árbol cuando encuentra y engulle partes importantes del árbol huésped. Las arquitecturas de estados provisionales suelen introducir construcciones temporales o superpuestas que no formarán parte de la arquitectura del estado final para facilitar la evolución al estado objetivo. La modernización del servicio web ASP.NET basado en SOAP ofrece 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 heredado hasta que puedan actualizarse a la nueva API REST.