I agree with Ryaner. If the only cost is hardware purchase, go for the 2 machines setup. I prefer not to "mix" frontend and backend loads when possible.
Also, security-wise, it's better to have them split apart, so that a vulnerability in one of them does not mean the other service/server fails directly.
Of course, now you have two servers that you have to:
- Provide power/cooling for
- Provide Rack Space for
- License the OS/apps that you need in them
Are your services "internet-facing"? If so, then splitting them is almost a must for security reasons, and I'd add a firewall in between.
Also, splitting the app in frontend/backend sooner than later will enable you to grow painlessly; as your load increases you might need more application servers or DB resources, or... so the sooner you make sure your app can be split/spread, the sooner you find any lurking dependencies/issues that might arise later on.
In the long run, it's normally much simpler/cheaper to scale out (ie, add more servers to the same problem, see google ;) than to scale up. Of course, normally DBs are harder to split so if you're lucky and become extremely successful, the DB might become the bottleneck.
Even if for some reason (rack space/power/cooling) you're limited to a single "hardware" server, then I'd recommend to get a powerful one, and to look into virtualization to split the load into 2 logical servers. Yes, I know that adds up in licensing, etc, but if my memory serves, MS lets you run a single Win2008 license in a single "bare metal" server and up to (2?/3?) virtual ones. VMWare also has a free server product (VMWare Server) that you can use.
My 0,002 cents.
I'd love opinions pro/against.
PS: My background is in security, not so much on Web Apps, so maybe what I'm saying is not the optimal solution, but I know that I'd feel more comfortable not "piling up" functionality on a single server/point of failure.