We have a server (4GB RAM, two 4-core Intel Xeon E5420) performing the following tasks:
- website with static content (currently just some CMS, we plan to add a caching reverse-proxy)
- customer control panel (basically web interface to a database)
- backend scripts for our desktop software - a few PHP scripts which perform a few DB queries/updates, but will be hit up every 5 minutes per customer
- database storing data for the above two
We are expecting a big (up to hundreds of thousands) influx of users in the upcoming weeks. My superiors are worried that our current setup may not be able to handle the load, and are considering moving to cloud hosting - however, I'm not convinced that this would help. From what I understand of cloud computing, virtualization won't be of much help unless we can split the workload across several machines (unless they have individual servers significantly more powerful than ours). They offer MySQL clusters, however the backend scripts simply read/write some values in a few rows and don't perform any computationally-intensive SQL queries, so again I'm not sure MySQL clusters would make much of a difference compared to Apache/PHP overhead + MySQL network latency. As for the website, we could also move most of the static content to a CDN as we have a few video clips which could stress our bandwidth.
So, would cloud hosting benefit us in any way?
Maybe, maybe not. As you suspect, unless you can easily split your system workload into discrete units that can communicate across the network, you won't see any benefit from going to a "cloud" provider in terms of scalability. There are "cloud" providers who do offer much larger machines (from a RAM perspective, anyway -- I have my doubts that you'll consistently get the equivalent of eight E5420 cores out of any of them), but you can get more RAM for your existing server, too, if necessary.
I'd spend the time looking at each individual component of the system, assessing the resource usage of each and hence how much of a "saving" it'd be to move it onto a separate box. Then, look at how each component (starting from the most resource intensive) could be clustered, so that the work of that component could be split onto multiple machines (what's referred to as "horizontal scalability"). Once you've done that for everything that has the potential to use anywhere close to a machine's worth of resources at your projected load levels, you can go to your superiors with a plan and an estimate of effort and cost to split it all out.
None of this is "cloud"-specific, it's just basic due diligence investigation into how to cope with increasing user load. Where you can start to use the benefits of "cloud" computing is when you do need to scale up in a hurry you can just hit a button and whoomp! there's more resources at your disposal. Don't wait until the load spikes to try that out, though -- if you value your uptime at all, run with at least two of every scalable component at all times, work out what your expansion trigger thresholds are going to be well in advance, monitor them, and spawn your new instances ASAP. Then put the system under massive load and test that it all works as you expect.
As Pauska indicates, much of the value of a virtualized environment is redundancy and availability, in addition to scale. You might want to consider a private cloud style solution such as Rackspace's, or roll your own, assuming you have good VMWare staff in house. This will take some time however, as womble's excellent post indicates to get it right.
If you have a deadline coming at you quick, and you don't have time to research sharding your apps, the following come to mind: