Logic Apps Pricing: Consumption Model vs Hourly Model

In case you missed it, Logic Apps moved to General
Availability last week.

At the same time, pricing for Logic Apps gained a new option: Consumption
charging i.e. pay by use.

I‘ve been talking to a number
of clients about this new pricing model, and every single one has expressed concerns:
it‘s these concerns that I wanted to touch
upon in this post. Most of these concerns are based around the fact that these customers
feel they can no longer accurately calculate the monthly cost for their Logic Apps
in advance.

I also feel that the whole discussion might be a bit overblown, as
once you remove the cost of having to pay for servers and server licenses for a traditional
on-premises application (not to mention the run and maintain costs), Logic Apps can
be significantly cheaper, regardless of which pricing model you use.

Old Pricing Model vs New

Prior to GA, Logic Apps were charged as part of the App Service Plan
(ASP) to which they belong: An App Service Plan has a monthly charge (based on the
number of compute units used in the plan), but also throttles a Logic App once a certain
number of executions are exceeded in a month (the limit changes depending on the type
of ASP the Logic App uses).

Effectively the old way was Pay Monthly, the new way is Pay As You
Go.

This table outlines the changes:

	App Service Plan Model	Consumption Model
Static Monthly Charge	TRUE	FALSE
Throttling	TRUE	FALSE
Limit on Number of Logic App Executions	TRUE	FALSE
Pay per Logic App Execution	FALSE	TRUE

I can understand why Microsoft are making the change: consumption
pricing favours those that have either a small number of Logic App executions per
month (as they only pay for what they use); or who have large numbers of executions
per month (and were therefore being throttled as they exceeded the ASP limits).

I‘m not sure yet if the
ASP-style pricing model will stay: there‘s
no mention of it any more in the Logic Apps pricing page, but you can still (optionally)
associate a Logic App with an ASP when you create it.

How to select either pricing model when creating or updating a Logic
App

When you create a new Logic App, you used to be able to select an
App Service Plan: now this option is no longer available, and all new Logic Apps use
the Consumption pricing plan by default.

However, if you have an existing Logic App and you wish to switch
the billing model, you can do so via PowerShell here.
You can also follow the instructions at the bottom of this blog post here (I
suspect this will get surfaced in the Portal if both billing models are kept).

Why the new model can be confusing

Consumption pricing makes sense: one of the benefits of Azure is
that you pay for what you use. Instead of paying upfront for an expensive license
fee (e.g. SQL Server and BizTalk Server licenses) you can instead pay a smaller amount
every month. A lot of businesses prefer this as it helps with cash flow, and reduces
capital expenditure.

The main issue with consumption pricing for Logic Apps is that instead
of paying for each execution of the Logic App, you‘re
paying for the execution of the actions within that Logic App. And this is the problem,
as a Logic App is opaque: when you‘re designing
a solution, you may know how many Logic Apps you‘ll
have, but you may not know exactly how many actions each will contain (or how many
pf those actions will be executed) and this makes it difficult to estimate the runtime
cost.

Up to now, it‘s been easy
to work out what a Logic App will cost to run. And that‘s
usually one of the first questions from a client: how much will this cost me per month.

But now, it‘s harder: instead
of knowing exactly you have to estimate, and this estimate has to be based not only
on how many times a Logic App will execute, but also *what* the Logic App will be
doing i.e. if it will be looping, or if actions in an IF branch will execute.

Effect of the consumption model on development and testing

The main concern I (and others) have with the Consumption billing
model is the effect it will have on development and testing: developers (and testers)
are used to executing their applications with little or no cost (other than maybe
the cost of an dev/test server and dev/test licenses).

Take a BizTalk Developer: chances are the BizTalk and SQL Server
Licenses they are using came from an MSDN subscription, or they bought the Dev edition.
In either case, they will execute their code during the development process without
paying any attention to cost.

The same applies to testers.

An argument can be made that the cost per action of a Logic App is
so low that this wouldn‘t be an issue (e.g.
a reasonably complex Logic App with 50 actions per execution would cost 2.5p (4c)
per execution. But the pennies do add up: imagine a corporate customer with 100 developers:
each time those developers execute a Logic App like this, it costs the company £2.50
(US $4.00) – and that‘s just executing
it once.

Microsoft will likely point out that an MSDN Subscription comes with
free Azure credit, and that therefore there is no extra cost to execute these Logic
Apps as they‘re covered in this free credit.
But this doesn‘t apply to most of my clients:
although the developers have MSDN, the free credit applies only to their MSDN subscription
not the corporate subscription where they perform dev and testing. The MSDN subscriptions
are usually used for prototyping, as they‘re
not shared amongst multiple developers, unlike the corporate subscriptions.

So to summarise:

Consumption pricing could lead to:

• A preference against Test Driven Development due to perceived cost
  of executing code frequently against tests
• Corporates hesitant to allow developers to execute code during development
  whenever they want due to perceived cost
• A hesitation on performing Load/Perf Testing on Logic Apps due to
  the cost of doing so e.g. with our sample 50 action Logic App, executing it a million
  times for load testing would cost £4500 (about US $6000) – consumption
  pricing gets cheaper once you get over a certain number of actions (so a million actions
  is £0.00009 per action) – this is retail pricing though, some large customers
  will benefit from a volume licensing discount e.g. for an Enterprise Agreement.

Note: There is questionable value in performing
Load/Perf Testing on Logic Apps, as there is little you can do to tune the environment,
which is the usual rationale behind Load Testing (especially in a BizTalk environment).
However, some level of testing may be required if your Logic App is designed to process
multiple messages and there is either a time limit or the messages are connected in
some way (e.g. debatching a request and then collating responses).

The solution

The solution (in my view) is to keep both billing models:

• ASP pricing can be kept for development/testing, which will have
  the effect of putting a cap on the cost of development and testing (although will
  hamper Load Testing). ASP pricing also benefits customers who have a reasonable number
  of executions per month, but aren‘t hitting
  the throttling limits. ASP pricing also allows for customer to try out Logic Apps
  for free by using the Free pricing tier.
• Consumption pricing can then be used for Production workloads, or
  for those who find that consumption pricing is cheaper for them for dev/test than
  ASP pricing

In addition, it would help if Microsoft provided more examples on
monthly cost; provided some way to help calculate the monthly cost under the consumption
model; and highlighted the overall reduction in cost through using Logic Apps for
most customers. For example, if your Logic App is under the ASP pricing model, and
you execute it, then the portal could tell you what that execution would have cost
you under the consumption model (using retail pricing). Just an idea!

Let me know if you have other opinions, or agree/disagree with this.