Single versus redundant servers
When deploying a solution, there is always the option of choosing between a single "large" server, or two "smaller" servers. The single "large" server usually works out a little more expensive (because of the hardware density and technology) - but there also some positives in doing this.
We cannot decide which is best suited for your needs, so here are the pro's and con's of each so that you can make your own decision.
| Benefits | Downsides | |
|---|---|---|
| Single Server | Substantially faster communication between web and database nodes | No hardware failure redundancy |
| Pooled resources provide more effective resource utilisation | No isolation of frontend/backend, so admin traffic could influence frontend performance | |
| Usually more expensive than two smaller systems | ||
| Longer lead times to deployment | ||
| Dual Server | Highly available, can survive the failure of a single server without loss of service | Twice the risk of hardware failure |
| More control over traffic distribution (eg. dedicated backend/admin server) | Bottlenecked resource over network connection | |
| Usually less expensive than a single large system | Slower disk writes due to replication | |
| Twice the server management administration | ||
| Horizontal scaling would usually require more hardware (due to smaller machines) | ||
| Scaling vertically from 2 machines to a single larger machine is time consuming |