Consumption vs Dedicated Billing Models, which One is for me?

In our previous blog posts, we have talked about consumption-based, or micro-billing models as an advantage to Serverless architectures. But, with recent announcements by the Azure Logic Apps product team to include Integration Service Environments (ISE), does it still make sense to focus on pure consumption billing models? Here, we will explore Consumption vs Dedicated Billing models and identify some of the pros and cons of each model.

Consumption-based Billing Models

Consumption-based billing models are predicated upon a basic concept: pay for what you use. This allows organizations to ease their way into a technology set without making a significant up-front investment. For organizations, just starting their integration PaaS or Serverless journey, this creates many opportunities over traditional approaches of paying large upfront license fee. Consumption-based approaches allow paying incrementally based upon consumption. Azure Logic Apps uses a graduated tier, meaning your cost per unit goes down with increased consumption.

This approach becomes very appealing to early adopters as their bill is much lower than it would be otherwise.

In addition, organizations who’ve already invested in existing middleware or other integration services that have a yearly subscription, it may be cost prohibitive to make another large-scale investment as you are now technically paying for two platforms. In a consumption model, the financial impact is minimized as you’re incrementally paying for new integrations. You’re not paying up-front and then growing into your investment.

Another aspect of consumption-based billing models that customers are attracted to is they have access to the same cutting-edge technology stack that large customers have access to.

With traditional models, there is an element of exclusiveness as some customers may not be able to afford the sticker price. But in a consumption-based model, they can use this technology, but perhaps in a smaller scale and pay proportionately. An example of this is Cognitive Services. If you’re going to build machine learning models, the tooling to train and deploy these models, it will cost prohibitive for most companies. But, having these services being made available in a consumption model allows organizations, of all sizes, to use this technology. This type of consumption model isn’t restricted to Cognitive Services, it also applies to technologies like Azure Logic Apps and Functions.

The Challenges in Consumption-based billing model

While everything up until this point sounds great about consumption-based models, there are some challenges as well. Budgeting for these types of applications can be difficult. For many organizations, they have yearly or even multi-year budget cycles. This creates friction in the budgeting process as it may be difficult to predict future costs.

Forecast too much money is required and you look like you aren’t in control of your costs. Forecast too little and people will question whether this new approach will live up to the expectations that you have established for it.

Noisy Neighbor scenario

Another challenge for consumption-based models is performance. Consumption-based models work on the idea that a cloud provider can always sell excess capacity. Meaning if you are not using a lot of resources, that those spare resources can be used by someone else. But, what happens if many customers all need resources at the same time? This scenario is often called “noisy neighbor” as someone else’s consumption may interrupt the system resources that are made available to service your requests.

Now, this isn’t to say that performance is going to be so bad that processes will fail. Cloud vendors will not remain in business if this is the case. But, it may mean that you will see the occasional API call that needs to be resubmitted. In addition, cloud vendors will publish limits and impose constraints to avoid run-away processes from impacting customers. Microsoft has chosen to be very transparent about limits and has published the following article as part of their documentation. Some of these limits include:

• Run duration (90 days)
• Storage retention (90 days)
• Foreach looping (100,000 iterations)
• Concurrent outgoing calls (~2,500)
• Message size (100 MB)
• Connector throttling (varies by connector)

So naturally, there are some tradeoffs that exist when using consumption-based plans when it comes to cost vs performance. For many organizations, these tradeoffs may be acceptable. For others, they may not and it will be worth looking into dedicated plans.

Dedicated billing models

Dedicated billing models allow organizations to take advantage of cutting-edge technology sets, but have more control over the financial costs and performance of these services. Within Azure, having dedicated consumption is nothing new. Azure Service Bus, Azure Event Hubs, and Azure Functions all have these types of plans.

By using dedicated models, you are making a commitment to the service which means that even if you are not servicing requests, you are still being charged for the service. This does result in some benefits though like more predictable performance. More predictable performance is achieved through reserved system resources, including things like VMs that host your services that are always available.

Integration Service Environment (ISE)

At the BizTalk360 Integrate 2018 conference in London, the Azure Logic Apps team announced their own dedicated solution called ISE, or Integration Service Environment. At the recent Microsoft Ignite conference in Orlando, they provided an update and informed customers that ISE is currently in private preview with an upcoming public preview being available later this year. Some of the benefits that Microsoft called-out include improved performance and storage and compute isolation. This isolation will provide customers with more predictable message processing.

VNET Connectivity

Another capability that often exists in dedicated plans is VNET connectivity. VNET connectivity allows you to join services like Azure Functions, Azure Event Hubs and now Azure Logic Apps to virtual networks in your Azure Subscription. VNETs are also used when creating VPN or ExpressRoute connections between your on-premises network and Azure. This means your integration services, like Azure Logic Apps, can connect to your on-premises networks without the need for an on-premises data gateway.

