A Cloud by Any Other Name

By Rich Wellner

The cloud list on google has been buzzing lately about the term "Enterprise Cloud" and whether it had any significance.

I had to chuckle as history started to repeat itself again between the early days of the grid and the early days of the cloud.

In our book Pawel and I wrote a section titled "How the Market Understands Grids". We didn't try to dictate terms, we tried to document the language in place at that moment in time.

In interviewing users we gathered the following terms:

• Clusters -- Computers standing together, but accessible only to a small group of people
• Departmental grids -- Multiple clusters accessible on a common backplane, but owned by one department
• Enterprise grids -- Corporate resources available to all in the company (known today as a Enterprise Cloud)
• Partner grids -- A few companies working together on big problems and sharing resources to accomplish their goals.
• Open grids -- Many organizations making resources available to other members of that grid. A key distinction between an open grid and a partner grid is that an open grid doesn't typically have a key application or goal while a partner grid does.

We blanched a bit because to us grid computing meant only the last definition and we viewed those other ones as missing some key attributes that those of us who had been working in the grid field since its inception thought were really important.

We see the same thing happening today with the term cloud and particularly in the term Enterprise Cloud.

That said, is Enterprise Cloud really an oxymoron, as one person suggested?

First we have to get to definitions:

Here are the key characteristics from the cloud computing wiki:

• Capital expenditure minimized and thus low barrier to entry as infrastructure is owned by the provider and does not need to be purchased for one-time or infrequent intensive computing tasks. Services are typically being available to or specifically targeting retail consumers and small businesses.
  
• Device and location independence which enables users to access systems regardless of location or what device they are using (eg PC, mobile).
  
• Multitenancy enabling sharing of resources (and costs) among a large pool of users, allowing for:
  
  • Centralization of infrastructure in areas with lower costs (eg real estate, electricity)
    
  • Peak-load capacity increases (users need not engineer for highest possible load levels)
    
  • Utilization and efficiency improvements for systems that are often only 10-20% utilised.
    
• Performance is monitored and consistent but can be affected by insufficient bandwidth or high network load.
  
• Reliability by way of multiple redundant sites, which makes it suitable for business continuity and disaster recovery, however IT and business managers are able to do little when an outage hits them.
  
• Scalability which meets changing user demands quickly, without having to engineer for peak loads. Massive scalability and large user bases are common but not an absolute requirement.
  
• Security which typically improves due to centralization of data, increased security-focused resources, etc. but which raises concerns about loss of control over certain sensitive data. Accesses are typically logged but accessing the audit logs themselves can be difficult or impossible.
  
• Sustainability through improved resource utilisation, more efficient systems and carbon neutrality.
  

None of those seem to exclude the term Enterprise Cloud.

Here's the list of attributes I compiled from the cloud google group and others IRL:

• Multiple vendors accessible through open standards and not centrally
  administered
  
• Non-trivial QOS (see the gmail debate thread)
  
• On demand provisioning
  
• Virtualization
  
• The ability for one company to use anothers resources (e.g. bobco
  using ec2)
  
• Discoverability across multiple administrative domains (e.g.
  brokering to multiple cloud vendors)
  
• Data storage
  
• Per usage billing
  
• Resource metering and basic analytics
  
• Access to the data could me bandwidth/latency limitations, security,
  
• Compliance – Architecture/implementation, Audit, verification
  
• Policy based access – to data, applications and visibility
  
• Security not only for data but also for applications
  

Now here we start to see some things that aren't applicable to enterprise clouds (i.e. 1, 5, 6). But the bulk of the list still works. And it's worth noting that EC2 fails on four of those things (i.e. 1, 11, 12, 13), but people don't hesitate to allow them the use of the term cloud.

In previous technology revolutions I learned the lesson (slowly) to not care so much what things are called as much as what they do (which was why, in my early writings on this group I was trying to point out to people (mostly unsuccessfully) that there are lessons to be learned from grid computing). But claiming there is a canonical definition of cloud and that enterprise cloud is a nonsense term doesn't seem accurate on the face of things. Enterprise Cloud does, however capture the essence of what many large corporate IT groups are doing/considering. Rather than telling them they shouldn't be calling it cloud/grid/enterprise cloud/managed services/SaaS/whatever, I'm taking the approach of helping them meet their business needs, with technology wearing a variety of banners, and letting them call it whatever they like.