Appliance or Not Appliance

That's the question Xavier asks in his blog entry titled
Security: DIY or Plug’n'Play

To me the answer is simple, most of the appliances I ran into so far have no way of configuring them apart from the ugly webgui they ship with their device. That means that I can't integrate them with the configuration management framework I have in place for the rest of the infrastructure. There is no way to automatically modify e.g firewall rules together with the relocation of a service which does happen automatically, and there is always some kind of manual interaction required. Applicances tend to sit on a island, either stay un managed ( be honest when's the last time you upgraded the firmware of that terminal server ? ) , or take a lot of additional efort to manage manually. They require yet another set of tools than the set you are already using to manage your network.
They don't integrate with your backup strategy, and don't tell me they all come with perfect MIB's.

There's other arguments one could bring up against appliances, obviously people can spread fud about some organisation alledgedly paying people to put backdoors in certain operation systems.. so why would they not pay people to put backdoors in appliances , they don't even need to hide them in there .. but my main concern is manageability .. and only a web gui to manage the box to me just means that the vendor hates me and dooesn't want my business

A good Appliance (either security or other type) needs to provide me an API that I can use to configure it, in all other cases I prefer a DIY platform, as I can keep it in line with all my other tools, config mgmtn, deployment, upgrade strategies etc.

Mabye a last question for Xavier to finish my reply ... I`m wondering how Xavier thinks he kan achieve High-availability by using a Virtual environment for Virtual Appliances that are not cluster aware using the virtual environment. A fake comfortable feeling of higher availability , maybe.. but High Availability that I'd like to see.


Bart's picture

#1 Bart : This is overgeneralizing

This is overgeneralizing things a bit. Its not because something ships as an appliance, that it needs to have a stupid webgui only.

For example, all my routers, firewalls and switches can be managed through an API. So can my DNS and address management servers and even the load balancers. In fact, I've long wanted to implement something to keep this all in sync automagically. But that would cost time and sometimes monkeys are cheaper than scripts :)

Of course, the APIs are different. But then again, every single software application also uses a different syntax for their config files, which takes just as much work to implement.

On the subject of virtual appliances, there are two rather important details people tend to forget.
- Vmware HA/FT etc isn't the same as two appliances in HA. Vmware HA will only protect against host failure, if the virtual server crashes or needs to be rebooted, there will always be an outage.
- You need control over how the VMs are distributed across physical hosts. If both VMs are on the same machine and that blows up or some guy drops it from the 10th floor, the service is down. This used to be an issue on AWS and required ugly workarounds. This is not limited to appliances of course, it can happen to custom implementations as well.

The least managed is typically the physical hardware itself because honestly, when is the last time you upgraded the ilo/dracs in your servers, or the bios or any of the gazilion different firmwares they use nowadays?
I've seen outdated ILOs take down half a server farm because they responded badly to certain types of network traffic. Oops.

Oh, that and telephony systems. I hate those, but I think all network admins do :)

Vincent Van der Kussen's picture

#2 Vincent Van der Kussen : i don't like them

I don't particulary like appliances because I never get the feeling I fully understand how the application running on the appliance works. I prefer doing things myself.

I also see people using appliances to "quickly test" something with the danger that the VM "rolling" into production.

And of course you never know what other hidden "treasures" it has on board...

Xavier's picture

#3 Xavier : Hi Kris, Thanks for the

Hi Kris,

Thanks for the mention! At the end of my post I wrote that the choice of a solution must be performed by the owner/maintainer. But my own feeling is definitively the same as yours: I hate being restricted by vendors! If I pay for a product, it's my right to use it as *I* want. The look and interface of my iPhone are therefore the only reason why I still keep it! ;-)

To come back on your question regarding the high-availability, I was maybe not very clear. Depending on the virtual appliance purpose, I think you may rely on the high-availability provided by the virtual environment. Of course, only if it is itself fully redundant! An appliance providing authentication services could be perfectly relocated on a new virtual server without too much impact. A firewall or proxy will be more risky (risk of interrupted sessions etc...)

BTW, "Virtual appliance" do not mean they are not cluster aware. For me, it's a copy of the same software running on the default hardware.


R.I.Pienaar's picture

#4 R.I.Pienaar : Development cost

Apart from all the above I don't like them because it's hard for me to provide them to my developers, dyi in software means I can provide functional equivalents to devs even on their own machines in a VM.