Migrating Logic Apps from Consumption to Standard

Sandro Pereira is a consultant at DevScope. In the past years, he has been implementing Integration solutions both on-premises and cloud for several international clients, each with different scenarios using Microsoft Azure (Logic Apps, API Management, API, Service Bus, …) and Microsoft BizTalk Server with various technologies like AS2, EDI, RosettaNet, SAP, TIBCO, etc.

He is a regular blogger, an international speaker, a member and moderator on the MSDN BizTalk Server Forums, and a Code Gallery contributor. Sandro is a technical reviewer of several BizTalk books focused on Integration and the author of the book “BizTalk Mapping Patterns & Best Practices.” He has been awarded MVP since 2011 for his contributions to the integration community.

A glimpse of the migration phase

Logic App Standard is relatively recent, and most companies have been using Logic App Consumption for a long time. Logic App Standard brings us all the benefits and other impossible features with the Consumption lead. Sometimes, clients migrate from the consumption layer to the standard layer. Microsoft is starting to create a tool to help clients migrate from the consumption layer to the standard layer. Now, Logic App Standard still doesn’t have many features on the consumption layer. It is something that Microsoft already spoke about publicly, and they are working early on closing the gaps between one and the other. Mainly the gaps are in the connectors. Not all the connectors available on the Logic App consumption are available in the standard layer. Microsoft is working on closing all these gaps and improving the overall experience between migrating Logic App consumption to standard.

Developer experience during the migration

These two Logic Apps use the front end and are different in essence. They seem equal in design. We still have a new designer in the Logic App standard that will be available and is already available in the consumption layers preview. In some cases, we can add the actual portal to the new Logic App Designer, and this is the designer that leads out of the box with the standard layer. It is identical but kind of static stuff. That is, we have smaller shapes, and we can figure out all the actions in the panel on the right side. If you know one, you know the other. It’s just the designer and the layout that is changing; all the rest are the same, but they are using different engines now. Logic App consumptions use the Logic App runtime more than the normal one; the one in the Logic App standard uses the functional asset runtime.

It is a different runtime, and because of that, the developer experience is slightly different. To develop the portal, you need to use Visual Studio code. It’s the only editor that has full capabilities. If you are a developer unfamiliar with Visual Studio Code, you must also become familiar with that. Because now we need to use both tools, we need to use Visual Studio code, and we need to use Visual Studio. In Azure, depending on the service, you need to adapt to the available developer tools.

When to use what?

Always look at the client’s requirements; that’s the first rule, and everything depends on the requirements. One thing making a bit of difference is that the consumption layer is pay-per-use. You buy what you will use, the cost is not fixed, and the advantage is you can automatically scale. It doesn’t matter if you send one or 1000 requests; it will adapt because it is serverless. You have to notice that you are sharing that environment with many clients, and Microsoft manages this. Of course, there are some throughput limits, for example, throughput limits about how many messages you send. The standard layer is a compute base layer; you need the behind-the-scenes. It’s a fixed cost, and you know that if you don’t process anything or process 1000 messages, it’s still the same CPU and memory is the compute base you are paying.

It is not mandatory to choose one, and you can choose both. In some integration layers, you can use the standard layer, and in some cases, you can use the consumption layer. What benefits more in terms of cost and requirements is what you need to use.