The Cloudscaling blog has a loyal following as can be seen from the website and RSS feed stats. As many of you long time readers know, I’ve been ‘in the game’ working on cloud computing technology or blogging about as long as anyone except perhaps those at AWS. In all of that time, my thinking and assessment of what’s happening and how it’s evolving has changed continuously. What was interesting for me this year is that this continuously changing perspective slowed to a crawl or perhaps even stopped. 2011 is the year that much of my thinking and perspective on cloud computing, particularly infrastructure clouds (aka “IaaS”) hardened.

That sounds tough. “Hardened.” I don’t mean hardened in the sense of rigid, but rather in the notion of wet cement drying. Many things that have seemed up in the air now seem settled and my doubts about the future of infrastructure clouds are gone. They are not only here to stay, but the shape and direction of them seem very clear. I’m not certain everyone else is clear, but I am. Perhaps I will be wrong, but I doubt it.

Let’s take a look back at the arc of my thinking and how things did NOT change in 2011. That will tell us what 2012 is likely to look like.

The Evolution of My Cloud Thinking
My thinking evolved through three clear phases:

Automation -> VMs & Virtual Datacenters -> New IT Paradigm

Phase 1: Automation
About this time of year, in late 2006, a short time after Amazon EC2 launched, myself and others prototyped a cloud application management framework similar to RightScale. At that time RightScale was named something else and had not been funded or publicly launched. These were early days.

As someone with a deep passion for automation, I remember thinking then that a lot of my lifetime interests (networking, storage, security, and systems management) were all converging and being managed by automation. For me, what was happening was all about automation … and lots of it.

Phase 2: Virtual Machines & Virtual Datacenters
Roughly summer of 2008, the first “CloudCamp” was thrown where a number of the cloud bloggers and thought leaders came together for the first time. Unknowingly we all centered about using the term ‘cloud computing’ to explain what this new emerging phenomena was. It was right after this event and over the summer of 2008 that the term “cloud computing” really took hold. This also led to the formation of the “clouderati”  and I simultaneously joined GoGrid as the VP Technology Strategy.

Perhaps GoGrid biased my thinking, but I started to move from a perspective that was cloud application centric back into my sweet spot of physical infrastructure and a focus on virtual datacenters or what I called at the time, “cloud centers”. In this view, virtual machines were king and inevitably, the question was: “how will we model existing datacenter environments?”

Phase 3: Cloud Computing is a new kind of IT
After leaving GoGrid in the summer of 2009 I had the opportunity to step back and take a fresh look at how things had evolved. I wanted to build my own cloud business again, but I wanted to skate to where the puck would be, not where it was today. I also could see that most everyone involved in the cloud computing space was spending time trying to retrofit the notion of ‘cloud computing’ to their existing business models and technology. Simultaneously, I still didn’t see any serious competitors to AWS.

What were they doing that was so different??

It’s not well known, but in the beginning of Cloudscaling’s (re)formation in fall of 2009 into mid 2010, I did a number of strategic and due diligence engagements on various IaaS vendors for VC firms, Platform-as-a-Service startups, enterprises, and enterprise vendors. During that time I was involved in deep technical dives on the technology and business models for these IaaS vendors. They ranged from GoGrid competitors to more of an enterprise cloud model. By late 2010 Cloudscaling, collectively, had deep architectural and business model understanding of roughly 10 different Infrastructure-as-a-Service (IaaS) players, not including the IaaS clouds that we helped build [1]. I am not sure anyone else had or has that understanding today. What we saw, was telling.

My primary takeaway was that even when it came to startups and direct AWS competitors, absolutely none of the infrastructure cloud players were developing their clouds like AWS. For the most part, they were simply integrating common-off-the-shelf (COTS) components to mimic an AWS-like environment. None of them had AWS velocity [2], nor were they paying attention to what made AWS special [3]. All too often, they identified ‘flaws’ in AWS that were instead unrecognized strengths. Examples of this include:

• Constrained feature set
• Standardized instance sizes
• Lack of VLANs [4]
• Ephemeral storage
• Generic load balancing service without fancy vendor lock-in features [5]

