Big Appliances Vs. Virtual Pools

As the industry starts to move to fully-virtualized models, and cloud-like environments, I'm encountering a specific debate around IT philosophy.

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.

The Basics

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 ....



 

Comments

[Brainy]

...and at the same time you're selling DMX, V-MAX etc. "Big Storage Appliances"

[Chuck Hollis]

@Brainy

Not really, if you give it a moment's thought.

Storage arrays can be used for just about any information types, they are not designed to be used just with Oracle, or just with Exchange, or any other application type, unlike the big appliances described above.

Storage resources can be pooled across multiple application types. There's usually a consistent way to manage, protect, replicate, etc. independent of the application -- again, very much unlike the big appliances described here.

Sure, they're a heap of hardware with some firmware on it, but that's where the similarity ends, and the differences begin.

You know, you should think through your intended zingers, otherwise we'll need to call you "Impulsive" rather than "Brainy"!

-- Chuck

[shiningarts]

To be honest with you, I don’t like bundling or appliancing any thing. Software or hardware aside, my broadband ISP provider Cox Communication keeps calling me about bundling their telephone service on to Cox broadband. I told them I use my cell phone instead. In truth, I use VOIP vender Vonage for that purpose, but I am afraid of telling them because they might say VOIP is using their service and they want to charge for that extra.

Anyhow, appliances are basically a quick and dirty job to do things faster. They may be better in short term, but in long run, it stifles individual creativity and overall integration effort. Who it really benefits is the vendor, who locks the customer into the specific appliance vendor’s bundle for good because they know you are a sucker falls into their “bundlese” talk.

Or, otherwise, you can check the CNET analyst’s here:
http://news.cnet.com/8301-13556_3-10375877-61.html

[Brainy]

@Chuck

I might be impulsive sometimes, but consider this:

Your "big storage appliances":

-have to be managed differently than the rest of my systems
-run only what you want me to run on it (this makes it an appliance)

While the so called DIY-Storage Systems are probably not quite there yet (OpenFiler, FreeNAS etc.), they will be soon, and they will not be appliances, instead they are build on commodity software. Truly open for users to run anything on top of it.

Beside that, OpenStorage has already reached the point, where it starts to put pressure on "big storage appliances"-vendors.

[Chuck Hollis]

@Brainy

Interesting point of view. Not widely shared, but interesting.

How do you feel about network devices, such as switches, routers, etc.? Servers that boot into hypervisors? Home storage such as Iomega? Are all of those "bad" as well?

Look, I understand the point you're trying to make, but it's not really relevant. DIY software for storage has been around for many, many years with scant adoption.

Hasn't made much of dent in the market, doesn't look like it's going to anytime soon. But, I'll keep a open mind, as things can change.

-- Chuck

[Mike Campbell]

You have summarized some of the thoughts I have around this topic.

Here is my challenge though. If not the Oracle Exadata - what? How can I build something using dell, Cisco and EMC that will approach 1 mil IOPS? This is the reason I'm not able to influence towards a best of breed hardware solution internally at my company. The app folks are of the opinion that they need (and will need more of later)a machine that will allow for OLAP type jobs to run like scalded dogs. Exadata allows for DW workloads and the ability to collaspe other Oracle DB's down onto the box - justifing the TOC with these combined functions (teradata and other DW solutions can't do this).

VM is not the answer for everything...yet...what other options do I have that will meet the reqirement for these workloads or even approach it?

Mike

[Chuck Hollis]

Drop me an email at hollis (underscore) chuck (at) EMC (dot) com, and we'll chat. There are some interesting scenarios ...

-- Chuck