Browsing articles from "August, 2007"

Scale or Save?

As any web administrator will tell you, there are just three factors that determine how your infrastructure will scale: price, performance, and the often-forgotten but ever so critical architecture.

graph4.png

Architecture

If you have inherent dependencies on everything running on one machine, for example, you can “scale up” by buying a dual proc quad core server with lots of memory, but eventually you’ll still run out of capacity. Similarly, if you’re at scale and your application has to run within a single data center, you’ll eventually have to architect to run in multiple data centers.

duomo_firenze.jpg

Performance

If you’re planning to “scale out” (that is, run your application or web site across many lower-power servers), you can focus on price and performance.

Assuming your application is architected to scale, performance can be purchased. With the right location and connectivity, you can run “on the Internet,” making access to your servers a non-issue. You can also place servers closer to your users or partner with content delivery networks to deliver even better responsiveness.

However, if there’s a fundamental limitation in your infrastructure, then money won’t buy you the scale you need when you need it. Simply put, you need sufficient underlying storage, processing, and power. If there are rolling brownouts in your part of the country, you can have all the storage and processors in the world, but they won’t be serving up your application and content.

Similarly, if you can’t bring the storage and processing capabilities you need online fast enough to meet the growing needs of your application or spikes in usage, either your application will fall over or a significant subset of your users won’t be able to access your offering.

Price

So price really comes after architecture and performance. At small scale and large scale, price really matters. This is because if you’re just starting out, you don’t want to pay a whole lot to try out a new web site. When you’re early, you don’t know if people will find what you’re building interesting, so you naturally don’t want to over-invest in infrastructure.

Conversely, when you’re much, much bigger price is also a huge factor: infrastructure becomes a key cost driver for your business. Like scale itself, price comes down to just a few simple factors: bandwidth, storage, and people.

To develop the chart above, I used the following assumptions:

AWS

Amazon Web Services:

  • Storage = $0.15 per GB per month
  • Data in = $0.10 per GB; Data out = $0.18 per GB down to $0.13 per GB

To put this in perspective, a 100MB un-metered port delivers about 31,622 GB of data per month. On AWS, that would cost about $4,750 for storage and a little less than $5,700 for bandwidth, per month, for a total of about $10K per month.

The advantage is that as you need more capacity, you simply call the APIs to write more objects or create more machine instances. (But keep in mind what I said earlier about the underlying infrastructure: you can only perform as well as it does.)

Dedicated

Using dedicated servers, assuming 2x250GB drives with RAID for each server, I used an aggressive $150 per server per month plus $0.05 per GB per month for bandwidth. (This assumes a $1,500 per month for un-metered 100Mbps bandwidth.)

Of course, the advantage of dedicated hosting is that you don’t have to deal with the servers. In fact, you never have to configure, setup or physically maintain a single server. It’s all done for you. But that comes at a cost: you’re paying a premium for the service and older hardware.

Collocated

For collocation, I assumed:

  • Storage/processing: 2x500GB drives with RAID for each server, and I estimated the total cost of each server at $1,500, amortized over 30 months for a price of $50 per month per server. This gives you well more than a Pentium-D 3.0 Ghz machine, which is more or less the current standard for dedicated servers.
  • $0.05 per GB per month for bandwidth (assuming $1,000 per month for a 100MB un-metered port).

Collocated servers require the biggest commitment. You have to buy your own hardware, configure it, and physically place and maintain it at the data center, along with keeping it updated with the latest patches.

Yet collocation still delivers the lowest cost over the long term. If you architect to keep the cost of managing servers as low as possible and you’re scaling fast, collocation is still the way to go.

Conclusion

The real question is: what kind of application do you have? If you’re building an application that just serves up text with a very small number of images or videos, collocation is probably overkill ““ you don’t need the bandwidth or storage discount. If you’re in the business of serving tons of videos and/or high resolution photos, however, you still need your own infrastructure. If you’re in between, you have to ask yourself what price you’re willing to pay to control your scale.

There’s just one thing. Stand-alone tech businesses have to be cost-effective to survive. But they don’t save their way to success. They scale it.

Aug 5, 2007