This is a cross posting from the Integration Playbook
Following on from my previous article about why I think Microsoft are extending the Logic Apps offering I wanted to take a shot at attempting to describe how things will be changing.
First off lets consider what we have now and then we will look at whats changing. Also I will call out that at this point in time based on what Microsoft have said, I think there is some work to do around naming because I think its a little confusing when there are similar things which arent actually the same thing. For the purposes of this article I will describe them as follows:
- Serverless Logic Apps = The current consumption based Logic Apps we have now
- Managed Logic Apps = This is when you have an Integration Services Environment
- Portable Logic Apps = This is the new stuff shown at Ignite
Although there were a bunch of great announcements the most significant ones were around the architecture and hosting of Logic Apps and ill discuss this more below.
Serverless Logic Apps
At present our Serverless Logic Apps are the consumption based Logic Apps we run on Azure and pay on a per action basis. If we consider the below diagram we can see that we deploy Logic Apps to a Resource Group within Azure and they use Connectors which are also deployed to the resource group.
Deployment Unit
The deployment unit is the individual Logic App. Each Logic App is its own isolated thing that you manage in isolation and has its own lifecycle.
Cost Model
The cost model is pay per action. If your Logic App has 100 actions and runs once you would pay the same as a Logic App which has 1 action and runs 100 times. If your Logic App doesnt execute or run a trigger then there is no cost.
Scaling
The scaling model is serverless and completely managed by Microsoft. Its a shared tenant and you are sharing compute under the hood with other users. You are trusting Microsoft to provide on demand the resources your logic app needs to run.
Deployment Model
The deployment model for your logic apps is based around ARM templates. You would have an ARM template which would contain 1 or more Logic Apps and 0 or more API Connectors. When you deploy the ARM template then each Logic App and API Connector is seen as an individual Azure Resource
Key Value Proposition
The key reasons people tend to choose this option are:
- Low cost
- Scale up/out and scale to zero
- Low maintenance
Managed Logic Apps
Next we have Managed Logic Apps. You will be more familiar with these being called an Integration Services Environment. This is where you have purchased a dedicated tenant to run your Logic Apps on. You can deploy many Logic Apps to your ISE. The below diagram shows a typical ISE model. You deploy your dedicated host which Microsoft will look after for you to your Azure Resource Group. You also get a free Integration Account with it (if I remember correctly) and then you deploy Logic Apps and API Connectors to your ISE.
You can also configure Virtual Network integration for your ISE which is one of the common use cases for using an ISE for hybrid scenarios.
Deployment Unit
The deployment unit for a Managed Logic App is exactly the same as for a Serverless one. The only difference is the additional deployment for the ISE which is a one off activity.
You can deploy many logic apps to your ISE
Cost Model
The cost model for the ISE solution is quite different to the Serverless model. In ISE you are paying a monthly cost for an amount of reserved capacity. The cost is quite significant so its unlikely you will have an ISE unless you have a big investment in Logic Apps.
The cost for the managed solution could overall be cheaper than the Serverless model if you have a lot of load on your Logic Apps solutions but there are scenarios where it can be cheaper.
Scaling
In ISE you would scale on a node basis. Your ISE will have be able to add and remove nodes on demand. Each additional node includes an additional charge for the node on a per hour basis
Deployment Model
The deployment model for Logic Apps on ISE is the same as for Serverless Logic Apps. The only difference is that the logic app definition includes a setting which tells it to execute on the ISE.
This is actually pretty cool because it makes it quite easy to swap from one to the other.
Key Value Proposition
The key reasons people tend to choose this option are:
- Dedicated Compute
- Premium reserved performance
- Network integration
Portable Logic Apps
The new stuff announced at Ignite is an interesting architecture and as I mentioned earlier I think there is some naming work to be done to help people understand the differences. It is Logic Apps but its slightly different. To help explain this I am going to call it Portable Logic Apps. Im sure the team at Microsoft will come up with a better name but for the purposes of this article I am going to call it Portable Logic Apps to help explain the differences between this and the other flavours of Logic Apps.
The reason I have called it Portable Logic Apps is that one of the reasons behind the change is that Microsoft want to allow customers to be able to host Logic Apps in different hosting platforms. In the two above options the hosting for Logic Apps is a black box where Microsoft are doing everything for you. Microsoft have modified the Logic Apps runtime to allow it to be hosted in other places. The first of those places is the Azure Functions runtime. This allows you to run Logic Apps on Azure as a type of Function App.
If we think back to the Serverless Logic Apps model then this is really the same as a Function App running on the consumption plan. A Function App can also run on an App Service Plan and this is where Logic Apps as a Function App is positioning itself. The below picture shows that in your resource group you would have an App Service Plan and a storage account and App Insights configured. This is your “infrastructure”. You would then deploy Portal Logic Apps onto the App Service Plan. You would be able to deploy multiple Logic Apps to your App Service Plan just like you can deploy multiple Web Apps and Function Apps to an App Service Plan.
The below picture shows this.
Deployment Unit
The deployment unit changes significantly in this model. A Logic App isnt really a Logic App now. In this model the term “Logic App” is really equivalent to a Function App. Within the “Logic App” you will have 1 or more workflows. A workflow is the equivalent of a function within a function app.
A Serverless Logic App is the same thing as a workflow within a Portable Logic App. If that makes sense 🙂
Cost Model
The cost model for this type of Logic Apps has not been announced yet but based on what Microsoft has said and making some assumptions I would expect it to be based on the App Service Plan model in some way.
That would mean it is more similar to an ISE than the Serverless Logic Apps. There would potentially be other cost models depending on where you host.
Scaling
The scaling model for Portable Logic Apps depends on the host you run it on. If you are running on Azure on an App Service Plan then you would inherit the benefits of the App Service Plan for scale up and scale out. You would also be able to scale in and down.
If you are running on a different hosting model such as running on Kubernetes then you would have the same experience as if you were hosting Azure Functions on Kubernetes.
Deployment Model
The deployment model for a Portable Logic App is different to the other types. Previously we are using ARM templates to deploy our json definitions to Azure. This time the workflows are contained inside the Logic App and the Logic App follows the Azure Functions deployment model for .net. In this scenario you are just deploying like you would to deploy a function app which is a pretty good approach.
Key Value Proposition
The key reasons people tend to choose this option are:
- Portable hosting on different platforms
- Opens up the on premise use case by hosting on Kubernetes on prem
- Benefits of App Service and Functions
- Low Latency from Stateless workflow
Summary
Hopefully this provides some interesting things to think about in relation to my interpretation of these changes. It will be really interesting to see how this progresses from Preview to GA and its a pretty exciting time to be in this space.
