The heart of tech is coming to the heart of the Mediterranean. Join TNW in València this March 🇪🇸

This article was published on July 5, 2012

Cloud pricing — A case of developers being stuck with an *aaS-backwards system

Cloud pricing — A case of developers being stuck with an *aaS-backwards system
Brad McCarty
Story by

Brad McCarty

A music and tech junkie who calls Nashville home, Brad is the Director TNW Academy. You can follow him on Twitter @BradMcCarty. A music and tech junkie who calls Nashville home, Brad is the Director TNW Academy. You can follow him on Twitter @BradMcCarty.

In the last few months, various cloud providers have cut their prices to stay competitive. Amazon reduced prices for the 19th time, Google dropped its prices for Storage and so did Microsoft, for Windows Azure.

When you talk to developers, startups and enterprises to get feedback about cloud pricing, the common theme from the answers you’ll receive can be distilled down to – “Cloud pricing is *aas backwards”. Joe Schwendt, Lead Solutions Architect at Apperian, feels that “cloud pricing models should be easy to understand and aligned with the success of the apps that use the cloud. They need to be easy and predictable.”

Cloud pricing is neither easy nor predictable. Today there are three common types of pricing models in the world of cloud computing:

The Resource-Based Model

This is the wild west of pricing. It is confusing and unpredictable. Developers start to pay when a server is provisioned, and for each server, there is an extra fee for memory, storage, I/O calls. network requests, etc.

Just go to the AWS pricing page and try to figure out what your monthly cloud costs are going be when you’re in development mode, and how your costs will change when you launch your app in production. You’ll be guessing.

Developers typically end up over-provisioning their cloud infrastructure, pay too much, and an unplanned banner month for their production application, could decimate a planned operating budget.

The Feature-Based Model

This pricing model charges the developer for every feature they use. Number of API calls – that’s one price. Want to add push notifications? – That’s extra. How about versions? – Again, an additional fee.

Apps that are being built today are increasingly feature-rich. However, a feature-based pricing model compels developers to limit the number of features in their app, which could thwart adoption of an otherwise useful app.

A developer should not have to artificially constrain the design of their app and its use of cloud features based on the penalties from a feature-based pricing model. Instead, developers should use any feature they want to build the best app possible.

The Tier-Based Model

The tier-based model brings familiar, painful overage penalties of cell phone plans to the world of the app developer. Remember getting your new smartphone, and having to guess in advance, how many minutes per month you will use? A few long conversations, and unintentional roaming calls later- you’re shocked at the bill you receive.

At the beginning of an app’s life – and at the beginning of each month – tiers force a developer to predict the future. Will this be the month your app goes viral? Should you choose a modest tier to keep expenses down? Guess wrong, and a great month for your app results in runaway overage charges, causing you to be sipping Ramen, instead of champagne.

Apart from the overage issue, a tier-based pricing model forces a developer to pay a higher fee for a feature they want, but they only get in a higher tier. For example, if you want the ability for multiple developers to collaborate on building an application hosted in the cloud, that’s extra, even if your app isn’t successful yet. At this point, developers can feel that you’re nickel-and-diming them for things that are essential for their success.

The Answer — Pricing aligned with an application’s success

A success-based cloud pricing model takes the guesswork out budgeting and the use of cloud features. The model should look something like this:

  • Developers shouldn’t be charged when they are in development mode (unlike resource-based pricing).
  • Out of the box, you’re provided with the full package of features (unlike feature-based or tier-based pricing).
  • You’re not asked to rub a crystal ball and predict the future – there are no overages.
  • The main pricing metric should align with a developer’s success. For example – per active user. Costs are calculated per-user, regardless of how many resources that one user uses. As a result, developers are not punished for having power-users of their app.

A few companies in the Backend as a Service space like Kinvey and CloudMine are experimenting with Success-based Cloud Pricing. Sravish Sridhar, Founder and CEO of Kinvey, sums it up best. “A success based pricing model around active users is a developer’s dream. It not only makes planning dead simple, but also gives developers a concise pricing metric, which directly aligns with growth goals. Clearly this model cares about only one thing — helping developers succeed.”

Ultimately, however, it comes down to how companies are going to be willing to approach the model. When you start talking about taking away assured money, companies get nervous. The idea, then, is to offer developers the best tools that they can have, at prices that they can afford, so that the cream of the development crop will flow toward your service, instead of your competition.

Top Image: Marcus Q via Flickr