You may be asking yourself “we have the on-premises data gateway, what is the big deal”? This is true, today the on-premises data gateway does provide some connectivity between Azure and local datacenters through a small software agent that gets installed in your network and connects to an Azure Service Bus Relay service that provides this network tunnel.

But, using a VNET provides some advantages including:

• Performance: During some initial tests, the Azure Logic Apps team saw up to 4x throughput improvement when using VNETs vs on-premises data gateway.
• Larger message sizes: Currently the maximum message size using the on-premises data gateway is 2MB. While this may make sense for some workloads like small database interactions, it clearly is a constraint in some enterprise scenarios.
• Larger number of concurrent connections: The on-premises data gateway is a small software agent that runs on a VM. These agents naturally have some limitations in their ability to handle a high number of concurrent connections vs a network pipe that has been designed to handle many network connections.
• Fewer Custom Connectors needed: Today if you have an on-premises system where Microsoft does not have a connector for it, you can create a custom connector that can use the on-premises data gateway for connectivity. However, this is a multi-step process. Instead, using a VNET will allow for HTTP connections that would otherwise require the use of the gateway and a custom connector.

Image Source: Azure Logic Apps Session at Ignite 2018

In addition to all of the benefits that we have described, customers who subscribe to a dedicated plan will still be able to take advantage of serverless characteristics that exist inside of Azure Logic Apps today in a consumption-based configuration. This includes Microsoft continuing to manage the underlying infrastructure, patching, SLAs etc.

Naturally, when you are in a dedicated billing model you can expect to make a larger up-front commitment to the cloud provider as you are receiving dedicated capacity. Azure Logic Apps ISE pricing currently is not available. But if we look at Azure Event Hubs for comparisons sakes, I think we can draw a reasonable conclusion.

Note:

The example provided below does not necessarily predict Azure Logic Apps costs. Refer to the Azure Portal once they are available. Azure Event Hubs pricing is being used for illustrative purposes only.

If we decide to choose an entry level Event Hub Standard configuration, it includes 1 million messages and 730 Throughput unit hours. For this service, we can expect to pay approximately $22 USD/month. If we choose to run this Event Hub in a dedicated manner, we can expect to pay approximately $4,999.770 USD/month. On the surface, this looks like a very disproportionate balance of costs vs performance. But, to be fair the Event Hub Dedicated plan has much greater performance capabilities.

For example, in the Standard plan, the maximum number of events per second is 1000 or 1 MB of data ingress. The Dedicated plan has no restrictions on ingress and egress since you have the reserved capacity. In addition, Event Hubs Dedicated offers 100,000 Brokered connections vs 1000 and a maximum message size of 1 MB vs 256 KB. In addition to raw performance, there are also some additional value-add features that are included in Event Hubs Dedicated including longer data retention periods and Capture which allows you to bifurcate your hot and cold analytics paths for further analytics and analysis.

While on the surface it looks like you pay a lot more for dedicated capacity and in some scenarios, this may be the case. But is very important to consider your requirements.

Consumption vs Dedicated Billing Models, which one is right for me?

In this article, we outlined many of the pros and cons of both consumption and dedicated plans. Ultimately, you need to look at your requirements and determine which of the following features matter to you the most. It may be worth stack ranking them so that you can really prioritize the features that you need. For example, a stack ranking that looks like the following may be a good candidate for the consumption-based approach:

1. Technology Evaluation
   1. Greenfield applications
   2. Migration from existing Integration Platforms
2. Unknown message throughput requirements
3. Small message sizes
4. Performance (If a message takes 1 second longer than expected, that is acceptable)
5. Limited on-premises integration
6. Budget predictability

Alternatively, if your stack ranking looks similar to the following, then its a good candidate for a Dedicated-based approach:

1. Strict SLAs in place with your customers/partners
2. Well understood message throughput requirements
3. Predictable on-premises connectivity
4. Budget predictability
5. Long-term commitment to the platform
6. Large message sizes
7. Advanced feature requirements/data retention

Something that is important to consider when deciding on consumption or dedicated plans is, for the most part, the way in which you build your application is generally the same. Yes, there may be some things that you deliberately need to do to work around file sizes or specific features, but in general, you can start with a consumption plan and then decide to move to dedicated plan without a lot of re-work. This should give organizations comfort that they can defer this decision if they are uncertain about it.

Wrap up

Ultimately, whichever path you choose, it is good to have options. If you look back at services like Azure Event Hubs, Azure Service Bus, and Azure Logic Apps, dedicated plans were created out of need. In specific circumstances, customers have exceeded some of the capabilities of consumption plans. For these customers, they now have another option. They now need to understand some of the nuances that exist with dedicated plans. But it gives them a choice that they can evaluate based on their requirements and their budget. This is ultimately a good thing.