Thursday, 24 February 2011

Cloud infrastructure pricing and billing models

Previous posts here have considered the costs of both buying and building storage in the cloud. Based on our work so far, we estimate that is possible to build an academic cloud infrastructure (storage and compute) that is both sustainable and that can be offered in broadly the same price 'ball-park' as, say, Amazon Web Services.

Of course, the proof of the pudding will be in actually building it! Furthermore, how compelling such an offer might be to the academic community is not just down to price. We also have to think about the nature of the technology on offer, the service level agreements that we are able to provide, the associated support that might be offered, and the kind of pricing and billing models that we can put in place.

This post considers (admittedly at a very high level) the last of these - pricing and billing models. The intention is not to provide any answers at this stage. Rather I'm interested in what sorts of pricing and billing models would be attractive to the consumers of academic cloud services... in an ideal world (I have to add the 'ideal world' bit because, clearly, there may be tensions between what consumers want and what providers are able to offer in a cost-effective way - there will likely be some trade-offs to be made).

To frame this question further, let's think about some of the different parameters that might be considered in this area. Firstly, on pricing... there seem to be two options here:
  • Pay as you use (essentially the Amazon model where you are charged under various different categories for the amount of resource that you use) vs. Plan (where you commit to a certain amount of resource, paying extra (probably at a premium) if you go over your allowance. GoGrid provide an example of this kind of pricing model).
Of course, there are some subtleties around these options. Amazon, for example, offer both Reserved Instances (where hourly rates are lowered by committing up-front to using the resource for either 1 or 3 years) and Spot Instances (where you bid for unused resource against a fluctuating hourly price). One might refer to these more generically as Short-term commitment vs. Long-term commitment and Fixed-pricing vs. Bid-pricing.

Reserved Instances allow the provider to plan their capacity more accurately (hence the lower prices - my understanding is that, from a consumer perspective, an Amazon Reserved Instance breaks even if it is used for more than 30% of the time). Spot Instances soak up otherwise unused capacity, again meaning that the provider can offer better value for money.

There's also the issue of whether providers offer any kind of free-tier, as Amazon currently do, meaning that consumers can get going at little or no cost but, ultimately, driving up consumption for the provider. Again, one might refer to this generically as Introductory tier pricing vs. Flat pricing.

On billing models... there seem to be two aspects to consider:
  • Credit card vs. Invoice.
  • Up-front payment vs. Pay in arrears.
To draw an analogy with mobile phone tariffs for a moment... pay-as-you-go is (typically) a combination of what I'm calling here 'Pay as you use' and 'Up-front payment' while contract is (typically) a combination of 'Plan' and 'Pay in arrears'. (Note: I really wouldn't want to wish the complexity of mobile phone tariffs on anyone!).

My understanding, from discussions at conferences and so on, is that universities (at the institutional level) are keen to pay by Invoice rather than Credit card, that they like to Pay in arrears and that they lean towards the predictability of a Plan rather than the open-ended nature of Pay as you use. Note: individual researchers may see things differently.

So, first question... is this categorisation into:
  • Pay as you use vs. Plan
  • Up-front payment vs. Pay in arrears
  • Credit card vs. Invoice
  • Short-term vs. Long-term commitment (a la Reserved Instances)
  • Fixed-pricing vs. Bid-pricing (a la Spot Instances)
  • Introductory tier pricing vs. Flat pricing
useful? What have I missed?

Secondly... what is attractive to you (either as an individual or as an institution)?

I have to say that our thinking, to date, leads us towards sticking close to the Amazon pricing model (not least because it is a widely understood and accepted way of thinking about things), ignoring discount for long term commitments and bid-pricing (at least in the short term), and allowing payment in arrears based on a saved credit card and/or invoice (probably).

Introductory tier pricing is problematic for the provider (particularly so where the infrastructure is limited) because it is difficult to manage. Further, it tends to encourage a mindset that stuff can be made available for free when the reality is that it can't. Which is not to say that introductory tier pricing can't be done - just that its consequences need to be thought thru.

Note that all of this is just theory at the moment. It is thinking that will (primarily) inform a FleSSR project deliverable on cloud business models. As such, I welcome any and all views. Thanks.

UCISA Cloud Computing seminar

Both David Wallom (OeRC) and Matt Johnson (Eduserv) spoke at the recent UCISA Cloud Computing event in Loughborough.

