Scalability versus burstability

By EveryCity on 17 May 2011

In this blog post (and the next) I’m going to look at a couple of the biggest challenges facing hosting providers in these days of fast bandwidth, cheap storage, ‘viral’ social media and seemingly infinite ‘cloud’ capacity, namely:

  • Scalability and
  • Burstability

These two topics often get lumped together as one, but they are distinct and do present different problems.

When dealing with issues around scalability, the challenge can be coping with an exponentially growing web site, which may mean that user numbers keep doubling every few months. However, the upside in this scenario is that growth can be reasonably predictable and capacity can be planned reasonably well.

When dealing with burstability, however, the opposite is often true: traffic may be low and manageable most of the time. The downside is that it may massively spike in an unpredictable way from time to time.

I’m going to tackle burstability in my next post. For now though, I’d like to look at scalability.

The first graph below represents a typical high growth site in terms of numbers of users. As you can see, it approaches quite an aggressive exponential curve.

The next graph below represents the old, pre-cloud, model for hosting procurement, where you’d be dealing with lengthy fixed term contracts and not a great deal of flexibility. Typically, in this scenario, you build a lot of ‘headroom’ into the solution to see you through the whole contract period, say the first twelve months. This often means that most of the time you are paying for capacity you aren’t using, raising quite a high barrier to entry. After the first year, you then review your hosting arrangements (against the data you’ve accumulated) and typically then there is another big ‘stair step’ in costs to see you through the next twelve months. However, if your growth is accelerating you might find that you run out of capacity far more quickly than anticipated, necessitating another even bigger stair step in hosting costs to keep up with your growth curve. So that’s what the dark red line below represents. By contrast, the lighter red line represents the actual costs with EveryCity, with an associated exponential trend line.

The final graph (below) shows how the number of services with EveryCity scale up in comparison to costs and is based on an actual customer case, over twenty one months (which is the period for which we have data) so all numbers and names have been removed. To give you an indication of growth, by month twenty one, you’re looking at users in the millions and nearly fifty servers with EveryCity.

As you can see, the big stair steps in cost were (largely) removed. However, there were two spikes in the cost line: the first was due to the customer negotiating a better bandwidth price by moving from a PAYG rate to a committed rate; the second was due to one off costs (such as set up fees or RAM upgrades).

While the cost curve isn’t perfect, you can see that spend is matched to demand pretty closely and in a way that a customer would like: that is, while spend and demand both exhibit exponential curves, the spend curve is a lot less steep than that of the number of services! You can also see that, with EveryCity, you get more bang for your buck as you scale up: although the cost, of course, increases with users, the ratio of numbers of users to cost at the end of the period looks very favourable from a customer’s point of view. In fact, the hosting cost per month per user (a sort of hosting CPA) was reduced by a whacking 75% over the period!

All this was achieved via EveryCity’s flexible approach to hosting. For instance, it is often more cost effective, once the ‘base’ platform has been built, to upgrade existing services rather than add additional services. Also, at a certain point, it typically becomes more cost effective to look at a ‘hybrid’ solution, rather than a purely cloud based platform. This may also become necessary from a technical standpoint – it’s important to note that not every type of work load will fit onto the cloud (very busy database servers for instance). This type of hybrid solution could include some cloud servers, some dedicated servers and possibly some of the customer’s own equipment co-located with, and managed by, EveryCity. On this last point, at a certain stage of growth, it may become necessary to think seriously about storage – simply because it becomes very difficult and expensive to move large amounts of data, should you need to. Often the best approach is to own the ‘media’, i.e. the storage servers. That way you can relocate your data, if need be, by physically unplugging them and carting them off to another data centre! Trying to move large amounts of data over the Internet is very expensive and time consuming. However, the important point to note, from the customer’s point of view, is that at EveryCity, we apply cloud-style thinking (utility based, scalable, on demand, you pay for what you use) to all our solutions, whether they are pure cloud or hybrid.

Posted by Jon.