Opciones de hospedaje de Azure Functions
Cuando crea una aplicación de funciones en Azure, debe elegir un plan de hospedaje para su aplicación. Hay tres planes de hospedaje básico disponibles para Azure Functions: Plan de consumo, plan Premium y plan Dedicado (App Service). Estos planes de hospedaje los facilita la infraestructura de Azure App Service y están disponibles con carácter general (GA) en máquinas virtuales Linux y Windows.
El plan de hospedaje de Azure Functions que elija determina los comportamientos siguientes:
- Cómo se escala la aplicación de funciones.
- Los recursos disponibles para cada instancia de aplicación de funciones.
- Compatibilidad con funcionalidad avanzada, como la conectividad con Azure Virtual Network.
Además del hospedaje de Azure Functions, también puede hospedar aplicaciones de funciones en contenedores que se pueden implementar en clústeres de Kubernetes o en Azure Container Apps. Si decide hospedar las funciones en un clúster de Kubernetes, considere la posibilidad de usar un clúster de Kubernetes habilitado para Azure Arc. Para más información sobre la implementación de aplicaciones de contenedor personalizadas, vea Hospedaje de Azure Functions en Azure Container Apps.
En este artículo se proporciona una comparación detallada entre los distintos planes de hospedaje, incluidas las opciones basadas en contenedores.
Nota:
El hospedaje de contenedores de Azure Functions en clústeres de Kubernetes habilitados para Azure Arc y Azure Container Apps se encuentra actualmente en versión preliminar.
Información general sobre los planes
A continuación se ofrece un resumen de las ventajas de los tres planes de hospedaje principales de Azure Functions:
| Planear | Ventajas |
|---|---|
| Plan de consumo | Escale de forma automática y pague los recursos de proceso solo cuando se ejecuten las funciones. En el plan de consumo, las instancias del host de Functions se agregan y quitan de forma dinámica según el número de eventos de entrada. ✔ Plan de hospedaje predeterminado. ✔ Pague solo cuando se ejecutan las funciones. ✔ Escala de forma automática, incluso durante períodos de carga elevada. |
| Plan Premium | Escala automáticamente en función de la demanda mediante trabajos preparados previamente que ejecutan aplicaciones sin ningún retraso después de estar inactivas, ejecuta en instancias más eficaces y se conecta a redes virtuales. Tenga en cuenta el plan Azure Functions Premium en las situaciones siguientes: ✔ La aplicación de funciones se ejecuta de forma continua, o casi continua. ✔ Tiene un gran número de ejecuciones pequeñas y una factura de ejecución elevada, pero pocos GB por segundo en el plan de consumo. ✔ Necesita más opciones de CPU o memoria de las que proporciona el plan de consumo. ✔ Su código debe ejecutarse durante más tiempo del máximo permitido en el plan de consumo. ✔ Necesita características que no están disponibles en el plan de consumo, como la conectividad con red virtual. ✔ Quiere proporcionar una imagen personalizada de Linux en la que ejecutar sus funciones. |
| Plan dedicado | Ejecute las funciones en un plan de App Service a los Precios de App Service normales. Mejor para escenarios de ejecución prolongada en los que no se puede usar Durable Functions. Considere el plan de App Service en las situaciones siguientes: ✔ Tiene máquinas virtuales infrautilizadas que ya ejecutan otras instancias de App Service. ✔ Se requieren escalado y costos predictivos. |
En las tablas de comparación de este artículo también se incluyen las siguientes opciones de hospedaje, que proporcionan el mayor control y aislamiento posibles en los que ejecutar las aplicaciones de funciones.
| Opción de hospedaje | Detalles |
|---|---|
| Azure App Service Environment | App Service Environment (ASE) es una característica de App Service que proporciona un entorno completamente aislado y dedicado para ejecutar de forma segura las aplicaciones de App Service a gran escala. Los ASE son adecuados para las cargas de trabajo de aplicaciones que requieren: ✔ Una gran escala. ✔ Aislamiento de proceso completo y acceso a redes seguro. ✔ Elevado uso de memoria. |
| Azure Container Apps | Azure Container Apps es un entorno totalmente administrado que le permite ejecutar microservicios y aplicaciones contenedorizadas en una plataforma sin servidor. Azure Container Apps le permite ejecutar las funciones con la eficacia subyacente de Azure Kubernetes Service (AKS) a la vez que elimina la complejidad de tener que trabajar con las API de Kubernetes. |
| Kubernetes (Directo o Azure Arc) |
Kubernetes proporciona un entorno completamente aislado y dedicado que se ejecuta sobre la plataforma de Kubernetes. Kubernetes es adecuado para cargas de trabajo de aplicaciones que requieren: ✔ Requisitos de hardware personalizados. ✔ Aislamiento y acceso a redes seguro. ✔ Capacidad de ejecutarse en entornos híbridos o de varias nubes. ✔ Ejecutarse junto con aplicaciones y servicios de Kubernetes existentes. |
En las tablas restantes de este artículo se comparan los planes con respecto a diversas características y comportamientos. Para obtener una comparación de costos entre los planes de hospedaje dinámicos (consumo y Premium), vea la página Precios de Azure Functions. Para obtener los precios de las diversas opciones del plan dedicado, vea la página Precios de App Service.
Sistema operativo o entorno de ejecución
En la tabla siguiente se muestran los sistemas operativos y la compatibilidad de lenguaje con los planes de hospedaje.
| Linux1, 2 Solo código |
Solo código de Windows | Linux1,2,3 Contenedor de Docker |
|
|---|---|---|---|
| Plan de consumo | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
No se admite |
| Plan Premium | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Plan dedicado | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| ASE | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Kubernetes (directo) | N/D | N/D | C# JavaScript Java PowerShell Core Python TypeScript |
| Azure Arc (versión preliminar) | C# JavaScript Java Python TypeScript |
N/D | C# JavaScript Java PowerShell Core Python TypeScript |
1 Linux es el único sistema operativo compatible con la pila del runtime de Python.
2 La compatibilidad con PowerShell en Linux se encuentra actualmente en versión preliminar.
3 Linux es el único sistema operativo compatible con los contenedores de Docker.
Duración del tiempo de espera de una aplicación de función
La duración del tiempo de espera de las funciones en una aplicación de funciones se define mediante la propiedad functionTimeout en el archivo de proyecto host.json. Esta propiedad se aplica específicamente a las ejecuciones de funciones. Una vez que el desencadenador inicia la ejecución de la función, la función debe devolver o responder dentro de la duración del tiempo de espera. Para más información, consulte Mejorar el rendimiento y la confiabilidad de Azure Functions.
En la tabla siguiente se muestran los valores predeterminados y máximos (en minutos) para planes específicos:
| Plan | Valor predeterminado | Máximo 1 |
|---|---|---|
| Plan de consumo | 5 | 10 |
| Plan Premium | 302 | Ilimitados3 |
| Plan dedicado | 302 | Ilimitados3 |
1 Independientemente de la configuración del tiempo de espera de la aplicación de función, 230 segundos es la cantidad de tiempo máxima que una función desencadenada por HTTP puede tardar en responder a una solicitud. Esto se debe al tiempo de espera de inactividad predeterminado de Azure Load Balancer. Para tiempos de procesamiento más largos, considere la posibilidad de usar el patrón asincrónico de Durable Functions o aplazar el trabajo real y devolver una respuesta inmediata.
2 El tiempo de espera predeterminado para la versión 1.x del runtime de Functions es ilimitado.
3 Garantizado para un máximo de 60 minutos. El sistema operativo y aplicación de revisiones en el entorno de ejecución, la aplicación de revisiones a vulnerabilidades y el escalado de comportamientos todavía pueden cancelar las ejecuciones de funciones, por lo que asegúrese de escribir funciones sólidas.
Escala
En la siguiente tabla se comparan los comportamientos de escalado de los distintos planes de hospedaje.
El número máximo de instancias se da en función de una aplicación por función (consumo) o por plan (Premium/Dedicado), a menos que se indique lo contrario.
| Planear | Escalado horizontal | N.º máximo de instancias |
|---|---|---|
| Plan de consumo | Controlado por eventos. Escale horizontalmente de forma automática, incluso durante períodos de gran carga. La infraestructura de Azure Functions escala los recursos de CPU y memoria mediante la incorporación de instancias adicionales del host de Functions, según el número de eventos de desencadenador entrantes. | Windows: 200 Linux: 1001 |
| Plan Premium | Controlado por eventos. Escale horizontalmente de forma automática, incluso durante períodos de gran carga. La infraestructura de Azure Functions escala automáticamente los recursos de CPU y la memoria mediante la incorporación de instancias del host de Functions, según el número de eventos desencadenados por las funciones. | Windows: 100 Linux: 20-1002 |
| Plan dedicado3 | Escalabilidad automática o manual | 10-30 |
| ASE3 | Escalabilidad automática o manual | 100 |
| Kubernetes | Escalado automático basado en eventos para los clústeres de Kubernetes mediante KEDA. | Varía según el clúster. |
1 Durante el escalado horizontal, actualmente hay un límite de 500 instancias por suscripción y hora para aplicaciones Linux en un plan de consumo.
2 En algunas regiones, las aplicaciones Linux de un plan Premium pueden escalar a 100 instancias. Para obtener más información, consulte el artículo Plan Premium.
3 Para conocer los límites específicos de las distintas opciones de plan de App Service, consulte Límites del plan de App Service.
Comportamiento del arranque en frío
| Planear | Detalles |
|---|---|
| Plan de consumo | Las aplicaciones pueden escalar a cero si están inactivas, lo que significa que algunas solicitudes pueden tener una latencia adicional durante el arranque. El plan de consumo incluye algunas optimizaciones para reducir el tiempo de arranque en frío, incluida la extracción desde funciones de marcador de posición previamente preparadas que ya tienen en ejecución un host de función y procesos de lenguaje. |
| Plan Premium | Instancias permanentemente preparadas para evitar cualquier arranque en frío. |
| Plan dedicado | Cuando se ejecuta en un plan dedicado, el host de Functions se puede ejecutar de forma continua, lo que significa que el arranque en frío no es realmente un problema. |
| ASE | Cuando se ejecuta en un plan dedicado, el host de Functions se puede ejecutar de forma continua, lo que significa que el arranque en frío no es realmente un problema. |
| Kubernetes | En función de la configuración de KEDA, las aplicaciones se pueden configurar para evitar un arranque en frío. Si están configuradas para escalar a cero, se produce un arranque en frío de los nuevos eventos. |
Límites de servicio
| Recurso | Plan de consumo | Plan Premium | Plan dedicado | Azure App Service Environment | Kubernetes |
|---|---|---|---|---|---|
| Duración de tiempo de espera predeterminada (min) | 5 | 30 | 301 | 30 | 30 |
| Duración máxima de tiempo de espera (min) | 10 | sin enlazar7 | sin enlazar2 | sin enlazar | sin enlazar |
| Número máximo de conexiones salientes (por instancia) | 600 activas (1200 en total) | sin enlazar | sin enlazar | sin enlazar | sin enlazar |
| Tamaño máximo de la solicitud (MB)3 | 100 | 100 | 100 | 100 | Depende del clúster |
| Longitud máxima de la cadena de consulta3 | 4096 | 4096 | 4096 | 4096 | Depende del clúster |
| Longitud máxima de URL de solicitud3 | 8192 | 8192 | 8192 | 8192 | Depende del clúster |
| ACU por instancia | 100 | 210-840 | 100-840 | 210-2508 | Precios de AKS |
| Memoria máxima (GB por instancia) | 1.5 | 3,5-14 | 1,75-14 | 3,5-14 | Se admite cualquier nodo |
| Recuento de instancias máximo (Windows/Linux) | 200/100 | 100/20 | varía según la SKU9 | 1009 | Depende del clúster |
| Aplicaciones de funciones por plan11 | 100 | 100 | sin enlazar4 | sin enlazar | sin enlazar |
| Planes de App Service | 100 por región | 100 por grupo de recursos | 100 por grupo de recursos | - | - |
| Ranuras de implementación por aplicación10 | 2 | 3 | 1-209 | 20 | N/D |
| Almacenamiento5 | 5 GB | 250 GB | 50-1000 GB | 1 TB | N/D |
| Dominios personalizados por aplicación | 5006 | 500 | 500 | 500 | N/D |
| Compatibilidad con dominio Compatibilidad con SSL | conexión SNI SSL sin enlazar incluida | conexiones SNI SSL ilimitadas y 1 conexión SSL de IP incluidas | conexiones SNI SSL ilimitadas y 1 conexión SSL de IP incluidas | conexiones SNI SSL ilimitadas y 1 conexión SSL de IP incluidas | N/D |
1 De manera predeterminada, el tiempo de expiración del runtime de Functions 1.x en un plan de App Service no está enlazado.
2 Requiere que el plan de App Service se establezca en Always On. Abonar según las tarifas estándar.
3 Estos límites se establecen en el host.
4 El número real de aplicaciones de funciones que puede hospedar depende de la actividad de las aplicaciones, el tamaño de las instancias de máquina y la utilización de recursos correspondiente.
5 El límite de almacenamiento es el tamaño total del almacenamiento temporal entre todas las aplicaciones en el mismo plan de App Service. El plan de consumo usa Azure Files para el almacenamiento temporal.
6 Cuando la aplicación de funciones se hospeda en un plan de consumo, solo se admite solo la opción CNAME. Para aplicaciones de funciones se hospedan en un plan Premium o en un plan de App Service, puede asignar un dominio personalizado mediante un CNAME o un registro A.
7 Garantizado para un máximo de 60 minutos.
8 Los trabajos son roles que hospedan las aplicaciones del cliente. Los trabajos están disponibles en tres tamaños fijos: Una CPU virtual/3,5 GB RAM; dos CPU virtuales/7 GB RAM; cuatro CPU virtuales/14 GB RAM.
9 Consulte los Límites de App Service para obtener más información.
10 Incluido el espacio de producción.
11 Actualmente hay un límite de 5000 aplicaciones de funciones en una suscripción determinada.
Limitaciones para crear nuevas aplicaciones de funciones en un grupo de recursos existente
En algunos casos, al intentar crear un nuevo plan de hospedaje para la aplicación de funciones en un grupo de recursos existente, puede recibir uno de los siguientes errores:
- El plan de tarifa no está permitido en este grupo de recursos
- Los trabajos de <SKU_name> no están disponibles en el grupo de recursos <resource_group_name>
Esto puede ocurrir cuando se dan las siguientes condiciones:
- Cree una aplicación de funciones en un grupo de recursos existente que haya incluido alguna vez otra aplicación de funciones o aplicación web. Por ejemplo, las aplicaciones de consumo de Linux no se admiten en el mismo grupo de recursos que los planes Dedicados de Linux o Linux Premium.
- La nueva aplicación de funciones se crea en la misma región que la aplicación anterior.
- La aplicación anterior es de alguna manera incompatible con la nueva aplicación. Esto puede ocurrir entre SKU, sistemas operativos o debido a otras características de nivel de plataforma, como la compatibilidad de zonas de disponibilidad.
El motivo por el que sucede esto se debe a cómo se asignan las aplicaciones de funciones y los planes de aplicación web a diferentes grupos de recursos cuando se crean. Las diferentes SKU requieren un conjunto diferente de funcionalidades de infraestructura. Al crear una aplicación en un grupo de recursos, este se asigna a un conjunto de recursos específico. Si crea otro plan en ese grupo de recursos y el grupo asociado no tiene los recursos necesarios, se produce este error.
Cuando se produce este error, cree la aplicación de funciones y el plan de hospedaje en un nuevo grupo de recursos.
Características de red
| Característica | Plan de consumo | Plan Premium | Plan dedicado | Azure App Service Environment |
|---|---|---|---|---|
| Restricciones de IP de entrada | ✅Sí | ✅Sí | ✅Sí | ✅Sí |
| Puntos de conexión privados entrantes | ❌No | ✅Sí | ✅Sí | ✅Sí |
| Integración de redes virtuales | ❌No | ✅Sí (regional) | ✅Sí (regional y puerta de enlace) | ✅Sí |
| Desencadenadores de red virtual (no HTTP) | ❌No | ✅Sí | ✅Sí | ✅Sí |
| Conexiones híbridas (solo Windows) | ❌No | ✅Sí | ✅Sí | ✅Sí |
| Restricciones de IP de salida | ❌No | ✅Sí | ✅Sí | ✅Sí |
Facturación
| Planear | Detalles |
|---|---|
| Plan de consumo | Solo paga por el tiempo durante el que se ejecutan las funciones. La facturación se basa en el número de ejecuciones, el tiempo de ejecución y el uso de la memoria. |
| Plan Premium | El plan Premium se basa en la cantidad de núcleos por segundo y en la memoria usada en las instancias necesarias y preparadas previamente. Al menos una instancia por plan se debe mantener preparada en todo momento. Este plan ofrece los precios más predecibles. |
| Plan dedicado | Paga lo mismo por las aplicaciones de funciones en un plan de App Service que por otros recursos de App Service, como las aplicaciones web. |
| App Service Environment (ASE) | Hay una tarifa plana mensual para las instancias de ASE en la que se paga por la infraestructura y que no varía según el tamaño de la instancia de ASE. Además, existe un costo por cada vCPU del plan de App Service. Todas las aplicaciones hospedadas en una instancia de ASE están en el SKU de precios Aislado. |
| Kubernetes | Solo paga los costos del clúster de Kubernetes; no existe facturación adicional para Functions. La aplicación de funciones se ejecuta como una carga de trabajo de aplicación en el clúster, al igual que una aplicación normal. |