Imagine a world where we only consume computing power - without having to worry about how that power is delivered. Now have a look at Serverless Computing in Microsoft Azure. You're welcome.
There is only one hitch: Azure does not offer an actual product called "Serverless Computing". Instead, you will find Power Automate (formerly known as "Flow"), Logic Apps, Azure Functions and Azure App Service WebJobs. So, which one fits your needs? That is what we will try help you decide in this blog series.
To do so we will look at the decision process from three different angles:
• Complexity of the process
• Level of control required
• Service scalability and costs of running
Blog series part 1: Workflow complexity
Let us take a step back and have a look at what you are trying to achieve. If you're looking to consume computing power, then you're likely looking to automate some sort of process. What does that process look like? How complex is it?
Power Automate and Logic Apps
Building workflows using Lego-blocks
Let us say you are a project manager. You want to automatically post a message to Teams each time you update the project status overview after a review meeting.
A workflow like this is about as straight forward as it gets in terms of complexity: you do one thing and something else needs to happen.
To accomplish this the project manager fires up Power Automate in a web-browser (or in its mobile app) and drags-and-drops logical pieces into a graphical workflow designer. Simply choosing the right "Lego-bricks" and putting them in a logical order gets the task done. This very intuitive "design-first" approach is ideal for business users. No need for dedicated developer resources, written-up technical design documents, etc.
Business users can automate a straightforward process themselves using Power Automate in a graphical, design-driven aproach.
Adding complexity
Let's make it a bit more complex. After using the workflow for a while the user decides that it would be great tot also send an e-mail to the project's cliënts containing relevant changes in status or budget and alert management about possible exceptions.
This calls for quite a bit more thought. What is relevant? Who are the project's stakeholders? And how do we reach them? The business owner decides that it would make sense to involve IT at this point - things are getting just a bit too complex and getting a developer onboard might bring some extra insights.
Together they decide on criteria of relevance and that it would make sense on integrating with Dynamics - after all the stakeholders' contact data is already present there which means we can maintain a single version of "the truth". The developer agrees to work on adding functionality to the workflow. However, she is used to working in Visual Studio and it would speed things up if she could use that rather than clicking in a graphical design interface.
So they decide to move the workflow to a Logic App. Luckily this is easy. After all Power Automate is based in Logic Apps, so exporting a Power Automate workflow and importing it as a Logic App is a snap. Logic Apps also support Visual Studio, so the developer can use that.
Even better, by moving to a full Logic App (instead of only utilizing the "tip of the Iceberg" -features exposed through Power Automate) we suddenly get a host of tools geared towards developers while the design process is still design-first and driven by the business user's needs.
Moving from Power Automate to fully-fledged Logic Apps when the workflow gets more complex is painless and exposes a host of tools geared towards developers. 
Complex scenarios and integrations with existing solutions
Many situations wil not be as clear-cut as the example above. They might be much more complex, have multiple custom integrations and feedback loops to external systems, require re-use of existing components or need to integrate with existing solutions for which Logic Apps offer no integration. In those case you will want to plan your code out well in advance. In other words, you will need to adapt a code-first approach.
When developing an application, you will have to ask yourself whether you need to integrate with an existing solution or whether you can develop the application on its own. Will the application run on its own? Then Microsoft's advise is to build it as a Function App.
Use Function Apps for new, highly complex apps.
App apps are equal - but some apps are more equal (or picky!) than others. In other words, sometimes you will need to control the environment in which the application runs to a greater extent than what a Function App will let you do. In that case it is best tot switch to Apps Service WebJobs. Stopping just short of being actual self-managed virtual servers (like you would have with self-hosted IaaS-webservers) this gives you the greatest flexibility in what can be customized - at the cost of having to maintain these dependencies.
Another reason to use Apps Service WebJobs is if the application will need to integrate with a set of applications already built and hosted on an existing App Service plan.
Use App Service WebJobs when building out existing solutions or when granular control over the underlying infrastructure host is required.
In the next part of this series we will dive deeper into the customization options of the various Serverless Computing offerings. And if that does not make your head spin enough then hang on for the final episode where we look at service limits and costs.
Summary
