I would say it depends on enough factors that pinning down an answer here is going to be difficult. I would recommend however, that if this is a web and SQL type data focused site, that you split those services if at all possible.<p>You can get a single beefy box and run apache/nginx/lighttpd(what???), mysql, memcached and anything else all on one system and there are certainly people that make it work... but given the number of times I have been called in to fix these kinds of scenarios and make them work properly, I can say from experience that if you expect any amount of traffic you invest in the ability to abstract these various services away from a single machine with ease (or just have them separate to start with).<p>Perhaps if you do not have a lot of operating capital to begin with, virtualization/cloud options would be a good place to start. You can have with virtualization that single beefy machine and still separate out the various pieces of the infrastructure and then allow to add additional virtualization hosts to the cluster usually with a click or two.<p>I am happy to answer other questions to scaling (within reason) if you post in response or mail me. I'd rather you start things in a good direction and give away free advice than see a company fail because of architecture decisions which hobble expansion in the future!
We're launching in January with a dedicated server (quad core, 32GB RAM) on which we have a single VPS (with <i>only</i> 8GB RAM) - this gives us plenty of options going further, either I can set up load balancing, add resources to the VPS, make more of them with distributed concerns (database, app, session...), etc. And with Hetzner, it's also very cost effective, like 60 euros per month.<p>Not sure that is the best way to go, but that's how we'll roll.
At Qard.at we used 3 Heroku dynos for: web server, mobile API, and our CMS. We used MongoLab for our MongoDB database. We also used Amazon S3 for static assets like CSS and images. The system was tested with Blitz.io and could scale to 7M hits/month. Our monthly fees were less than $1. The takeaway from this is not that you should run your company on free services, but that you can get started for (as good as) free with a scalable architecture which is then easily transferrable to AWS or similar once the need arises.
blekko needed 700 servers at launch for our web-scale search engine. We figured an index of a few billion webpages was the minimum needed to give reasonable results.<p>This is definitely not a one-size-fits-all sort of question!
It depends hugely on what you are doing. At Kickfolio, we needed to think about dev ops and infrastructure right from the start. Kickfolio launched with 13 servers in place (10 Mac Mini's, EC2 load balancers, Heroku front end).<p>Having been featured on a few large sites, it was enough. We spun up 3 dynos on Heroku for the front end, and in the first week of launch we had gone through a few hundred GBs on bandwidth (not including static assets hosted on Cloudfront).
Super-obvious answer here, but if you only have one of something you can't upgrade things, reboot, etc., without downtime, and you have a single point of failure if things go wrong. Having N+1 of each component, ideally with automated failover, makes a huge difference to how easy it is to maintain your system. You'll also enjoy life more when you can wait until the morning to fix something falling over in the middle of the night.
Why do you want servers? Are you building a server centric product? Why not use a PaaS like Heroku and some monitoring tools? Then you've got your scaling, your deployment, your security and log aggregation solved -- and you don't have to wear a pager while you sleep.<p>Each app and service is different, more info about what yours does and it's known bottlenecks would greatly influence answers.
One of my favorite stories about this was from the guys at 500px.com.<p>When they first launched, their only server was a Mac Mini in a second-tier colo that was run by a friend of theirs. After about six months, they did their first major server upgrade - buying an external USB hard drive for more storage. They bought another two (and a USB hub) a month or so later. This lasted them another four months, until the got to the point where the USB bus was being constantly saturated. Only then did they move to some more enterprisey hardware.<p>Moral of their story was to use only as much hardware as you need now (while having plans on how to scale up in the short- and medium-term which don't cost you money now), and to worry more about getting users and building a product. Worry about scaling after you've got customers (and data that will show you actual use patterns), as opposed to paying for a complex scaling infrastructure before you've got any users.
We started with 1 RackSpace Cloud Server, their most powerful offering, for our development. Our thinking was we'd use cloud servers to scale. Well, RackSpace's top of the line cloud server is, for our application's needs, a total dog. Getting reasonable performance required a server 8 times more powerful than RackSpace offers. And at the rate RackSpace charges for their top of the line dog, we can buy the server we need in 3 months. So, at launch we had 2 servers: one for DEV, one for LIVE; each being 32gigs RAM, 32 cores, & 1.5T disk. Now, 1 year later we've expanded to 6 servers in a half rack with hardware firewall, fully raided up fileShare and passable redundancy.
I'm not sure there is a one-fits-all answer here - specifically regarding disk space & bandwidth.<p>Are you saving HD video files? Then you will probably need a data store connected to your web server.<p>Are you just allowing people to post text, small images and such? In that case, 1 server could easily cut it.<p>With proper software configuration, and a <i>decent</i> hardware config, you can go quite a long way with 1 machine.<p>Can you provide any details? Maybe someone can help out with your specific question, since the general question you've asked is quite difficult to give a proper answer to.
Many problems have two solutions, the solution for "one" and the solution for "two or more". If you really want to be ready to scale I would be a lot more confident with two servers than one. On the other hand, if you are coming out with a true MVP and don't expect the world to come rushing in, then one seems like the right answer if it saves time.
At the moment we have 5 small Linode VPSes (1.5/1/1/768/768) for app/db/solr/redis/async-jobs and paying around $200/month.<p>I've been looking for alternatives, preferably hybrid dedicated/cloud with good RAM/IO for app/cache/db and cloud based storage. Rackspace seems to offer something like this, but at a higher price. Any other suggestions?
One Amazon EC2 'micro' instance when I launched <a href="http://www.nepaladz.com" rel="nofollow">http://www.nepaladz.com</a> That too was running on a free server (for the first year). And it was delivering around 200k requests per day at around 40% server load. It is however configured to auto scale as per the load.