Why rPath?

I have received several requests lately to comment on the relative strengths of the rPath platform as compared with other alternative approaches to delivering an appliance experience. In particular, I have been asked to contrast the rPath approach with Solaris, BSD, and Ubuntu/Debian/Red Hat/SuSE/Mandriva/(pick your favorite Linux and insert it here) Linux. I will throw Windows into the mix as well because many of the same arguments apply.

If you are going to deliver an appliance-like experience for your application, you must deliver all of the infrastructure for the customer to receive AND use the application without any of the typical hassles of installation, integration, maintenance, and administration. That means that you need to engineer a solution that eliminates all of the complexity of these hassles throughout the lifecycle of the application. Engineering that lifecycle capability can be very expensive, or it can be very cheap depending on the decisions you make regarding your platform. Let's take each element of the solution and comment on the capability of each platform.

Hardware

Solaris – if you choose Solaris on SPARC your hardware will be expensive. Perhaps you can get a deal on the first shipments, but if you are successful your hardware will be costly. If you engineer a solution that is tightly integrated with Solaris on SPARC, your switching costs to another platform will be high. The Sun sales team knows that high switching costs means NO DISCOUNTS. If you choose Solaris on X86, your hardware will be expensive for the same reason. No X86 hardware vendor but Sun works hard to assure that Solaris works well on their servers. It might work, but it might not. You will be shipping Sun hardware, and you will be paying more than you should.

BSD – if you choose BSD, your hardware choices will be better than Solaris, but you will spend more engineering cycles in validation and test. BSD does not generally have the large community of development that benefits Linux, so you will have to augment those efforts if you want significant hardware flexibility.

Linux – all of the Linux platforms will enable good driver support for X86 hardware.

Windows – Windows has the best driver support because it is the leading platform for X86.

rPath – rPath benefits from the very good driver support provided by Linux.


Installation

Solaris – Sun does not provide an installation toolkit suitable for an integrated installation of the system software and your application on hardware or within a virtualized environment. By choosing Solaris, you have already marginalized your hardware choices, and lack of installation technology just adds insult to injury when it comes to flexibility of hardware partners.

BSD – Like Sun, no real installation toolkit is available.

Linux – There are various utilities for unattended installation, but none of them is very robust nor do they provide for the configuration of the application as part of a unified installation process. If you choose Linux without rPath, you will likely settle on a single hardware platform. Switching hardware platforms will entail some incremental engineering effort - limiting flexibility in choosing hardware partners.

Windows – Microsoft does not provide any scriptable installation technology for an appliance experience, to my knowledge. They have announced 9 “server core” roles that enable specific functionality to be installed for Microsoft applications, but nothing has been announced to extend that capability to third parties. Switching hardware platforms will entail some incremental engineering - limiting flexibility in choosing hardware partners.

rPath – rPath provides installation technology that allows the application vendor to configure and brand the installation experience to be specific to the needs of the application. Installation technology is provided both for standard X86 server hardware as well as for the various hypervisors (VMware, Xen, etc.). This capability is a core competency of rPath because it provides our ISV customers with the greatest platform flexibility in delivering their application to their customers. Flexibility in choosing hardware partners is important because it gives the ISV choices for go to market strategy. A great partner in North America may not be suitable for delivering appliances in Europe. You may want to provide the customer with the ability to install the appliance on server hardware they prefer. And while hypervisor support may not seem important now, the rise of virtual appliances is inevitable. Engineering support for each hypervisor spec and for every “cloud” computer such as Amazon's EC2 will be an expensive proposition for application companies in the future. rPath eliminates these expenses by providing systematic support for all of the hypervisors and “cloud” computers.


Integration

Solaris – packaging technology for Solaris is non-existent. You will be on your own figuring out how to systematically build and maintain your tailored appliance image.

BSD – same situation as Solaris.

Linux – there are essentially 2 competing package standards that Linux projects use to create and maintain a general purpose OS release – rpm and dpkg. Both are reasonably well supported with a community of development, but neither make it easy to maintain an application specific system image. Because they were engineered to support a general purpose OS, they are both unwieldy and inflexible as platforms for integrating applications with the various system software components required for a complete appliance experience. See the Zimbra whitepaper for a comparison of standard Linux packaging vs. the rPath approach.

