Tuesday, May 14, 2013

Building infrastructure to accomodate peak usage.

Daily and weekly spikes in usage are a common problem in building out cost-effecive online infrastructure. I know of three basic approaches to dealing with spikes, which I'll outline below, but am wondering if there isn't a fourth, missing option: building for peak and leveraging the inevitable surplus capacity?



Imagine that the area below the wavy line is the daily usage of an online service. Let's say that it peaks for a few hours each day between 7-10PM. Let's assume that you have to pick between owning/leasing dedicated hardware or using a cloud-based option like EC2. My assumption is that, given full utilization, dedicated hardware would be cheaper.

Let's work on the assumption that not catering for peaks (e.g. by letting the service degrade) is really bad.

The options then:
  1. Go completely on-demand (cloud). Your usage model would approximate the wavy line assuming your cloud option was perfectly granular. The cost would be high.
  2. Own/lease dedicated infrastructure that covers your maximum usage (the top "Full" line). In this case, all the yellow shaded areas are "wasted" capacity. Whether or not this is better than being completely on-demand depends on the relative costs, and the amplitude and duration of the peaks versus the valleys.
  3. Go with a "Hybrid" solution: buy enough infrastructure to cover your valleys (the green shaded area) and have some mechanism to send any usage above that to a cloud solution. In theory, this would be the most cost-effective of the three.
But what I'm wondering is this:

Is it possible to go with the "Full" (owned/leased) infrastructure level, and find solutions to leverage the yellow areas? To farm Bitcoins, maybe?

Is this already a solved problem? Are there efficient, scalable, and reliable ways to turn surplus capacity into cash besides BitCoin? Are there real-time brokers of unused processing power out there just like there's companies that aggregate left-over ad inventory?

No comments:

Post a Comment