So you’ve got a web server…you’ve started your new internet application and you’re going to strike it rich. Awesome. Next thing you know, you’ve grown and you need more web servers. Congratulations! You’ve probably built or purchased some sort of load balancer to put in front of your web servers.
Next thing you know, you’ve diversified and you want to run a few different apps, or if you’re lucky, a few different domains using the same codebase. You think “I probably need a few new servers to run this hot new application”. You’re probably right. You may think “I should probably set up a new server pool/farm for this new domain/app/whatever”. Think twice!
Additional server pools or farms need justification. They’re additional overhead when you’ve probably already got enough on your plate. Here are some problems with additional server pools:
Additional management overhead on your load balancer. Put enough enough pools on there and you could actually increase latency and/or decrease throughput. Sure, with modern hardware this isn’t a huge deal. You might need a thousand pools before you start seeing a reduction in performance, but if you have a really complex rule or transform set applied to URLs for a pool, this could come to a head sooner.
Additional management overhead on your servers. Keeping track of which servers are running which domain or which application can be difficult, especially if your growth has been organic. Every customer facing web server should be able to run any domain you host. This probably doesn’t apply to a major hosting company hosting different customer URLs since you may not get that much control over the application, but if you’re fortunate enough to have customers running something written to be domain/vhost aware, it’ll pay dividends later.
This methodology doesn’t apply to everything. You may not want to mix presentation layer services with your business logic services unless they’re both pretty lightweight (though since you can squeeze 32GB of RAM in 1U these days, it may not be a big deal). You’ll probably want to run your database on your front-end web servers even less. If you have extra cycles turn burn, this may be a way to get better utilization out of your machines, but this doesn’t work for everything. When it comes down to it, you (should) know your application best.
Another point: make sure you understand how your application behaves. Benchmarking will save you when you suddenly need to know how many more servers you need to buy. Do certain things make the memory footprint expand dramatically? Do some hits generate a lot of extra CPU load (maybe those URLs will need their own pool soon)
In my experience getting in this habit will make your life easier. If you’ve half a dozen domains and half a dozen servers, taking half the farm down for maintenance behind the scenes will become much more trivial.