A coworker of mine has gotten me seriously addicted to Azure Web Jobs- simple little console apps that handle the background processes of your application. With the advent of Functions and Logic Apps, we were intrigued, but I simply didn’t have time to dig in till recently.
What Are They?
Web Jobs: Any console application can get published as a web job. Initially designed to handle background processes for websites (hence the name), they are great for just about any task you want to automate. With the ability to trigger a job on demand, based on a queue or on a timer, the uses are pretty much endless. C# not your thing? There are plenty of options to choose from including Bash scripts and Python.
Functions: Apparently Microsoft is also addicted to WebJobs. So addicted in fact they decided to simplify the process fo building them, add lots of triggers, and divorce them from Application Service subscriptions. The result is Azure Functions. Designed to handle simple, autonomous tasks, Functions are a great successor to your basic Web Job. You can still run them on an Application Service account if you have excess capacity, but the real strength is when you use them on their own pricing plan, which only costs you money when the app is actually processing. That means that when your app isn’t running you are paying virtually nothing, and sudden bursts of usage don’t necessitate a larger App Service account.
The biggest downside I have found so far is that there is no built in chaining functionality. Since each function is supposed to perform a single task, it would be nice if, say, a starting function was able to examine the input and then either trigger the next function in the chain or perform some other task like adding an item to a Service Bus queue. You can still do this, you just need and intermediaries like an HTTP call or a service bus trigger.
Logic Apps: If you are familiar with Zapier, IFTTT, or Flow then you will have no trouble with Logic Apps. In fact, they are extremely similar to their Office365 cousin, Flow, but are oriented more towards developers than end users. I haven’t gotten to play with integrating Functions into Logic apps, but if your process is contained within what Logic Apps has to offer than the drag and drop GUI is a pretty darn attractive option. For data wizards, this is also going to be far less intimidating than the coding required to use Functions or WebJobs to move data around in Azure on demand (or if you just don’t like Data Factory).
To be honest, I haven’t played with Logic Apps yet, but my experience has been the same as with IFTTT– the one API endpoint I want isn’t available yet in a given service. Maybe that says something about the things I want to automate more than any failure on Microsoft’s part to offer a good product. There is definitely a lot of potential there, it just doesn’t work with every endpoint for every Azure service. A girl can dream….
Which One Should I use?
The biggest deciding factor is going to be the complexity of what you are trying to do. Logic Apps and Functions are designed to perform a single, simple task. Chaining them together can accomplish quite a bit even with this restriction, but sometimes you are just going to need the extra dev power that comes with full web jobs or the connector you need simply isn’t available any other way. If you are relying heavily on Azure for your infrastructure, then a mix of the three is entirely plausible. Where this can get difficult is in making sure each app is well named and documented. With so many small pieces it could quickly become a twisted web. Any decent sized application can suffer the same fate, but since all the calls between apps go through an intermediary, it can be harder to trace all the links between them than with straight method calls.
On the flip side, one could theoretically build quite a complex application with just Functions and Logic apps. Trying to trace the logic through might be quite the tangled web, but each function would definitely be self-contained and easy to switch out autonomously.