This blogs records why we should migrate our consumption Logic Apps to standard.
Back in the day Microsoft signalled that we should migrate our BizTalk interfaces to Azure Logic Apps and other Azure resources. We listened and six years later we shutdown our BizTalk server. Our BizTalk server architecture has become an Azure architecture tabulated below.
| Type | Count |
| Action group | 14 |
| API Connection | 102 |
| APIM Management Plan | 3 |
| App Serviceplan | 1 |
| Application Insights | 3 |
| Function App | 1 |
| Integration Account | 1 |
| Key vault | 1 |
| Log Analytics workspace | 7 |
| Log Search Alert Rules | 4 |
| Logic app | 291 |
| Managed Identity | 1 |
| Metric Alert rules | 704 |
| Service Bus namespace | 8 |
| Smart detector alert rule | 4 |
| Solution | 2 |
| SQL database | 11 |
| SQL Server | 1 |
| Storage account | 4 |
BizTalk Migration ADR
During the migration we stuck to our original architectural decision record (ADR). In the first place, ignoring many of the new additions to Azure during these six years. We are now catching up on these in another development cycle.
Our plan was to move our logic apps to run under an app service plan or ISE once we knew our costs better. Thus, opting for a ‘pay as go’ service and planning to go to a fixed cost service later. ISE has now been deprecated and superseded. Logic apps that run under an app service plan are now Standard Logic Apps. The name of the original Logic Apps is now Consumption Logic Apps. The terminology is different now too. Consumption Logic Apps are described as being hosted in a multi-tenant runtime. Standard Logic Apps are hosted in a single tenanted runtime inherited from the Azure App service ecosystem. There are many benefits to the single tenanted runtime and this is summarised here. While this migration is the main topic of the rest of this article it is worthwhile highlighting some of the other new additions that we want to retrofit to our exchange.
Event Grid was added to suite of Azure components in 2017. Event Grid enables you to build event-driven solutions. Adding Event grid will reduce unnecessary polling by some triggers and reduce overall cost.
In logic app workflows, some triggers and actions support using a managed identity for authenticating access to resources protected by Azure Active Directory (Azure AD). When you use a managed identity to authenticate your connection, you don’t have to provide credentials, secrets, or Azure AD tokens.
Please let me know if you think there is anything else in the last six years that we should be adding to our ecosystem.
The case for migrating from consumption to standard Logic Apps
I think that Microsoft are now signalling that you should move enterprise grade integrations to standard Logic Apps. Furthermore, there have been no new innovations for consumption Logic Apps in the last year. If anyone knows of one please let me know. For example, the new mapper and the Azure monitoring experience are only available with the standard tier.
To tell the truth, I think most people have chosen standard Logic Apps because they can map, encode and decode message without having to pay for an Azure Integration Account. On the other hand, the only thing that an Integration account brings that you can’t do in standard Logic Apps is store and manage B2B artifacts in workflows for B2B scenarios. For this reason, I think you need an integration account for AS2, EDIFACT, RosettaNet or X12. A basic integration account is expensive costing about $1000. It is not clear whether the standard tier will ever include these costs too. Please let me know if you know of a way to do B2B for these scenarios in the standard tier without using an integration account.
To conclude with migrating from consumption to standard Logic Apps is the right thing to do.
The cost of standard versus pay as you go
Last but not least given that migration of consumption to standard tier is straight forward what would our costs look like? The difference is that instead of paying for Logic App actions as you go you pay for App Service host. Most importantly this is a fixed cost whether you run any Logic App instances on that host or not.
In our case we have 292 Logic App to host in App service hosts. Firstly, we have to decide how to partition these because this will tell us how many hosts we need. I guess this will be an art rather than a science. I hope that the fixed cost is no more than your pay as you go costs.
The fixed cost depends on the number and type of host that you chose. The choices are
| Instance | Estimated Fixed cost $NZ/per month |
| WS1 – 1 vCore, 3.5 GiB RAM, 250 GB storage | $309 |
| WS2 – 2 VCore, 7 GiB RAM, 250 GB storage | $618 |
| WS3 – 14 VCore, 14 GiB RAM, 250 GB storage | $1238 |
Thus if your consumption Logic Apps cost you $1000 month, you could run 3 WS1 hosts, 2 WS2 hosts or 1 WS3 hosts.
Could I run 292 Logic Apps on so few hosts? Does a fixed cost model offer any advantage with respect you costs? I have been asking these question to a few people this week. The combined wisdom is that 50 is about the practical maximum but the limit is 100. Clearly we require a lot of performance testing to validate this. Thus it seems that the fixed cost model will not lower our costs.
Conclusions
As was previously stated migrating from consumption to standard Logic Apps is the right thing to do. Unfortunately, I think it is unlikely that our fixed costs will not be less than our “pay as you go” costs. This cost modelling would change if we did not have to pay for an Integration Account for AS2 and EDIFACT B2B interfaces with the standard Logic App tier. Thus we will wait until there is clarity about whether you require an integration account for Standard logic Apps or not.
