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.

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.