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 (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 con 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 ambas API: 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 y añade funcionalidades transversales y de 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 funciones de API son posibles gracias al uso de API Management como fachada para que la nueva aplicación cliente las consuma de forma coherente y utilizando 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) de uso inmediato 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 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:
- Cuando API Management está vinculado a una red virtual de Azure, la organización podría dirigirse directamente al servicio back-end a través de 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 Protocolo de seguridad de Internet (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.
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 el Protocolo simple de acceso a objetos (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.
Confiabilidad
La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.
- Plantéese 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 la integración con Azure Application Insights, que también expone las métricas mediante Azure Monitor para la supervisión. Por ejemplo, se puede usar la métrica de capacidad 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 trata de buscar 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 costes.
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.
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