rPath and Software Appliances

My chosen after lunch dessert at NGDC is another virtualization topic, this time presented by rPath. rPath provides a means for making software appliances and being able to distribute them. Software appliances attempt to address one of the growing problems in Linux which is the application certification issue. Specifically, a key customer problem today is that applications are often certified on a subset of all of the Linux distributions that are available. And, what is worse, is that different ISV's certify their applications on different distros, but customers expect to buy any application off the shelf and run on their chosen distribution. Alas, this is becoming less and less the case. I've been at a number of customer sites where the number one complaint was that their key applications were not certified against their chosen RHEL or SLES distribution. Or worse, some were running Debian, Ubuntu, or some other distro. At the core, the distros are very similar, and most applications will *probably* run. But, if they don't, the customer gets to keep all the broken pieces.

So, how do appliances help with this problem? Well, simply put, the encapsulate all of the key attributes, including potentially the operating system!, into a single image which can easily be distributed, loaded, and delivered to a system with a hypervisor, such as VMware ESX, Xen, etc.

Examples of appliances can be found on the rPath site, like this LAMP stack, for instance.

Erik points out a few problems with virtual machines, some of which are noted in the previous blog entry. This include the fact that proliferating virtual machines are just as painful to manage as physical machines, and managing things like security updates take the same amount of effort as managing physical machines. Also, hypervisors today have some dependencies on their operating systems if they are going to get the benefits of the leading edge para virtualization techniques and such. While those compatibility issues should fade away over time, that is at least a short term consideration. As a result, a virtual image's kernel may be build for interfaces to a given hypervisor (Xen is probably the worst in this space right now, but mainline kernel API's for domU guests went into mainline just recently and should start to show up in distros over the next year or so).

On the flip side, Erik pointed out how well Software Appliances fit in with the Software as a Service (SaaS) model that is becoming so popular. In short, it fits in very nicely - a software appliance is basically a software service. There are a lot of other advantages, such as the fact that a software appliance is easier to test (it is always the same stack, no matter where you install it), easier to support (stack is well known, all customers using the same appliance), and easier for teams to configure (again, all components are the same). Erik believe that Software Appliances are actually better than SaaS for a few simple reasons: there's no need to worry about multiple applications residing on the same OS - apps are isolated by a virtualization boundary; there is no internet latency - multiple apps/software appliances can reside on the same physical system; no remote/unsecured data; no significant data center infrastructure - software appliances are virtual.

Erik provided a pretty common sense list of best practices for creating software appliances that I won't re-iterate here but the guidelines are definitely useful - small, simple, easy to administer (no CLI, minimal to no configuration required), etc.

Something that Erik pointed out that I have not really looked at is Amazon's elastic compute cloud. It has the ability to auto-create and host software appliances. The rate is a mere ten cents an hour in US Dollars. He demonstrated the creation of a MediaWiki site in less than ten minutes from click, create, configure, use, system updates all based on a preconfigured software appliances. Definitely a pretty cool option.

In short, I think software appliances will be a major boon not just for the SMB market but even for large corporations who need to deploy anything from sandboxes to entire racks of new machines with their custom workload. Since most of these solutions require a virtualization layer/hypervisor in here somewhere, I believe this will provide a significant push for virtualization in leading edge datacenters as well.