That’s when I began to understand that ‘cloud computing’ had less to do with automation or virtual machines/datacenters on demand and more to do with *how* AWS was building their infrastructure cloud.

Ask yourself these questions:

• Why isn’t VMware more successful in the public cloud space if it’s just VMs and VDCs?
• Why isn’t there a VMware-based competitor at similar scale to AWS? Or even close?
• There are now 100+ “VMs on demand” competitors, but almost none have the same growth rate as AWS … why not?
• What do the largest Internet giants (Amazon, Google, Facebook, SFDC) all have in common from an architectural standpoint and how is that different from a typical enterprise datacenter?

Cloud Computing vs. Enterprise Computing
I gave the third opening keynote at Cloud Connect 2011, behind Werner Vogels of Amazon and Lew Tucker of Cisco. That keynote drove much of the discussion during the first day around ‘enterprise clouds’ and their viability. In that talk was also the initial crystallization of my infrastructure cloud thinking:

We didn’t have one way to build infrastructure clouds … we had two.

One was rooted in the old modalities and thinking around existing datacenters and enterprise applications. The other was rooted in a new way of thinking about Information Technology (IT) that uprooted every approach that had gone before.

Enterprise Computing applied to ‘infrastructure cloud’ [6]:

• How do I virtualize and manage my existing datacenter apps?
• How do I achieve bottom line cost savings and extend server consolidation?
• How can my existing vendors help me create a ‘private cloud’?
• How can I be compatible with everything I own today?

Cloud Computing applied to ‘infrastructure cloud’:

• What can we do to allow application developers to experience ‘infinite scalability’?
• How can we simplify the allocation of traditional IT resources of networking, storage, and compute?
• What will it take to help next generation web applications ‘scale’ by simply adding more of these IT resources?
• How do we make it continually less expensive such that application developers can consume as much as they need?
• How can I, the service provider, make my cost of capital equipment and operational management as low as possible so I can pass those savings on to app developers? [7]

These are two very different schools of thought. One is about saving money for existing datacenters and applications. The other is about enabling new revenue streams via new applications and unlocking the potential for developers to add value to the business. The starkest example of this I can think of can be found in my blog interview with Adrian Cockcroft, the chief architect at Netflix on their adoption of Amazon Web Services [8].

A brief aside: This is why I think the NIST definition of cloud computing is such a huge FAIL. It’s focus is on the superficial aspects of ‘clouds’ without looking at the true underlying patterns of how large Internet businesses had to rethink the IT stack.  They essentially fall into the error of staying at my ‘Phase 2: VMs and VDCs’ (above).  No mention of CAP theorem, understanding the fallacies of distributed computing that lead to successful scale out architectures and strategies, the core socio-economics that are crucial to meeting certain capital and operational cost points, or really any acknowledgement of this very clear divide between clouds built using existing ‘enterprise computing’ techniques and those using emergent ‘cloud computing’ technologies and thinking. [9]

How 2011 Unfolded …
Ever since that keynote at Cloud Connect, it’s become more and more clear that not only is cloud computing a new disruptive displacement of the existing IT model (see blog link just above) in the same way that enterprise computing (aka ‘client-server’) displaced mainframe computing, but that it’s directly intersecting with other major trends in technology.

Infrastructure cloud computing directly intersects and either enables or works with:

• Big data, the explosion of data and data processing needs
• The post-PC era, or the notion of the rise of appliances and mobile platforms as the long term predominant platform, and the shift to ‘apps’ from ‘desktops’ [10]
• Consumerization of IT (TrendMicro whitepaper in PDF), or the notion that knowledge workers prefer more adaptive and flexible environments to get their work done such as they experience in their private lives with the large web application providers (Google, Amazon, Facebook, etc.)

I’m probably overlooking other related trends here, but what is blindingly obvious is that all of these trends are new opportunities, not old. Nor are they a re-hash of old opportunities. Every single one of them are driving infrastructure cloud computing growth. From the hidden, such as Apple’s iCloud, to the obvious, such as becoming the de facto platform for building big data or mobile app backend services.

