I enjoyed Phil Wainright’s article on “Defining the true meaning of cloud“.

In it he defines what he sees as the four components that make up the definition of cloud:

Abstracted infrastructure. In most cases, that means virtualization, but I’ve chosen a slightly more generic term because virtualization implies a specific technology choice and the key point here is that the underlying infrastructure isn’t tied to any specific hardware or operating software. In theory, any component could be swopped out or exchanged without affecting the operation of whatever is running above. Crucially, the abstraction provides elasticity to scale usage up or down without having to stop to upgrade the underlying infrastructure.

As-a-service infrastructure. The pairing of virtualization with automated provisioning and management has been a crucial element in enabling the on-demand, pay-as-you-go nature of public cloud. When enterprises talk about implementing private cloud, these are the ingredients they focus on, and there’s no doubt that they deliver enormous cost savings and productivity gains when implemented privately. But these components alone are not the only constituents of cloud. Taking existing platforms and applications and implementing them on a pay-as-you-go, virtual machine is not cloud computing. You’ll still have enormous extra management overhead, duplicated resources and wasted redundant capacity — and gain none of the additional benefits of a fully cloud-scale environment.

Multi-tenancy. Sharing a single, pooled, operational instance of the entire top-to-bottom infrastructure is more than simply a vendor convenience; it’s the only way to really achieve cloud scale. Look beyond the individual application or service and consider also the surrounding as-a-service infrastructure and any connecting framework to other cloud resources. Understand the value of having all of that infrastructure constantly tuned and refreshed to keep pace with the demands of its diverse user base across hundreds or even thousands of tenants. The most conservative among them will constantly probe for potential risks and weaknesses. The most progressive will clamor for new functionality to be brought into production as rapidly as possible. Every tenant benefits from sharing the collective results of those two extremes and all points in-between, keeping the shared infrastructure both battle-hardened and future-proofed. Every tweak and enhancement is instantly available to every tenant as soon as it’s live.

Cloud scale. It’s no accident that cloud architectures are multi-tenant — just look at Google, Amazon, Facebook and all the rest. If you start from a need to perform at cloud scale, you build a multi-tenant infrastructure. It’s the only way to deliver the walk-up, on-demand, elastic scalability of the cloud with the 24×7 reliability and performance that the environment demands. Cloud scale consists of all of this globally connected operational capacity, coupled with the bandwidth and open APIs required to effortlessly interact with other resources and opportunities and platforms as they become available in the global public cloud. A computing architecture can have all the other attributes of cloud, but without this cloud scale dimension, it will not be able to keep pace with the operational demands, the overwhelming connectivity and the continuous rapid evolution of the cloud environment.

Are we heading back to the days of Shadow IT, now with hidden infrastructure out on the cloud rather than in secret server rooms or under desks? Photo credit: Google’s First Production Server by Jurvetson on Flickr.

There is a very interesting article Bernard Golden in CIO magazine about what really runs on Amazon’s public cloud. He challenges the common perception that “public cloud computing is not being used by big enterprises… if large companies are using public clouds, it’s for “unimportant” applications.”

He argues that not only are enterprises using Amazon, and for important applications, but that use is increasing, despite the rise if private clouds.

Golden attributes this to the claim that

“…developers are the true decision makers in organizations…IT organizational decisions are actually made bottom up (i.e., by developers), and that senior management perception lags reality by a significant margin”.

He goes on to quote Stephen O’Grady of analysts Redmonk

“We are founded upon the idea that developers are the single most important constituency in technology. Open source dramatically lowers the barriers to adoption, such that developers may build upon what they want rather than what they’re given.”

Golden continues,

“The implication for organizations…is that decisions made by developers create commitments for the organizations they are part of — commitments that the organization does not recognize at the time they are made by the developer and may, in fact, be decisions that, had the organization understood them at the time they were made by the developer, it would have eschewed them. The result is that two or three years down the road, these organizations “discover” technology decisions and applications that are based on choices made by developers without organizational review.

This reminds me of a quote from Tolstoy quoted in “The Inner Ring” by CS Lewis:

When Boris entered the room, Prince Andrey was listening to an old general, wearing his decorations, who was reporting something to Prince Andrey, with an expression of soldierly servility on his purple face. “Alright. Please wait!” he said to the general, speaking in Russian with the French accent, which he used when he spoke with contempt. The moment he noticed Boris he stopped listening to the general who trotted imploringly after him and begged to be heard, while Prince Andrey turned to Boris with a cheerful smile and a nod of the head. Boris now clearly understood-what he had already guessed-that side by side with the system of discipline and subordination which were laid down in the Army Regulations, there existed a different and a more real system-the system which compelled a tightly laced general with a purple face to wait respectfully for his turn while a mere captain like Prince Andrey chatted with a mere second lieutenant like Boris, Boris decided at once that he would be guided not by the official system but by this other unwritten system.

