Azure Webjobs vs Azure Funciones: cómo elegir

Creé algunos Webjobs de Azure que usan disparadores y acabo de aprender sobre las Funciones de Azure .

Por lo que entiendo, Azure Functions parece superponerse con las características de Azure Webjobs y tengo algunas dificultades para entender cuándo elegir entre Function y Webjob:

• A diferencia de Webjobs, las funciones solo se pueden activar, no se ha diseñado para ejecutar un proceso continuo (pero puede escribir código para crear una función continua).

• Puede escribir Webjobs y Funciones utilizando muchos lenguajes (C #, node.js, python ...) pero puede escribir su función desde Azure Portal para que sea más fácil y rápido desarrollar pruebas e implementar una Función.

• Los Webjobs se ejecutan como procesos en segundo plano en el contexto de una aplicación web del Servicio de aplicaciones, una aplicación API o una aplicación móvil, mientras que las Funciones se ejecutan utilizando un Plan de servicio de aplicaciones clásico / dinámico.

• Con respecto al escalado, las funciones parecen ofrecer más posibilidades, ya que puede usar un plan de servicio de aplicación dinámico y puede escalar una sola función, mientras que para un trabajo web debe escalar toda la aplicación web.

Entonces, seguro que hay una diferencia de precio, si tiene una aplicación web existente en ejecución, puede usarla para ejecutar un trabajo web sin costo adicional, pero si no tengo una aplicación web existente y tengo que escribir código para activar una cola ¿Debo usar un webjob o una función?

¿Hay otras consideraciones a tener en cuenta cuando necesita elegir?

Hay un par de opciones aquí dentro del Servicio de aplicaciones. No tocaré Logic Apps o Azure Automation, que también toca este espacio.

Azure WebJobs

Este artículo es sinceramente la mejor explicación, pero resumiré aquí.

On Demand WebJobs aka. Programado WebJobs aka. WebJobs activados

Los WebJobs activados son WebJobs que se ejecutan una vez cuando se llama a una URL o cuando la propiedad de programación está presente en schedule.job . Los WebJobs programados son solo WebJobs que han creado un trabajo del Programador de Azure para llamar a nuestra URL en un horario, pero también admitimos la propiedad del horario, como se mencionó anteriormente.

Resumen:

• + Ejecutable / Script bajo demanda
• + Ejecuciones programadas
• - Tiene que dispararse a través del punto final .scm
• - El escalado es manual
• - VM siempre se requiere

WebJobs continuos (no SDK)

Estos trabajos se ejecutan para siempre y los despertaremos cuando se bloqueen. Debe habilitar Always On para que estos funcionen, lo que significa ejecutarlos en el nivel básico y superior.

Resumen:

• + Ejecutable / Script siempre ejecutándose
• - Requiere siempre activado: nivel básico y superior
• - VM siempre se requiere

WebJobs continuos con el SDK de WebJobs

Estos no son nada desde el punto de vista de "WebJobs the feature". Esencialmente, tenemos este dulce SDK que escribimos dirigido a WebJobs que le permite ejecutar código basado en desencadenantes simples. Hablaré de esto más adelante.

Resumen:

• + Ejecutable / Script siempre ejecutándose
• + Registro / tablero más rico
• + Activadores compatibles con tareas de larga duración
• - Requiere siempre activado: nivel básico y superior
• - El escalado es manual para configurar
• - Comenzar puede ser un poco agotador
• - VM siempre se requiere

SDK de Azure WebJobs

Azure WebJobs SDK es un SDK completamente separado de la función de plataforma de WebJobs. Está diseñado para ejecutarse en un WebJob, pero realmente puede ejecutarse en cualquier lugar. Tenemos clientes que los ejecutan en roles de trabajo e incluso en prem u otras nubes, aunque el soporte es el mejor esfuerzo.

El SDK se trata de facilitar la ejecución de algún código en reacción a algún evento y vincular los servicios / etc. fácil. Honestamente, esto está mejor cubierto en algunos documentos , pero el núcleo de eso es la naturaleza de "evento" + "código". También hemos realizado un buen trabajo de extensibilidad, pero eso es secundario al propósito principal.

Resumen:

• La mayoría de estos se mencionan anteriormente
• +Puedes extender y ejecutar lo que quieras. Control total.
• - El material HTTP es un poco inestable, pero funciona

Funciones Azure

Azure Functions se trata de tomar ese propósito central del SDK de WebJobs, alojarlo como un servicio y facilitar el inicio con otros idiomas. Aquí también presentamos el concepto "sin servidor" porque tenía mucho sentido hacerlo: sabemos cómo se escala nuestro SDK, por lo que podemos hacer cosas inteligentes por usted.

Azure Functions es una experiencia muy administrada. No apoyamos traer su propio host. Actualmente, no admitimos extensiones personalizadas, pero es algo que estamos investigando. Somos convencidos sobre lo que puede y no puede hacer, pero por las cosas que habilitamos, son ingeniosas y fáciles de usar y administrar.

Sin embargo, la mayoría de las cosas "marco" que hemos hecho para mejorar las funciones pasan por el SDK de WebJobs. Por ejemplo, subiremos un nuevo NuGet para WebJobs que realmente aumenta drásticamente la velocidad de registro, lo que tiene enormes beneficios de rendimiento para los usuarios del SDK de WebJobs. En el envío de funciones como "SDK como servicio de WebJobs", realmente hemos mejorado muchos problemas de experiencia.

• + Muchos idiomas soportados
• + Escalado dinámico totalmente gestionado
• + Portal fácil de usar con UX para gestionar conexiones / etc.
• - Host no personalizable (todavía)
• ~ Se ejecuta en una "aplicación" separada que requiere cierta configuración en su repositorio, pero facilita mucho el mantenimiento a largo plazo.
• ~ Sin herramientas (todavía) Algunas herramientas ahora están en alfa o en vista previa: https://www.npmjs.com/package/azurefunctions (actualización de febrero de 2017: Visual Studio Tools para Azure Functions ahora disponible en vista previa: https: //blogs.msdn .microsoft.com / webdev / 2016/12/01 / visual-studio-tools-for-azure-functions / )

Probablemente soy parcial ya que Functions es nuestro último y mejor, pero siéntase libre de disparar más contras para Functions a mi manera.

Probablemente termine publicando un blog que explique un poco más, pero traté de mantener esto lo más breve posible para este foro.

Al estar Azure Functions basado en WebJobs SDK, proporcionan la mayor parte de la funcionalidad ya disponible en WebJobs, pero con algunas nuevas capacidades interesantes.

En términos de desencadenantes , además de los que ya están disponibles para WebJobs (por ejemplo, Service Bus, colas de almacenamiento, blobs de almacenamiento, programaciones CRON, WebHooks, EventHub y proveedores de File Cloud Storage), las funciones de Azure se pueden activar como API. Y las llamadas HTTP no requieren credenciales kudu, pero pueden autenticarse a través de Azure AD y proveedores de identidad de terceros.

Con respecto a las salidas , la única diferencia es que las Funciones pueden devolver una respuesta cuando se llama a través de HTTP.

Ambos admiten una amplia variedad de idiomas , incluidos: bash (.sh), lote (.bat / .cmd), C #, F #, Node.Js, PHP, PowerShell y Python.

Siendo Funciones actualmente en Vista previa, las herramientas todavía no son ideales. Pero Microsoft está trabajando en eso. Con suerte, obtendremos la misma flexibilidad de desarrollar y probar funciones localmente que en la actualidad para WebJobs con Visual Studio.

Las ventajas más significativas y geniales aportadas por Functions son la alternativa de tener un plan de servicio dinámico con un modelo "sin servidor" , en el que no necesitamos administrar instancias de VM o escalado; Todo está gestionado por nosotros. Además, al no tener instancias dedicadas, solo pagamos por los recursos que realmente utilizamos.

Una comparación más detallada entre los dos aquí: https://blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/

HTH :)