Their presentations are available from the event website:Some general thoughts on the event by Andy Powell are also available on eFoundations.

Friday, 10 December 2010

The costs of building storage for the cloud

In a previous post, The costs of storage in the cloud, I attempted to assess the differing costs of storing various amounts of data in the cloud using Amazon S3, Dropbox and Rackspace. I ended by asking:

What is interesting is whether [those prices] can be matched or beaten by academic providers (such as Eduserv) and/or in-house institutional provision, and if so by how much?

So... let's do a quick exercise!

Supposing you wanted to build your own Amazon S3 service? How much would it cost? Could you beat Amazon's S3 prices? And if not, what economies of scale would be necessary before you could?

To answer those questions, let's forget about actual money for a moment. Rather, let's draw up a list of the things that would have to be paid for. We can fill in the numbers later.

So firstly, there's the storage hardware - the raw disks. Of course, it's not quite as simple as that. Decisions need to be made about the kind of storage you want... a fibre-channel based SAN vs. cheaper SATA disks organised into some kind of Network-attached Storage (NAS) for example. Reliability vs. cost will be the issue here. Given that we're trying to build an alternative to Amazon S3, let's use SATA disks. Then there's the chosen architecture. How resilient do you want your storage to be? Amazon offer 99.999999999% durability (which, I think, means they will only lose data 1 time in 100,000,000,000?) with no single points of failure (and a design to sustain the concurrent loss of data in two facilities)... both of which are pretty hard to compete with, so let's relax that requirement a little. Let's say that we want all data to be replicated across 2 separate NAS clusters (meaning that both clusters have to fail before data is lost), running RAID 6 within each cluster (providing fault tolerance from two simultaneous drive failures). With that kind of configuration, providing 1PB of usable disk would require something like 2.7PB of raw disk. (Actually, according to Backblaze's How to build cheap cloud storage, a RAID 6 design based on 15 disks, of which 2 are parity disks, should deliver "87 percent of the raw hard drive totals" as usable space, so we should be able to do a bit better than that).

Then there's the network switching and cabling necessary to join everything together - with, again, decisions to be made about bandwidth and so on. There's also the connection to the outside world to worry about - routers, switching and a firewall for example.

Finally, there's the cost of the physical data centre space to consider, at least insofar as it represents an opportunity cost against doing something else.

That covers the initial investment (which is already non-trivial for any kind of substantial cloud infrastructure), for which costs can probably be depreciated over, say, 5 years.

There are also the recurrent costs...

Energy, both to power the disk arrays and other servers and to keep everything cool, and staffing. Operator cover (perhaps 0.5FTE per 10PB?), some developer effort at least initially (both to keep things running smoothly and to assist in integrating the cloud storage with other systems - let's say 1FTE), a service/project manager (again, let's say 1FTE) and some procurement/financial effort. Again, these are non-trivial sums of money.

So that's my shopping list. What have I forgotten? What have I over-specified?

At this stage, I'm not going to fill in the actual amounts of money - not least because the costs of storage are dropping all the time and the actual price paid will be subject to negotiation. But the shopping list:

  • Disks
  • Network infrastructure (switching, etc.)
  • Router/firewall
  • Physical space costs
  • Energy
  • Operator cover
  • Development effort
  • Project/service management
  • Procurement/financial effort
seems to me to be a useful way of thinking about the overall costs that would have to be met in any activity of this kind.

Because I haven't indicated actual costs (in monetary terms), I can't answer my opening question - at least not in public. We can, and have, begun to answer it privately, and our answers, so far, indicate that we would be able to beat Amazon's prices (not least because a direct connection to JANET means that network bandwidth doesn't need to be charged for but also because our not-for-profit mission means that we are focused solely on delivering effective use of IT for the benefit of education - that's why we do what we do).

Of course, individual institutions are also able to do the sums and in some cases may be able to come up with better answers than we can. Ultimately, economies of scale will win out, one presumes.

Our thinking to date gives us confidence that an academic cloud service of the kind envisioned by FleSSR is viable (in a sustainability sense). The next step is to do some more thinking about the numbers and to consider pricing models that might be more acceptable to HEIs than Amazon's. One of the problems with the Amazon model is that the costs are not predictable in advance. That's something that we'd like to see if it is possible to address.

More anon...

Thursday, 9 December 2010

Date for your diary - UCISA-IG/NG cloud event, 16th Feb 2011

