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.

There is a growing chatter about the idea that businesses should provide staff with a free choice of PC technology (including Windows, Mac, Linux, or other devices), and indeed that staff should be given a cash allowance (at Citrix, for example, the allowance is $2100) to purchase and use their own PC for company and personal use.

Many claims are made to support this so called Bring Your Own PC (BYOPC) approach – although they seem mostly, if not only, to originate from vendors (notably desktop virtualization and application virtualization vendors) that have a vested commercial interest in its success. I disagree with many of these claims (especially the questionable claims of cost reduction), but I do agree that BYOPC can have some benefits.

However, one of the many claims in support of BYOPC is that it will help organizations to attract and retain an important demographic of young, technologically sophisticated employees – the so-called ‘millennials’,  ‘echo boomers’, ‘generation next’, or ‘generation Y’, all loose terms generally used to describe people aged between 18 and 35 years old.

Personally, I find this claim to be absurd.

My main issue with this claim is the implicit assumption that millennials have such a strong choice in their employment options that issues like what type of operating system they use, or what device they work on, can be significant decision factors in whether or not to accept a job offer.

This flies in the face of unemployment statistics that suggest, today more than ever, millennials simply do not have this level of choice. Put plainly, in the near term millennials should be happy to simply get a job offer, let alone one that comes with over $2000 to buy themselves a shiny new MacBook Air.

Specifically, data from the US Bureau of Labor Statistics (see chart below) shows that in fourth quarter of 2009, unemployment for 18-35 year olds was on average 17%. For males specifically, this was on average 25%, and as high as 30%  (for males, 18-19 y.o). Compare this to the national average for ages 35 and above – 8% for the general population, and 9% for males – and you can see that this demographic does not exactly have abundant bargaining power on the job market.

Unemployment by age, sex, marital status 2006-2009 (Source: BLS)

Perhaps this will change over time, but as the chart above shows, unemployment for millennials has been trending up, not just since the onset of the recession around the end of 2008, but at least since 2006. It may (and hopefully will) come down dramatically, improving millenials’ bargaining power for employment,  but there is no sign that this is happening, or that it will happen anytime soon. And remember, when we are looking at BYOPC it is not only for technology workers,  but also (perhaps primarily) for knowledge workers across many fields – sales, finance, management, R&D, etc. – so any specific skill shortages in IT that may skew millennials’ bargaining power do not really come into play.

Of course, there are probably nuances here that a behavioural statistician would find and explain much better than I can – granular variations by  age, education, location, industry, and more. For example, unemployment among slightly older millennials aged 25 to 34,  many of whom presumably have college degrees, is much lower than millennials aged 18 to 24. Yet at over 10% unemployment, even this group still has an unemployment rate several percentage points higher than ages 35 and up (just under 8%).

However, I do not see any promoters of BYOPC incorporating such detailed demographic analysis to substantiate their claims for BYOPC; rather, most seem to just be making unsubstantiated claims using baseless assumptions about millennials’ employment ‘needs’ without even considering widely available independent data that substantially undermines their position.

Sure, there are studies that suggest, for example, that millennials consider “state-of-the-art technology is an important consideration in selecting an employer.” However, the most credible of these studies was conducted prior to the global economic downturn, when unemployment among 18-35 year olds was just 9-10% – almost half what it is today. In any case, an organization does not need a BYOPC program simply to provide state-of-the-art technology. If an employer gives a millennial employee a top-of-the-line company-owned Dell, HP, Lenovo, Sony, or Apple laptop, would they turn the job down just because they cannot buy it themselves?

So based on a cursory analysis of recent, credible, and available data, the idea that a young person would turn down a job in this economic climate, simply because they can’t get their preferred laptop or mobile device seems to me quite ridiculous. At best, it may help companies attract the very top tier of millennial graduates who do have multiple job offers to choose from, but I expect this would still be the least of the considerations of 18-35 year olds. Even for the best of them, this likely pales compared to significant concerns about compensation, vacation and holidays, health care, education support, flexible hours, corporate ethics, retirement funding, work-life balance, telecommuting, career opportunities, and more.

This then has significant implications for CIOs and others looking at BYOPC.  Despite the validity (or otherwise) of any other claims in favour of BYOPC, no organization should be looking to BYOPC to attract and retain staff from the echo boom generation. They would be better off looking at a dozen or more other important factors than spending the significant time, effort, and money on implementing a BYOPC program.

