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 'VM Stall' A Stop Sign for Virtualization?

There appears to be a challenger to ‘VM sprawl’ as the scourge of virtualization success – a problem I call ‘VM stall’.

We know about ‘VM sprawl’ – because new virtual machines are so easy to deploy, organizations can end up with more VMs that they can handle, or even use. This has the potential to cause severe problems to availability, performance, compliance, costs, security, and more.

However, I am seeing more and more evidence of this new phenomenon I think of as ‘VM stall’ – the tendency for virtualization deployments to stall once the ‘low-hanging fruit’ has been converted (typically around 20-30% of servers).

I think it happens more or less like this…

In general, organizations start virtualization deployments by converting relatively low-risk, low-impact systems – dev/test servers, Web servers, file servers, internal applications, etc. – to virtualization. With a big impact, great results, and reasonably fast and easy implementation, it is a great hit with IT and business owners. This may even spawn a ‘virtual first’ initiative, where all new server requests are deployed as virtual servers by default.

However, when faced with the next step, converting the remaining existing servers – including tier 1 business services, customer-facing environments, enterprise-wide systems, 3^rd-party applications, multi-platform services, and composite applications – virtualization projects often stall.

I was interested to see the notion of VM stall confirmed again last week (courtesy of eWeek via @JSchroed) in some new research into virtualization (PDF) coming out of Prism Microsystems, a software vendor in the SIEM market.*

One of the most interesting outcomes in this research was again the low penetration of server virtualization within each organization. As the chart below shows, most organizations have still virtualized less than a third of their production servers.

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

What’s more, fully 15% have not even started to virtualize their production servers at all!

It might seem that this is really at odds with ‘the common wisdom’ that sees virtualization as mature, ubiquitous, commoditized, and even passé. We hear so much about virtualization, how it has been a top priority for years, about how everyone is deploying virtualization. For example:

• The IBM Global CIO Study 2009 in September showed 76% of 2500 global CIOs are undergoing or planning virtualization projects
• The Gartner 2010 CIO Survey in January reported that virtualization is the top priority for over 1500 global CIOs (up from number 3 the previous year).
• In January, CDW’s Server Virtualization Life Cycle Report (registration required) found that 90% of respondents have implemented server virtualization at some level.
• As far back as 2008, EMA research showed 75% of enterprises were using virtualization for production use cases
• The Prism Microsystems report the chart above comes from states that 85% of their sample have adopted virtualization to some degree

I am even starting to hear that virtualization is set to be irrelevant, becoming nothing more than just a stepping stone to cloud.

However, despite the widespread adoption of virtualization as a percentage of organizations, it is consistently still very low as a percentage of production servers.

Indeed, this is not the only recent (and not so recent) research study to highlight this issue. Over time, CIOs have reported a persistent difficulty in expanding their virtualization deployments beyond the initial 20-30% of servers. For example:

• Around 6 months ago, Gartner reported that “only 16 percent of workloads are running in virtual machines today.”
• Research from EMA has found that the average organization has only virtualized around 25% of servers (and only retired just 17%).
• The CDW Server Virtualization Life Cycle Report cited above showed that just 34% of the average organization’s total server infrastructure consists of virtualized servers
• CIO and HP survey in October 2009 reported that on average just 38% of mission-critical business services have been virtualized by companies with virtualization projects
• Forrester Research from May this year (conducted for CA) shows that the average enterprise has virtualized only around 30% of their servers.

At a time when so many organizations are experiencing VM sprawl, it seems hard to believe that VM stall is such an issue. Yet time and again we see that organizations find it difficult to ‘get over the hump’ of the initial 20-30% of servers, and difficult to move from low-risk/low-impact servers to high-risk/high-impact services.

If this were just a point-in-time observation, then VM stall might not exist. The low penetration rate may just be a point in the deployment cycle. However, VM stall appears to be a longitudinal effect, as it has been holding many deployments at around 20-30% of servers for several years. IIRC, something resembling VM stall was cited as an issue in EMA research as far back as 2008, and again in 2009. The CDW virtualization lifecycle research also reinforces the potential for long-term VM stall. In it, even organizations that self-report as “fully deployed” for server virtualization have only virtualized 37% of their servers. So while many organizations see VM stall as a short-term delay to virtualization rollout, many others are seeing VM stall as a permanent situation.

I see many possible causes for VM stall. For example:

• Risk aversion – high-risk, high-impact services have more stakeholders, more politics, larger and more distributed infrastructures, greater cost of failure and downtime, reduced or non-existent 3^rd-party support, and maximum management attention, among many other risk factors. The risk of failure may be too great, and the newest technology is always blamed for any new problems. Without new ways to address continuity, availability, performance, cost allocation, and other business requirements, conversion risk may be enough to stall virtualization deployment.
• Resourcing – with around 20-30% of servers converted, virtualization staffing starts to become a real challenge. As I talked about recently with my great mate, David Marshall, staff and skills shortages put a real throttle on virtualization deployments, especially as virtualization starts to scale. Not only is demand for virtualization skills still high, but supply continues to lag. Plus, the problem is getting worse, not better. Without the resources and skills to go forward, there is often little alternative to VM stall.
• Scalability – with one (typically small) team trying to manage a quarter of the entire server workload, staff from the virtualization project team simply cannot handle further virtualization deployment. In some cases, the virtualization technology itself does not scale well either; and in others, the management tools do not scale. Throwing more bodies at the problem is rarely the answer – after all, nine women cannot make a baby in one month. So organizations end up with VM stall almost by default, as they find that they need to fundamentally change their processes and technologies to enable further virtualization growth.
• Manageability – new IT management issues come up as the scale and risk of virtualization deployment increases. Enterprise virtualization needs new approaches to performance assurance, process automation, VM mobility, continuity planning, security and audit, software compliance, OEM support, configuration compliance, and more. The importance of manageability is greatly magnified  for high-risk/high-impact services, but few (if any) organizations seem to have the virtualization-aware management tools to scale to handle enterprise-class virtualization deployments. Again, VM stall happens almost by default, as IT tries to figure out enterprise-class manageability.

