Adventures in start-up land: part 2

After 6 months at a startup building an eco-friendly database of product and company information, I have decided to move on, to another startup focusing on deployment and auto-scaling platforms for cloud computing systems. Part of my motivation is that the company moved offices in an unfortunate way for me, increasing my commute to 2-2.5 hours each way (which is rough but could be workable). But also, while an eco-friendly database and search engine is really cool, I've realized that it also falls under a very risky category of funding and possible business plans. Would a product like this really take off in a recession economy? And how will it make money? The answer to this last question (at least for most website startups) is usually "advertising," but user traffic is fickle, the switching cost for search engines is 0, and name-brand advertising companies have very specific and strict requirements for user demographics and traffic patterns. It's a noble goal, but perhaps too risky for me personally to justify the commute or relocation...

Also, I'm pretty excited about the cloud computing space. Last November Amazon launched the Elastic Compute Cloud, a pay-per-use linux server farm built on Amazon's existing, successful, massively scalable data center management infrastructure. Since then many startups have deployed onto EC2 (I personally deployed my previous startup onto it), and have seen drastic cost savings and flexibility compared to traditional hosted deployment models.

In the past, companies either had too much hardware or too little. If they needed to save money, they would purchase too little, and a sudden burst of unexpected traffic would take their site down, usually taking hours or days to recover from. The safe but costly alternative was to buy more hardware than you need, and let it sit idle most of the time, but utilize it when the traffic surge occurred. This was very expensive.

A good analogy for this problem is figuring out how many active cash registers to have at a store at any given time. If there are 20 people and 1 cash register at a store, the line to the cash register will take so long that people will leave without buying stuff, and the store won't make as much money. If you open up 4 more cash registers, then the lines get short enough that the people stick around and make their purchases, and the store makes more money. But if you have 5 cash registers open all the time when there aren't many people, this costs the store more without additional gain, so how do you know how many cash registers to keep open at any given time?

With a cloud computing system like EC2, you set up your production website architecture on the number of machines you need to handle your current load of traffic. For most startups this is the bare minimum needed to ensure redundancy and eliminate single points of failure. Then you set up monitoring to notify you when your traffic starts to spike up. When it does, you can automatically (or manually) scale out your application fleet to handle the traffic by booting more machine instances of your application server. When the traffic subsides, scale the fleet down by terminating the extra machine instances. In the EC2 model you only pay for what you use, so you only pay the high cost of running many machines for the time period in which you need them. The tricky part is how to automatically scale in an efficient way that minimizes cost, minimizes downtime, and adheres to your SLAs? That's where my new startup comes in. :)