Aplicación web sin servidor

Esta arquitectura de referencia muestra una aplicación web sin servidor. La aplicación proporciona contenido estático desde Azure Blob Storage e implementa una API con Azure Functions. La API lee datos de Azure Cosmos DB y devuelve los resultados a la aplicación web.

Para esta arquitectura hay dos implementaciones de referencia en GitHub: Drone Delivery App (ARM y Azure Pipelines) y To Do App (Bicep y Acciones de GitHub).

Architecture

Descargue un archivo Visio de esta arquitectura.

El término sin servidor tiene dos significados diferentes pero relacionados:

• Back-end como servicio (BaaS). Los servicios de back-end en la nube, como el almacenamiento y las bases de datos, proporcionan varias API que permiten que las aplicaciones cliente se conecten directamente a estos servicios.
• Funciones como servicio (FaaS). En este modelo, una "función" es un fragmento de código que se implementa en la nube y se ejecuta en un entorno de hospedaje que abstrae completamente los servidores que ejecutan el código.

Ambas definiciones tienen en común la idea de que los desarrolladores y el personal de DevOps no necesitan implementar, configurar ni administrar servidores. Esta arquitectura de referencia se centra en FaaS con Azure Functions, aunque la entrega de contenido web desde Azure Blob Storage podría ser un ejemplo de BaaS. Algunas características importantes de FaaS son:

1. La plataforma asigna dinámicamente los recursos de proceso según sea necesario.
2. Precios basados en el consumo: se le cobrará solo por los recursos de proceso utilizados para ejecutar el código.
3. Los recursos de proceso se escalan a petición en función del tráfico, sin necesidad de que el desarrollador realice ninguna configuración.

Las funciones se ejecutan cuando se produce un desencadenador externo, como una solicitud HTTP o un mensaje que llega a una cola. Esto hace que un estilo de arquitectura orientada a eventos resulte adecuado para las arquitecturas sin servidor. Para coordinar el trabajo entre los componentes de la arquitectura, considere el uso de agentes de mensajes o patrones de publicación y suscripción. Para elegir entre las tecnologías de mensajería de Azure, consulte Elección entre los servicios de Azure que entregan mensajes.

Componentes

La arquitectura consta de los siguientes componentes:

Blob Storage. El contenido web estático, como los archivos HTML, CSS y JavaScript, se almacena en Azure Blob Storage y se entrega a los clientes mediante el hospedaje de sitios web estáticos. Toda la interacción dinámica se produce mediante código JavaScript que hace llamadas a las API de back-end. No hay código en el servidor para representar la página web. El hospedaje de sitios web estáticos admite la indexación de documentos y páginas de error 404 personalizadas.

Content Delivery Network. Use Azure Content Delivery Network para almacenar en caché el contenido y así reducir la latencia y acelerar la entrega de contenido, además de proporcionar un punto de conexión HTTPS.

Aplicaciones de función. Azure Functions es una opción de proceso sin servidor. Utiliza un modelo orientado a eventos, en el que un desencadenador invoca un fragmento de código (una "función"). En esta arquitectura, la función se invoca cuando un cliente realiza una solicitud HTTP. La solicitud siempre se enruta mediante una puerta de enlace de API, como se describe a continuación.

API Management. Azure API Management proporciona una puerta de enlace de API que se coloca delante de la función HTTP. Puede usar API Management para publicar y administrar las API que usan las aplicaciones cliente. El uso de una puerta de enlace ayuda a desacoplar la aplicación de front-end de las API de back-end. Por ejemplo, API Management puede reescribir las direcciones URL, transformar las solicitudes antes de que las reciba el back-end, establecer los encabezados de solicitud o respuesta y mucho más.

API Management también se puede utilizar para implementar cuestiones transversales, como:

• Aplicación de cuotas de uso y límites de frecuencia
• Validación de tokens de OAuth para la autenticación
• Habilitación de solicitudes entre orígenes (CORS)
• Almacenamiento en caché de las respuestas
• Supervisión y registro de solicitudes

