I’ve always been fascinated by pricing models. These models can have a huge impact on the realized value of a good or service, and define a big portion of the risk associated with consuming a good or service. Pricing models can also put the customer and vendor at odds with each other, but, when done right, can also be amazing vehicles for driving win-win scenarios for vendors and their customers.

Given that enterprises are actively pursuing Platform as a Service (PaaS) evaluations and purchases, it’s no surprise that Apprenda is getting more inquiries than ever regarding our pricing methodology. Apprenda, at the technical level, is a distributed fabric that stitches together an arbitrary number of Linux and Windows OS instances into a single resource pool for deploying, running, and managing multi-tier apps. The capacity of an Apprenda instance is entirely defined by how many OS nodes are contributing compute, memory, and storage to that Apprenda instance. Our pricing aligns with this.

The cost of an Apprenda license is based on the amount of memory, in gigabytes, contributed by the OS in that fabric instance. For example, if a customer is running 10 nodes (some mix of Linux and Windows) with 24GB of RAM, they will secure a 240GB Apprenda subscription. If that customer had 20 nodes, each with 12GB, it’s still a 240GB license.

Why is our licensing this way? Years ago we used to license Apprenda based on number of nodes. (Pay attention that I’m not saying VMs. This will matter later in the post.) We learned that, in practice, counting only nodes was an awful model. It didn’t align well with the value we generated, and it certainly didn’t align well with what customers want to do with their IT strategy.

Let’s start with the value discussion. There are five important principles:

1. Applications are typically memory bound. As such, quantifying an application footprint tends to be most straightforward if we use memory as a lowest common denominator.

2. Whether an organization has lots of small apps, a few very big apps, or a mix of the two, memory tends to properly quantify the “size” of an application portfolio.

3. A well-built, modern PaaS should be application centric. Any cost associated with a PaaS should closely mirror the application footprint, and thereby the value generated by that application portfolio. It should not be shaped by infrastructure decisions.

4. Memory is “fair” in that it’s hard for both the vendor and the customer to cheat. Memory is hard to oversubscribe without serious negative consequences, thereby providing the stability one would expect from any good unit of measure.

5. Memory-based pricing doesn’t influence infrastructure architecture in a negative way. Whether someone decides to have lots of small apps or a few big ones, the only thing counted is aggregate memory.

These five principles provide a reasonable foundation for why memory-based pricing makes sense and more closely reflects application value. But now let’s dig into something more controversial: the assertion that VM-based pricing burdens PaaS customers with unnecessary inflexibility and, in many cases, exists to propagate old technology in new packaging.

For any PaaS with a VM-based pricing model, the unit of measurement is the VM-unit. That is, for any VMs that are activated in support of the PaaS or guest applications, a customer pays a license fee. For example, if an enterprise were charged $7,000 per VM per year, and ran 30 VMs in support of the PaaS and its guest applications, that would result in a $210,000 per year aggregate license fee.

This model is problematic for a number of reasons:

1. VM-based pricing is incongruent with the application-centric vision for PaaS. It’s levying a cost based not on value drivers (e.g. applications), but rather on raw infrastructure. This alone should invoke pause in anyone evaluating PaaS pricing.

2. In this model, customers are not free to shape infrastructure-architecture decisions independently from PaaS licensing. For example, if an enterprise builds an initial private PaaS footprint with 20 VMs each with 24GB of RAM, and then decides that it can achieve lower resource contention and higher system stability by having 40 VMs with 12GB each, it has to pay the PaaS vendor for more VMs. Or, put another way, it’s a tax on making better design choices. This fact artificially and unfairly penalizes customers, and handcuffs IT strategy because of the economic penalties caused by the PaaS.

3. Bare metal is not an option here. For many, the idea of a hypervisor sitting underneath a container-based PaaS is redundant. A well-built PaaS provides guest applications with portability across the infrastructure, high availability, etc. In this model, an enterprise is precluded from choosing an implementation where the PaaS sits atop Linux and Windows nodes that are sitting directly on the hardware.

4. In this model, the complexity of planning for capacity and cost increases. Today’s PaaS offerings expose container-size options to developers. That is, as a developer, I’m presented options that map to the size the OS processes (not exactly, but close enough) running my app components, and not VM sizes. A single VM may act as host to multiple containers of different sizes. A PaaS packing strategy isn’t obvious, so as developers deploy more apps, how many VMs will I need? How does that map to cost? This layer of complexity obfuscates the situation, whereas memory-based pricing maps directly to the domain model that developers use to assign resources to their apps.

VM-based pricing puts the economics of PaaS at odds with the freedom and flexibility that customers need to execute a broad IT strategy. Simply put, vendors promoting a VM-based pricing model are either illogical or disingenuous, existing to drive revenue for virtualization-oriented vendors. By embracing VM-based pricing, these vendors simply aren’t focused on the best outcome for the customer but instead focused on how to more effectively pad their pocketbooks.