Windows – same situation as Solaris.

rPath – rPath's platform was engineered to support the integration of applications with just enough OS (JeOS or “juice”) to support the application. It is designed to enable the application vendor to integrate (or “package”) their application in a manner that eliminates integration hassles for the customer while also eliminating those hassles for the application vendor. Additionally, rPath provides a brandable web interface for the customer to use in configuring the application on first boot. All of the “knobs” the customer needs to “turn” to setup the application are available in the web interface. No complex, command line actions are required by the customer – ever.


Maintenance

Solaris – Sun provides an engineered maintenance stream for Solaris, but due to the lack of packaging technology (see above), Solaris maintenance will be difficult. Sun provides very little infrastructure for delivering maintenance to the ISV customer base with an appliance type experience. It is all command lines and complexity. It seems that they are planning to change it to something they describe as a network packaging system that might be more similar to rPath, but we will need to wait several months to understand what that means. And then wait several more months or years for it to be a stable, production quality product.

BSD – same situation as Solaris but without the support of a vendor.

Linux – there are a number of utilities for Linux maintenance that are associated with the various packaging technologies listed above. There is the Yellow Dog Updater (yup), the Yellow Dog Updater Modified (yum, which Red Hat uses), apt (Debian and Ubuntu), as well as commercial offerings from Red Hat and SuSE. Unfortunately, none of these is engineered to make it simple for the ISV to provide their customers with a maintenance stream that is tested and released by the ISV. They are all geared at providing general, broadcast updates to the end user base for the general purpose OS. In many cases, the maintenance is not even required by any particular application, but simply serves to keep various utilities associated with the OS secure and bug-free. The burden of maintaining a general purpose OS can be a significant one, independent of the applications running on the OS, because the OS is so bulky and bloated.

Windows – Microsoft provides a utility for receiving updates, but they do not allow the ISV to control the promotion of those updates to the customer. If an update is unnecessary, or even harmful to the application, that is simply the price you pay to receive the value of the Microsoft platform. Microsoft determines what is needed for the OS, and the applications must simply deal with the consequences. And, like general purpose implementations of Linux, the OS requires a large amount of maintenance work because it is so bulky and bloated.

rPath – rPath provides the technology and the process for an appliance-like maintenance experience. Since there is only JeOS to support the application, the maintenance requirement is reduced by an order of magnitude as compared to a general purpose OS. rPath also promotes all maintenance to the ISV instead of broadcasting it to the end customer. The ISV then manages the release of system software maintenance in coordination with application maintenance to minimize unnecessary disruptions at the customer site. Finally, rPath provides the infrastructure for maintenance delivery and installation - both the customer facing web interface (branded by the ISV) as well as the server infrastructure the ISV uses to authenticate maintenance requests and deliver the maintenance payload. rPath also provides for a robust logging and rollback capability in the very unusual circumstance that a tested, certified update goes awry. None of the other platforms offer this capability.


Administration

Solaris – Sun does not provide an appliance specific, web based user interface for Solaris and applications that might be attached to it. Sun provides great utilities for managing an operating system, but most of the functions provided by these utilities are completely unnecessary for an appliance experience. The ISV is on their own to engineer an appropriate web based administration interface.

BSD – Same situation as Solaris.

Linux – Same situation as Solaris.

Windows - Same situation as Solaris.

rPath – rPath provides a scriptable, brandable web interface to the ISV for use by the customer to configure and administer the appliance. Configuration utilities for backup, networking, user management, maintenance, and license management are all included. rPath also provides professional services to write the application specific configuration utilities, or the ISV can write those modules using the documentation provided by rPath. In either case, it is simple for the ISV to provide their customers with a simple experience for administering their application.

In summary, none of the other alternative appliance platforms has been engineered to support an ISV in delivering an appliance experience. They are all engineered as one-size-fits-all, general purpose operating systems, which are difficult to conform to the needs of a specific application. Further, because of the one-size-fits-all engineering, they are all bloated and bulky. This bloating yields inefficient application performance and creates a significant incremental maintenance burden. Until these platforms are significantly re-tooled to acknowledge the appliance market requirements, rPath is the only efficient approach for delivering an appliance experience.