Bill Jensen calls attention to this phenomenon of staff breaking rules to get things done in his new book “Hacking Work: Breaking Stupid Rules for Smart Results”. In an interview on AMA Edgewise her says:

“The number 1 source of work complexity is the infrastructure we find inside our companies. The tools, the procedures,  the processes – everything that is designed ton help us get our work done –  to be an  enabler –  is actually a problem, but senior executives own that and they are not willing to addresses it.”

So within organisations there are the official hierarchies  of the Org chart, and then there are the real IT hierarchies, with developers at the top, dictating real-world strategy by taking substantial decisions for their organisations almost by accident, as an orthogonal by-product of just trying to get things done, usually by breaking or bending rules.  What we have on the ground is a return to a form of Shadow IT, this time enabled by the cloud. As Golden notes,

One CIO noted that he had gone through the expense reports turned into him for reimbursement and found 50 different cloud computing accounts being used by developers in his organization. The reason? It’s a lot easier for a developer to obtain computing resources from a public cloud provider than to undergo the extended waits typical of the existing compute environments.

This is undoubtedly true. I see this all the time in enterprises I work with. In my experience it is usually test environments, proof of concepts for project justifications and sneaky ways of meeting requirements (Requirements checklist item #44: Offsite back-up? Check….backed up to Amazon S3)that end up in the public clouds, not core application components.

Developers and other IT professionals are taking the path of least resistance to the public cloud due to lack of internal agility (speed) or capacity is also one of the main reasons I hear from CIOs for why they want to adopt private clouds. They want to offer their developers (and other users) the sort of speed, elasticity and cost benefits of public clouds, but in a controlled private cloud.

“The upshot of all this is that today decisions are being made by developers about use of cloud computing that upper levels of the organization are unaware of (the CIO just cited is undoubtedly an exception to the general rule). A corollary to this is that IT organizations will discover new public cloud-based applications in a year or two that they had no idea were being placed in those cloud environments. “

I am not convinced of this. CIOs might wake up to find – to their relief – that their developers adopted “cloud thinking”, that their applications architectures are cloud optimised, that their applications can use cloud APIs. I do not think we will find that large submerged sections of their are running on public clouds. I think private clouds will fill this gap quickly, just as I think that eventually hybrid clouds and the applications they enable, are the future. Right now I see hybrid, but it is usually a hybrid of public cloud and traditional bare metal within the firewall.

Golden sees three ramifications from all this:

“1. Organizations will be taking on operational responsibility for applications located in cloud environments for which they are unprepared.”

He exhorts organisations to

“quickly get up to speed on the cloud environment and learn how to operate an application within it. This will include the need to retrofit monitoring, security, and management into applications, as developers often fail to address these areas because they are not required for application functionality. “

This is a very good point. Developers may be conversant with Cloud, but the Operations and Support people need time to integrate cloud applications into their portfolios even if they are very familiar with the cloud technologies in question.

“2. Compliance requirements will need to be analyzed for these “discovered” applications.”

Golden rightly identifies  a massive “tail-end” problem of cloud adoption – controlled or uncontrolled. The front end problem is often of of encapsulating or abstracting ones application into the cloud. Once that is successful, the tail-end problems hit. These are the compliance and governance issues, the modifications to internal procedures, the challenges of defining ownership and maintaining cloud bases systems. He advices have a multi-disciplined rapid response team ready to react to the discovery of a renegade application (or part of an application) running on  a public cloud.

“3. Investment patterns of IT spend will be modified in a stealthy fashion”

Golden reiterates  point made beautifully by Simon Wardley in his absolutely brilliant “”Situation Normal, Everything Must Change” talk at OSCON 2010 in which he points out that whilst Cloud Computing will unleash innovation and IT backlog, but it is unlikely to lower costs thanks to Jevons Paradox, Componentization and Creative disruption.

I will let Simon explain. This talk is one of the best I have seen on Cloud Computing and very well worth watching end-to-end:

I am not convinced that Simon is entirely correct about Cloud Computing not reducing IT spending. Cloud Computing introduces efficiencies. There is more bang for buck.

Simon contends that instead of CIOs being able to reduce costs, the new efficiencies and innovations will give rise to greater demand (Jevons Paradox) which will wipe out the cost savings.

I think that the IT backlog caused by today’s problems will be eroded by Cloud Computing and may generate more demand, but that demand will still be backlogged. The key constraint will moved from cost and infrastructure to processes constraints like workload capacity of  IT solution architects, support staff or even the developers themselves.

In other words, demand will be constrained by human factors, whilst the infrastructure costs of satisfying demand will drop, leading to a net drop in costs (i.e. a reduced IT spend).

That said, In suppose one could reasonably argue that those cost savings would be diverted into easing the key contraint(s), the net result still being no reduction in IT spend, just more to show for it.