Single-Purpose Clouds: The Next Step After Private, Public And Hybrid

We’ve become accustomed to the notion of public cloud services (freely available to everyone), private cloud services (maintained by a specific company, but charged and deployed on a usage/needs basis) and hybrid clouds (which blend the two). The next possible development on the cloud horizon? Single-purpose clouds, optimised for a particular kind of workload.

Tap picture from Shutterstock

I chatted through this concept recently with Alan Perkins, the Australian CTO for cloud provider Rackspace. “It’s a natural evolution,” he said. “Cloud is ultimately about abstraction The idea of specialised clouds makes perfect sense.” Since the tasks that can be deployed into cloud environments have very different requirement, it might make sense with some applications to choose a particular type of provider.

“Traditionally, we’ve seen clouds as having the benefit that you can increase the capacity as you need it — but we’ve done it in a way where the XYZ co-ordinates on the box are locked, so they’re all in ratio,” Perkins said. In other words: if you want more memory, you may have to pay for more processors too.

“Increasingly, as we move towards better virtualisation and better abstraction at the software level, we’re going to be able to extend just one axis,” Perkins said. “This gives you the flexibility to specialise your workloads.”

As an example, Perkins cited Rackspace’s ObjectRocket, which can be crudely summed up as “MongoDB as a service”. One important point about that example: it seems unlikely that a single-purpose cloud would define itself purely in hardware terms. A given platform might have specific needs, such as fast I/O or access to powerful CPUs. In the case of ObjectRocket, those include specific chipsets and high-performance Fusion IO drives.

Those elements will be required to deliver it, but purchasers of such a cloud service won’t be thinking about the hardware at that level of detail. “The whole notion of hybrid is that you shouldn’t have to think about topology or specific vendor requirements,” Perkins said. “You should be able to plan at a high level.”

“It has to become like taps. You turn on the tap and you know what pressure water you want. You don’t want to have to go to someone to have them turn the tap on for them.”

One challenge with that approach (and even with cloud in its current form) will be ensuring that applications can successfully interoperate — a problem that’s familiar enough with on-premises business systems, but which can become much more pronounced when cloud apps are being deployed by different business divisions without any central co-ordination.

“It’s a bit of a problem,” Perkins commented. “The world is going to be worse off in the long run because if you don’t put professionals into the mix you’re going to have a lot of siloed applications. And you want to know that if something goes wrong, somebody behind the scenes is going to make sure things get fixed quickly.”

Another issue is how to charge for those newly-flexible services, though Perkins argues the main issue is how to present that information to a potential buyer. “The biggest challenge is not about providing a calculation engine, but in providing a user interface the average punter can understand. One issue is not knowing what you’re actually paying for,” he said. It’s not a question of the cost — the key to that is providing sensitivity and what-if analysis, so they can drag the dimensions as they need them. The more we expose the inner workings of the cloud, the less ‘cloud-y’ it is.”