Si no necesita todas las funcionalidades proporcionadas por API Management, también puede usar Functions Proxies. Esta característica de Azure Functions le permite definir una única superficie de API para varias aplicaciones de función, mediante la creación de rutas a las funciones de back-end. Functions Proxies también puede realizar transformaciones limitadas en la solicitud y la respuesta HTTP. Sin embargo, no proporciona las mismas funcionalidades enriquecidas basadas en directivas de API Management.

Azure Cosmos DB. Azure Cosmos DB es un servicio de base de datos de varios modelos. En este escenario, la aplicación de función recupera documentos de Azure Cosmos DB en respuesta a solicitudes HTTP GET del cliente.

Microsoft Entra ID. Los usuarios inician sesión en la aplicación web con sus credenciales de Microsoft Entra ID. Microsoft Entra ID devuelve un token de acceso para la API que la aplicación web utiliza para autenticar las solicitudes de API (consulte Autenticación).

Azure Monitor. Azure Monitor recopila métricas de rendimiento sobre los servicios de Azure implementados en la solución. Puede visualizarlas en un panel para obtener visibilidad del mantenimiento de la solución. También se recopilan los registros de aplicación.

Azure Pipelines. Azure Pipelines es un servicio de integración continua (CI) y entrega continua (CD) que compila, prueba e implementa la aplicación.

Acciones de GitHub. Flujo de trabajo es un proceso automatizado (CI/CD) que se configura en el repositorio de GitHub. Puede compilar, probar, empaquetar, liberar o implementar cualquier proyecto de GitHub con un flujo de trabajo.

Detalles del escenario

Posibles casos de uso

Esta solución de entrega de drones es perfecta para las industrias de aeronaves, aviación, aeroespacial y robótica.

Recomendaciones

Planes de Function App

Azure Functions admite dos modelos de hospedaje. Con el plan de consumo, la potencia de proceso se asigna automáticamente cuando se ejecuta el código. Con el plan de App Service, se asigna un conjunto de máquinas virtuales para el código. El plan de App Service define el número de máquinas virtuales y el tamaño de máquina virtual.

Tenga en cuenta que el plan de App Service no es estrictamente sin servidor, según la definición proporcionada anteriormente. Sin embargo, el modelo de programación es el mismo, y el mismo código de la función se puede ejecutar en un plan de consumo y en un plan de App Service.

Estos son algunos de los factores a tener en cuenta al elegir qué tipo de plan se va a usar:

• Arranque en frío. Con el plan de consumo, una función que no se ha invocado recientemente requerirá cierta latencia adicional la próxima vez que se ejecute. Esta latencia adicional se debe a la asignación y preparación del entorno de tiempo de ejecución. Normalmente está en el orden de segundos, pero depende de varios factores, como el número de dependencias que se deban cargar. Para más información, consulte Descripción del arranque en frío sin servidor. El arranque en frío es normalmente más una cuestión de cargas de trabajo interactivas (desencadenadores HTTP) que de cargas de trabajo controladas por mensajes asincrónicas (desencadenadores de colas o de Event Hubs), porque los usuarios observan directamente la latencia adicional.
• Período de tiempo de expiración. En el plan de consumo, la ejecución de una función agota el tiempo de espera tras un período de tiempo configurable (hasta un máximo de 10 minutos)
• Aislamiento de red virtual. El uso de un plan de App Service permite ejecutar las funciones dentro de una instancia de App Service Environment, que es un entorno de hospedaje dedicado y aislado.
• Modelo de precios. El plan de consumo se factura según el número de ejecuciones y el consumo de recursos (memoria por tiempo de ejecución). El plan de App Service se factura por horas en función de la SKU de las instancias de máquina virtual. A menudo, el plan de consumo puede ser más económico que un plan de App Service, ya que solo se paga por los recursos de proceso utilizados. Esto es especialmente cierto si el tráfico sufre puntos máximos y mínimos. Sin embargo, si una aplicación experimenta un rendimiento de alto volumen constante, un plan de App Service puede costar menos que el plan de consumo.
• Escalado. Una gran ventaja del modelo de consumo es que se escala dinámicamente según sea necesario, en función del tráfico entrante. Aunque este escalado sucede rápidamente, hay un período de inicialización. Para algunas cargas de trabajo, puede aprovisionar en exceso deliberadamente las máquinas virtuales de manera que pueda controlar ráfagas de tráfico con un tiempo de inicialización igual a cero. En ese caso, considere la posibilidad de un plan de App Service.

