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.

Is old-school physical security really 'good enough' for virtualization?

Whatever happened to virtualization security?

Back in the day, everyone was talking about blue pills and red pills, about sideways attacks and DOM-0 threats, about security profiles and isolation policies, about perimeter defense and security embedded in the hypervisor.

Then, all of a sudden, the buzz seemed to disappear. It really seems like organizations simply don’t have the time, money, desire, or otherwise to pursue dedicated virtualization security.

Indeed, it seems like most of the pure-play virtualization security vendors have folded, been sold, or reworked their strategy.

For example:

• Blue Lane ended up being sold to VMware, reputedly at a bargain price, after failing to get any traction.
• Third Brigade was rolled up into Trend Micro, and now offers a solution for combined ‘physical, virtual and cloud’ protection.
• Reflex and Catbird have repositioned to highlight their value in configuration, compliance, and/or systems management (in addition to their security value).
• Tripwire and Configuresoft have long promoted some virtualization security values, but were never really pure-play virtualization security vendors.
• Even security specialists like Symantec and RSA do not push virtualization security products, preferring mainly to build on existing security paradigms to support virtualization.

Of course VMware still has vShield Zones and the VMsafe API, but of the ISVs it seems that only Altor Networks still plays strongly in the pure-play virtualization security space.

This barely sustaining demand for pure-play virtualization security was reinforced last week in new research from Prism Microsystems (PDF), a software vendor in the SIEM market* (which I learned about in eWeek via @JSchroed). Possible vendor/sample bias aside, this research showed quite starkly how many respondents are securing their virtual environment using traditional (or no) security, and how few are using virtualization-specific security:

Source: Prism Microsystems, ‘2010 State of Virtualization Security Survey’, April 2010

In confirmation of this ennui, Gartner recently predicted at least a 5 year maturity cycle for virtualization security.

All of this is especially perplexing, because there is no doubt virtualization security is still top-of-mind for some very smart and dedicated people. The Prism Microsystems research, for example, says that 86% of its respondents acknowledge that securing virtualization is as important as securing their physical environment.

So I am unclear as to what is causing this lack of market interest. Perhaps CIOs (and/or CISOs):

• saw virtualization security as unnecessary insurance against threats that have never played out ‘in the wild’
• rated the potential financial impact of any additional risks as low enough that they can simply accept them
• believe that vShield Zones and VMsafe are all that is needed (but what about Hyper-V, Xen, etc.?)
• decided instead to invest in management disciplines with more straightforward ROI (virtualization, automation, configuration management, asset management, etc.)
• have simply been unable to justify virtualization security purchases during the economic downturn

Whatever the reason, it really does focus the question: does virtualization security really matter?

In my opinion, it absolutely does. Yet, it seems to me that decision makers are saying that standalone virtualization security is more important theoretically, from a technology and business perspective, than it is in practice. Most enterprise buyers – for better or worse – apparently believe that their existing security paradigns are at least ‘good enough’. They definitely appear instead to be taking classic intrusion detection, data loss prevention, identity & access, and other entrenched security management disciplines, and adapting them to the new technologies of virtualization (and probably cloud as well).

All of which actually does make sense. Without any major virtualization-specific exploits in evidence, perhaps they are right. While it may be valid to take the view that  it is only a matter of time until they are proven wrong, perhaps extending traditional security capabilities into the virtual world is indeed a good approach, at least for now.Perhaps CISOs are actually ahead of the game, integrating management across virtual and physical domains even while their systems and operations counterparts are maintaining virtualization as a silo.

Regardless of whether it is the right approach or not, one thing is apparent – the heat is off the pure-play virtualization security market, at least for now. As CIOs and CISOs focus on applying traditional physical security paradigms on their virtual environments, a different breed of cross-domain, integrated, and extensible tools are proving superior value – at least for now.

The only significant and unique benefit of KVM for server virtualization (as noted by Sander van Vugt in our (virtual) debate on Xen vs.KVM Linux Virtualization Hypervisors) is that KVM is part of the Linux kernel. This ensures broad standardization, patch compatibility, simpler upgrades, and a low-impact on-ramp for existing Linux IT shops.

Yet this is a solution for a problem that does not really exist.

Large enterprises already run thousands of components, from services/daemons to drivers to applications, all as additions to various kernels. Maintaining one more (or even several more) non-kernel components like Hyper-V, XenServer, ESX, etc., is not a net negative. On the contrary, EMA data shows that virtualization actually improves the productivity of server administrators, and by an average of around 10% – up to 20% or more for best performers. For competent administrators with good lifecycle management tools, the time they spend to learn, test, and maintain hypervisors is a significant effort, but it is time paid back with interest.

