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.
Architecture
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 desde la instancia de API Management pase a través del firewall corporativo hacia los servicios locales existentes con transporte seguro (HTTPS o SSL).
- El equipo de operaciones solo permite las llamadas entrantes a los servicios desde la instancia de API Management. Este requisito se cumple mediante la inclusión en la lista de permitidos de la dirección IP de la instancia de API Management dentro del perímetro de la 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 API Management proporciona.
- 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 ha desarrollado y publicado como una aplicación de API web de PaaS de Azure.
- Se configura (mediante la configuración de la característica Web Apps de Azure App Service) para aceptar solo la dirección IP virtual 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 con Microsoft Entra ID y OAuth 2.
- La nueva aplicación web basada en explorador depende de la instancia de Azure API Management para ambas API: la API HTTP existente y la nueva API.
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
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 ha decidido mantener la privacidad de los puntos de conexión existentes y no los expone públicamente, su instancia de API Management podría vincularse a una instancia de Azure Virtual Network:
- En un escenario de migración mediante lift-and-shift de Azure vinculado a una red virtual de Azure implementada, la organización podría direccionar directamente el servicio de back-end con direcciones IP privadas.
- En el escenario local, la instancia de API Management podría llegar al servicio interno de forma privada mediante Azure VPN Gateway y conexiones VPN de IPSec de sitio a sitio o Azure ExpressRoute. A continuación, este escenario se convertiría en un híbrido de Azure y en el entorno local.
La organización puede mantener privada la instancia de API Management mediante su implementación en modo interno. A continuación, la organización puede utilizar la implementación con Azure Application Gateway para permitir el acceso público para algunas API mientras que otras siguen siendo internas. Para más información, vea 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 todavía puede aprovechar las ventajas de 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.
Nota:
Para obtener información general sobre la conexión de API Management a una red virtual, consulte este artículo.
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, existen algunos servicios HTTP basados en SOAP 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 utilizar Azure API Management para solucionar 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 del Marco de buena arquitectura de Azure, que es un conjunto de principios rectores que ayudan a mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
Disponibilidad y escalabilidad
- Puede escalar horizontalmente Azure API Management mediante la elección de un plan de tarifa y la posterior adición de unidades.
- El escalado también puede ocurrir automáticamente con el escalado automático.
- La implementación en varias regiones permite opciones de conmutación por error y se puede realizar en el plan Premium.
- Considere la posibilidad de la integración con Azure Application Insights, que también expone las métricas mediante Azure Monitor para la supervisión.
Optimización de costos
La optimización de costos consiste en buscar formas de reducir los gastos innecesarios y mejorar la eficiencia operativa. Para más información, vea Información general del pilar de optimización de costos.
API Management se ofrece en cuatro niveles: Desarrollador, Básico, Estándar y Premium. Puede encontrar instrucciones detalladas sobre las diferencias entre estos niveles en 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 realizar la personalización pertinente en función de las necesidades de la implementación, puede modificar el número de unidades de escalado y las instancias de App Service en la Calculadora de precios de Azure.
Implementación de este escenario
Para empezar a trabajar, cree una instancia de Azure API Management en el portal.
Como alternativa, puede elegir una plantilla de inicio rápido de Azure Resource Manager existente que se adapte a sus necesidades específicas.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Ben Gimblett | Ingeniero de clientes sénior
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
Documentación del producto:
Módulos de Learn:
- Explorar Azure App Service
- Implementación de un sitio web en Azure con Azure App Service
- Protección de las API en Azure API Management