I have been talking with many CIOs for some time about strategic adoption of cloud solutions. A key step in these conversations is always the review of the portfolio of services they provide to business users, so they can choose which clouds to adopt and why.

This has led me to describe a high-level taxonomy that segments the service portfolio according to the different cloud requirements, capabilities, and approaches in different types of applications and services.

Essentially, this work has segmented most (all?) service portfolios into four areas, which (roughly) follow the adoption curve of cloud computing

Cloud Service Taxonomy - Cloud-Free, Cloud-Migrant, Cloud-Native, and Rogue Cloud

Cloud-Free Services

For most of the large enterprises I talk to, some services will not be part of any cloud. These ‘cloud-free’ services may migrate from physical to virtual, but do not need elastic scalability and self-service, are too impractical or incomprehensible, are too locked into non-commodity (e.g. z-Series) hardware, or are too sensitive or mission-critical to migrate to (especially public) cloud environments. With apologies to the ‘pure cloud’ fantasists, it is a reality for many organizations, especially larger enterprises, many services will not be part of their cloud adoption plans – at least not soon, perhaps not ever. It is important to identify these ‘cloud-free’ services.

Cloud Migrant Services

As CIOs get a handle on cloud, they start proactively evaluating their service portfolio and migrating selected existing workloads – from the OS up – initially from physical to virtual, then to appropriate public or private cloud choices. These ‘cloud migrant’ services are not fundamentally changed, as they simply ‘lift and shift’ the same code, requirements, interconnections, users, data sources, etc. from traditional environments to (typically IaaS) clouds. Many benefits can accrue from running these services in a cloud – agility, flexibility, efficiency, cost reduction – but the services themselves are not specifically built in or for the cloud.

Cloud Native Services

As organizations embrace cloud computing, they start developing and using new ‘cloud-native’ services built in the cloud and for the cloud. Mobile and social services, for example, really blossom when built on cloud-native characteristics like self-service, mobility, scalability, and ‘big data’, while cloud-native development also allows business ideas to ‘fail fast’ or prove success with minimal upfront investment. Of course, rogue-cloud services (see below) can become cloud-native services when they move to ‘official’ production status; and SaaS applications are also cloud-native services, just delivered out-of-the-box by public providers.

Rogue Cloud Services

In many organizations, business users or developers have adopted cloud already, outside of the normal IT procurement process. The term ‘rogue’ may seem pejorative, but is not intended to be – I simply described a process that is outside of IT’s knowledge or control. As I wrote back in 2009, rogue cloud can be very positive, and there is no per se reason for IT should to shut it down. However, IT does need to establish visibility into rogue cloud to ensure security or compliance, avoid cost overruns, drive broader adoption of good cloud choices, or even to promote better cloud choices.

Why Does This Matter?

This segmentation came about not as an academic exercise, but to help CIOs with a taxonomy for service portfolio analysis and cloud choice. Each of these cloud service types has different needs, from both platform and management perspectives. By identifying cloud service types, a CIO can better adopt their choice of cloud as appropriate for different services at different times.

For example,

• A cloud-native service can be ‘designed to fail’, whereas a cloud-migrant service needs additional management (e.g. real-time replication) to maintain the same level of continuity.
• A cloud-migrant application that has been QA’d on a closed and proprietary hypervisor may need additional testing and QA before it can be moved to a different (or unspecified) hypervisor.
• A rogue cloud service must be discovered before it can be managed as part of a whole portfolio, whereas a cloud-native or cloud-migrant service will be catalogued as it is deployed.
• A cloud-free service needs none of the above, and specifically can fall outside the cloud portfolio and be exempt from new policies specifically designed to enable cloud services.

This segmentation is not meant to replace a thorough service portfolio analysis in making good cloud choices. In my session at VMworld 2011 in Las Vegas, for example, I presented analysis models from Visible Ops – Private Cloud, a CA Technologies quadrant framework, Forrester Research’s Evaluating Application Fit With Cloud model, and Freeform Dynamics’ model from Applied Cloud Computing: A practical guide to identifying the potential in your environment.

