The proliferation of cloud computing has had, and continues to have, profound consequences for technological innovation and economic growth. For the majority of today’s companies, subscription-based cloud computing, delivered via a software-as-a-service (SaaS) model, has become an operational necessity. Internal business strategies no longer include deliberations about whether or not to leverage SaaS-based business management solutions, but rather, how many of them does a business need, and which solutions are the best in terms of functionality, interoperability, and economic efficiency?
At the same time that SaaS has revolutionized the way we conduct business, so too has cloud computing infrastructure changed in terms of increased scale, agility, and structural efficiency. Whereas before, cloud computing services, including server racks, data storage, networking and RAM (for greater computational bandwidth) were offered only on a fixed cost basis, now, enhanced services, in addition to a new breed of tracking and reporting software, can accommodate a highly flexible, consumption-based, usage fee model.
This consumption-based, B2B usage fee model for cloud computing infrastructure services is exactly what smaller (non-enterprise) software companies, startups, and developers have been gravitating toward in the past three years. It has unburdened these small companies from a fixed infrastructure spend, and given them the flexibility to access and leverage the same technology resources, but at a variable cost, so they can scale-in to the expense as they grow.
Completing a feedback loop in what I would argue is a virtuous cycle, is the increase in demand for consumption-based, usage fee billing from SaaS company end-users seeking the same economic efficiencies and flexibility in accessing technology resources. As SaaS companies continue to proliferate, in large part through differentiation in the business management solutions they offer, they continue to move ‘downstream’ in terms of the size of their end-users. The same dynamic that exists between SaaS companies and their infrastructure providers plays-out here as well.
Regardless of where the demand for the usage fee billing model is coming from, the demand is high, and it’s continuing to grow.
Back to infrastructure…
Most, if not all of the cloud computing giants – Amazon Web Services, Microsoft Azure, Google Cloud – and second tier providers – Twilio, DigitalOcean, Snowflake, Databricks, Confluence – now accommodate a consumption-based, usage fee model. Typically, it’s referred to as usage-based (UB) billing and it’s offered in addition to their standard one-size-fits-all billing option tiers. This transition to usage-based billing, where effectively the cloud service providers are acting in an infrastructure-as-a-service (IaaS) capacity, has led to more efficient economics for small SaaS providers while at the same time granting them access to their valuable computational and hardware resources – by only paying for the back-end infrastructure they use, and eliminating wasteful, recurring costs, small SaaS companies can moderate cash-burn.
But for all this to work, there needs to be a way, a software solution actually, to measure the usage.
Metering software is a system of record (SOR). It’s an application that measures, records and stores an agreed upon attribute of usage – every time, and in real-time. Attributes of computational infrastructure usage that are typically metered include number of users, duration of usage, and even frequency of usage as measured by API calls per period of time.
But the single most important quality of metering software, or any SOR, is that it must be authoritative – what it measures and records becomes the permanent record of usage, from which both parties, a SaaS company and an infrastructure company in this case, base their transactional relationship upon, i.e., “here’s what you used, here’s when you used it, and here’s what you owe.”
Investment bank take…
I love the metering and billing software space and I’ll be watching it closely this year on three fronts.
The first is its growth in the B2B, SaaS to cloud-based infrastructure realm. Though most of the larger cloud companies have already incorporated UB into their services options, not all of them are using their own metering software – in some cases they’re using a third party’s.
The second front is its growth in the B2B, SaaS to end-user area. Again, as SaaS-based business management solutions continue to diffuse through the economy, the SaaS companies themselves need to be able to accommodate their end-user’s, especially smaller businesses’, need for flexible billing terms. Assuming usage billing will be one of the ways SaaS firms address that need, there’s a real opportunity here for quality metered billing products to gain traction.
The third front is its adoption by existing, recurring billing companies. In this case, it’s important to remember that metering is more specialized than invoicing and collecting payments. The ability to measure, record, and be the SOR for usage is niche functionality that recurring billing software companies don’t (generally) own or employ. In fact, their core offering is much better designed for the fixed cost pricing packages that usage fee models are competing with. So, it will be interesting to see whether there’s greater adoption of metering in this space, as well as what form that adoption takes i.e., is it built, acquired, or offered in partnership with a third party.
Lastly, and this may be a bit ‘out there’ in terms of a potential opportunity for a metered billing software, there’s blockchain.
For those familiar with blockchain technology, a metered billing solution operating in the B2B, SaaS to end-user sphere, almost begs of a blockchain solution because it creates a dynamic wherein ‘trust’ is an issue. Being an authoritative, Solution of Record almost requires it. Though this concept bares greater consideration in the venture capital arena, I’d be very bullish on the prospects for a metering software solution built on a private, permissioned blockchain.