Peter in the Azure sky

I really like the Azure Logic Apps. I really do. Combined with API Apps, Azure Functions you can build really nice and well micro-service-like workflows in a really well designed way. Saying that – I also believe Microsoft has made a mistake with the pricing model in the consumption plan. I will therefore post this to raise your awareness of scenarios you should avoid. I am certain that Microsoft will fix this pricing injustice later due to the fact that it discourages well-designed logic apps.

Update 2018-03-21: The cost model has now changed and the costs used in the examples below are not accurate anymore. I have written a new post regarding the logic app costs that will give you updated advice on how to tackle, plan your Logic App costs. You will find the updated post here. You should still be aware of the pricing model to make sure that the cost does not surprise as you may still (during certain circumstances) get a quite high cost for your logic apps. But not as bad as is presented below. I however decided to leave the information below as the part of explaining action executions is still valid. But when it comes to costs, I  recommend this updated post instead.

A little back story. When I posted my last post on Logic Apps (The Bad-PR Logic App) the pricing model for Logic Apps were based on App Service Plans and you had a ceiling on the price you would pay for your logic app. This has now changed and the only pricing model available is the new(er) Consumption Plan. Consumption plan in itself is what the cloud is all about with pay for what you use but what I will try to illustrate is that you are penalized for a clean pure micro-service approach and are in fact charged higher the more steps/activities that are activated. I will also illustrate that the prize of a single Logic app may become quite expensive at the current pricing rate at certain use.

First lets dig into the pricing model of Logic Apps. The total story can be found here.

Important: In the examples below I will look at the cost of the Logic App execution only (any other costs part of the Logic App execution will not be a part of the calculation such as databases, service bus, twilio SMSes, sendgrid emailing, data traffic etc). I will also use list price which may or not be too high because it can often be discounted if you have an EA or buy from a CSP.

Action execution – what is it?

The chargeable unit in a logic app is an action execution, and the simplest way of describing this is any step that is run in the logic app. It is important to understand that triggering a Logic app to look for messages in an empty service bus queue or database will still count as an executable action.

Charged:

• So any polling action will count as a chargeable action.

  

• Any step (send SMS,  call to azure function, database lookup etc) in the logic app that is actually run is also counted

What is not charged:

• any (non-polling) action that is not run due to that for example the queue was empty or there was a condition that prevented the action from being run will not count

So what does this mean in terms of payment? My interpretation for this is that you are penalized the more steps you run. If your logic app has polling trigger followed by 9 steps is going generate 5 times more action executions than if you call a single Azure Function after the trigger (where you do many steps in one activation). So the nice micro service based solution will cost you 5 times more per logic app execution even if your design is a better one seen from an architectural perspective.

Also you need to consider the amount of executions that the Logic app will run per month. Lets consider the picture I illustrated in the previous section. This generated 172 800 actions/month even if we don’t receive any messages at all.

Actions executed/month	List Price (as of 2017-Feb-16 North Europe)
First 250 000 actions	€0,0007/action
250 000–1 million actions	€0,0003/action
1 million –50 million actions	€0,00013/action
50 million –100 million actions	€0,00008/action
100 million + actions	€0,000046/action

So lets think of a couple of scenarios.

Scenario 1: For the basic scenario above where I will look for messages each 15th second but will never receive any messages in a service bus queue will cost  172 800 *  €0,0007 = € 121/month. That is a fairly high amount for nothing.

Scenario 2: If we tweak the first scenario a little bit. Why should we check for messages this often if we don’t expect to get any messages? So if we would change the polling interval to every tenth minute the cost would be: (6 times per hour * 24 hours * 30 days) * €,0007 = 4320 Actions  * €,0007 = €3 which is a really low figure even for nothing.

Scenario 3: we design a logic app that will receive 100 000 messages on a service bus per month, they must be processed as soon as possible, it will parse the message from JSON to a JSON schemed message, save it to a database with action set to ‘start’, fetch some information from a web service using parameters from the SB message, depending if the value is above a certain value will email and send a SMS message (that will occur half of the executions on average), and then update the previous row with action set to ‘done’ and then complete the message.

Queue polling: Every 10 seconds (6 times per minute * 60 minutes * 24 Hours * 30 Days) = 259 200 Actions

Actions for single message:  Parse Json + initial save to the database, call web service, 0.5 emails, 0.5 SMS, Update database) = 5 Actions on average per message

Actions for the 100 000 monthly messages: 100 000 * 5 = 500 000 actions

Cost	Calculation	Actions
Polling actions	Every 10 seconds (6 times per minute * 60 minutes * 24 Hours * 30 Days)	259 200 Actions
Actions for single msg	Parse Json + initial save to the database, call web service, 0.5 emails, 0.5 SMS, Update database) = 5 Actions on average per message
Actions for messages total	100 000 messages * 5 actions (row above)	500 000 Actions

This adds up in 759 200 actions/month and a total sum of: (250 000 actions * €0,0007/action) + (509 200 actions * €0,0003/action) =  €175 + €152 = € 327 /month for a single integration. Looked on a yearly basis € 3 924 this integration alone can be compared to a the yearly license cost on a weak BizTalk Standard installation (in the cloud or on premise) capable of handling perhaps all your integration needs (you still have to pay for the hardware also, but it is also likely that you need more than one Logic Apps).

Also compare to set up a web job bound to the app service you would probably get away with a decent App Service for a lower cost. You could likely also put several web jobs on the same instance.

So what have we learned?

Logic Apps costs can get quite expensive. You should calculate the cost and compare it to other integration services before you choose it (even if it is the coolest guy in town right now).

If you can live with the expensive initial costs for the first Million executions, action executions are extremely cheap once you reach 100 Million action executions/Month. It will get cheaper and cheaper the more you have, i.e. the cost curve will level off.

Try to avoid excessive polling. Poll no more often than you expect to receive new data.

The more steps you have the more it will cost.

The more invocations the more it will cost. Consider that a partner gets a problem in their system and starts to send millions of service bus messages to your queue and you have a logic app consuming messages your cost will rise very quickly. A Web Job (unless auto-scale) will have some issues processing timely but costs will stay the same (for the Web Job – not necessarily other used services in the web job).

You can not reuse processing capacity between Logic Apps like you can with Web Jobs. Each Logic App will be charged individually and many integrations with Logic apps may generate a substantial cost.

There are a couple of bad scenarios for Logic apps with the current pricing model:

• IoT will generate too many action executions for being a logical component of an IoT scenario. Look at Event Hubs instead.
• Base load a database through a logic app. Will generate too many action executions (Write a console app, make an export/import or similar instead)

Look at what is available: There are for example other different logic app actions that may fit you Logic App better. Maybe you could write your own Azure Function to lower some costs etc.

What will it cost me?

As you can see in his post you really have to do the math and think long-term integration solution before you go all-in on the logic apps. There

https://azure.microsoft.com/en-us/pricing/calculator/?service=logic-apps