On the other hand, many downsides to KVM are all too apparent.

It is easy to point to the lack of technology features and maturity in KVM – areas like live migration, paravirtualization, networking, isolation, performance, security, or a host of other  features which KVM (in some cases arguably) lacks. I have only some doubt that KVM will meet these low-level functional requirements eventually, but it will not be anytime soon. Yet they are essentially table stakes in server virtualization today.

The inherent dependency on Linux would also require a major shift in  platforms for the average datacenter (where Windows outnumbers Linux by  150:1), and a major investment in resourcing, training, and software. This is hardly an attractive proposition for a data center manager. Still, existing Linux staff will be able to pick it up, and could even have some success on their (relatively few) existing Linux platforms.

However, even if these weaknesses are overcome, KVM has a much more strategic problem – the gaping void in the KVM management ecosystem. There is almost no third-party support for KVM from management vendors. Even stated support from key partner vendors like IBM, HP, and of course Red Hat is basic at best. What’s more, EMA data suggests KVM will not foster a significant management ecosystem in the future, either.

EMA’s research on Virtual System Management showed convincingly how important management is to virtualization. Across 18 different management disciplines, almost all correlated with measurably better outcomes in metrics like MTTR, provisioning time, availability, VM density, migration speed, and more.

EMA’s new cloud research shows a similar importance. Applying mature automation and management disciplines to virtual systems is directly correlated with positive cloud outcomes like reduced CapEx, reduced OpEx, improved operational maturity and more.

Not surprising then, that over 80% of enterprises consider manageability an important or very important factor in their virtualization and cloud technology decisions.

Unfortunately, KVM ranks anywhere from 4^th to 10^th in enterprise preferences for virtualization and cloud technology providers. It comes behind first ESX, then Hyper-V or Xen (multiple implementations), often various UNIX hypervisors (PowerVM, Integrity VMs or vPars, Solaris Containers), and even z/VM. No enterprise demand means that management vendors have little incentive to support KVM.

In fact, in my conversations with management software vendors, most generally put KVM around 5th in line for support – which, realistically, means it is not even on the current roadmap. What’s more, for better or worse several of them have a vested interest in not supporting KVM (no points for guessing who).

This means KVM has little or no prospect of gaining third-party support for virtualization management tools like VM-aware backup and restore, VM provisioning, virtual resource management, VM configuration auditing, virtual performance monitoring, VM lab management, VM image control, storage management,network automation and more. The same holds true for integration with higher-level virtual systems management tools for virtual and physical data center automation and service management disciplines.

For any IT group, sophisticated management tools deliver many proven benefits. For larger enterprises especially, they are simply not optional.  Without even the prospect of a robust management ecosystem, KVM is simply a non-starter in most large-scale deployments. For my enterprise clients at least, it is certainly not a credible choice for x86 server virtualization.

Enter Intelligent Workload Management (IWM), which, according to the Novell press release is:

… Novell’s differentiated approach to Intelligent Workload Management [that] integrates identity and systems management capabilities into an application workload, thereby increasing the workload’s security and portability across physical, virtual and cloud environments

All I can say is … bravo Novell!

No, really. It is about time. Novell has exceptional capabilities in virtualization, automation, and service management; and it also adds critical capabilities for security management and compliance, especially around identity management.  These are all core values in what EMA calls ‘the responsible cloud’.

The EMA thesis, essentially, is that cloud computing has too many cowboys, and not enough sheriffs. Enter Novell, the “Doc” Holliday of the cloud landscape, with responsible capabilities for virtualization, automation, service management, and security and compliance.

IBM, Microsoft, Sun, and even Oracle might argue with Novell in some of its claims of uniqueness – after all, all of them have substantial capabilities in all these areas too.

However, regardless of some overreaching in their marketing, competitive threats, a nascent market, and gaps in actual product capability, Novell has an excellent opportunity to re-brand itself and deliver some exceptional capabilities to deliver on private cloud computing goals, and is as well positioned as any vendor to stake a claim to what they label ‘Intelligent Workload Management’.

Keep an eye out for EMA’s more detailed Impact Brief on this announcement. Very interesting stuff, without doubt.

Andi.

It is described on TechTarget as follows:

While not distinctly different from traditional data center management, cloud computing management presents a new environment and new situations for vendors and users to master in order to keep a watchful eye on their applications and data.