Límites de una aplicación de función

Una aplicación de función hospeda la ejecución de una o más funciones. Puede usar una aplicación de función para agrupar varias funciones como una unidad lógica. Dentro de una aplicación de función, las funciones comparten la misma configuración de aplicación, plan de hospedaje y ciclo de vida de implementación. Cada aplicación de función tiene su propio nombre de host.

Use aplicaciones de función para agrupar funciones que comparten el mismo ciclo de vida y configuración. Las funciones que no comparten el mismo ciclo de vida deben hospedarse en distintas aplicaciones de función.

Considere la posibilidad de adoptar un enfoque de microservicios, en el que cada aplicación de función representa un microservicio, que posiblemente se compone de varias funciones relacionadas. En una arquitectura de microservicios, los servicios deben tener un acoplamiento flexible y una alta cohesión funcional. Un acoplamiento flexible significa que puede cambiar un servicio sin necesidad de que los demás se actualicen al mismo tiempo. Cohesiva significa que un servicio tiene un propósito único y bien definido. Para más información sobre estas ideas, consulte Diseño de microservicios: Análisis de dominios.

Enlaces de funciones

Use enlaces de Functions cuando sea posible. Los enlaces proporcionan una forma declarativa de conectar el código a los datos e integrar con otros servicios de Azure. Un enlace de entrada rellena un parámetro de entrada a partir de un origen de datos externo. Un enlace de salida envía el valor devuelto de la función a un receptor de datos, como una cola o una base de datos.

Por ejemplo, la función GetStatus de la implementación de referencia usa el enlace de entrada de Azure Cosmos DB. Este enlace está configurado para buscar un documento en Azure Cosmos DB mediante los parámetros de consulta que se toman de la cadena de consulta de la solicitud HTTP. Si se encuentra el documento, se pasa a la función como un parámetro.

