There are literally dozens of potential angles to what I heard during my two days at VMWorld. But the most compelling story line as far as I’m concerned was the “virtual appliance” notion, challenging as it does some long held ideas of the operating system’s essential role, how application stacks are built and so on.
Before we get to the “virtual” appliance, it’s worth doing a bit of definitional work on the plain ol’ appliance. Wikipedia’s got a predictably comprehensive description here, but the relevant bit for our purposes is this:
Traditionally, all computing functions were written as software applications running on top of a general-purpose operating system. The consumer (whether home computer user or the IT department of a company) bought a computer, installed the operating system or configured a pre-installed operating system, and then installed one or more applications on top of the operating system. An e-mail server was just an e-mail application running on top of Linux, Unix, Microsoft Windows, or some other opearting system, on a computer that was not designed specifically for that application.
Specialized applications have recently started to use a different model. Instead of installing firewall software on top of a general purpose computer/operating system, the engineers have built computers that are designed specifically for the task.
An appliance, in other words, is a purpose built, pre-integrated system that rather than an assembled collection of piece parts.
Most of us rely to some degree on appliances, even if they’re not recognized as such. The wireless access point in your home, as an example, is an appliance. As is your Tivo. And the various firewalls, routers, switches and so on that your ISP uses to provide you with internet access (probably, anyway).
The concept, in other words, isn’t terribly new. It’s been with us for a while now.
What is (arguably) new is their relevance to mainstream application categories. Take Greenplum’s Thumper based data warehousing appliance, for example.
Greenplum writes an interesting business intelligence (and scalability) focused Postgres derivative in Bizgres MPP, while Sun cooks up a curious hybrid storage server device now known as the X4500 (neé Thumper). Some time subsequently Jonathan Schwartz and Scott Yara connect, conclude that it’s a chocolate/peanut butter scenario, and boom – an appliance is born. Customers purchase a preintegrated combination of the two, saving them the effort of marrying them after the fact. Two other items worth pulling out of this combination:
- First, that this appliance is in fact competing with other specialized appliances, as Farber notes, “Greenplum CEO Scott Yara told me that general purpose computing, as in the Sun Fire 4500 (Solaris, AMD Opteron, ZFS), is going to replace special purpose machines with custom ASICs, operating systems and interconnects.”
- Second, the collection of integrated piece parts become secondary to the appliance itself. In other words, questions of operating systems and such are often assumed to be unimportant, because they are not the primary focus of the customer.
I use the word assumed above, as you probably have guessed, to indicate my skepticism with the assumption in question. But we’ll come back to that.
In the meantime, it’s worth considering the advantages and tradeoffs that the appliance decision involves. Far and away the most important advantage appliances offer is convenience; customers don’t have to integrate anything, as that work has already been done for them. For an industry that is increasingly solution focused, this is a real differentiator. Appliances can also offer a variety of performance and scalability benefits, as the various components are often not only preintegrated but specifically tuned and configured for one another.
In return for these benefits, however, customers are asked to make certain sacrifices. More often than not, the ability to substitute individual components for one another – such as RHEL for Solaris in the case of the Greenplum example – is absent. Configuration options and choices are typically throttled as well. Flexibility and choice, therefore, are generally not considered strengths of appliance based approaches, which is a possible explanation for why they’ve been successful in some areas (e.g. networking) and dramatically less so in others (e.g. packaged applications).
At the VMWorld show this week, VMWare touted an even more aggressive (and controversial, if the press/analyst Q&A is anything to judge by) appliance strategy with its Virtual Appliance marketplace. In simple terms, a virtual appliance is “stack” of software that essentially precombines (and preconfigures) pieces such as the operating system and application software together, and is deployed as an instance atop the virtualization layer. Zimbra’s CEO, Satish Dharmaraj, touted the benefits described their virtual appliance on stage at the event, saying that “virtual appliances bring not just hardware independence, but location indepedence as well.”
As with their more traditional counterparts, virtual appliances bring a number of advantages. Take, for example, Zimbra. While the product is certainly very capable, it’s decidedly non-trivial to setup and configure. With a virtual appliance, you essentially obtain and deploy the Zimbra stack, feed it an IP and some other very basic configuration information and you’re off to the races. Sounds good, no?
Unfortunately this convenience does not come without a cost. As described in several of the sessions at VMWorld, the very notion of a virtual appliance blurs heavily the line between application and operating system. VMWare was, to a person, very up front about the more limited role that operating systems play in the virtual appliance world. Their contention is simple: general purpose operating systems are designed to handle a number of tasks, but only some of these are applicable in the context of a virtualized environment. Why bother including the hardware support in your operating system layer, they ask, if the application is being deployed to a virtualized environment? They propose instead that application vendors create and deliver as part of their appliance operating system layers that include only what they need.
From an engineering perspective, this has an undeniable appeal: it’s simplicity taken to a whole new level. What I’m wondering about is how this will work in practice. The approach makes several critical assumptions, any of which are by themselves sufficient to raise questions:
- That the application vendor has enough operating system expertise to know how effectively deliver a scalable and secure operating environment
- That the application vendor will be able to effectively support not only their application but the operating environment
- That the application vendor will be able to not only support the application and operating environment, but effectively manage it (patch it, update it) and so on indefinitely
- That customers will trust application vendors to provide what is effectively both operating system and application support
- That customers are comfortable running what effectively becomes a different operating system per virtual appliance instance
- That customers are willing and able to deal with the licensing and pricing complexity that ensues (are you running a full instance of an OS? if so, who are you paying for support? if not, does the application vendor charge more because they are delivering and managing support for a stack rather than just application? and so on)
Ian shares some of my skepticism, although his comments are more on virtualization generally as opposed to appliances specifically.
It’s also worth mentioning that the notion is somewhat biased against Windows as an operating system. While it’s possible for virtual appliance purveyors to run full instances of operating systems, that doesn’t seem to be what VMWare has in mind – they clearly view the advantages of the virtual appliance being rooted not only in the convenience derived from precombining the application with the platform it runs on, but selectively building the platform with only what’s required. Windows, as many of you know, is not composable in this fashion; vendors do not have the ability to rip apart the operating system and include only the pieces they want. VMWare admitted as much, saying that Linux was far and away the predominant choice for the virtual appliances they have on hand currently.
While much of the above may be seen as dismissive of the potential for virtual appliances, that’s only partially true. For some of the reasons cited above, I am indeed skeptical of the opportunities for mainstream acceptance of virtual appliances in the short term. Essentially, I think they raise more questions than they answer, at least at the present time. Will they find opportunities in niche areas, such as SMBs or application categories that are relatively single purpose and don’t require a great deal in the way of customization or configuration? It seems probable. But I expect the appetite for them in a mainstream capacity to be similar to what it was for virtualization more generally several years ago: there, but not overwhelming. I have yet to speak with potential customers, however, so mark this conclusion as pending further review.
In the big picture, however, enterprises are going to have increasingly consider questions of appliances, both virtual and otherwise, and determine where they can and should be embraced, and where they represent a bad fit. These questions will depend – as they always do – on what you need, what your comfort levels are, and what your resources might be. The trend towards virtualization is, in my book, quite clear: it’s an increasingly important part of enterprise roadmaps and strategic directions. The trend towards appliances – virtual or otherwise – is less obvious from where I’m sitting.
Underlying these discussions is, of course, the operating system. While virtualization can, in many cases, disintermediate the operating system the virtualization software itself has to run on an operating system of some sort. Appliances, likewise, have the ability to change perceptions of what the role of an operating system is within the context of application delivery.
But it is still apparent to me that whether it’s on a traditional or virtual appliance basis, the operating system still matters. Not only for some of the reasons raised above, but because appliances vendors will ultimately choose or decide against operating systems on the basis of what they offer. Or don’t. In other words, though the words may change, the song remains the same. I’m very curious to hear what you all think of this, particularly if you’re actively considering appliances.
Disclaimer: Greenplum and Sun are RedMonk customers, while Microsoft, VMWare, and Zimbra are not.