Según los documentos, Azure Functions tiene lo siguiente que WebJobs no tiene:

• Escalado automático (la CPU y la memoria se escalan según las necesidades determinadas en tiempo de ejecución)
• Precios de pago por uso (plan de consumo en lugar de plan de App Service)
• Más eventos desencadenantes (como WebHooks)
• Desarrollo en el navegador (Visual Studio aún es posible)
• Soporte F #

En pocas palabras: Azure Functions es el animal más nuevo. Si aún no tiene un plan de App Service, iría con Functions porque a largo plazo no veo ninguna razón por la cual comenzar con WebJobs sería mejor (aunque las herramientas de Functions podrían no ser tan estables).

Me gustaría agregar dos puntos más a las publicaciones anteriores largas y poco antiguas. Si elige el plan de consumo en funciones azules, a continuación se detallan las limitaciones.

Si desea ejecutar cualquier trabajo durante más de 10 minutos, elija webjobs. Funciones de Azure, se ejecuta solo durante 5 minutos de forma predeterminada, si su proceso supera los 5 minutos, entonces la función azul arroja una excepción de tiempo de espera. Puede aumentar el tiempo de espera a 10 minutos en host.json .

Nota: No hay ningún problema de tiempo de espera si está utilizando las funciones azules del plan de servicio de la aplicación.

Otra razón para distinguir es. Si utiliza la función azul, su tiempo de inicio inicial será lento porque las máquinas (contenedores) se crean sobre la marcha y se destruyen una vez que se utiliza.

Para evitar el arranque en frío, la aplicación de función azul ha lanzado un plan premium, donde una instancia se ejecutará todo el tiempo y, según la carga, la aplicación de función comenzará a escalar y se le facturará una instancia y otras instancias en función del consumo.