As 2011 draws to a close this weekend, I’m beginning to see the upcoming ‘trough of disillusionment’ or ‘chasm’ as Geoffrey Moore called it.

Writing -> Wall
We are five years in and no one has emerged as a legitimate challenger to AWS’s market dominance. And, frankly, none are on the horizon. The enterprise infrastructure cloud providers I’m aware of have terminally poor growth rates (<10% CAGR in many cases) and most of them won’t see a return on investment before they hit their five-year hardware refresh cycle. Translation: these enterprise clouds are essentially net losses when evaluating them on a 5-year TCO basis. The hardware itself won’t even be paid for during that time, much less the cost of operations.

Meanwhile, AWS will reach $1 billion in revenue this year and those few that are following roughly the same trajectory as AWS have at least similar growth rates, if not scale (see slide 11).

While VCE touts $1 billion in vBlock sales [11], the onslaught of so-called ‘shadow IT’ hasn’t ceased or slowed down if AWS growth is any indication. Most of these ‘private cloud’ deployments have failed to deliver on the promise of cloud computing, hence app developers still adopt AWS in droves. Frankly, it’s stunning how many of the Fortune 1000 are running production apps, mostly next gen web apps or re-architected versions of last gen web apps, on AWS, but won’t talk about it.

The Road Ahead: 2012
In 2012, we’re going to see the gap between ‘enterprise clouds’ and ‘web-scale clouds’ widen as we enter the chasm. At Cloudscaling we are already seeing just about everyone with an ‘enterprise cloud’ out researching ‘low cost’ alternatives. Unfortunately, this is still missing the forest for the trees, as business agility and top-line revenue growth is a far more compelling value proposition for web-scale clouds.

I believe that 2012 will be a time of experimentation, learning, and quite possibly even larger ‘cloud failing’ than has gone before. Before it can get brighter, it’s got to get darker.

I don’t know the ultimate solution, but one thing is for certain, we’re all going to learn a lot making it through the chasm to the other side. The only other thing I can tell you for certain is that mimicking existing enterprise datacenters is a ‘looking back’ rather than ‘leaning forward’ strategy.

In this coming year I plan to spend a lot more time on this blog and in speaking engagements exploring all of these ideas, thoughts, and revelations in more depth.

–Randy Bias
Co-Founder & CTO, Cloudscaling

1. Architecting apps to be cloud-ready is key
2. Architecting massive-scale clouds to handle massive-scale updates is critical to a successful security strategy; see #1
3. AWS again shows that the web scale cloud model has distinct advantages over enterprise clouds running legacy enterprise apps that can’t support rapid cycling of many VMs in a short period of time

Here’s a roundup of what else is being said:

• GigaOm
• PCWorld
• San Francisco Chronicle
• Computer Reseller News
• Light Reading
• CMS Wire

Building a cloud that works like AWS or Google involves a complete rethink of just about every concept considered canonical in enterprise IT for the past 20 years.

This is the message Randy Bias and Lew Tucker (Vice President and CTO, Cloud Computing at Cisco) delivered on the main stage CloudBeat 2011 last Wednesday.

High-level takeaways from the video (embedded below) include:

Enterprise IT is not ready to do real cloud. AWS is growing phenomenally: perhaps $1b in 2011 revenue and a 100% CAGR. But even with this market approval, enterprise IT is not psychologically prepared to run their infrastructure the way AWS does. Most large enterprises and service providers still design with the philosophy that each application architecture drives its own infrastructure architecture. The only successful public clouds turn that idea on its head.

Uptime at scale is in the software, not the hardware. Designing failover into the software – rather than the hardware – is another source of dissonance when moving from the enterprise IT mindset to cloud design. At scale, you cannot avoid hardware failure, so successful public clouds manage it though software architecture.

Open source is only part of the answer. Open source software is the only way to go if you want to build a cloud the way AWS and Google do. It’s not easy, though. More than 80% of your time will be spent dealing with issues beyond the cloud OS.

