Great article :) Another option is to use Web Jobs. They have pretty much the same semantics as Azure Functions but are deployed as part of a normal web app. That way you can configure and scale your host using app service etc quite easily. I have a blog about it here compositional-it.com/news-blog/rea...
Funny you should say that, on my previous project earlier in the year I did opt for WebJobs to handle some background processing triggered by a Storage Queue. I nearly blogged about that that experience then, as I'd tried to use both Functions and WebJobs and found the latter more straight forward to get working because there was less magic.
I think if it wasn't for the fact that the consumption billing model was only available for functions then I would exclusively use WebJobs, especially given that Azure Functions are just a thin layer on top of WebJobs anyway and even more so when using the dotnet-isolated runtime.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article :) Another option is to use Web Jobs. They have pretty much the same semantics as Azure Functions but are deployed as part of a normal web app. That way you can configure and scale your host using app service etc quite easily. I have a blog about it here compositional-it.com/news-blog/rea...
Nice! 👍
Funny you should say that, on my previous project earlier in the year I did opt for WebJobs to handle some background processing triggered by a Storage Queue. I nearly blogged about that that experience then, as I'd tried to use both Functions and WebJobs and found the latter more straight forward to get working because there was less magic.
I think if it wasn't for the fact that the consumption billing model was only available for functions then I would exclusively use WebJobs, especially given that Azure Functions are just a thin layer on top of WebJobs anyway and even more so when using the
dotnet-isolatedruntime.