Migración de una aplicación web mediante Azure API Management
En este escenario, una empresa de comercio electrónico del sector de viajes migra una aplicación web heredada mediante Azure API Management. La nueva interfaz de usuario se hospedará como una aplicación de plataforma como servicio (PaaS) en Azure y dependerá de las API HTTP nuevas y existentes. Estas API se entregarán con un conjunto de interfaces mejor diseñado que permita un mejor rendimiento y facilite la integración y la extensibilidad futura.
Arquitectura
Descargue un archivo de Visio de esta arquitectura.
Flujo de trabajo
- La aplicación web local existente continua con el consumo directo de los servicios web locales existentes.
- Las llamadas desde la aplicación web existente a los servicios HTTP existentes permanecen sin cambios. Estas llamadas son internas en la red corporativa.
- Las llamadas entrantes se realizan desde Azure a los servicios internos existentes:
- El equipo de seguridad permite que el tráfico de la instancia de API Management pase el firewall corporativo a los servicios locales existentes mediante el transporte seguro (HTTPS o SSL).
- El equipo de operaciones solo permite las llamadas entrantes a los servicios desde la instancia de API Management. Cumple este requisito agregando la dirección IP de la instancia de API Management a la lista de permitidos dentro del perímetro de red corporativa.
- Un nuevo módulo se configura en la canalización de solicitudes local para los servicios HTTP (para actuar solo en conexiones que se originan externamente). La canalización valida un certificado que proporciona API Management.
- La nueva API:
- Se expone solo mediante la instancia de API Management, que proporciona la fachada de la API. No se accede a la nueva API directamente.
- Se desarrolla y publica como una aplicación de API web paaS de Azure.
- Está configurado (mediante la configuración de la característica Web Apps de Azure App Service) para aceptar solo la dirección IP virtual (VIP) de API Management.
- Se hospeda en Web Apps con el transporte seguro (HTTPS o SSL) activado.
- Tiene habilitada la autorización, proporcionada por Azure App Service a través de Microsoft Entra ID y Open Authorization (OAuth) 2.
- La nueva aplicación web basada en explorador depende de la instancia de Azure API Management para la API HTTP existente y la nueva API.
- La empresa de comercio electrónico de viajes ahora puede dirigir a algunos usuarios a la nueva interfaz de usuario (para la versión preliminar o pruebas) a la vez que conserva la interfaz de usuario antigua y la funcionalidad existente en paralelo.
La instancia de API Management se configura para asignar los servicios HTTP heredados a un nuevo contrato de API. En esta configuración, la nueva interfaz de usuario web no es consciente de la integración con un conjunto de servicios y API heredadas y nuevas API.
En el futuro, el equipo del proyecto migrará gradualmente la funcionalidad a las nuevas API y retirará los servicios originales. El equipo controlará estos cambios dentro de la configuración de API Management, dejando la interfaz de usuario de front-end sin verse afectada y evitando el trabajo de redesarrollo.
Componentes
- Azure API Management abstrae las API de back-end, así como la adición de funcionalidades transversales y detección para desarrolladores y aplicaciones. En este escenario, la recomposición de las API de back-end heredadas existentes y la adición de nuevas funcionalidades de API se hace posible mediante API Management como fachada para que la nueva aplicación cliente consuma de forma coherente y con estándares modernos. Dado que API Management se basa tanto en las API existentes como en las nuevas, los desarrolladores pueden modernizar los back-end heredados detrás de la fachada de API Management de forma iterativa y con un impacto mínimo o nulo en el desarrollo del nuevo front-end.
- Azure App Service es un servicio de plataforma como servicio (PaaS) llave en clave para el hospedaje web que proporciona características integradas, como seguridad, equilibrio de carga, escalado automático y administración automatizada. Azure App Service es una excelente opción para las nuevas API que se desarrollan para esta solución, ya que proporciona hospedaje flexible de uso inmediato, lo que permite al equipo de DevOps centrarse en la entrega de características.
Alternativas
Si la organización planea mover la infraestructura completamente a Azure, incluidas las máquinas virtuales (VM) que hospedan las aplicaciones heredadas, API Management todavía es una buena opción, ya que puede actuar como una fachada para cualquier punto de conexión HTTP direccionable.
Si la organización había decidido mantener los puntos de conexión existentes privados y no exponerlos públicamente, la instancia de API Management de la organización podría estar vinculada a una instancia de Azure Virtual Network:
- Cuando API Management está vinculado a una red virtual de Azure, la organización podría dirigir directamente el servicio back-end a través de direcciones IP privadas.
- En el escenario local, la instancia de API Management podría volver a ponerse en contacto con el servicio interno de forma privada a través de una instancia de Azure VPN Gateway y una conexión VPN de protocolo de Internet (IPsec) de sitio a sitio o Azure ExpressRoute. Este escenario se convertirá en un híbrido de Azure y local.
La organización puede mantener privada la instancia de API Management mediante su implementación en modo interno. Después, la organización puede usar la implementación con Azure Application Gateway para habilitar el acceso público para algunas API, mientras que otras siguen siendo internas. Para más información, consulte Integración de API Management en una red virtual interna con Application Gateway.
La organización puede decidir hospedar sus API en el entorno local. Un motivo de este cambio podría ser que la organización no pudo mover las dependencias de base de datos de bajada que están en el ámbito de este proyecto a la nube. Si es así, la organización puede seguir aprovechando API Management localmente mediante una puerta de enlace autohospedada.
La puerta de enlace autohospedada es una implementación contenedorizada de la puerta de enlace de API Management que se conecta de nuevo a Azure en un socket de salida. El primer requisito previo es que las puertas de enlace autohospedadas no se pueden implementar sin un recurso primario en Azure, lo que conlleva un cargo adicional. En segundo lugar, se requiere el nivel Premium de API Management.
Detalles del escenario
Una empresa de comercio electrónico del sector del turismo va a modernizar su pila de software heredado basado en explorador. Aunque la pila existente es principalmente monolítica, algunos servicios HTTP basados en protocolo simple de acceso a objetos (SOAP) existen desde un proyecto reciente. La empresa está planteando la creación de flujos de ingresos adicionales para rentabilizar parte de la propiedad intelectual interna que ha desarrollado.
Los objetivos del proyecto incluyen la solución de la deuda técnica, la mejora del mantenimiento continuo y la aceleración del desarrollo de características con menos errores de regresión. El proyecto usará un proceso iterativo para evitar el riesgo, con algunos pasos que se realizan en paralelo:
- El equipo de desarrollo modernizará el back-end de la aplicación, que consiste en bases de datos relacionales hospedadas en máquinas virtuales.
- El equipo de desarrollo interno de la empresa escribirá nuevas funcionalidades de negocio que se expondrán mediante nuevas API de HTTP.
- Un equipo de desarrollo subcontratado creará una nueva interfaz de usuario basada en explorador, que se hospedará en Azure.
Las nuevas características de la aplicación se entregará en fases. Dichas características reemplazarán gradualmente la funcionalidad de la interfaz de usuario cliente-servidor basada en explorador existente (hospedada en el entorno local) que ahora impulsa el negocio de comercio electrónico de la empresa.
Los miembros del equipo de administración no quieren modernizar innecesariamente. También desean mantener el control del ámbito y los costos. Para ello, se ha decidido mantener los servicios HTTP SOAP existentes. También pretenden minimizar los cambios en la interfaz de usuario existente. Pueden usar Azure API Management para abordar muchos de los requisitos y restricciones del proyecto.
Posibles casos de uso
En este escenario se resalta la modernización de las pilas de software heredadas basadas en exploradores.
Puede usar este escenario para:
- Ver cómo su empresa puede beneficiarse del uso del ecosistema de Azure.
- Planear la migración de servicios a Azure.
- Obtener información sobre cómo un cambio a Azure afectaría a las API existentes.
Consideraciones
Estas consideraciones implementan los pilares de Azure Well-Architected Framework, que es un conjunto de principios rectores que puede usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Well-Architected Framework.
Confiabilidad
La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.
- Considere la posibilidad de implementar la instancia de Azure API Management con zonas de disponibilidad habilitadas. La opción de implementar API Management en zonas de disponibilidad solo está disponible en el nivel de servicio Premium.
- Las zonas de disponibilidad se pueden usar junto con instancias de puerta de enlace adicionales implementadas en diferentes regiones. Esto mejora la disponibilidad del servicio si una región se queda sin conexión. La implementación en varias regiones también está disponible solo en el nivel de servicio Premium.
- Considere la posibilidad de integrar con Azure Application Insights, que también expone las métricas a través de Azure Monitor para la supervisión. Por ejemplo, la métrica de capacidad se puede usar para determinar la carga general en el recurso de API Management y si se requieren unidades de escalado horizontal adicionales. El seguimiento de la capacidad y el estado de los recursos mejora la confiabilidad.
- Asegúrese de que las dependencias descendentes, por ejemplo, los servicios back-end que hospedan las API en las que se basa API Management, también sean resistentes.
Optimización de costos
La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costos.
API Management se ofrece en cuatro niveles: Desarrollador, Básico, Estándar y Premium. Para obtener instrucciones detalladas sobre las diferencias en estos niveles, consulte la guía de precios de Azure API Management.
Puede escalar API Management agregando o quitando unidades. Cada unidad tiene una capacidad que depende de su nivel.
Nota
Puede usar el nivel Desarrollador para la evaluación de las características de API Management. No lo use para producción.
Para ver los costos proyectados y personalizar sus necesidades de implementación, puede modificar el número de unidades de escalado e instancias de App Service en la calculadora de precios de Azure.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Ben Gimblett | Ingeniero superior de clientes
Para ver perfiles de LinkedIn no públicos, inicie sesión en LinkedIn.
Pasos siguientes
Documentación del producto:
Módulos de Learn:
- Exploración de Azure App Service
- Implementación de un sitio web en Azure con Azure App Service
- Protección de las API en Azure API Management