However, I do think it is a useful taxonomy to start making sense of your own service portfolio as you start to take stock of where you are in your cloud strategy, and where you want to go. So far, the CIOs I have worked with on this have agreed.

What do you think?

Mike Laverick's RTFM Education

I recently had the great pleasure of recording a ‘Chinwag’ on RTFM Education hosted by the inestimable Mike Laverick (@Mike_Laverick). Mike is a consummate pro with a comprehensive understanding of virtualization, so it was a privilege and a joy to record this video chat with him.

Andi and I covered a wide range of questions – and we simple didn’t have enough time to cover every topic. These are the questions we DID manage to get through in our time!

Q1. Folks used to talk about VM Sprawl, now their talking about VM stall. What is VM Stall, and what causes it?

Q2. I see you took a side swipe at the “the software mainframe” analogy for virtualization – go on let rip!

Q3. So you have just published a new book on virtualization and private cloud – what is that all about?

Q4. There’s a lot of talk on both sides about whether or not ITIL can coexist with virtualization and cloud. What is your take on that?

You can see/download  the whole Chinwag (on video or audio-only) here – Chinwag with Mike.

Obligatory picture of random cloud

Without pointing any fingers, there seems to be a persistent refrain from some public cloud computing proponents that says, ‘If you are running your own IT, then you are doing it wrong’. This attitude fails to account for the magnitude and value of many legacy investments in people, process, and technology.  It ignores the many challenges and risks posed by migrating enterprise IT to public cloud service providers.

I have no doubt that many organizations will continue to run their own IT, even as they also adopt public cloud services – for very good reasons. At the same time, many will migrate their entire IT environment, wholesale, to public cloud services. I do not see this as even slightly contentious.

In fact, my colleague, Gregor Petri (@GregorPetri) argues very well that this should not even be a debate. I cannot disagree – and in an ideal world I would not be talking about it either – but there needs to be a realistic balance to the ‘private IT is doing it wrong’ crowd.

After all, try telling most Fortune 1000 CIOs that they should tip their entire multi-data center IT investment, along with their entire end-user IT investment, into the dump and put it all on Amazon (like Netflix did). I bet they will laugh in your face before they kick you out of their office and get back to doing real work.  They have a sunk cost in existing IT investments – not to mention a valuable investment in people who know the environment and the business they are supporting. This is also supported by a vast array of IT and business processes that actually make the business more efficient and effective.

Public cloud might be logical for most smaller businesses, new businesses, or new applications like Netflix’ streaming video service, but for large enterprises, completely abandoning many millions of dollars of paid-for equipment, and an immeasurable amount of process and skill investment, is frequently unjustifiable. As much as they might want to get rid of internal IT, for large enterprises especially, it simply will not make sense – financially, or to the business.

To start with, there is the massive cost of rewriting all the existing applications from mainframe, UNIX, i5/OS, Unisys, and NonStop (at least) to run on commodity servers and infrastructures. Of course, this is not just a porting exercise. Migrating to public cloud would require completely new architectures for most enterprise applications, not least to accommodate the higher impact (though not necessarily greater frequency) of the downtime endemic in cloud computing. Moreover, given the typically high utilization, performance, and throughput of most of these ‘legacy’ platforms, the cost benefit of migration to commodity systems is questionable at best.

Deploying all new applications to the cloud and just letting legacy applications die through attrition will not allow wholesale migration to public cloud providers either. Some enterprises have applications that are 10, 20, or even 30 years old and still running critical workloads. Today’s crucial applications are going to be around – and running on private ‘legacy’ systems – for a long, long time.

In many cases, regardless of financial factors, it is not even desirable to move enterprise IT into the cloud. Despite all the failings – and they are typically legion – of existing investments in ‘legacy’ people, process, and technology, they frequently do still deliver substantial value to the business. Moreover, they have baked-in an irreplaceably deep level of experience, commitment, and understanding of the core business. They don’t treat all workloads as equal, and do prioritize the most important services in their portfolios.

