Why do so few vendors in the serverless space offer metered billing?

I was chatting recently with a client friend about optimising some dev workflow and operational aspects of the serverless solutions his company is building for its clients. I asked him if he had considered choosing a non-AWS third party service to help in these areas. He told me that the main thing putting him off is that the pricing models of these third party services don’t align well with the serverless solutions he’s building.

When you hear folks discussing the definition of serverless or the serverless mindset, the expectation of per-use pricing is almost taken as a given—the amount you pay for a particular service should scale linearly with your use of it.

In recent years, many vendors have sprung up around the AWS serverless ecosystem with PaaS/SaaS offerings aimed at addressing common problem areas such as monitoring, CI/CD and developer workflow tooling. Some of these products are complements to AWS services (that plug a feature gap) and some are outright replacements for an AWS equivalent (aiming to be best-in-class).

But ironically, very few of these vendors targeting the fast-growing market of teams building on serverless offer granular, metered billing.

Metered Billing vs Quota-Based Plans

From a customer viewpoint, metered billing for a service is the closest to the “I only pay for what I use” serverless ideal. A metered service defines a small number of core usage dimensions (often tied to compute, storage or requests) and charges in fine-grained units for each dimension. There is no minimum charge, so if you don’t use it, you don’t get charged. This is the model that almost all the AWS serverless suite of services use.

A quota-based billing model is where the vendor provides tiered packages/plans (often 3 or 4), with each plan stipulating maximum values of each usage dimension. Each plan has a fixed monthly fee and any unused quota does not roll over to the next month.

Here are some examples of vendors in the serverless space who use a form of quota-based billing plans:

• Thundra (Monitoring): Tiered plans with caps on function invocations and users.
• Epsagon (Monitoring): Tiered plans with caps on traces
• Lumigo (Monitoring): Tiered plans with caps on function invocations
• Serverless Framework Pro (Monitoring and CI/CD): Tiered plans with caps on events and concurrent CI/CD builds.
• Seed (CI/CD): Tiered plans with caps on users and build minutes (with additional users bolt-on option)

There are a few vendors that I should mention whose billing model is definitely closer to metered than quota-based plan:

• Stackery (Deployment/IaC): Pay per active stack
• Dashbird (Monitoring): Pay per monitored resource and GB of logs ingested
• Furnace (Data Pipelines): Cost-plus model relative to the charges incurred by the underlying cloud resources it provisions.

What’s the problem with quota-based usage plans?

Capped usage plans have been the staple of SaaS businesses ever since the SaaS genre was born. They are well understood by customers but they have several drawbacks.

First and foremost, you will pay even when you aren’t using something. Yes, many services offer a free starter plan but this often doesn’t help much for workloads whose usage will be inconsistent over the course of a year.

Another problem is that the price jump between plans is often steep. It’s not uncommon for a monthly fee to 3x or even 5x from one month to the next whenever a customer “graduates” to the next level up. Some vendors may auto-upgrade/charge you immediately when you hit a quota limit, others will give you a month’s warning. To avoid this, engineering teams may feel incentivised to make architectural decisions that otherwise would be considered suboptimal (e.g. bundling lots of functionality into a single Lambda function).

Whenever a dev team wants to use a service for multiple projects/products, these issues can exacerbate. Does the service allow you to isolate each project within a single account or do you need to register (and pay) for each one separately? Can your account’s usage quotas be spread across each of your projects?

The Vendor Economics of Metered Billing

So why don’t more vendors offer granular, metered billing?

Short answer: predictable recurring revenue.

These businesses have fixed costs to cover (primarily staff salaries) and having a steady income they can rely on from month-to-month helps greatly with making it sustainable in the long term. By selling in tiered packages, their income isn’t intrinsically linked to the usage levels of their customers.

I know from personal experience with my small SaaS product that if I wasn’t able to rely on a predictable sales income every month, my product wouldn’t have survived past its first year.

The big cloud providers of Amazon, Microsoft and Google can afford the income volatility that granular pay-per-use brings as they have other cash cows to fall back on to smooth things out. Smaller vendors don’t have this luxury.

Another motivation for quota-based plans is that some enterprise customers prefer the predictability that they bring over the more variable metered model, even if it means they end up paying more. My counter-argument to this is that most vendors already offer a “Call Us” enterprise plan with no published price so they could still offer metered billing in their published plans while privately offering custom quota-based plans for larger enterprises.

Conclusion

So there’s a clear tension here between the growing expectation of pay-per-use billing within engineering teams building on serverless and the vendor’s need to make their business sustainable. Will this change in the next few years? I’m not sure. For lower-level services that require minimal customer-facing support and cover their other running costs with their pricing, it’s certainly possible. For more complex, higher-level products with varied usage scenarios, it will be much harder to pull off.

If you know of any good examples of product companies serving serverless engineering teams using a granular, metered pricing model, please drop me a message.

— Paul.