[Function("GetStatusFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req,
        [CosmosDBInput(
           databaseName: "%COSMOSDB_DATABASE_NAME%",
           containerName:"%COSMOSDB_DATABASE_COL%",
           Connection  = "COSMOSDB_CONNECTION_STRING",
           Id = "{Query.deviceId}",
           PartitionKey = "{Query.deviceId}")] DeviceState? deviceStatus)
{
  ...
}

Mediante el uso de enlaces, no es necesario escribir código que se comunique directamente con el servicio, lo que simplifica el código de la función y también abstrae los detalles del origen o el receptor de datos. En algunos casos, sin embargo, puede que necesite una lógica más compleja que la que proporciona el enlace. En ese caso, use directamente los SDK de cliente de Azure.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Escalabilidad

Funciones. Para el plan de consumo, el desencadenador HTTP se escala según el tráfico. Hay un límite para el número de instancias simultáneas de la función, pero cada instancia puede procesar más de una solicitud a la vez. Para un plan de App Service, el desencadenador HTTP se escala según el número de instancias de máquina virtual, que puede ser un valor fijo o se puede escalar automáticamente basándose en un conjunto de reglas de escalado automático. Para más información, consulte Escalado y hospedaje de Azure Functions.

Azure Cosmos DB. La capacidad de procesamiento de Azure Cosmos DB se mide en unidades de solicitud (RU). 1 RU corresponde al rendimiento necesario para una solicitud GET de un documento de 1 KB. Para escalar un contenedor de Azure Cosmos DB más allá de 10 000 RU, debe especificar una clave de partición al crear el contenedor e incluir la clave de partición en todos los documentos que cree. Para más información sobre las claves de partición, consulte Particiones y escalado en Azure Cosmos DB.

API Management. API Management se puede escalar horizontalmente y admite el escalado automático basado en reglas. El proceso de escalado tarda al menos 20 minutos. Si se trata de tráfico por ráfagas, se debe aprovisionar para la máxima ráfaga de tráfico esperada. Sin embargo, el escalado automático es útil para controlar las variaciones horarias o diarias del tráfico. Para más información, consulte Escalado automático de una instancia de Azure API Management.

Recuperación ante desastres

La implementación que se muestra aquí reside en una sola región de Azure. Para un enfoque más resistente a la recuperación ante desastres, aproveche las ventajas de las características de distribución geográfica de los distintos servicios:

• API Management admite la implementación en varias regiones, lo que se puede utilizar distribuir una única instancia de API Management en cualquier número de regiones de Azure. Para más información, consulte Implementación de una instancia del servicio Azure API Management en varias regiones de Azure.

• Use Traffic Manager para enrutar las solicitudes HTTP a la región primaria. Si la aplicación de función que se ejecuta en dicha región no está disponible, Traffic Manager conmuta por error a la región secundaria.

• Azure Cosmos DB admite varias regiones de escritura, lo que permite escribir en cualquier región que se agregue a la cuenta de Azure Cosmos DB. Si no habilita la funcionalidad de escritura múltiple, todavía puede conmutar por error a la región de escritura principal. Los SDK de cliente de Azure Cosmos DB y los enlaces de la función de Azure controlan automáticamente la conmutación por error, por lo que no es necesario actualizar los parámetros de configuración de la aplicación.

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.

Autenticación

La API GetStatus de la implementación de referencia usa Microsoft Entra ID para autenticar las solicitudes. Microsoft Entra ID admite el protocolo OpenID Connect, que es un protocolo de autenticación basado en el protocolo OAuth 2.

En esta arquitectura, la aplicación cliente es una aplicación de página única (SPA) que se ejecuta en el explorador. Este tipo de aplicación cliente no puede contener un secreto de cliente ni un código de autorización oculto, por lo que el flujo de concesión implícita es adecuado. (Consulte ¿Qué flujo de OAuth 2.0 debo usar?). Este es el flujo general:

1. El usuario hace clic en el vínculo "Iniciar sesión" de la aplicación web.
2. El explorador se redirige a la página de inicio de sesión de Microsoft Entra.
3. El usuario inicia sesión.
4. Microsoft Entra ID redirige de vuelta a la aplicación cliente, incluyendo un token de acceso en el fragmento de dirección URL.
5. Cuando la aplicación web llama a la API, incluye el token de acceso en el encabezado de autenticación. El identificador de aplicación se envía como notificación de audiencia ("aud") en el token de acceso.
6. La API de back-end valida el token de acceso.

Para configurar la autenticación:

• Registre una aplicación en un inquilino de Microsoft Entra. Esto genera un identificador de aplicación, que el cliente incluye con la dirección URL de inicio de sesión.

• Habilite la autenticación de Microsoft Entra en la aplicación de funciones. Para obtener más información, consulte Autenticación y autorización en Azure App Service.

• Agregue la directiva validate-jwt a API Management para autorizar previamente la solicitud mediante la validación del token de acceso.

Para más información, consulte el archivo Léame de GitHub.

Se recomienda crear registros de aplicaciones independientes de Microsoft Entra ID para la aplicación cliente y la API de back-end. Conceda el permiso de aplicación cliente para llamar a la API. Este enfoque le ofrece la posibilidad de definir varias API y clientes y de controlar los permisos de cada uno.

En una API, use los ámbitos para dotar a las aplicaciones con un control detallado de los permisos que solicitan a un usuario. Por ejemplo, puede que una API tenga los ámbitos Read y Write, y puede que una aplicación cliente determinada solicite al usuario que autorice solo permisos Read.

Authorization

En muchas aplicaciones, la API de back-end debe comprobar si un usuario tiene permiso para realizar una acción determinada. Se recomienda usar la autorización basada en notificaciones, en la que el proveedor de identidades (en este caso, Microsoft Entra ID) transmite la información sobre el usuario que se usa para tomar decisiones de autorización. Por ejemplo, al registrar una aplicación en Microsoft Entra ID, puede definir un conjunto de roles de aplicación. Cuando un usuario inicia sesión en la aplicación, Microsoft Entra ID incluye una notificación roles por cada rol que se ha concedido al usuario (incluidos los roles heredados por la pertenencia a grupos).

El token de identificador que Microsoft Entra ID devuelve al cliente contiene algunas notificaciones del usuario. En la aplicación de funciones, estas notificaciones están disponibles en el encabezado X-MS-CLIENT-PRINCIPAL de la solicitud. No obstante, es más sencillo leer esta información desde los datos de enlace. Para obtener otras notificaciones, use Microsoft Graph para consultar a Microsoft Entra ID. (El usuario debe dar su consentimiento a esta acción al iniciar sesión).

Para más información, consulte Uso de identidades de cliente.

CORS

En esta arquitectura de referencia, la aplicación web y la API no comparten el mismo origen. Esto significa que, cuando la aplicación llama a la API, es una solicitud entre orígenes. La seguridad del explorador impide que una página web realice solicitudes AJAX a otro dominio. Esta restricción se conoce como la directiva de mismo origen y evita que un sitio malintencionado lea información confidencial de otro sitio. Para habilitar una solicitud entre orígenes, agregue una directiva de uso compartido de recursos entre orígenes (CORS) a la puerta de enlace de API Management:

<cors allow-credentials="true">
    <allowed-origins>
        <origin>[Website URL]</origin>
    </allowed-origins>
    <allowed-methods>
        <method>GET</method>
    </allowed-methods>
    <allowed-headers>
        <header>*</header>
    </allowed-headers>
</cors>

En este ejemplo, el atributo allow-credentials es true. Esto autoriza al explorador para el envío de las credenciales (incluidas las cookies) con la solicitud. En caso contrario, el explorador no envía las credenciales con una solicitud entre orígenes de forma predeterminada.

Aplicación de HTTPS

Para mayor seguridad, puede requerir HTTPS en toda la canalización de la solicitud:

• CDN. Azure CDN admite HTTPS en el subdominio *.azureedge.net de manera predeterminada. Para habilitar HTTPS en la red CDN para los nombres de dominio personalizado, consulte Tutorial: Configuración de HTTPS en un dominio personalizado de Azure CDN.

• Hospedaje de sitios web estáticos. Habilite la opción "Se requiere transferencia segura" en la cuenta de Storage. Cuando esta opción está habilitada, la cuenta de almacenamiento solo permite solicitudes de conexiones HTTPS seguras.

• API Management. Configure las API para que solo utilicen el protocolo HTTPS. Puede configurar esto en Azure Portal o mediante una plantilla de Resource Manager:

  {
      "apiVersion": "2018-01-01",
      "type": "apis",
      "name": "dronedeliveryapi",
      "dependsOn": [
          "[concat('Microsoft.ApiManagement/service/', variables('apiManagementServiceName'))]"
      ],
      "properties": {
          "displayName": "Drone Delivery API",
          "description": "Drone Delivery API",
          "path": "api",
          "protocols": [ "HTTPS" ]
      },
      ...
  }
  

• Azure Functions. Habilite la opción de configuración "Solo HTTPS".

Bloqueo de la aplicación de función

Todas las llamadas a la función deben pasar a través de la puerta de enlace de la API. Para ello, haga lo siguiente:

• Configure la aplicación de función para que requiera una clave de función. La puerta de enlace de API Management incluirá la clave de función cuando llame a la aplicación de función. Esto evita que los clientes llamen a la función directamente, omitiendo la puerta de enlace.

• La puerta de enlace de API Management tiene una dirección IP estática. Puede restringir la función de Azure para permitir solo las llamadas desde esa dirección IP estática. Para más información, consulte Restricciones de IP estáticas de Azure App Service. (Esta característica está disponible solo para los servicios de nivel Estándar).

Protección de los secretos de aplicación

No almacene secretos de aplicación, como las credenciales de la base de datos, en el código ni en los archivos de configuración. En su lugar, use la configuración de la aplicación, que se almacena cifrada en Azure. Para más información, consulte Seguridad en Azure App Service y Azure Functions.

Como alternativa, puede almacenar los secretos de aplicación en Key Vault. Esto permite centralizar el almacenamiento de secretos, controlar su distribución y supervisar cómo y cuándo se accede a los secretos. Para más información, consulte Configuración de una aplicación web de Azure para que lea un secreto desde Key Vault. Sin embargo, tenga en cuenta que los enlaces y desencadenadores de funciones cargan sus valores de configuración de la configuración de la aplicación. No hay ningún medio integrado para configurar los desencadenadores y los enlaces para que usen secretos de Key Vault.

DevOps

Los procedimientos de implementación seguros se automatizan mediante un servicio de CI/CD confiable, como Azure Pipelines o Acciones de GitHub. Estos servicios se usan para compilar e implementar automáticamente todos los cambios de origen en el front-end y back-end. El origen debe residir en un sistema de control de versiones en línea. Para obtener más información sobre Azure Pipelines, vea Creación de la primera canalización. Para obtener más información sobre Acciones de GitHub para Azure, consulte Implementación de aplicaciones en Azure.

Implementación del front-end

El front-end de esta arquitectura de referencia es una aplicación de una sola página, que incluye JavaScript que accede a las API de back-end sin servidor y contenido estático que proporciona una experiencia de usuario rápida. He aquí algunas consideraciones importantes para dicha aplicación:

• Implemente la aplicación uniformemente para los usuarios a través de un área geográfica amplia con una red CDN preparada para uso global y hospede el contenido estático en la nube. Esto elimina la necesidad de un servidor web dedicado. Consulte Integración de una cuenta de Azure Storage en Azure CDN para comenzar. Proteja su aplicación con HTTPS. Lea los procedimientos recomendados para usar las redes de entrega de contenido para conocer recomendaciones adicionales.
• Comprima los archivos del sitio web para reducir el consumo de ancho de banda en la red CDN y mejorar el rendimiento. Azure CDN permite comprimir sobre la marcha en los servidores perimetrales. La canalización de implementación de esta arquitectura de referencia también puede comprimir los archivos antes de implementarlos en el almacenamiento de blobs. Esto reduce los requisitos de almacenamiento y ofrece mayor libertad para elegir las herramientas de compresión, independientemente de las limitaciones de la red CDN.
• La red CDN debe ser capaz de purgar su memoria caché para asegurarse de que todos los usuarios reciben el contenido más actualizado. Se requiere una purga de caché si los procesos de compilación e implementación no son atómicos; por ejemplo, si reemplazan los archivos antiguos con los recién creados en la misma carpeta de origen.
• Una estrategia de caché diferente, como el control de versiones mediante directorios, podría no requerir de purgas de la red CDN. La canalización de compilación de esta aplicación front-end crea un nuevo directorio para cada versión recién compilada. Esta versión se carga como una unidad atómica en el almacenamiento de blobs. La instancia de Azure CDN apunta a esta nueva versión solo después de que se haya completado una implementación.
• Aumente el TTL de la caché; para ello, almacene en la caché los archivos de recursos durante un período de tiempo más largo. Para garantizar que los almacenados en memoria caché se actualizan cuando cambian, cree huellas digitales de los nombres de archivo cuando se vuelvan a generar. Esta aplicación front-end crea huellas digitales de todos los archivos, excepto los archivos de acceso público como index.html. Ya que index.html se actualiza con frecuencia, refleja los nombres de archivo modificados, lo que actualiza la memoria caché. Consulte Administración de la expiración del contenido web en Azure CDN para más información.

Implementación del back-end

Para implementar la aplicación de funciones, se recomienda usar archivos de paquete ("Ejecución desde el paquete"). Con este enfoque, puede cargar un archivo zip en un contenedor de Blob Storage y el entorno de ejecución de Functions monta el archivo zip como un sistema de archivos de solo lectura. Se trata de una operación atómica, lo que reduce la posibilidad de que una implementación con errores deje la aplicación en un estado incoherente. También puede mejorar los tiempos de arranque en frío, especialmente para las aplicaciones de Node.js, porque todos los archivos se intercambian a la vez.

Agregue un número suficiente de pruebas automatizadas en las canalizaciones de compilación e implementación. Tenga en cuenta que cuantas más unidades implementables individuales compongan su carga de trabajo, más límites de red se introducirán. Esas unidades individuales funcionan conjuntamente para admitir flujos de datos y usuarios. Posteriormente, las pruebas de un extremo a otro de un sistema de este tipo requieren una inversión adicional en pruebas de integración.

Control de versiones de la API

Una API es un contrato entre un servicio y los clientes. En esta arquitectura, el contrato de API se define en el nivel de API Management. API Management admite dos conceptos de control de versiones distintos que se complementan:

• Las versiones permiten a los consumidores de API elegir una versión de API en función de sus necesidades, por ejemplo, v1 en lugar de v2.

• Las revisiones permiten a los administradores de API realizar cambios no importantes en una API e implementar esos cambios, junto con un registro de cambios para informar a los consumidores de API sobre dichos cambios.

Si realiza un cambio importante en una API, publique una nueva versión en API Management. Implemente la nueva versión en paralelo con la versión original, en una aplicación de función independiente. Esto le permite migrar los clientes existentes a la nueva API sin interrumpir las aplicaciones cliente. Finalmente, puede dejar de utilizar la versión anterior. API Management admite varios esquemas de versiones: ruta de acceso URL, encabezado HTTP o cadena de consulta. Para más información acerca del control de versiones de API en general, consulte Control de versiones de una API web RESTful.

Para actualizaciones que no son cambios importantes en la API, implemente la nueva versión en un espacio de ensayo en la misma aplicación de función. Compruebe que la implementación se realizó correctamente y, a continuación, cambie la versión de ensayo por la versión de producción. Publique una revisión en API Management.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Puede usar la calculadora de precios de Azure para calcular los costos. Tenga en cuenta los siguientes puntos para optimizar el costo de esta arquitectura.

Azure Functions

Azure Functions admite dos modelos de hospedaje.

• Plan de consumo.

  La potencia de proceso se asigna automáticamente cuando se ejecuta el código.

• Plan de App Service.

  Se asigna un conjunto de máquinas virtuales para el código. Este plan define el número de máquinas virtuales y el tamaño de máquina virtual.

En esta arquitectura, se invoca una función cuando un cliente realiza una solicitud HTTP. Ya que no se espera un rendimiento de gran volumen constante en este caso de uso, se recomienda el plan de consumo, porque solo paga por los recursos de proceso que usa.

Azure Cosmos DB

Azure Cosmos DB factura el rendimiento aprovisionado y el almacenamiento consumido por hora. El rendimiento aprovisionado se expresa en unidades de solicitud por segundo (RU/s), que se pueden usar para las operaciones de base de datos comunes, como inserciones o lecturas. El precio se basa en la capacidad de RU/s que haya reservado.

El almacenamiento se factura por cada GB usado para los datos e índice almacenados.

Para obtener más información, consulte Modelo de precios de Azure Cosmos DB.

En esta arquitectura, la aplicación de funciones recupera documentos de Azure Cosmos DB en respuesta a solicitudes GET HTTP del cliente. Azure Cosmos DB es rentable en este caso, ya que las operaciones de lectura son significativamente más baratas que las operaciones de escritura expresadas en RU/s.

Content Delivery Network

La tasa de facturación puede variar en función de la región de facturación de la ubicación del servidor de origen que entrega el contenido al usuario final. La ubicación física del cliente no es la región de facturación. Cualquier solicitud HTTP o HTTPS que pase por la red CDN es un evento facturable, que incluye todos los tipos de respuesta: correcto, error u otros. Respuestas distintas pueden generar cantidades de tráfico diferentes.

En esta arquitectura de referencia, la implementación se hospeda en una sola región de Azure.

Para reducir los costos, considere la posibilidad de aumentar el TTL de la memoria caché; para ello, almacene en caché los archivos de recursos durante más tiempo y configure el TTL más largo posible en su contenido.

Para más información, consulte la sección Costos del artículo sobre el marco de buena arquitectura de Microsoft Azure.

Implementación de este escenario

Para implementar la solución de referencia de esta arquitectura, consulte el archivo Léame de GitHub.

Pasos siguientes

Documentación del producto:

• ¿Qué es Azure Blob Storage?
• Azure Content Delivery Network
• Introducción a Azure Functions
• Acerca de API Management
• Bienvenido a Azure Cosmos DB
• Microsoft Entra ID
• Introducción a Azure Monitor
• ¿Qué es Azure Pipelines?

Módulos de Learn:

• Elección de la mejor tecnología sin servidor de Azure para su escenario empresarial
• Creación de lógica sin servidor con Azure Functions

Recursos relacionados

Para obtener más información sobre la implementación de referencia, consulte Tutorial de código: Aplicación sin servidor con Azure Functions.

Instrucciones relacionadas:

• Procedimientos recomendados para usar redes CDN
• Patrón Static Content Hosting