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.
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).
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.
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 only 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.
Not sure that is the best way to go, but that's how we'll roll.
The issue with Hetzner is not the price of the servers. The problem is their connection. The max bandwidth I could get was around 180Mb/s, even though their marketing says 1 Gb/s port. In fact the port is shared.
I have got around 10 servers there and now I am moving away and decided to go with Amazon.
However for a startup with european market it could be a good option.
I'm not familiar with Hetzner, but another thing to consider is whether the "crazy prices" are sustainable (and they may well be -- again, I'm not familiar with the company).
Hetzner exists since 1997, it's a well known provider at least in germany for many years. So it's not like they will go bancrupt. They probably just know how to be cost efficient out of experience.
Considering how unreliable their servers and links are. And how their support responses are catastrophicly slow ... I wouldn't put anything citical on Hetzner.
You can safely move to them, I have several servers, no problems so far, every support request is answered pretty much the same day, and the prices are just ridiculously low. No provider has 100% customer satisfaction rate.
It's sad that when i'm comparing AWS to Hetzner, I'm always asking what will people say ... Hetzner isn't cloud..Cloud is "in".. Damn it.. I hate that!!!
We recently provisioned a new 32GB server from Hetzer. The server was delivered with only one of the two raid1 drives working. When I complained they said it would take a few hours to replace and then it was up to me to figure out how to rebuild the 2nd drive as part of the array. All I expected was a working server from the start, anything that went wrong after that I would have been happy to resolve myself. Very poor service, we've already moved to uk2.net. Also don't forget that Hetzner uses desktop class hardware in most of their servers.
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.
This is definitely not a one-size-fits-all sort of question!
Hah! Yeah, I imagine that this answer is probably outside of the question the OP is asking, but I do always enjoy hearing about scaling requirements for projects outside of those I have dealt with. Do your requirements (If you don't mind me asking) require a more disk, memory or CPU focused infrastructure?
To let our programmers be a bit lazy, we want fat (2-socket) nodes. That allows us to do things like have gigabyte-sized tables in memory on all nodes for instant access.
At that kind of server core count, it turns out that we can keep 8-12 disks busy, when crawling and indexing. For serving results, it turns out that we can keep 2 ssds busy, and, 96 gigs of ram seems to be the sweet spot.
The one thing we don't stress so much is the network. We're very conscious of locality, and we can get away with having 1 gigabit to all the nodes. We use beefy 10 gig switches in the middle to give high bisection.
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).
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.
Each app and service is different, more info about what yours does and it's known bottlenecks would greatly influence answers.
Heroku, being on top of AWS, doesn't really have the greatest uptime, do they? There are plenty of dedicated hosting and VPS companies that have better uptimes than AWS at this point.
For many early-stage startups at launch, ease of development/ops is much more important to optimize for than uptime, and Heroku excels at that compared to dedicated hosting or VPS. If a quarter of the internet is already down because of an AWS outage, people will survive without being able to access your shiny new "AirBnb for Pets" startup. When you're successful, build out manual infrastructure, sure, but at initial launch it's often worth the tradeoff of potential downtime for the savings in manpower.
Naturally, if your startup is a backup service or something else where having as close to 100% uptime as possible is a truly key feature, then it's probably not in your best interests to rely on Heroku/AWS.
How much money are you willing to spend per nine? How many nines do you need? Do you replicate across 3 or more data-centers? What about across 3 or more continents using 3 or more providers?
If you're running a heart-transplant registry, you probably need 10 nines, if you're running a cat dating site, you probably need less. Sure everyone wants massive uptime, but few are willing (or even need) to take the steps needed.
One of my favorite stories about this was from the guys at 500px.com.
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.
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.
Are you saving HD video files? Then you will probably need a data store connected to your web server.
Are you just allowing people to post text, small images and such? In that case, 1 server could easily cut it.
With proper software configuration, and a decent hardware config, you can go quite a long way with 1 machine.
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.
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?
Linode is one of the cheapest providers of VPSes that are mainstream. I think you will have a hard time finding something comparable. I track web hostign companies for my startup ( http://reviewsignal.com/webhosting ) and the only company that jumps to mind is RamNode. But I haven't collected enough data on them to say anything meaningful. They seem to be offering high ram + ssd drives which would match what you're after.
CloudSigma may be worth a try. You can tune CPU/RAM and HDD/SSD storage as you see fit, and they give you 7 days for free to test all the weird things you can come up with. It's based on KVM and you can install anything by uploading an ISO.
Full disclosure: crazy CloudSigma customer running FreeBSD with ZFS in the cloud :)
Note that Rackspace cloud (not sure about their managed services) do not include free bandwidth. It can be a killer if you rely on Linode's bundled bandwidth.
I migrated to Rackspace cloud, due to the Slicehost acquisition and the first month bill was hard to swallow.
One Amazon EC2 'micro' instance when I launched http://www.nepaladz.com 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.
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).
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.
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!