Learn about the meaning of cloud management, its growing purpose in the cloud computing world and the expectations laid on cloud management providers in this podcast with Andi Mann, vice president of research with Enterprise Management Associates.

In the podcast, Carl and I talk about:

• specific disciplines in cloud management like threat management, performance management, availability, malware detection, provisioning, and automation
• the offerings and suitability of different vendors like Hyperic (now part of VMware), Rightscale, CA, BMC Software, and Nimsoft
• options for small and medium business (SMB) vs. large enterprises
• benefits and issues with home-grown, do-it-yourself (DIY), or scripting approaches vs. packaged software
• cloud computing and cloud management vendor lock-in
• who needs cloud service management
• the need for threat and vulnerability management (and impact of not having it)
• who needs to deploy cloud computing management tools
• and when to consider management tools for cloud computing

Check out the full podcast at TechTarget’s SearchCloudComputing.com site!

Part 2 will be coming soon too. I will letyou know when it is up.

Andi.

The General Manager had hired a new architect, a ‘virtualization expert’, to handle a new project. The architect designed a solution using server-hosted virtual desktops (in this case using XenDesktop) for the teachers and administrators in a school environment. The physical systems would use PXE boot to load a virtual desktop containing the apps that the teachers and administrators needed (essentially just Office 2007).

The problem was the teachers and administrators all had laptops, and needed to take their work home; meanwhile, the school was running a wireless network.  The laptops would need to establish and secure a wireless network connection before the virtual desktop could be loaded (via PXE). Unfortunately, they cannot establish a wireless connection until after they have already loaded an operating system. Catch 22.

My client – the desktop manager at the company – was called in to fix the problems created by the ‘virtualization expert’. He actually solved the technology issues pretty easily, by designing a new solution using server-based application virtualization (in this case with XenApp) on top of a simple, local, Windows installation. A common Windows installation would be easy to maintain; teachers could access their applications from any LAN or Internet connected location; applications and data would still be centrally stored and secured; they could cache applications on users’ laptops for offline use; and they could even publish a full virtual desktop for each user if they desired.

Despite some tradeoffs, it was clearly a better solution for their requirements.

When he called me, it was ostensibly to help him validate the new solution, but in the end my assignment wasn’t really about the technology; it was to help resolve relationship issues with the client, explain the project change to the client, advise them on license issues, help to get the customer on board with a different technology, liaise with the GM over resourcing and skill levels, etc.

As is typical, the human issues were the sticking point. After all – technology is easy; people are hard. In fact, throughout the project, the real problem had been human issues – a lack of time and people; lack of skills or knowledge; and interdepartmental political issues:

• Lacking the time and people internally for their endpoint virtualization initiatives, the company had hired an ‘expert’ with strong server virtualization knowledge.
• Sadly, that person was himself lacking in skills and knowledge when it came to endpoint virtualization, so he designed a solution that would not work.
• This created the political problems, as they failed to deliver the ‘virtual desktops’ that the customer was expecting.

These issues are in fact very typical, and EMA research (‘Real World Experiences of Endpoint Virtualization‘) shows they are actually the top three challenges most organizations need to overcome when implementing or expanding end-user virtualization deployments.

So what are the key takeaways for endpoint virtualization projects from this experience?

• Devote time and resource to training internal staff – virtualization skills are tough to find, and most companies don’t have enough of them in-house; conversely, IT staff consistently cite training & skills development as a key reason they stay with their employers. Seems like training existing staff should be a no-brainer.
• Use desktop experts for endpoint virtualization projects – EMA research has shown convincingly that the desktop team are the best people to handle endpoint virtualization projects. They are intimately familiar with the unique facets of endpoint environments (like the PXE limitations of WiFi networking), user requirements, mobility, application delivery, etc. Server people don’t deal with these issues every day; desktop people do.
• If you do need new people, get the right ones – and if you train internally first, then you have a much better shot at hiring better new people too. In this case, they might have been able to see that a server virtualization guy was not the right fit for their endpoint virtualization needs.
• Don’t get hung up on specific products or technologies – focus instead on solving problems. Endpoint virtualization is a continuum of technologies, each suited for different users and use cases. Understand that the best solutions may even involve multiple platforms, technologies, and even vendors.

This is a keen lesson on how to approach user-facing IT in general, and for endpoint virtualization in particular. Use your desktop expertise, supplemented with good training, and a deep understanding of your customer requirements, to focus on providing solutions to problems, rather than installing technologies and products.

[edited November 6, 2009 at 11:29:27 am - added link to EMA research]