Commodity cloud providers on the other hand treat all workloads – and all customers – in a shared environment as commodities. They do not provide the special treatment that some workloads really do require – such as some compliance-bound, high-revenue, or non-stop workloads. They do not provide time or event-based reactions to changing business priorities. They do not make sure to allocate the first servers that come up after a system-wide outage to high-priority workloads based on business policy. I talk to CIOs all the time who are laser-focused on aligning IT to the business; if a public cloud provider doesn’t even understand their business priorities, let alone prioritize them, then that goal is difficult, if not impossible, to reach.

This commodity attitude can be even more deleterious when a business (or their website) comes under attack – such as directly in a DDOS or similar attack, in a public relations campaign, or by a sovereign government – for supporting a controversial cause, providing some information, or otherwise becoming unpopular with some group – private or public. When that happens there is no guarantee that your cloud service provider will not just pull the plug on ‘your’ IT service for fear of public backlash, or under pressure from some government force, covert or otherwise (as recently happened with Wikileaks and with Florida pastor Terry Jones). They may even just ‘bump’ one business workload for another, simply because they have oversold capacity – a common practice in all sorts of shared service industries (including transportation, telecommunications, utilities, banking, and Web hosting).

For cloud providers, each supported IT service is just part of their revenue. If hosting any given IT service is not profitable to them (and/or causes them a public relations or legal problem), whether they cancel your contract is simply an ROI calculation. They are not going to fight their customers’ legal battles; they are not going to stand up to a autocratic (or even democratic) government; they are not going to risk their whole business for the sake of one customer. If the service provider does pull the plug, the business is likely to be left not only without an IT infrastructure, but possibly without an offsite backup to restore continuity on another provider – assuming another host will even take them on.

For many enterprises then, moving their private IT to public cloud service providers would not just add cost, but also add additional management burdens, compliance issues, security threats, and business risks. For enterprises that can operate within their own scalable and dynamic data center, public cloud is not ‘your mess for less’; it is ‘more mess for more’.

Moreover, in some cases there may not even be available (or possible?) cloud computing solutions – for example, in low (or no) bandwidth environments, delivering POS or ATM infrastructure, hardware-dependent back-office systems, or high-volume distributed end user computing.

However, there is no reason why private IT cannot gain at least some, if not all, of the benefits of public cloud. Most large enterprises can, will, and should use virtualization, automation, and service management to build elastic resource pools, allocate them to fixed and variable service requirements, and effectively deliver on-demand computing.

With continuous capacity management, integrated with performance monitoring, provisioning, and configuration management, this is possible even without over-investing in spare capacity. Even though they don’t actually have ‘unlimited’ compute resources, large well-managed private IT systems can appear infinitely scalable, at least as much as cloud service providers can. It would actually be interesting to compare the IT resources of major global enterprises with Amazon and other service providers. I would bet that enterprises like Wal-Mart, Citigroup, General Electric, etc. (not to mention many governments) actually have more compute resources to allocate in a dynamic cloud than most of the supposedly ‘infinite’ cloud providers.

With highly automated IT solutions, enterprises like Qualcomm have already delivered these benefits with their own private internal cloud. Others have been so successful they are now public cloud providers themselves – like Telstra Australia and Verizon. In fact, Gartner is actually predicting that by 2015, 20 percent of non-IT Global 500 companies will be cloud service providers. Moreover, there is even evidence that over time, investment in private IT infrastructure is actually more cost-effective than outsourcing it to external cloud providers, especially for larger enterprises.

I am certainly not saying enterprises should avoid public cloud computing entirely. That is just as absurd as the converse. Public cloud computing provides incredible opportunity, especially for small and mid-sized businesses, but also for enterprises. Without doubt, many workloads absolutely should be relocated to public cloud providers; some businesses probably are doing it wrong by running any IT of their own.

And perhaps in 20 years all these problems will  be solved. But I do not think it is very useful to rely too much on what might happen ‘in the long run’. It is an interesting exercise, and certainly can help inform long-term strategy, but as Keynes famously said, “The long run is a misleading guide to current affairs. In the long run we are all dead.” Especially predicting some hypothetical future state where all problems are solved is just a bit too convenient.

However, framing cloud computing as ‘all or nothing’ is a false dichotomy, because there is a realistic and hugely popular third option: a hybrid cloud. Indeed, most real-life CIOs are actually planning or deploying this model today, where both internal and external IT are combined in the best possible ways to drive business value. Most enterprise CIOs running their own IT are also engaging in both evolutionary and revolutionary approaches to cloud; managing a hybrid supply chain of public, private, and hybrid IT; and delivering a complex mix of IT services.

They are not ‘doing it wrong’ – they are doing what they need to do, with what they have, to make their businesses successful.

Enterprise desktops may soon be a thing of the past

In my last blog, I talked about the idea of a ‘software mainframe’, and how – if that term really means anything – IBM could actually be a serious threat to VMware (and the Virtual Computing Environment coalition of VMware/Cisco/EMC) , if it decided to support native Windows guests on its zSeries mainframes. As I noted in that post, I think this is far from impossible, and would change the face of the server virtualization substantially.

After I published that blog it occurred to me that IBM’s biggest opportunity may not be (or may not only be) in server virtualization. After all, VMware has a pretty good lock on that market right now, so simply getting penetration would be very tough (just ask Microsoft!). Plus, scaling out a zSeries platform with 1000 or more virtual servers in one hit is a major project, with a major upfront hardware budget, that is not going to fit many server virtualization & consolidation initiatives.

However, consider the needs of a desktop refresh. For even a relatively small refresh of a few thousand desktops, hardware costs alone can run well into six and even seven figures. It only takes 2000 desktops at $500 a piece to crack into the million-dollar hardware range – and you can accommodate a substantial mainframe in that kind of budget.

How about the mainframe then, not as an enterprise server, but as an enterprise desktop server?

In fact, IBM already has almost all the piece-parts it needs to deliver this.

To start with, according to IBM, the new IBM zEnterprise 196 mainframe supports up to 96 total cores, each running at a lightning-fast 5.2-GHz. ComputerWorld reports it can support up to 3TB of memory on board, and can also manage external Power and x86 IBM blade systems to support up to 114 blades with eight cores. IBM says that means the new zEnterprise can manage more than 100,000 virtual machines, has 60% more capacity than its predecessor, the System z10, is up to 60% faster than the z10, and can deliver up to an 80% saving on energy compared to x86 architectures.

Big claims? Big machine.

As to the virtualization layer, the zSeries comes with virtualization built-in, of course, courtesy of the z/VM architecture, and its ability to run Linux (31-bit and 64-bit) and OpenSolaris natively. It also supports KVM-based virtualization, and before IBM stripped it down to make IBM PowerVM, the predecessor technology acquired from Transitive in late 2008 supported virtualization of applications for Windows, Mac, AIX, i5/OS, Linux, and Solaris/SPARC. Transitive also supported pSeries, PowerPC, Intel Mac, IA64, and x86 architectures. Moreover, the zSeries can even run standalone C/C++ and Java workloads natively.

With just a little engineering, it is not difficult to imagine a single zSeries mainframe serving up end-user desktops and applications regardless of platform – Windows, Solaris, Linux, Mac, or even Java/C++ native. Talk about a data center in a box!

It is not just the back-end data center components either. IBM also has an innovative desktop virtualization partnership with Canonical Ubuntu and Virtual Bridges VERDE, which can deliver both Linux and Windows desktop clients hosted from a Linux VDI backend (with offline client support too).

Moreover, the mainframe excels at four areas that are among the biggest hurdles in VDI-style desktop virtualization – high bandwidth, high CPU, high memory, and high storage utilization rates.

So, how about an IBM zEnterprise:

• delivering thousands of Windows, Linux, Solaris, and even MacOS (!) client from one enterprise server
• serving up desktop productivity tools like Lotus Symphony and Notes (or maybe OpenOffice.org), perhaps even running natively
• using the Verde native capability, or integrating with an open-source Xen or KVM client hypervisor, to enable a ‘mobile/hosted’ hybrid desktop
• partnering with a third party streaming vendor to deliver ‘on-demand’ desktops and applications
• All of the above, offered in a hosted Desktop-as-a-Service (DaaS) model, through IBM Global Services (which some partners already do – in part)

Now that would upset the endpoint virtualization apple cart!

Of course, IBM is not the only vendor that could take aim at delivering an ‘all-in-one’ enterprise VDI server. The Cisco UCS has exceptional benchmarks for memory, throughput, and storage, as does the HP Integrity Superdome, but at least on spec neither comes close to the high-end of the zEnterprise in processor or memory capacity. Oracle (mainly through its Sun acquisition) has all of the virtualization components, from desktop to server, including hardware and software, but is struggling with maturity and in any case cannot deliver the sort of hardware specs that Cisco or HP does, let alone IBM.

IBM, on the other hand – within a hair either way – has it all, right now.

I have no significant inside knowledge on any of the desktop virtualization strategies of these vendors. In fact, so far, this is just a barely cooked idea in the back of my mind. It may be ludicrous in any number of ways. However, there is clearly an opportunity here, and it would be interesting to see if IBM could or would try – not least to see client computing come full circle from mainframe-attached terminals, to standalone PCs, back to mainframe-attached desktops.

And to be able to say, to all those who (still!) claim the mainframe is dead, “long live the enterprise (desktop) server!”

IBM Z10 Mainframe

IT loves analogies.

Seriously, will the computer-as-a-car analogy ever die (please)? It has been over 10 years since we first heard jokes about if Microsoft built cars:

At a computer expo (COMDEX) Bill Gates reportedly compared the computer industry with the auto industry and stated “If GM had kept up with technology like the computer industry has, we would all be driving twenty-five dollar cars that got 1000 miles/gallon.” Recently General Motors addressed this comment by releasing the statement : “Yeah, but would you want your car to crash twice a day?”

It has been popular ever since.

Citrix stretched the car analogy significantly last year, comparing VDI to a truck, XenDesktop (or was it XenApp?) to a Prius (or was it an SUV?), and XenServer to a Porsche (with Xen as the engine, ‘natch). This year Citrix again used some kind of car analogy, but the compact car was apparently no longer a Prius. Only a couple of months ago, Ballmer and Jobs were going after each other again, with Jobs comparing PCs to trucks, and Ballmer riffing on a questionable ‘Mac(k) truck’ analogy.

The latest and greatest example (depending on your reference point) is, of course, computing as a cloud – for many years as no more than a network icon, but mostly recently as a metaphor for a network-based on-demand computing model.

The analogy that has been bugging me recently though is virtualization (or cloud) as a ‘software mainframe’.

It was almost 18 months ago when VMware’s CEO, Paul Maritz, used the term ‘software mainframe’ at VMworld Europe. I bridled at it even then. Stephen Herrod soon followed, and both have used it periodically ever since. At Citrix’s annual Synergy event in May this year, Microsoft’s Brad Anderson used it too.

The thing is, with my experience in virtualization, cloud, and mainframe, the whole ‘software mainframe’ thing simply isn’t working for me.

Despite Maritz’s claims at the time that the analogy “proved especially useful in describing vSphere to people age 45 and over,” almost all the people I know with actual mainframe experience (both over and under 45) scoff at it. For them, even vSphere fails to live up to an actual mainframe in so many areas – uptime, throughput, manageability, security, scalability, standardization, lifespan, interoperability – the list goes on.

Meanwhile, I consistently hear most people without mainframe experience – including many CIOs, even those over 45 – want nothing to do with mainframes. “That old junk?” they say. After all, who really longs for the world of green screens, CICS and IMS, SNA/VTAM, COBOL and VSAM, transaction processing, DB2, and on and on?

I simply cannot see how the analogy is appealing for anyone. Indeed, in my experience, the message of a ‘software mainframe’ appeals to exactly no one.

In any case, VMware should really be careful what it wishes for – it may just come true. After all, if IBM ever decides to be more aggressive in its virtualization strategy, they might just enable their zSeries mainframe to run Microsoft Windows (and I for one do think they should). If they did, the real mainframe would make a very strong server virtualization option, especially for mid to large enterprises.

Remember, IBM didn’t just invent the mainframe, they invented virtualization. And if they delivered a real virtualization mainframe, you know that VMware would stop talking about mainframes pretty quickly.

And I for one would applaud, not least because I am heartily sick of the ‘software mainframe’ analogy.

IT is the Magpie of the Business World

I have a request. I hope it is not too onerous, because something is really starting to grind my gears.

Can we in IT please all stop claiming that any technology is going to kill another?

The latest I am reading, for example, is that NoSQL (for want of a better term) will kill off SQL.

No, it won’t.

My hyperbole aside, I know this with complete and utter certainty,  even though I am barely conversant in database technologies. Seriously, SQL hasn’t even killed off VSAM – first released in 1974 – which is still the foundation for a huge volume, perhaps even the majority, of our daily financial, logistics, retail, and government business. In fact, not only are we still storing data in VSAM, we are still programming in COBOL, and even doing it on 20 year old mainframes. So realistically, an upstart like NoSQL has no chance of killing anything.

Similarly, virtualization will not kill the physical computing infrastructures that came before it. Even most early adopters are struggling to get over 50% of their servers virtualized, while the average penetration is, by some reports, as low as 16%. Meanwhile, the percentage of desktops that have been virtualized is still in single digits. In some cases, so-called ‘legacy’ systems are actually becoming their own hypervisors (e.g. Windows, z/VM, Solaris, and Linux).

The same is true of cloud computing. Even if, as Gartner predicts, by 2012, 20 percent of businesses will own no IT assets – which I find highly dubious; and even if the cloud computing market will be worth $160bn by 2011 – also somewhat dubious; then still a vast majority of organizations will continue to own their IT assets. Even allowing for some substantial private cloud deployment (much less dubious), there is no chance cloud computing will kill the on-premise, installed and owned, IT environment.

Historically, this has always been true. Distributed computing never fully replaced mainframe computing. Indeed, the mainframe is actually experiencing record levels of growth (.pdf) in particular among heavy mainframe users (over 500 MIPS). Personal computing never replaced distributed computing either. The Internet did not kill local computing; thin clients did not kill desktops; Firefox did not kill IE (although IE did eventually kill Netscape); Java did not kill COBOL, let alone C; disk did not kill tape; Salesforce.com did not kill Siebel; Google did not kill Yahoo; Gmail did not kill Exchange.

In fact, it is really quite rare that any new technology completely kills off any other. We in IT are the magpies of the business world, collecting and hoarding all the shiny technologies we can. These are not just collector items or museum pieces though; these are real, mission-critical systems and applications. So we end up with a hybrid of critical technologies spanning not just years, but decades.

(Which is why I am such a strong proponent of heterogeneous IT management … but that is another article)

Perhaps it is just semantics, or a philosophical distaste for absolutes. Perhaps the rampant pace of IT development just makes it seem like we don’t replace technology (when of course we do).

But I would still be really happy if we could all refrain from declaring the death of any technology.

Because chances are it is simply never going to happen.