There may be more or different causes, but whatever the reasons, there is little doubt in my mind that VM stall exists. It is not universal – indeed, every study shows that a decent percentage of organizations are able to power through it – but for the majority of organizations, it appears to be very real. I have personally seen many enterprises going through it. More and more research continues to support it. For affected organizations, it is a significant problem, too, because stalled virtualization deployment means the highly desirable outcomes of virtualization – OpEx reduction, improved continuity, greater IT and business agility, energy cost reduction, ROI, etc. – either stalls as well, or even starts to backslide.

Whether VM stall represents as big a problem as VM sprawl, time will tell; but it is certainly a significant and growing challenge to the success of virtualization – and a fundamental driver for better virtualization management.

(EDIT: This article has been picked up and published on CIO.com! Join in the discussion there, or here.)

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.

Good for them!

What I liked most was that they are trying to break down the barriers between systems and security management. Certainly this is something that I discuss regularly with enterprises – the need to stop focusing on silo-based management, and perhaps even more importantly, to stop pandering to silo-focused low-level managers. Almost all of the CIOs, VPs, and IT Directors who I talk with are critically aware of the problems these silos cause – including human errors, resource inefficiencies, security problems, and higher costs.

This is also a constant discussion I have within EMA, especially with the lead of our security practice, Scott Crawford – a brilliant mind on security (amongst many other subjects) who constantly thinks about security in ways I never could or would. We work and publish together on this topic frequently. Indeed, it has come up again in our latest research, which shows that security and risk management are a fundamental requirement for cloud computing – or what EMA calls the ‘Responsible Cloud’.

The upshot of all these conversations is simple – security management and systems management are not, cannot, and should not be completely separate. Not in human terms, not in processes, and not in technologies. Without doubt, anyone in a large enterprise who has ever tried to implement a patch, a configuration change, a firewall update, a software release, or a hundred other data center changes will attest to this in a heartbeat.

Of course (as Scott rightly pointed out when I last spoke with him about this), we will always need security experts, and systems experts – the two disciplines are not the same, and we will always need deep domain expertise in each. So I am not advocating complete convergence. But we need more software tools that provide integration and interoperability that allow these professional to work more effectively together.

While multi-function vendors like CA, Symantec, IBM, and others have the product portfolio to approach these cross-silo problems holistically, there are few ‘best of breed’ vendors thinking this way. Of course, Tripwire and the ever-inspiring Gene Kim (who I have sadly never met) spring to mind for me; so would Configuresoft (although now as part of EMC Ionix, hardly a niche vendor), and the indefatigable Dennis Moreau. Both inspire their teams, technologies, and customers by championing a fundamental understanding that systems and security cannot, at their heart, be completely separated.

(As an aside, these two seem like they would have been incredibly compelling arch-enemies in some ubergeek superhero genre – although I would never want to choose which should be the hero and which the villain!)

I must say that, so far at least, I don’t know the product design team from Reflex personally – guys like Hezi Moore, Aaron Bawcom, and Mike Wronski – as well as I do Dennis or Gene. However, I do know that they all have very credible security chops. Plus, one thing is clear to me.

They get it. They really get it.

And that in itself is a thing of rare beauty.

Deliberately designing functionality that addresses both security and systems management – like functional isolation, integrated access control, change segregation, granular audit trails, policy based management, and role-based access – into a systems management toolset is a rare feat, especially in startup and niche products. It is something I look for all the time, because my enterprise clients often demand it. Sadly, all too often I fail to find it – and I am not even a real security wonk! When I do, I am pleasantly surprised. When I see deep thought going into the security value of a systems management product, I am almost ecstatic.

Unfortunately, the challenge for vendors like Reflex and Tripwire (as it was for Configuresoft, and perhaps is still for EMC, Symantec, etc.) is to find customers that value this synergy. While most high-level IT execs understand this imperative, their holistic view frequently does not translate to many of their lower-level managers, or to many functional IT practitioners.

Of course, there are plenty of departmental ops managers and security managers who do get it. They strive to connect their teams with other groups, driving greater business efficiency and effectiveness as a result. However, unfortunately, many do not, instead focusing on protecting their small empires, walling themselves off from integrated management and cross-functional resourcing.

Similarly, many positive-minded individual technicians will actively seek out cross-skilling opportunities, recognizing that it makes them not just more useful but also more valuable, and more indispensable. However, many practitioners (both security and ops) can be just as bad as the most myopic managers (who they often work for), dogmatically eschewing integrated management tools and processes, seeing them as threats to their own personal domains of control.

Sad but true, best practices like breaking down IT management silos are not always adopted.

Fortunately, vendors like Reflex and Tripwire that have expertise and passion in both ops and security (and – shameless plug – trusted advisors like EMA, which is big enough to have experts in both disciplines, yet small enough that we still work together), are trying to break down these barriers.

And more power to them. They serve their clients much better by promoting the undeniable facts that security values are critical to systems management, and systems management is critical to security.

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.

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.