The question revolves which is better for IT: purpose-built appliances, or pools of generic resources that are dynamically used?
And it's turning out to be one of the more contentious issues going forward.
Any software needs hardware -- physical resources -- to run. An "appliance" in this context dictates the precise physical resources (as well as supporting software infrastructure) needed to run a given application title. Practically speaking, an appliance model usually dictates who you'll buy it from as well.
Appliances became popular with doing specific network functions within IT, e.g. firewall, spam control or something very specific.
But some vendors took the model "upmarket" so to speak.
Netezza, for example, made the big appliance model very popular in data warehousing. Today, Oracle is chasing it with various iterations of Exadata. Microsoft is starting to promote an appliance-like model for newer versions of Microsoft Exchange.
These big appliances are not cute and cuddly devices with a single power cord and a few status lights. Often they are sizable investments in dozens of processors and many terabytes of storage, and can easily go north of $500k or more. Basically, we're talking heavy metal here.My working definition of an appliance is "hardware architecture and component selection is explicitly and narrowly defined by the software vendor".
And, to be fair, I think the view is considerably different when considering small, single-purpose appliances as compared to the more recent "small data center in a box" variety.
The Case For Big Appliances
Software vendors that argue for these larger appliances can make a relatively appealing case, if one just looks at the positives.
If all you want is to get to application goodness, having to build out physical hardware infrastructure can get in the way of achieving the immediate business value you're looking for. You can "get to good" sooner with an appliance model, they would point out.
Software vendors claim that -- if they know precisely what they're running on -- they can tune and optimize their software for better performance.
Software vendors also claim they have a tough time supporting all the different variations of infrastructure software and hardware that are out there, raising support costs and making it more difficult to provide top-level support.
Besides, who wants to deal with all that physical stuff, when you can just plug in a box of application goodness, and be done with it?
The Case Against Big Appliances
It's not the first big appliance that causes the problem, it's when you have a fleet of them that you realize you've traded one class of headache for another.
None of them are built the same way. None of them manage the same way. None of them are supported the same way. None of them know how to work together in a cooperative fashion, and so on.
Going a bit deeper, big appliances are typically over-provisioned from a resource perspective -- you're buying far more compute, memory and perhaps storage that you'll probably never use. I look at the current Exadata, for example, and wonder just how often people will need its maximum theoretical crunch?
Want standardization at the different layers of an architectural stack? Sorry.
Want a pool of resources that can flow and flex to support whatever workload is at hand? Sorry, can't do.
Want to use the latest-greatest infrastructure technology from (choose your favorite vendor here)? Sorry about that as well.
You can see the nature of the tradeoff, can't you? It's basically trading immediate gratification for a specific project vs. creating long-term value through IT infrastructure.
And, depending on IT's relationship with the business, that can be a hard choice to make.
Who's Driving The Big Appliance Agenda?
Larger software vendors, primarily. They're the only ones with enough large-scale footprint to even make the case remotely attractive. The rest of the software vendor community has to largely accept the choices that IT makes for computing infrastructure.
However, that being said, many organizations have a large Oracle / Microsoft / DW footprint, so they'll listen carefully to the big appliance pitch -- as they should!
Full disclosure: EMC (and many other vendors) generally get locked out when a big appliance decision is made for a specific software application, unless -- of course -- the appliance is built with our technology, which is true in a few cases.
The Virtual Appliance?
VMware -- and a few other virtualization vendors -- have been promoting a hybridized appliance model for some time that makes certain sense.
Standardize at the virtualization level. Application vendor controls all the bits from the hypervisor up -- operating system, middleware, patch levels, config files, etc. etc. IT, in turn, is now responsible that the virtual machine gets enough resources to run adequately.
Nice way to split the difference, to my way of thinking.
Application vendors can provide that better support experience that's so important to them. They can optimize and control not only the pieces within the VM, but by providing recommendations for external resource usage.
IT gets to create shared pools of resources, rather than dedicated islands. A great degree of standardized orchestration and security can be achieved at the hypervisor level, allowing consistent operations across IT, and not tied into a specific big appliance model.
A Big Appliance For Virtual Appliances?
How about the other half the "big appliance" value proposition? You know, the accelerated time-to-value, one way of doing things, a better support experience, and so on?
Given that so much of the industry is standardizing on virtualization -- and specifically VMware -- it makes a certain sense to start thinking about the potential for big appliance-like infrastructure to support, well, virtual appliances. The idea would be to have pre-fab infrastructure that's designed to support vast, dynamic pools of resources all neatly running in virtual containers -- pre-integrated, standard operational and security model, one throat to choke, etc.
Will we see a best-of-both-worlds approach in the future?
More on that later ....