Esta arquitectura de referencia usa Azure Integration Services para orquestar las llamadas a los sistemas de back-end empresariales. Los sistemas de back-end pueden incluir sistemas de software como servicio (SaaS), servicios de Azure y servicios web existentes de su empresa.
Architecture
Descargue un archivo Visio de esta arquitectura.
Flujo de trabajo
Sistemas de back-end. El lado derecho del diagrama muestra los distintos sistemas de back-end que la empresa ha implementado o usa. Aquí se pueden incluir los sistemas SaaS, otros servicios de Azure o servicios web que exponen puntos de conexión REST o SOAP.
Azure Logic Apps. En esta arquitectura, las aplicaciones lógicas se desencadenan mediante solicitudes HTTP. También se pueden anidar flujos de trabajo para una orquestación más compleja. Logic Apps usa conectores para integrarse con los servicios usados más comúnmente. Logic Apps ofrece cientos de conectores, y además puede crear conectores personalizados.
Azure API Management. API Management consta de dos componentes relacionados:
Puerta de enlace de API. La puerta de enlace de API acepta llamadas HTTP y las enruta al back-end.
Portal para desarrolladores. Cada instancia de Azure API Management proporciona acceso al portal para desarrolladores. Este portal proporciona a los desarrolladores acceso a documentación y ejemplos de código para llamar a las API. También se pueden probar las API en el portal para desarrolladores.
Azure DNS. Azure DNS proporciona resolución de nombres mediante la infraestructura de Azure. Al hospedar dominios en Azure, puede administrar los registros DNS con las mismas credenciales, API, herramientas y facturación que usa con los demás servicios de Azure. Para usar un nombre de dominio personalizado, como contoso.com, cree registros DNS que asignen el nombre de dominio personalizado a la dirección IP. Para más información, consulte el artículo sobre cómo configurar un nombre de dominio personalizado en API Management.
Microsoft Entra ID. Use Microsoft Entra ID para autenticar a los clientes que llaman a la puerta de enlace de API. Microsoft Entra ID admite el protocolo OpenID Connect (OIDC). Los clientes obtienen un token de acceso de Microsoft Entra ID y la puerta de enlace de API valida el token para autorizar la solicitud. Si utiliza el nivel Estándar o Premium de API Management, Microsoft Entra ID también puede ayudar a proteger el acceso al portal para desarrolladores.
Componentes
- Integration Services es una colección de servicios que puede usar para integrar aplicaciones, datos y procesos.
- Logic Apps es una plataforma sin servidor para la creación de flujos de trabajo empresariales que integran aplicaciones, datos y servicios.
- API Management es un servicio administrado para la publicación de catálogos de API de HTTP. Puede usarla para promover la reutilización y la detectabilidad de las API e implementar una puerta de enlace de API para solicitudes de API de proxy.
- Azure DNS es un servicio de hospedaje para dominios DNS.
- Microsoft Entra ID es un servicio de administración de identidades y accesos basado en la nube. Los empleados de la empresa pueden utilizar Microsoft Entra ID para acceder a recursos internos y externos.
Detalles del escenario
Integration Services es una colección de servicios que puede usar para integrar aplicaciones, datos y procesos en la empresa. Esta arquitectura emplea dos de esos servicios: Logic Apps para orquestar los flujos de trabajo, y API Management para crear catálogos de API.
En esta arquitectura, se crean API compuestas mediante la importando de aplicaciones lógicas como API. También se pueden importar servicios web existentes mediante la importación de especificaciones de OpenAPI (Swagger) o la importación de API SOAP a partir de especificaciones WSDL.
La puerta de enlace de API ayuda a desacoplar los clientes de front-end del back-end. Por ejemplo, puede reescribir las direcciones URL o transformar las solicitudes antes de que lleguen al back-end. También controla muchos aspectos transversales como la autenticación, la compatibilidad con uso compartido de recursos entre orígenes (CORS) y el almacenamiento en caché de respuestas.
Posibles casos de uso
Esta arquitectura es suficiente para los escenarios de integración básica en los que las llamadas sincrónicas a servicios back-end desencadenan el flujo de trabajo. Una arquitectura más sofisticada que usa colas y eventos se basa en esta arquitectura básica.
Recomendaciones
Los requisitos específicos pueden diferir de la arquitectura genérica que se describe aquí. Use las recomendaciones de esta sección como punto de partida.
API Management
Use los niveles Básico, Estándar o Premium de API Management. Estos niveles ofrecen un Acuerdo de Nivel de Servicio (SLA) de producción y admiten escalabilidad horizontal dentro de la región de Azure. La capacidad de rendimiento de API Management se mide en unidades. Cada plan de tarifa tiene una escalabilidad horizontal máxima. El nivel Premium también admite la escalabilidad horizontal entre varias regiones de Azure. Elija su nivel en función de su conjunto de características y el nivel de rendimiento necesario. Para más información, consulte Precios de API Management y Capacidad de una instancia de Azure API Management.
Cada instancia de Azure API Management tiene un nombre de dominio predeterminado, que es un subdominio de azure-api.net, por ejemplo, contoso.azure-api.net. Considere la posibilidad de configurar un dominio personalizado para su organización.
Logic Apps
Logic Apps funciona mejor en escenarios que no requieren baja latencia para una respuesta, como por ejemplo las llamadas a API asincrónicas o de ejecución semiprolongada. Si se requiere una latencia baja, por ejemplo en una llamada que bloquea una interfaz de usuario, use otra tecnología. Por ejemplo, use Azure Functions o una API web implementada en Azure App Service. Use API Management para enfrentar la API a los consumidores de API.
Region
Para minimizar la latencia de red, coloque API Management y Logic Apps en la misma región. En general, elija la región más cercana a los usuarios (o más cercana a los servicios de back-end).
Consideraciones
Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para 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 tu aplicación puede cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.
Revise el SLA de cada servicio:
Si implementa API Management en dos o más regiones con el nivel Premium, es apto para un Acuerdo de Nivel de Servicio superior. Consulte Precios de API Management.
Copias de seguridad
Realice una copia de seguridad periódica de la configuración de API Management. Almacene los archivos de copia de seguridad en una ubicación o región de Azure diferente de la región donde se implementa el servicio. En función de su RTO, elija una estrategia de recuperación ante desastres:
En un evento de recuperación ante desastres, aprovisione una nueva instancia de API Management, restaure la copia de seguridad en la instancia nueva y redirija los registros DNS.
Mantenga una instancia pasiva del servicio API Management en otra región de Azure. Restaure con regularidad las copias de seguridad a esa instancia para mantenerlas sincronizadas con el servicio activo. Para restaurar el servicio durante un evento de recuperación ante desastres, solo es necesario redirigir los registros DNS. Este enfoque conlleva costos adicionales, ya que se paga por la instancia pasiva, pero se reduce el tiempo de recuperación.
Para las aplicaciones lógicas, se recomienda un enfoque de configuración como código para la copia de seguridad y la restauración. Dado que las aplicaciones lógicas son sin servidor, puede volver a crearlas rápidamente a partir de plantillas de Azure Resource Manager. Guarde las plantillas en el control de código fuente e integre las plantillas con el proceso de implementación continua e integración continua (CI/CD). En un evento de recuperación ante desastres, implemente la plantilla en una nueva región.
Si implementa una aplicación lógica en una región diferente, actualice la configuración en API Management. Puede actualizar la propiedad Backend de la API mediante un script de PowerShell básico.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.
Aunque esta lista no describe completamente todos los procedimientos recomendados de seguridad, estas son algunas consideraciones de seguridad que se aplican específicamente a esta arquitectura:
El servicio Azure API Management tiene una dirección IP pública fija. Restrinja el acceso para llamar a los puntos de conexión de Logic Apps a solo la dirección IP de API Management. Para obtener más información, vea Restricción de las direcciones IP entrantes.
Para asegurarse de que los usuarios tienen niveles de acceso adecuados, utilice el control de acceso basado en roles de Azure (Azure RBAC).
Proteja los puntos de conexión de API públicos en API Management con OAuth o bien OpenID Connect. Para proteger los puntos de conexión de API públicos, configure un proveedor de identidades y agregue una directiva de validación de JSON Web Token (JWT). Para obtener más información, consulte Proteger una API mediante OAuth 2.0 con Microsoft Entra ID y API Management.
Conéctese a servicios back-end desde API Management mediante certificados mutuos.
Exija HTTPS en las API de API Management.
Almacenamiento de secretos
Nunca compruebe contraseñas, claves de acceso ni cadenas de conexión en el control de código fuente. Si estos valores son necesarios, protéjalos e impleméntelos mediante las técnicas oportunas.
Si una aplicación lógica requiere valores confidenciales que no se pueden crear dentro de una conexión, almacene esos valores en Azure Key Vault y haga referencia a ellos desde una plantilla de Resource Manager. Utilice parámetros de plantilla de implementación y archivos de parámetros para cada entorno. Para más información, consulte Parámetros seguros y entradas dentro de un flujo de trabajo.
API Management administra los secretos con objetos denominados valores con nombre o propiedades. Estos objetos almacenan de forma segura los valores a los que se puede acceder a través de directivas de API Management. Para más información, consulte Cómo usar valores con nombre en las directivas de Azure API Management.
Excelencia operativa
La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.
DevOps
Cree grupos de recursos independientes para entornos de producción, desarrollo y pruebas. Los grupos de recursos independientes facilitan la administración de implementaciones, la eliminación de implementaciones de prueba y la asignación de derechos de acceso.
Cuando asigna recursos a los grupos de recursos, debe considerar estos factores:
Ciclo de vida. En general, coloque los recursos que tienen el mismo ciclo de vida en el mismo grupo de recursos.
Acceso. Puede usar el control de acceso basado en roles de Azure (Azure RBAC) para aplicar directivas de acceso a los recursos de un grupo.
Facturación. Puede ver los costos acumulados del grupo de recursos.
Plan de tarifa de API Management. Use el nivel Desarrollador para los entornos de desarrollo y pruebas. Para minimizar los costos durante la preproducción, implemente una réplica del entorno de producción, ejecute las pruebas y, a continuación, apáguela.
Implementación
Use plantillas de Azure Resource Manager para implementar los recursos de Azure, según el proceso de infraestructura como código (IaC). Las plantillas facilitan la automatización de las implementaciones mediante Azure DevOps Services u otras soluciones de CI/CD.
Ensayo
Considere el almacenamiento provisional de las cargas de trabajo, lo que significa realizar las implementaciones en varias fases y ejecutar validaciones en cada una de ellas antes de pasar a la siguiente. Si aplica este enfoque, puede enviar actualizaciones a los entornos de producción de una manera muy controlada y minimizar los problemas de implementación imprevistos. La implementación azul-verde y las versiones de valores controlados son estrategias de implementación recomendadas para actualizar entornos de producción en directo. Considere también la posibilidad de tener una buena estrategia de reversión en caso de que se produzca un error en una implementación. Por ejemplo, puede volver a implementar automáticamente una implementación anterior exitosa desde el historial de implementación. El parámetro de marca --rollback-on-error en la CLI de Azure es un buen ejemplo.
Aislamiento de cargas de trabajo
Coloque las instancias de Azure API Management y cualquier aplicación lógica individual en sus propias plantillas independientes de Resource Manager. Mediante el uso de plantillas independientes, puede almacenar los recursos en sistemas de control de código fuente. Puede implementar las plantillas en conjunto o por separado como parte de un proceso de CI/CD.
Versiones
Cada vez que realiza un cambio en la configuración de una aplicación lógica o implementa una actualización con una plantilla de Resource Manager, Azure guarda una copia de dicha versión y mantiene todas las versiones que tengan un historial de ejecución. Puede usar estas versiones para hacer el seguimiento de los cambios históricos o promover una versión como configuración actual de la aplicación lógica. Por ejemplo, puede revertir una aplicación lógica a una versión anterior.
Azure API Management admite dos conceptos de control de versiones distintos, pero complementarios:
Las versiones permiten a los consumidores de API elegir una versión de API en función de sus necesidades, por ejemplo, v1, v2, beta o producción.
Las revisiones permiten a los administradores de API realizar cambios no importantes en una API e implementar esos cambios, junto con un registro de los cambios para informar a los consumidores de API sobre ellos.
Puede crear una revisión en el entorno de desarrollo e implementar ese cambio entre otros entornos con el uso de plantillas de Resource Manager. Para obtener más información, vea Publicación de varias versiones de la API
También puede usar las revisiones para probar una API antes de realizar los cambios actuales y permitir que los usuarios puedan acceder a ella. Sin embargo, este método no se recomienda para pruebas de carga o pruebas de integración. En su lugar, use entornos de prueba o preproducción independientes.
Diagnóstico y supervisión
Puede usar Azure Monitor para la supervisión operativa tanto en API Management como en Logic Apps. Azure Monitor proporciona información según las métricas que se configuran para cada servicio y está habilitado de manera predeterminada. Para más información, consulte:
- Supervisión de las API publicadas
- Supervisar el estado, configurar el registro de diagnósticos y activar alertas para Azure Logic Apps
Cada servicio también tiene estas opciones:
Para realizar análisis más exhaustivos y agregarlos a los paneles, envíe registros de Logic Apps a Azure Log Analytics.
Para la supervisión de DevOps, puede configurar Azure Application Insights para API Management.
API Management admite la plantilla de solución de Power BI para análisis de API personalizados. Puede usar esta plantilla de solución para crear su propia solución de análisis. Los informes están disponibles en Power BI para los usuarios empresariales.
Eficiencia del rendimiento
La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.
Para aumentar la escalabilidad de API Management, agregue directivas de almacenamiento en caché donde corresponda. El almacenamiento en caché también ayuda a reducir la carga de sus servicios back-end.
Para ofrecer mayor capacidad, puede escalar horizontalmente los niveles Básico, Estándar y Premium de Azure API Management en una región de Azure. Para analizar el uso del servicio, en el menú Métricas, seleccione Métrica de capacidad y, luego, escale verticalmente u horizontalmente según corresponda. El proceso de actualización o escalado puede tardar entre 15 y 45 minutos en aplicarse.
Recomendaciones de escalado de un servicio API Management:
Considere los patrones de tráfico al escalar. Los clientes con patrones de tráfico más volátiles necesitan más capacidad.
Una capacidad coherente superior al 66 % puede indicar la necesidad de escalar verticalmente.
Una capacidad coherente inferior al 20 % puede indicar una oportunidad para reducir verticalmente.
Antes de habilitar la carga en producción, realice siempre una prueba de carga del servicio API Management con una carga representativa.
Con el nivel Premium, puede escalar una instancia de API Management entre varias regiones de Azure. Esto hace que API Management sea apto para un Acuerdo de Nivel de Servicio superior y le permite aprovisionar servicios cercanos a los usuarios en varias regiones.
El modelo sin servidor de Logic Apps significa que no es necesario que los administradores planifiquen la escalabilidad del servicio. El servicio se escala automáticamente para satisfacer la demanda.
Optimización de costos
En general, use la calculadora de precios de Azure para calcular los costos. Estas son algunas otras consideraciones.
API Management
Se le cobra por todas las instancias de API Management cuando están en ejecución. Si ha escalado verticalmente y no necesita ese nivel de rendimiento todo el tiempo, reduzca verticalmente de forma manual o configure la escalabilidad automática.
Logic Apps
Logic Apps usa un modelo sin servidor. La facturación se calcula en función de la acción y la ejecución del conector. Para obtener más información, consulte Precios de Logic Apps.
Para más información, consulte la sección acerca de los costos del artículo sobre elmarco de buena arquitectura de Microsoft Azure.
Pasos siguientes
Recursos relacionados
Para obtener mayor confiabilidad y escalabilidad, utilice colas de mensajes y eventos para desacoplar los sistemas de back-end. Esta arquitectura se muestra en el siguiente artículo de esta serie:
También pueden interesarle estos artículos del Centro de arquitectura de Azure: