AnchorCloud: Thoughts on Pricing Models
The Engineering group has spent much of the last six months developing Anchor Cloud, an infrastructure-as-a-service platform built on OpenStack to offer our customers access to public cloud services in addition to our traditional managed VPS hosting. Instant, on-demand API access to instance provisioning, storage allocation and network management deserves an equally flexible and high-resolution pricing model, and a metering system to support it.
Something we’ve been thinking extensively about is how we can best help users assess their infrastructure costs. We think that an invoice detailing (and demanding payment for) your usage over the last month as 256 hours of instance type
x and 100 hours of instance type
y, while technically accurate, often isn’t the best way of helping users understand where their cost-centres are and how they can optimise their spend. A web company needs to know how much each component of their infrastructure is costing them in order to decide whether the value it adds to their business is worthwhile. Development teams don’t architect systems by plugging together numbers of instance hours used or gigabytes stored, they do it by plugging together services. These could be individually-named web servers or multi-region storage clusters, but the business value of the technology lies in the service it provides. Accordingly, we think that’s where costs should be presented as well, and our metering system has been built with this outcome in mind.
That’s one facet of the general problem of billing for public cloud services; another question we’ve been considering while designing Anchor Cloud is to what extent usage should be treated like any other utility when it comes to pricing. In the same vein as your electricity or gas bill, your invoice could reflect what you use, not just what you’ve been allocated. Traditional cloud infrastructure providers have offered VPS instances at hourly rates — if you start a
foo42.somewhatsizeable instance and leave it running for an hour you’ll get the same number on your invoice regardless of whether it’s keeping lots of cat pictures in memory for rapid access to adorably-captioned images or working flat-out processing collider data for CERN. We suspect that many of our users could benefit from more flexibility in this area — making your applications more efficient could not only make your site faster and your customers happier, it could also reduce the bottom line on your invoice each month.
In keeping with Anchor’s policy of developing in the open and releasing the systems we build as open-source projects, the components of our metering system are available on GitHub. We pull metering messages out of OpenStack’s Ceilometer, queue them, and write them to our time-series datastore, Vaultaire.
Given AnchorCloud’s fledgling status, both of these capabilities are still under active development. How we deploy and use the technology will be driven by customer demand — so if you have requirements you’d like us to take into account while bringing these systems into production, let us know!