People do not need need to know what’s in the box. The box delivers an SLA and a set of services. It’s an appliance. This defines the move toward a utility computing model. You get one of 2-3 configurations for different classes of workloads, and that’s it.

If you skip through the introductions, the video is just under 20 minutes.

A conversation last week between Randy Bias and mobile analyst/Asymco founder Horace Dediu maps out how this diversity of new business models will evolve. Hosted at 5by5, Randy and Horace discuss the emergence of the “super platform” that is making it all possible. The first 20 minutes or so sets the table, with a discussion of how cloud computing and mobile ecosystems fit the definition of disruption theory. Then, Randy and Horace dig in:

• Enterprise hardware vendors are facing big challenges because their legacy computing model is at odds with the way web-scale clouds are being built to support emerging mobile ecosystems.
• Web-scale solutions are simple, and simplicity – in the hardware, architecture, stacks, networking – is critical to designing large systems that can be cost-effectively supported.
• Google operates as many as 10,000 physical servers with one employee. You can’t do that without a radical new approach to data center architecture.
• Apple, Android and other mobile device platforms are defining the post-PC era because of their ability to collect user-level data and take it to a cloud-based backend where it is aggregated and analyzed. Then, data can be fed into a wealth of new application concepts that offer previously impossible benefits at very low cost to users.
• A look at how we’ve shifted from a hardware-centric view of the world (hardware availability) to a platform-centric view (ecosystems) to a super-platform-centric view (ecosystems enabled by cloud). Examples include iOS, Silk browser, Siri, Facebook, and Android. Users extract new value from trading personal data for aggregate knowledge.
• Net-centric business models take advantage of aggregated data from users to provide them with new and very compelling ways to understand the world they live in and interact with it. The Quantitative Self Movement and other crowdsource apps are examples of powerful concepts that were not possible before powerful edge devices connected to web-scale cloud.
• This, coupled with voice, location-based services, augmented reality and situational awareness, puts us on the front end of an explosion of new app and business model possibilities.
• What do mobile network operators bring to the table that’s more valuable than AWS? A global footprint. Ownership of the IP backbone. Ownership of mobile network. OSS/BSS (billing system) integration. Low latency.

Randy and Horace conclude with a discussion of the utility business model and how IT organizations are adapting their thinking to embrace it.

Listen in on their conversation and check out Horace’s post, then tell us how you see the “twin disruptions” unfolding.

In the short segment, David and Ian explore the five key points that carriers and large service providers are beginning to figure when it comes to their cloud strategies:

1. Commodity Cloud is Winning. A growing list of carriers are beginning to realize that building with commodity-based hardware architectures is the only way to build large systems that are fault tolerant and cost efficient enough to be competitive with their non-carrier competitors.
2. Simplicity Scales. Large, fast, simple systems produce reliable and cost-effective platforms. Complexity does not.
3. Open Systems are Winning. The timing of Oracle’s public cloud launch compared to the sellout crowd in Boston for the OpenStack Summit is a perfect contrast that illustrates this. Proprietary systems are expensive and offer a questionable value proposition. Open source offers short-term risk to be sure, but a more promising future with limited lock-in and licensing overhead.
4. Building at Web Scale Requires New Thinking. In large systems, hardware is going to fail, regardless of how expensive it is. What makes a big cloud reliable and scalable is software, not hardware. Carriers are realizing that they can leave behind their old, expensive, legacy infrastructure when they build web-scale commodity clouds. They get a more competitive cloud with lower capex that’s easier to operate and has less operational baggage.
5. Carriers Have Big Advantages Over Google and AWS. Carriers have nearly limitless, cheap bandwidth. They have deep expertise in network architecture and operations. They own the wired and wireless broadband networks And, they can easily connect mobile and tablet apps to OSS/BSS systems that can help developers get paid and manage customer relationships.

Check it out. Tell us know what you think in the comments below.

We covered:

• The recent AWS outage
• Why you need two cloud providers
• The Federal Government’s inability to adopt cloud compute
• How big will the cloud *really* be?
• … and my recent development of shooting as a hobby

Not sure why folks are surprised that an avowed west coast liberal enjoys using firearms, but it’s a nice change of pace from all cloud, all the time.  :-)

Please listen to the podcast HERE on the Blue Mountain Labs website.  You can follow David Linthicum and Bill Russell on twitter as @DavidLinthicum and @BillatBML respectively.

Let’s put this all to bed right now.  We’re going to look at the issues around multi-tenancy, security, pricing, and positioning.

Market Positioning
I’ll go into depth on this in the near future as it’s tightly related to my recent postings and presentations on ‘enterprise clouds’ (cloud-washed enterprise computing & virtualization systems).  Right now though, the key thing to understand is that AWS is *already* in the business of servicing enterprise customers regardless of security concerns.

Enterprises, like most other businesses, have two key adoption types: greenfield applications and legacy applications.  Greenfield enterprise applications have been adopting AWS and other commodity clouds for some time now.  During that same time, AWS has been very busy adding enterprise friendly features to increase the ability for legacy enterprise applications to adopt EC2.

A great example of this is Virtual Private Cloud (VPC), which originally provided simple layer-2 VLAN/Ethernet emulation combined with a VPN termination point.  Now, as of their latest release it also allows creating complex networking topologies, just like in a traditional enterprise datacenter.

Dedicated Instances are yet another arrow in the AWS quiver that reduces friction for enterprise adoption of existing legacy applications.  This is an enterprise focused feature.  It reduces concerns around security of the hypervisor and ‘sharing’.  Reduces, not eliminates.

It’s also worth noting that while billed as ‘Dedicated Instances’, Amazon has already been effectively selling dedicated VMs/instances in their HPC offering. [1]

Hypervisor Security
Whether you or I believe hypervisor security issues are relevant doesn’t matter.  Some people clearly do and not sharing the hypervisor may be a requirement in some regulatory and audit situations.  Providing customers a dedicated physical server and reducing sharing to only the network and (maybe) storage[2] is seen as a win by some security and compliance people.

For large enterprises, getting over that security and compliance hump is important. Frankly, my recent observation is that when a massive disruption is happening the incumbents will focus on creating Fear, Uncertainty, and Doubt (FUD) in key areas.  One is security.  Many of the threatened enterprise IT vendors specifically throw this up as a reason to avoid adopting public commodity clouds or using their same approaches to build your own cloud.  Dedicated Instances remove this obstacle.

Multi-Tenancy
Perhaps the most pernicious idea out there is that this is somehow ‘Uncloudy’ because the hypervisor is not shared.  I’m not sure how this kind of thing gets started, but at it’s roots it assumes that multi-tenancy is a core property of infrastructure clouds and that it is only achieved via the hypervisor.  Taking aside the definition of ‘multi-tenancy’ and whether it’s a core property, it should be noted that clouds ‘share’ many resources, of which the CPU/server is only one.  They also can share storage, networking, billing systems, etc.

Don’t misunderstand me.  I *do* think some kind of multi-tenancy is important, but there is a spectrum of multi-tenancy from ‘a little’ to ‘a lot’.  Also, what you call a ‘tenant’ is critical.  Finally, tenancy happens differently in SaaS from PaaS and IaaS.  The tenancy models are very very different.

So, let’s dig into this notion of hypervisor tenancy.  I have a couple of diagrams to show my point.  Assume we have 6 customers with 4 instances each on a cloud with 6 compute nodes.  Randomly distributed we see something roughly like this:

Voila!  Multi-tenancy.  Everyone is happy.  We have a cloud, people.

However, if we re-shuffle these instances and ‘bin pack’ them onto dedicated servers, we suddenly turn off the multi-tenancy:

What’s different here?  Have we truly lost multi-tenancy?  Customers are no longer sharing hypervisors and nothing has changed but that we’ve reshuffled the instances.  But perhaps we haven’t lost multi-tenancy.  Networking, storage, and other resources are still shared.