Me doy cuenta de que llego muy tarde al juego con esta respuesta, pero dado que este sigue siendo un resultado de búsqueda superior en Google, quería dar una guía sobre este tema estrictamente desde una perspectiva de costo, ya que parece que el OP tiene algunas preocupaciones sobre el costo . Ya hay algunas respuestas excelentes aquí que hablan sobre las limitaciones técnicas y los detalles de cómo funciona cada servicio, por lo que no voy a repetir esas respuestas.

Si realmente necesita algo que se ejecute de forma "gratuita" (como sin costo adicional a lo que ya ha pagado por su aplicación web), entonces tiene dos opciones:

1. Webjobs: implementado junto con su aplicación web existente y utiliza los mismos recursos que su aplicación web. No hay un costo monetario adicional para usar webjobs, pero hay algunas limitaciones, como ya se mencionó, que pueden generar costos de rendimiento en su aplicación web.
2. Funciones: al utilizar el plan de consumo, se le asigna una cierta cantidad de ejecuciones gratuitas. El número al momento de escribir esto es bastante alto, 1 millón de ejecuciones gratuitas. Sin embargo, el límite de 1 millón de ejecución no es el límite que probablemente le cause problemas; son los 400K GB-s (gigabyte segundos). Esto es básicamente un cálculo de la cantidad de memoria que utiliza su función multiplicada por la cantidad de segundos que se ejecuta (consulte el cálculo oficial en la página de precios aquí ). Se sorprenderá de lo rápido que se agota esta asignación gratuita.

Si le preocupan los costos, pero no se limitan a ningún costo , tiene más opciones disponibles.

1. Funciones: puede ejecutar el plan de consumo o el plan de servicio de la aplicación por un precio relativamente económico. Sin embargo, tenga en cuenta el modelo de facturación de GB-s. Si está utilizando el plan de consumo y está haciendo un trabajo frecuente y "pesado", podría sorprenderse con una gran factura.
2. Servicios en la nube: esta opción no se ha discutido como alternativa, principalmente porque el OP no preguntó al respecto. Pero esta también es una opción viable. Los servicios en la nube son, en última instancia, solo máquinas virtuales que se ejecutan en la nube, por lo que puede ejecutar cualquier trabajo en segundo plano que necesite en ellas y se amplían / ​​reducen bastante bien (aunque tiene que conectar sus propios disparadores para la ejecución, un pequeño inconveniente en comparación con las funciones / trabajos web) ) Tienen más costos iniciales asociados con ellos (porque paga por instancia, ya sea que lo use o no), pero si tiene trabajos que necesitan ejecutarse constantemente y están haciendo mucho trabajo pesado, entonces los servicios en la nube podrían ser una mejor opción porque, en mi opinión, es más fácil administrar / monitorear una VM de precio fijo que ejecuciones y gigabytes de segundo.

Si está interesado en leer algunos escenarios específicos y por qué elegiría uno (webjobs, funciones, servicios en la nube) sobre el otro, recientemente escribí una publicación de blog sobre webjobs vs funciones vs servicios en la nube .

Una consideración importante es que Azure Functions dejó de admitir el .NET Framework completo después de la versión 1, que se suspendió con v2.0, y que no cambiará en la versión preliminar v3.0. 😔

• La documentación deja esto claro aquí ,

• al igual que esta respuesta de retroalimentación ,

• así como este problema / respuesta de github .

Mientras tanto, afortunadamente este fuerte enfoque armado no se aplicó, todavía, a Azure WebJobs :

La versión 3.x del SDK de WebJobs admite las aplicaciones de consola .NET Core y .NET Framework.

Me gustaría dar cuáles son los puntos en común y las diferencias entre las dos funciones de Azure que se crean sobre AppService y WebJobs SDK. WebJobs SDK te dará más libertad para jugar, mientras que las funciones de Azure están más estructuradas y tienen menos responsabilidades para los desarrolladores.

Cuando observa los puntos en común, Ambos utilizan el modo de programación orientado a funciones, enlaces para desencadenador / entrada / salida, admiten bibliotecas externas y pueden ejecutar y depurar localmente artículos de tocador Supportruntime.

Las diferencias

|-----------------------|------------------|
|      Functions        |     Web Jobs     |
|-----------------------|------------------|
|Can support HTTP       | Can't support HTTP
|                       |  requests        |
|-----------------------|------------------|
|Supports a variety of  | Traditional .NET |
|languages/tools        | developer        |
|                       | experience       |
|-----------------------|------------------|
|Bindings are configured| Config files are |
|using attributes       | used             |
|-----------------------|------------------|
|Scale is managed by    | Scale is managed |
|Azure                  | by user          |
|-----------------------|------------------|
|Limited control over   |Host can be       |
|host                   |controlled by user|
--------------------------------------------