Red Hat appliances: the OS does matter

The broad strokes of Red Hat's announcement yesterday left a lot of canvas unpainted. Its JBoss middleware, an acquisition that hasn't met Red Hat's expectations, was MIA. And a great deal of management, provisioning, identity, etc. capabilities--essentially the services that span the entire infrastructure--were casually lumped under the Red Hat Network (RHN) umbrella, or handed off to Open APIs, without much in the way of detail. RHN is a capable update and monitoring tool that has become increasingly capable over time. But RHN, even augmented by Red Hat's other infrastructure products, hardly comprises a complete enterprise automation strategy, contrary to what the company seemed to suggest. Overall, it seemed more like a conceptual vision for a strategy than an actual strategy.

For me, more interesting for the near- to medium-term were a pair of other announcements that are more closely related than they might initially appear. One was the Red Hat Appliance Operating System (AOS) that the company plans to make available in the first half of 2008. (The acronym takes me back to my previous life...but that's another story.)

It goes almost without saying these days that the appliances in question are virtual ones. The idea is that you can take an app, the operating system it runs on, supporting programs, libraries, and what have you; configure the whole mess properly; and then write it out to disk ready to be fired up as a self-contained, ready-to-run virtual machine. Although the early use cases for virtual appliances were mostly around trials and demos, we're starting to see more and more interest in them as a general-purpose way of deploying software. (I previously discussed the evolution of virtual appliances in this piece.)

The company wasn't especially specific about exactly how AOS would differ from standard Red Hat Enterprise Linux, except to say that it was optimized for running on virtual infrastructures and would come with a software development kit (SDK) the construction of appliances and their integration with third-party software. Presumably Red Hat will leverage its existing Red Hat Exchange as part of the way these appliances would be distributed, but no details on that yet. The company did say that there would be tools in place to help ISVs update their own software in an appliance, but it wasn't ready to make any specific announcements about that yet.

VMware has run an aggressive play on virtual appliances. rPath has built an entire business around appliances. Perhaps an even more significant player is Oracle. Oracle Unbreakable Linux isn't an appliance as such. But it is an attempt to subsume the operating system with the application. With AOS--which Red Hat says will maintain all the software certifications associated with its Enterprise Linux product--the company is effectively arguing that the OS does matter, even in an appliance. Which, for an operating system vendor, is certainly a preferred state of affairs.

Another important announcement concerned making Red Hat Enterprise Linux available on Amazon's Elastic Compute Cloud (EC2) utility, which is currently in beta. At first blush, this would seem to be largely orthogonal to the appliance announcement. In fact, they have a lot in common. EC2 runs on a Xen-based virtual infrastructure; its virtual machines can be stored as Amazon Machine Images (AMI). Although Amazon hasn't yet done much around creating any sort of formal marketplace for AMIs (a la Red Hat Exchange), that wouldn't be a big leap. And, as I discussed last week, I expect that we're going to see far more use of Amazon's style of utility computing to deliver software services rather than the raw hardware. Most users want to do things rather than run stuff.

One way to do this is a pure Software as a Service (SaaS) model whereby some vendor out in the cloud someplace may be using Amazon to host some storage or deliver some Web services but this is mostly transparent a user. However, it's also easy to imagine applications that are better delivered in a more traditional way (i.e. running on an operating system image that the user "owns"). In this case, virtual appliances offer one potential way to get those applications up and running in a way that mimics the way we're used to doing things on a physical server but with many of the fast setup characteristics of SaaS.