Surfing  a couple of blogs today, jumping from another analyst commenting that virtualization is not cloud (a fair, if unexplored, post), I came across William Vambenepe’s post from September on the confusion between virtualization and Cloud Computing. As he did on my blog recently, I started to post a reply to his site, and then as it expanded, decided to post it as a full reply on my own blog.

I like the thinking, and agree with a lot of the principles involved. Without doubt, virtualization is not cloud. But I can’t agree with it all. Apart from technical quibbles (like the part about mainframe LPARs not running on a hypervisor), I simply find it unreasonable, if not impossible, to think of implementing cloud computing without virtualization.

My key sticking point in most of these discussions [edit: not necessarily William's post - see comments below] is that they continually assume that ‘virtualization’ is synonymous with ‘hypervisor’, or at best with ‘server virtualization’. Neither is true. When EMA first defined virtualization (a definition that has taken hold more or less throughout the industry), we defined it as:

“a technique for abstracting or hiding the physical characteristics of computing resources from the way in which other systems, applications, or end users interact with those resources.”

Even now, Wikipedia defines virtualization as “the abstraction of computer resources” and “hid[ing] the physical characteristics of a computing platform from users.”

No mention of a hypervisor there, and with good reason. Virtualization is much more than a hypervisor, and applies to much more than servers. In fact, EMA’s original definition made this clear by including the following clarifying note:

“This includes making a single physi­cal resource (such as a server, an operating system, an application, or storage device) appear to function as multiple logical resources; or it can include making multiple physical resources (such as storage devices or servers) appear as a single logical resource.”

Indeed, many forms of virtualization (and cloud) are possible without a hypervisor – like OS virtualization, storage virtualization, grid and cluster computing, terminal services, and more. So while it is widely known that Amazon runs its cloud on a classic server virtualization platform (Xen), even a Google-like cloud, which is based (as I understand it) entirely on a fully hardware-based deployment, without any hypervisors, is still using another virtualization technology – grid computing.

So cloud is definitely possible without a hypervisor, but is it possible without virtualization?

Perhaps, but it is far less than ideal.

William cited SoftLayer Technologies  as doing cloud on bare metal; and  Loudcloud as being cloud before it was in vogue. Although I am not sure the latter is true, and Softlayer provide few details about their bare-metal cloud, it seems to be possible to provide cloud computing without virtualization.

Yet with very few exceptions, it is ill-advised at best. In implementation, if not in theory, the many essential characteristics noted in the NIST cloud definition (EMA’s preferred definition) are only barely possible in a purely physical environment.

Sure, you could get rapid elasticity, rapid provisioning, minimal human interaction, dynamic resource assignment, location independence, resource abstraction, etc. with a physical deployment. While they were both substantially unsuccessful with customers, IBM’s On-Demand and HP’s Adaptive Infrastructure both accommodated these elements primarily through automation, and without virtualization (or at least with virtualization as only an optional component). Even without automation, you could imaginably provision and manage physical servers manually to achieve this on-demand, adaptive, cloud infrastructure. In theory, all things are possible.

In practice though, cloud computing without virtualization is barely realistic. It is an edge case at best. Given what virtualization can do – for resource pooling, rapid provisioning, reducing intervention, resource abstraction, workload elasticity, and more – why would you try to implement cloud without it?

And that is just on the server! Given the different types of virtualization – especially network virtualization and storage virtualization – it seems that cloud without virtualization is not just ill-advised, but positively crazy.

For example, would anyone really copy all the data from one DAS drive to another in order to ‘dynamically’ scale a workload onto a bigger machine? Would you uninstall a drive from one server, and put it into another? Would you physically switch or reprovision a network in order to abstract a new server located in a different data center? Even to the biggest skeptic, cloud without any virtualization must seem a ridiculous notion, if not an impossible one.

So yes, William is technically correct (“the best kind of correct!”) – virtualization is not cloud, and it is possible to provide cloud services without virtualization.

But (with apologies to Samuel Johnson) it is like a dog walking on his hind legs – it is not done well; but you are surprised to find it done at all.