Behind a usage-based pricing change: an interview with Cloudflare

A couple of weeks ago, I talked about how Cloudflare’s new Workers pricing launch was the latest in a trend the company has been pushing towards simplicity and effectiveness in pricing. Recently, I sat down with Brendan Irvine-Broque, a product lead on Workers at Cloudflare to learn more – both about the architecture of the product, and how Cloudflare thinks about pricing across its whole product suite.

Although Cloudflare got its start protecting existing websites from attacks, and making them faster, it’s broadly an infrastructure company dedicated to building a better Internet. Cloudflare took that high-performance software and all the accrued process knowledge of working with a global network (300+ cities!), and has grown into a serverless developer platform, centered around Cloudflare Workers.

As our conversation turned to Cloudflare’s pricing, Brendan highlighted how tied it is to the go-to-market motion of an individual product line. If a product is primarily sold as a “lift and shift”, meaning you’re directly replacing a competitive product and mirroring the existing usage pattern, customers must be able to understand how existing usage would map to Cloudflare’s solution. It’s no surprise, then, that a product like R2, which provides S3-compatible object storage, is priced on writes, reads, and storage where a developer might be mapping utilization to their current S3 usage and costs. 

On the other hand, Brendan tells me that Workers are the foundation of so many net-new workloads for customers that clarity and innovation on pricing is crucial: “Realistically, most developers don’t understand industry-standard duration in Gb-seconds, and they shouldn’t have to. In Cloudflare’s new usage-based pricing model, you only pay for CPU seconds without any limit or charge for duration or wall time.” Underlying this pricing change is the value that Cloudflare places on both predictability and understandability for developers: the technical champions for Cloudflare’s product. There’s a huge cognitive overhead to assessing the tradeoff between limiting your CPU time and being charged for duration, which can be fundamentally out of your control. With new Workers pricing, the vast majority of users pay Cloudflare less for any individual worker invocation and are more in control of their bill, since they’re not paying for the variable time external services and APIs take.

In our conversation, Brendan highlighted how crucial the isolate-based model of Cloudflare workers was for the ability to launch this pricing. Unlike other serverless solutions that use process-based isolation which is significantly more heavyweight, Cloudflare can run multiple workloads in a single process. This allows the company to think in microseconds of CPU time and minimize the memory allocation overhead associated with new userland code. Although Cloudflare is familiar with Firecracker (the virtualization runtime underlying AWS’ Lambda), v8 isolates allow for faster startup time and lower overhead when switching between workloads, making them a fit for the low-latency requirements of Workers. Without this core investment early on in building Workers, simpler pricing would have been many leaps away.

Having worked with fast-growing companies at Orb to arm them with the data infrastructure they need for usage tracking, I pushed Brendan on the sheer investment required to pass on this pricing efficiency to developers. It turns out that the same infrastructure that powers Workers’ billing and pricing – heavily dependent on Clickhouse for extremely fast operational analytics – is also what’s used internally for observability. In fact, it’s even shipped as part of a new beta product, Workers Analytics Engine. Brendan underscored that observability, analytics, and dynamic billing are so closely tied together; if internal teams need visibility into their worker CPU time as part of architecting other products that compose them, chances are that this should be passed onto Cloudflare customers as well.

Brendan’s framing of usage-based pricing at Cloudflare reminded me that monetization is a truly user-driven product exercise – not something that happens purely in spreadsheets and back-office tools. At Orb, we believe that your billing system should be an accelerant in helping you iterate quickly, so you can bring your best product innovations to market without having billing get in the way.

‍