In the report, I defined ‘Endpoint Virtualization’ as:

a (mostly) new set of technologies aimed at abstracting the end user experience – typically their logical desktop, application, and/or workspace environments – from the physical systems they rely on to provide that experience – typically a physical desktop or laptop PC.

This primary research covered many different technologies, including:

• Application Isolation – where an application is installed locally, but in a ‘bubble’, ‘sandbox’, or ‘layer’ that does not use the standard installation (e.g. VMware ThinApp, Novell ZENworks Application Virtualization)
• Remote Application Virtualization – where end users access a single-user application hosted on a remote/data-center system on the corporate LAN (e.g. Citrix XenApp, Microsoft App-V)
• Application or OS streaming – where an application or desktop OS is delivered incrementally from a remote/data-center system on the corporate LAN (e.g. Symantec Workspace Streaming, Endeavors)
• Remote (server-hosted) desktop virtualization – where a user accesses a full desktop environment from a remote/data-center system on the corporate LAN (e.g. Quest vWorkspace, Citrix XenDesktop)
• Local (client-hosted) OS virtualization – where a user runs multiple independent operating environment(s) locally on top of their standard operating system (e.g. MokaFive, VMware Fusion)
• Client-Side Hypervisor – where a user runs multiple independent operating environment(s) locally directly on the BIOS, without an underlying operating system (e.g. Virtual Computer NxTop, Neocleus)
• Browser-based applications – applications hosted on a corporate Web server, accessed over the LAN via a Web browser, with little or no local code installation (typically custom or in-house)
• Software-as-a-Service (SaaS) – individual applications hosted by a third party, accessed over the Internet via a Web browser, with little or no local code installation (e.g. Salesforce.com, PingConnect)
• Desktop-as-a-Service (DaaS) – entire end-user desktop environments hosted by a third party, accessed over the public Internet, with little or no local code (e.g. Desktone, Doyenz)

What I did not explain, and what a number of people have asked me since, is “Why does EMA use the term ‘Endpoint Virtualization’?”

A number of terms have been used by various analysts, media,  vendors, and users to describe this space. However, I don’t think anyone is looking at or defining the same breadth of the market as EMA and I do. Given the research data that showed these technologies were barely separable in real world use cases, I needed a a single term that covered all of them.

My  first thought (that I used in all the drafts of this report) was ‘end-user-facing virtualization’. While accurate and descriptive, it is too cumbersome to be usable, so I always knew that was going to be replaced.

I also rejected all the other terms I have seen for various reasons:

• Desktop virtualization, application virtualization – both too narrow for the broad space I was researching, with each excluding the other
• Client virtualization – the legacy of ‘client-server’, common usage of ‘client’ to mean ‘customer’, and lack of breadth killed this for me
• Presentation virtualization -  only describes remote delivery, so excludes local virtualization, SaaS, browser apps, etc.
• User virtualization – does not work for me at all, because I think of users as people, not technologies
• Workspace virtualization – too specific to desktop virtualization, plus a ‘workspace’ is anything from a cubicle to a bench with a drill-press

What’s more, the end user experience is more than just desktops and laptops. VMware CTO Stephen Herrod spoke at VM Forum Sydney (my home town) about VMware on Android, and VMware desktop CTO Scott Davis has been talking Android on his blog too. Similarly, Citrix’s CEO Mark Templeton demonstrated Citrix Receiver for iPhone as far back as May 2009**.

So I looked at the term ‘endpoint’, a term used commonly in IT management, and by many different vendors, in phrases such as in ‘endpoint management’, ‘endpoint security’, ‘endpoint encryption’, ‘data endpoint’, ‘endpoint provisioning’, etc. By most definitions, ‘endpoint’ accommodates all the ways the computing experiences can be made available to, and used by, an end user – including PCs, Macs, desktops, laptops, & mobile devices; centralized or Internet-based delivery mechanisms as well as local implementations; full desktop operating systemsor just individual applications; and both online or offline use cases.

Thus, I settled on ‘Endpoint Virtualization’ as EMA’s standard term for these various technologies.

Will it hold up over time? Will an irresistible groundswell form behind some other term that will force me to change? It is hard to tell, and I am certainly interested in your opinions. For now though, I think this is the best possible term, and will continue to use it throughout my writings and presentations with EMA.

Andi.

** Off-topic – what is it with vendor C-level elites targeting edge platforms like Android and iPhone? Seems to me it would be more useful if they targeted the enterprise-friendly mobile platforms that more real business users work on – like Blackberry or Windows Mobile. But that is a rant for another time