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.

Intel Invests Heavily in the Future of Operating Systems - VMware

Intel and VMware announced today that Intel Capital is making a $218M pre-IPO investment in VMware. This investment would give Intel a 2.5% ownership stake in VMware, with a board seat, but no real voting rights whatsoever (less than 1%) relative to VMware's parent company, EMC. So why might Intel be making such a significant investment in VMware? I believe it is because Intel plans to influence the outcome of the investment through its X86 distribution chain.

Sales of computers, especially server computers, are currently constrained by the complexity of software. Larry Ellison estimates that for every $1 in license spending for applications customers spend $6 in integration and maintenance expense. Not only is this complexity a drag on new license sales of software, it is also a drag on new sales of servers to run that software. What if a technology existed that could eliminate the drag of integration and maintenance such that customers could spend more money on new applications and servers? Maybe Intel would be interested in seeing such a technology proliferate?

Well, VMware has that technology, and I believe Intel plans to integrate VMware's technology with it's chipsets such that applications can arrive as virtual appliances, attach to the system in a matter of seconds, and then be managed by the application provider as a complete system image instead of being managed by the customer as a set of “lincoln logs” to be assembled in a unique manner each time. With VMware hypervisor technology as the replacement for the bloated, “one size fits all” general purpose operating system, customers can actually take advantage of Moore's law instead of being held back by the lack of installability, maintainability, and portability of software applications.

How many times has the hardware sales rep been stymied in the sale of a hot new machine because the customer absolutely refused to touch the machine that was currently running their ERP/CRM/SCM/(pick your alphabet soup) application? They refused to touch it because once it was installed, configured, and stabilized no one wanted to repeat the hellish process that led to that stability.

Imagine the new world order with the hypervisor embedded at the chipset level as the replacement for the bloated general purpose operating system. You simply hook up power and networking to the new box, and then “vmotion” the system image on the old box over to the new box. And magically you now have X% more processing power, I/O, memory, or whatever you need on that fancy new box. Life doesn't get much better than that for a hardware sales guy or gal.

My bet is that you see Intel pushing their downstream server partners to adopt Intel chipsets that enable VMware hypervisor functionality at the level of the BIOS. Intel and its downstream partners such as IBM, Dell, and HP will develop system management technology along with vendors like Cisco, Symantec, and McAfee that enables “value added” services to also be delivered to the machine without the general purpose operating system getting in their way. You will see these supply chain partners develop virtual appliance catalogs that contain applications that can be added to the system in the same manner that you add songs to your iPod through iTunes. When software ceases to be a drag due to operating system complexity, hardware sales accelerate tremendously. All this for a measly investment of $218M. I think Intel got a great deal.