A couple of days ago, I was dropped into the middle of a sticky situation with one of my clients, a service provider of desktop systems – both physical and virtual (VMware and Citrix) – to schools across the country. This situation provides a great case study (or war story) of endpoint virtualization, especially the challenges that human issues pose to project success.

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]

Back in September 2009, EMA released a research report that I authored, titled Real World Experiences of Endpoint Virtualization*. In it, I defined and used a new term (for EMA), ‘Endpoint Virtualization’. 

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

I have to say – and I have said it before – I am not a great fan of the ‘virtual appliance’ model for delivering enterprise management software. Specifically, I have ongoing concerns about how these software appliances break compliance, security, and other important management and policy requirements.

For example:

• Virtual appliances add an unknown operating system to the environment. It is typically a slimmed-down Linux distro, but you rarely know – it could be DR-DOS 6.2 or a pirate copy of Windows ME. This breaks any software SOE, ignoring top level decisions on OS stability, reliability, longevity, security, etc.
• Administrators have virtually no control over virtual appliance management. Management functions are required for any software, but virtual appliances rely entirely on a middle-man for proper OS, middleware, application, and database patches & upgrades, malware detection, performance monitoring, problem analysis, etc.
• Even when ad hoc management is possible, it is almost always manual. You can’t put agents on most virtual appliances, they don’t come with WMI, and most have only a GUI for management. So you cannot use standard tools or automation, which wastes admins’ time, risks audit non-compliance, and invites human error.
• Security is a particular concern. Timeliness of patches, effectiveness of hardening processes, zero-day threat response, malware protection, and so on are all at the whim of the vendor, and rarely disclosed to the customer.
• You pretty much have to pay maintenance. If you don’t, chances are you simply cannot keep a virtual appliance up-to-date yourself.

Of course, many of the same criticisms can be slated against physical appliances. I have even talked with one enterprise that will not deploy even physical management appliances because they would break the company’s hardware SOE (even though network devices, storage systems, and other ‘boxes’ are often just purpose-built appliances). However, with just an Ethernet cable connecting them to the enterprise, and a generally slimmer system profile, they seem to pose a lesser risk. They are also much simpler than virtual appliances, which add (in many cases unnecessarily) a layer of complexity and abstraction that physical appliances do not, by virtue of being encapsulated within a virtual machine. Moreover, the resources and effort to build a ‘real’ appliance is far greater than just slapping some software into a virtual machine, so physical appliance vendors seem somehow more committed, more reliable.

Is this distinction fair? Possibly not. But regardless of my own concerns, my research has shown that virtual appliances are the least-preferred of any form factor for management software, with physical appliances, niche software, and even software suites more preferred. Really, when the dreaded ‘framework’ is more popular than you, perhaps you really are an ugly duckling.

Which is not to say that virtual appliances are pointless. They are easy to implement, provide fast time-to-value, and are especially good for trials and POCs. They require little or no tuning, and the OS environment is often a bare bones install which is fast and efficient. Unlike physical appliances, they are easily scalable, and highly mobile. They can be deployed in seconds (maybe minutes) even to far-flung locations in regional offices with zero travel time and cost. And they allow even a sysop to deploy a new management server without getting the network, storage, security, or server teams involved. All of these are powerful factors in their favour.

I am also seeing, despite their potential issues, that several vendors are being very successful selling virtual appliances. KACE, for example, told me today that 26% of their total sales in Q3’09 have been of their virtual appliance, the V-KBOX; VKernel provide all their software in virtual appliance formats, and their Q3’09 sales were 205% up on Q3’08; Citrix is finding a remarkable early demand for their Netscaler VPX virtual appliance.  Meanwhile, IBM, Symantec, up.time, Reflex, SourceFire, and several others are agressively in or entering the market for management systems delivered as virtual appliances.

I also think that virtual appliances have a bright future – but in some ways I continue to see them as a beta version of what could (or should) come next.  By adding in capabilities for responsible and accountable management, they could form the basis of more fully-functional virtual service management containers. These in turn could form the basis of elastic, mobile, network-deployed, responsible cloud appliances that deliver complete end-to-end service management without regard to physical location or domain of control.

A couple of vendors are clearly headed this way, but even without this level of sophistication and maturity,  it certainly seems like vendors and buyers are increasingly embracing virtual appliances, despite their many potential flaws.

Perhaps I should too?

Andi.