cost of scaling and running a web site

Question

This is a rather broad question..but throwing it out there. So let's say someone comes up with a decent web service idea, build an app on open source framework. Hosts it on a VPS for less than $100/month and things pick up, users start showing up.

1 - Assumming the above happens, how does one grow from a VPS to a full fledged internet company that's generate significant revenue, from a technical standpoint. How does one scale from a VPS to a distributed server farm, especially with Rails. I am trying to understand the architecture of a fully grown web site and how it gets there from a VPS hosting environment.

2 - How much does this cost? I read somewhere that StackOverflow's burn rate is $6 million/month. I don't know how big their payroll is, but that's a good chunk of change, is it going towards operations of the Web Site?

Please consider the context to be a website like SO or something similar, not a Google or Facebook.

Thanks

Answer 1

Part #1: Usually when you start on a VPS you have everything on a single general server. There's no specialization of server tasks, like a web server, database server, caching server, etc. So, the logical first technical hurdle is to start splitting tasks across specialized servers. Make your 1st VPS server the web server, and buy an additional VPS for the database. Expand from there into a memcached server.

After your tiers are split, you can turn them into farms. For the web layer, you may consider using either a load balancer or nginx as a proxy server to your "real" web servers that are doing the work. Depending on the type of database you are running, you can do something similar, except you would use either database clustering or master/slave database replication.

Farms are by definition flexibly expandable, and it will be a long time before you would run into other issues, but the next step would potentially be distribution using a CDN to cover geological latency.

Part #2: Costs vary widely depending on the platform, application needs, and your aversion to downtime. If you can accept potentially lower downtime, you would be fine on Dreamhost. In real life though, I would buy several low-cost/low-power servers with great uptime. You mentioned $100/month for your VPS. I have the iWebFusion VPS Pro plan, and it's 30/month for 3ghz/512mb RAM. I would be able to buy a web server, DB server, and memcached server for the price you're paying, and probably still have better performance than you through specialization.

If you use open source, you can save many $1000s/month over Microsoft/Oracle/etc just in licensing and server costs. Realistic costs? You could serve a large number of simultaneous requests/sec if you get caching correctly. I can serve about 40 requests/sec if they all hit the database on the server I mentioned above. For completely cached requests, I get about 250-300. I figured it out to be somewhere around 5 to 8 million views/day on my dinky server, but my app's resources will of course be different than yours. If you want to spend the time on performance tuning, you will be able to squeeze much more out of your hardware.

From a business perspective, your main goal is to keep positive cash flow. For my business, if I have 7 customers at the low-end $9/month plan, I can cover all of my hardware and operational costs that month. Everything on top of that goes in my pocket or back into the business.

Answer 2

Great question and one pondered endlessly many web companies when starting to design and launch a new service. The following are some general comments and opinion and obviously every web application exhibits different characteristics and has consequently different requirements. Mileage will vary considerably.

The initial tradeoff is between getting something functional out the door but limiting the spend, at least until a real and sustainable market for the service has been demonstrated. You will be keeping in mind what success could mean and designing for success where possible but not to the detriment of cost-overruns or being too-late-to-market

Assuming that this first part is successful (the customers came) then you may start to worry more and more about scalability (you can meet increasing customer demand?), performance (you can do it in a timely manner?) and availability (you can do it most of the time where most is at least 99.9% of the time or preferably more?).

A well architect-ed web application can allow most of its piece parts to scale horizontally relatively easily with modern tools and techniques. That may or may not be true of the database, especially if it's relational. By now you've probably left behind the VPS world and gone to bare metal or you got a lot more VPS (or similar) nodes in the mix. You've also probably started to scale the database vertically on its own dedicated hardware with lots of RAM and everything heavily memory-cached in-between. This might be fine for a while or forever especially as you can put up to a 1TB of RAM in servers these days. That's not cheap but it might be OK because you should be comfortably in sustainable and growing revenue by now. And the cost of scaling vertically is falling all the time.

If you do find that this isn't enough then you've got problems that most companies would love to have. Theoretically you can now fund the best and the brightest to go help solve the problem with whatever is state-of-the-art when you get there.