This article is more than 1 year old
Spikes in demand get lost in the cloud
Which service is best?
One approach to smoothing out application demand is a load-balanced server farm. Another is virtualisation to bring extra resources to bear when needed.
But what about public cloud services? Surely they could be used to mop up excess demand?
More disk space, more bandwidth? Certainly, how would you like to pay?
The answer is yes, in theory, with a plethora of public cloud services to choose from, many offering scalable processing power, storage and other resources on a pay-as-you-go or utility basis.
Want more cores? Click a button. More disk space, more bandwidth? Certainly, how would you like to pay?
In practice, bolting these onto applications won’t be easy. To start with you would need to replicate the applications and their data sources, a lengthy and complex task that few would relish.
You also need some way of bringing those resources online when needed. Let me know if you can think of one. I can’t.
Moreover there’s no guarantee that your application will run in the cloud, at least not without a lot of modification and development.
So much so that most companies find it better to move their applications wholesale to the cloud, where it is much easier to cope with the peaks and troughs.
The move is the same but the service can differ, providing three distinct approaches: software as a service (SaaS), infrastructure as a service (IaaS) and platform as a service (PaaS). Each has its own advantages and limitations.
SaaS
Here you effectively buy a hosted application, leaving it to the service provider to handle the server, storage and networking infrastructure required to support it.
For example, rather than replacing or upgrading an in-house Microsoft Exchange server, you might turn to a service provider to host your email for you. You might use Exchange or an alternative such as Google Mail, but whatever the application no development work is required. All you do is connect users to the service, migrate their data and press start.
Unfortunately, scalability and the ability to cope with peaks in demand are very much down to the provider. As the customer you have little say in the matter, other than tying down what you expect in the contract and the associated service-level agreement.
IaaS
This is where you are mostly paying for the hardware resources that make up a data centre – things like servers, storage, and network switches and routers. Software is limited to virtualised operating systems, web and SQL servers.
A number of vendors spring to mind, including Microsoft (and its network of partners), Amazon, Rackspace and SunGard. All sell IaaS on a utility model by which you pay only for the resources you need, with the option of “flexing” up and down as demand changes.
A proffered advantage of IaaS is the ability to pick up applications and move them as is to an infrastructure service, but it is not always that easy. There's always some development and testing to do, plus most services are x86-based, which rules out moving legacy applications running on mainframes, minis or custom Unix hardware.
OK, some Unix applications could be re-compiled for x86, but that's quite a task and you might prefer to start from scratch and develop web applications specifically for the cloud.
PaaS
What you are buying is, again, scalable infrastructure, available from vendors as a pay-as-you-go utility, like IaaS. However, rather than having to source tools to port applications, with PaaS these tools are provided together with supporting web and other services needed to run them.
Vendors include Microsoft with Windows Azure and Google with its App Engine service.
Of course, with PaaS you are one step removed from the supporting infrastructure, but the same limitations apply when migrating legacy applications, where often the only option is redevelopment.
So can you mop up excess demand using public cloud services? Yes, but not by bolting the cloud onto what you already have.
The only workable way is by moving applications to the cloud to begin with, and that is not always as straightforward as it seems. ®