Let’s look at a more real world example, though, since most clouds don’t run at 100% capacity[3]:

Here we have a cloud running at about 75% utilization rate with instances randomly distributed.  This is in pretty good shape, but of course, all of these open ‘slots’ aren’t generating revenue anyway.  Of course, that’s part of the business model, so no harm, no foul.

Time to reshuffle!

Right, so now we’re still running at 75% for the entire cloud, but some customers are 25% utilization for their dedicated servers, some 50%, and some 100%.  Our cloud wide efficiency hasn’t been reduced significantly, but per customer it has.  This also means that customers are going to control the efficiency rate quite a bit more we would like, holding certain physical servers to themselves if this is the same as the AWS Dedicated Instances model.

This is where AWS rather clever pricing comes in.  They simply charge a sort of ‘tax’ across a single region of $10/hr if you choose to use this capability.  This tax effectively makes up for any inefficiency created by allowing customers to hold open a few more instance slots than normal.

AWS Dedicated Instances Pricing
Again, the confusion on whether this feature is ‘cost effective’ mostly comes from the Register’s biased assessment of the costs.  This feature is not targeted at individual consumers, but large enterprises looking to adopt en masse.  For such customers I’ve heard of monthly run rates between 100K-1M in usage charges.  $12M/year for a large enterprise is a drop in the bucket.  $1.2M/year doesn’t even touch the radar.

As an example, if a large enterprise was spending $1M/month and wants to get slightly better security, much better compliance, they would have to spend a whopping $10/hr per AWS region, roughly $7200/month[4].  That’s $86,400/year.  Let’s see, that’s an addition of .7% to their total annual spend on AWS.  Is slightly better security and ability to meet compliance standards worth >1% in additional cost?

If that same enterprise was only spending $100K/month, then we are looking at a 7% addition to total annual spend.  I don’t know what the value is of the AWS Dedicated Instances feature is to such a large customer, but I’m certain it’s more than 1-7% addition in additional spending.  Probably much more.

This pricing makes AWS Dedicated Instances extremely good value for money for a large business.  Combined with the new VPC features and being able to ride Amazon’s innovation curve, constant cost reduction cycle, and the other benefits of a large commodity public cloud provider, it’s hard not to find the whole offering rather compelling.

Conclusion
Better security, better compliance, less impedance mismatch with legacy applications, ability to onboard enterprise customers, and still cloudy.  This is a net win for everyone involved: AWS, enterprise customers, and the cloud community as a whole.

BTW, there are whispers that AWS has significant amounts of other related features that will further reduce impedance mismatch with enterprise clouds.  I expect that anyone sitting on an enterprise cloud (public or private) that doesn’t have an innovation cycle matching Amazon’s is going to get run over in the next year or two.  More from us on remaining competitive soon, though.

UPDATE: Cleaned up some language and fixed some typos.

The stacked graph by service is as follows (click through for full size image):

And here is a slightly different view that unpacks the various services a bit:

Obviously the EC2 service, which encapsulates a number of sub-services (e.g. ELB, EBS, Elastic IP), has the lion’s share of updates, but every service is being touched on a regular basis.

Perhaps most importantly, in 2010, every single service had significant feature updates and releases.  This, I think, is the crux of one of Amazon’s key competitive advantages.  A fast-firing multi-service release cycle that allows them to continue to plow ahead of others in the market place.

In my Cloud Connect 2011 Keynote, I panned the so-called “enterprise cloud” model for building clouds.  This is the model epitomized by traditional (I prefer “legacy”) enterprise vendors who are trying to help cloud service providers capture the non-existent legacy application outsourcing market.

Perhaps enterprise clouds will ultimately be successful, but can anyone really see a legacy enterprise vendor providing this level of release cycle across 10+ services on a monthly, quarterly, or annual basis?  It requires a whole different kind of DNA; the kind we see in large web/Internet operators and cloud pioneers such as Amazon and Google.