David Wallom (OeRC) and Matt Johnson (Eduserv) will be speaking about the FleSSR project at the UCISA-IG/NG Seminar on Cloud Computing at Holywell Park, Loughborough University on Feb 16 next year.

Wednesday, 8 December 2010

The costs of storage in the cloud

As part of beginning to think about the business model issues around FleSSR (one of our deliverables for next year) I've been estimating the costs of storing various amounts of data in the cloud using Amazon S3, Dropbox and Rackspace.

I've done calculations for all 3 services for between 50GB and 500PB of storage for one year.

To make the costs realistic I've had to make some working assumptions about how much data might be shipped across the network, as well as the costs for storage. On that basis, I've arrived at a total cost by starting with the costs of storage for 1 year, adding the costs of uploading all the data (spread evenly over the year) and then adding a little bit more network traffic to simulate local re-use of the data (1% per month). In the case of Amazon, where IO operations are part of the charging model, I've also had to make some assumptions about the average file size - which I've set to 1MB. So, in the case of, say, 1TB of data, I've costed the storage of 1TB in the cloud, plus the costs of uploading 93GB (1/12th of the total data plus 1%) per month, plus the costs of downloading 10GB (1% of the data) per month plus the costs of 93,000 upload operations (PUT requests) and 10,000 download operations (GET requests) per month.

Clearly the 1% figure is a complete finger-in-the-air job - I have no idea if it is reasonable or not - but I've intentionally set it quite conservatively. It is also worth noting that any scenario involving more than 500TB data storage probably has to consider how the data is uploaded to the cloud in the first place (other than by using the network), so my calculations probably go a bit wrong in those cases.

My costings come out higher than similar estimates that I've seen from other sources... I think because people tend not to include the costs of transferring data across the network when they do this kind of thing. Network costs are actually quite significant in terms of the overall price.

Prices are based on the available information on the web (Amazon S3, Dropbox, Rackspace). Note that Rackspace's pricing includes support and a Content Delivery Network (CDN) and so isn't directly comparable with Amazon S3. Also that the largest offer from Dropbox is for 100GB of storage, so that service isn't relevant for most of my data points.

A Google spreadsheet of my workings is available. Please let me know if you think I've made any mistakes.



The point here is not to make comparisons between these three services - please don't use my numbers to do that. Indeed, making such a comparison based only on cost would be rather foolish because there are significant differences between the services in other ways. Rather, it is just to get a feel for how the different charging models work and, more importantly, to get a feel for what we are up against as we think about transforming FleSSR into a production service.

So, what can we conclude? Looking at the cost per TB per year, the Dropbox and Rackspace prices are pretty much flat (i.e. the same irrespective of how much data is being stored) at around £1530/TB/year and £1220/TB/year respectively (though, as noted above, the Dropbox prices are only applicable for 50GB and 100GB). Amazon's pricing is cheaper, particularly so for large amounts of data (anything over 100TB data where the price starts dipping below £1000/TB/year) but never reaches the kind of baseline figures I've seen others quote for Amazon storage alone (i.e. without network costs) of around £450/TB/year. (My lowest estimate is around £510/TB/year for 500PB data but, as mentioned above, this estimate is probably unrealistic for other reasons.)

Superficially, these prices seem quite high - they are certainly higher than I was expecting. What is interesting is whether they can be matched or beaten by academic providers (such as Eduserv) and/or in-house institutional provision, and if so by how much?

I'll return to that question in a later post.

Wednesday, 24 November 2010

OpenStack Design Summit Website Launched

Although the FleSSR project has no current plans to use it, the emergence of OpenStack is a very significant development in the open source cloud space and therefore something worth keeping an active eye on. Videos and other material from the recent OpenStack Design Summit are now available through the summit website.

OpenStack is a collection of open source technology products delivering a scalable, secure, standards-based cloud computing software solution. OpenStack is currently developing two interrelated technologies: OpenStack Compute and OpenStack Object Storage. OpenStack Compute is the internal fabric of the cloud creating and managing large groups of virtual private servers and OpenStack Object Storage is software for creating redundant, scalable object storage using clusters of commodity servers to store terabytes or even petabytes of data.

Friday, 5 November 2010

Community clouds

A presentation about community clouds, using FleSSR as a case study, given by Matt Johnson and Ed Zedlewski of Eduserv to the UCISA CISG 2010 conference in Brighton during November 2010: