Subscribe: Comments on: Do Operating Systems Matter? Part 2: The Appliance Question
http://redmonk.com/sogrady/2006/11/10/do-operating-systems-matter-part-2-the-appliance-question/feed/
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
appliance virtual  appliance  appliances  application  don  linux  point  rpath linux  rpath  stack  system  talk rpath  virtual  zimbra 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Comments on: Do Operating Systems Matter? Part 2: The Appliance Question

Comments on: Do Operating Systems Matter? Part 2: The Appliance Question



because technology is just another ecosystem



Last Build Date: Mon, 13 Nov 2017 09:54:21 +0000

 



By: James

Sun, 26 Nov 2006 14:46:59 +0000

you should also followup with the likes of MBX, networkengines, and the hardware side as well.



By: stephen o'grady

Tue, 21 Nov 2006 22:03:41 +0000

Kevin: lots of folks are beginning to talk about rPath, and they were on my list to talk about this but ran out of time. will look at them in more detail shortly. and it's not that i don't understand the benefits from a user perspective - it's more than i don't think users properly appreciate the costs. Ian: i'm inclined to agree. i'll have more to say after i talk to rPath, and i don't think it's an unsolvable problem, but i do believe that this approach is going to create significant issues. Dick: well, i think the appliance vendors would instead say that the point is that the drivers actually aren't necessary in guest OSs b/c that's already handled by the host. whether or not you buy that is a matter of where you fall on appliances. the system management point here is an interesting one, however.



By: Dick Davies

Mon, 20 Nov 2006 12:55:31 +0000

This sounds like a step backwards to the days when all apps spoke to hardware directly. We replace 'apps scheduled by an OS kernel' with 'VM+OS+appstack scheduled by a hypervisor'. Each appstack effectively needs it's own drivers, network stack etc - some of this can be pushed down into the hv, but then that starts to look like a kernel again... Not that this is automatically bad thing, but it certainly says something about the sorry state of system management if this is saner than the status quo.



By: Ian Holsman

Sat, 11 Nov 2006 23:23:51 +0000

"That customers are comfortable running what effectively becomes a different operating system per virtual appliance instance" I think this is going to be a large problem personally. especially when it to security upgrades, and even knowing what your threat is. If appliance manufacturers could come up with a standard way of configuring and maintaining their appliances (physical or virtual) so operations staff can truly treat them like a black boxes It would be a big step forward. but for now, I (or a admin) still needs to have a in-depth knowledge of all the working parts inside a appliance, and the diversity that appliances bring will be devastating when it comes to time to maintain a system of them.



By: KevinH

Sat, 11 Nov 2006 05:27:07 +0000

The OS matters, but there are tools and options to make the job of an ISV who wants to build an appliance much easier. Take rPath for example. http://www.rpath.com At Zimbra we choose to build both our software appliance and virtual appliance based on rPath Linux. They provide a toolset(rBuilder/Conary) that allow you to extract the minimum required set of dependencies for your custom Linux distribution and application stack. The advantages of this for an application like Zimbra with a *thick* stack (40+ OSS dependencies) is that we eliminate many of the variables that come with installing on a traditional Linux distro - port conflicts, dependency problems, conflicting applications, SELinux/iptables/ipchain problems, etc. Basically you get a clean install base and can fully automate most of the install. So in your 1-6 above much of this load in our case is still on rPath since they are Linux OS experts and stand behind it. Since you've got a minimum Linux distro there is less to support. Updates for both the Linux stack and the application stack(Zimbra) are delivered from the Zimbra updates server. So the update story is even better than what we have for the traditional OS's. rPath Linux is mirrored from rPath and the Zimbra bits come from our internal build machines. To the end appliance it only sees and manages a single update connection. This single point of OS+application updates prevents a mis-match between OS and application bits. Still not convinced that an appliance virtual or software are not the right solution. You can try our 1st vmware appliance beta for yourself here: http://www.zimbra.com/vmware/