Meantime, AWS continues to release feature after feature that reduce the impedance mismatch for legacy applications to adopt their cloud.  Mark my words, while greenfield apps are driving AWS today, legacy apps will eventually need clouds to move to and I suspect that by the time we see mass adoption (2-3 years out most likely) AWS will be as attractive a target as an ‘enterprise cloud’, but at a fraction of the price.

Alistair has been consistent in managing two conflicting imperatives:

1. Get large enterprise vendors to sponsor the event
2. Avoid the event feeling like a sales pitch

You can’t have a conference without sponsors of some kind.  Simultaneously, sponsors can be their own worst enemy as most have an agenda in sponsoring the event: sell their vision and products.  Unfortunately, if every sponsor is left to their own devices an event can become a clamor of sales pitches.

What Cloud Connect has managed to do is to thread the needle of providing high value content, while allowing everyone to participate fairly equally: sponsors, independent vendors, startups, customers, bloggers, and the greater cloud ecosystem.

The result has been a terrific event that doubled in size this year.  I just went through the evaluation results from attendees and it was clear that most everyone got a tremendous amount of value from this conference.  My guess is that it will double again next year, so be prepared.

The Cloudscaling Keynote
Cloudscaling was well represented at the conference as many of our regular readers know. One of the most impactful contributions we had was to set the tone of the conversation on the first full conference day (Tuesday) with our keynote.  I followed Werner Vogels, CTO of Amazon, and Lew Tucker, CTO – Cloud Computing of Cisco.

The nut of the presentation was that I argued against the notion of ‘enterprise clouds.’ The presentation was extremely well received (better than expected, really), but unfortunately, one point of confusion is the term “enterprise cloud.”  With only 10 minutes to present, some times nuance can be lost.  Before you watch the video of the keynote (below), I’d like to explain what I mean by ‘enterprise clouds.’

So, what is an “enterprise cloud?”  When some people hear that term, they think ‘private cloud’ or a ‘cloud for enterprises’.  What I mean is an infrastructure cloud built using ‘enterprise computing’, not ‘cloud computing’ techniques.

Here is a way you can test if an infrastructure cloud, public/private or internal/external, is built using enterprise computing instead of cloud computing:

• It has more than 2 ‘brand name’ enterprise vendor’s products
• Allows for complex networks and routing topologies
• Focuses on allowing migration of unchanged (‘legacy’) applications from existing enterprise datacenters (e.g. features like hypervisor compatibility, live migration, complex networks, VPN access, etc.)
• Has an expensive price tag
• Doesn’t take credit cards, instead requiring contracts and monthly invoices
• Provides you an arbitrary ‘pool’ of ‘resources’ (i.e. clock cycles, RAM, storage) to carve up any way you want

If more than half of these are true, you are probably looking at an enterprise cloud. Examples, obviously, include some of the more prominent public clouds billed as enterprise clouds and some of the more prominent private cloud technologies coming from the largest enterprise vendors (no need to name names here).

So, as you watch my keynote, keep in mind I’m basically arguing that these ‘enterprise clouds’, regardless of whether they are public or private, are currently losing against the non-enterprise clouds.  I provide some great real-world data points about why this is.

Here’s the video of the keynote:

Randy Bias – Keynote at Cloud Connect 2011 from Randy Bias on Vimeo.

Here’s the slides if you want to follow along with the video (original on slideshare)[1]:

In addition to the keynote, I provided some updated information on AWS releases during panels I moderated this week at Cloud Connect.  Some audience members requested more details. I wanted to provide these details for everyone.

But first as a reminder, here’s the graphic showing Amazon’s development momentum by showing ‘significant’ feature releases per year:

AWS Release Counts by Year

This shows a strong development cycle and continued momentum on Amazon’s part.  The light grey bar on the right indicates a rough prediction for releases this year (2011).  If AWS meets this, that would be roughly 5-6 ‘significant’ releases per month.

The source data, originally in a Google Doc, is published here and we appreciate any thoughts or feedbacks you have into our basic methodology shown in ‘decision criteria‘ tab.  This is how we decided if something was ‘significant’ or not.

UPDATED: Changes made for clarification due to great feedback from Chris Hoff (@Beaker).