05 August 2008

The case against 'private clouds' - a [counter]example.

In my last post (The future of cloud computing - an army of monkeys?) I took exception to the concept of a 'private cloud', as presented by a number of hardware & software vendors who would have us believe that it is 'any large, intelligent and/or reliable cluster' (typically while trying to sell the same). I suggested that we should call a spade a spade (a cluster a cluster), but I didn't go into a great deal of detail as to why it is impossible to emulate some of the key features of cloud computing in-house, most notably, peak-load engineering, but more generally unleashing the true potential of a global service oriented architecture.

Let's use a concrete [counter]example:
I spend a lot of time in a small town dominated by two very large companies working on difficult environmental problems that, for the sake of the argument, require a bunch of computing horsepower for modeling every other day. Yesterday $CUSTOMER would have called $VENDOR to ask for $CLUSTER, and the vendor(s) (quite possibly the same vendor for both) would implement two identical datacenters, both engineered for the (identical) peak load of these two companies (that is, exactly double what is required).

In this simple example they could have come to some time sharing arrangement and dealt with the same security problems grids deal with (remember these guys are competitors working on the same problems) but that only works for a very small number of clients, and often not at all.

A cloud provider on the other hand would have been able to securely share the hardware between these two companies, while abstracting the capex, running costs, etc. The customers would pay for the 'overhead' of the cloud provider, but said provider would only have to buy half the hardware, half the staff, half the real estate, etc. and the customer wouldn't have to worry about building and maintaining it so they still win.

Another very significant win for their being 'in the cloud' is that once they've done their modeling they can easily build on top of other cloud services. For example they can slap the results straight onto a map hosted by another provider without having to buy /very/ expensive mapping software, middleware, integration and of course the maps themselves (Actually since the results are not public they still typically have to pay something, but a fraction of what it would have cost before).
In this case they are a 'client' of The Cloud, a second rate citzen if you like, but then by pumping the results back out to the stakeholders (employees, clients, suppliers and/or other cloud users) they can become a full participant, in much the same way that participation is a key characteristic of Web 2.0 (itself a key component of cloud computing).

A purist view? Perhaps, however it's becoming increasingly clear that this is how computing will look in the (not too distant) future and the technology itself is a reality today. Before you sign the purchase order for that shiny new 'private cloud', do yourself a favour and be sure you and your vendor are on the same wavelength by challenging them to explain why their cloud is not a cluster, without resorting to saying "It's the vibe...".

At the end of the day these companies can get on with making widgets with a reduced bottom line and without having to worry about becoming computing experts (which is the equivalent of building your own power station to keep the lights on). The increases in agility and efficiency will give these early adopters a significant advantage over their competitors who remain shackled to legacy systems.

Updated: 5 August 2008 10:00 UTC This on the other hand is a 'private cloud'... don't forget to check out The Flight of the Conchords' hilarious but potentially NSFW 'Business Time' YouTube video at the bottom.


  1. Sam - maybe this argument works for SMB.

    But you can't view a large enterprise as a monolithic entity. They generally have many business units and departments, and so its IT department is effectively serving 100's of internal customers. The same tech that serves well for external cloud vendors will work just as well for an internal enterprise cloud - for exactly the same reasons.

  2. Peter,

    Thanks for the feedback. Most of my clients are large enterprises with 5 and 6 figure user counts and I agree both that they are not monolithic and that there are advantages to be gained from deploying a cloud computing architecture internally - perhaps a utility billed grid is part of that architecture, or maybe some form of peer-to-peer cpu scavenging will do. It's our job as consultants/integrators to help our clients find the best solution for their particular needs. That said, they will not unlock the true potential of cloud computing until they overcome objections (security, compliance, etc.) and migrate some or all of their systems 'into the cloud'. This may happen today, it may happen in 10 years, but it will ahppen and those who do it sooner will have a head start over those who sit it out.

    In the environment you describe (with hundreds of internal customers) another very significant advantage is that cloud providers are very well connected and can be easily and cheaply accessed by all users and offices over standard internet connections rather than WAN-optimised VPNs or traditional WAN links.

    Anyway there's exciting times ahead for all of us (consultants, vendors and of course customers themselves)... thanks for getting involved.


  3. As a software designer/architect that does in-house development for a large company, a private cloud would help things tremendously. There are two main factors why I make this statement:

    1) My company is paranoid about allowing their data, intellectual property, applications, etc. go outside of their own data center and networks. As much as it would be nice to break this, it is just too strong of a matter and does not lie with technology, but the business unit instead.

    2) With many small projects starting up all the time, there is simply too much overhead to setup storage, database, and servers (even if they are VM). This adds to development and maintenance costs considerably. Additionally the more you can abstract yourself away from the filesystem the better. As soon as you have to know about the file system (as opposed to using a storage solution such as S3), your application dependencies shoot through the roof.

  4. That's not cloud though is it, it's advanced virtualisation.

  5. Well I don't want to criticise really your point of view about clouds, but you seem to me nothing but a partisan for the "public cloud party". Your examples are nonsense in a real world and also, you don't take data privacy into account at all. And this is 2 things in one, because big customers not just want to have security on their data which we (a commissioner of a project for the customer) use but they have serious regulations, policies and responsibilities for their data and they cannot afford us to "play" with it.

    Deal with it

  6. @AC: Ah, compliance... but that's not the same as security now, is it. In fact it turns out that the level of *compliance* is often inversely proportional to *risk*, so in fact in almost all circumstances you're better off going public but you may indeed be prevented from doing so by arcane regulations (which will be updated in due course, as evidenced by PCI's recent incorporation of virtualisation).


Note: only a member of this blog may post a comment.