The Pervasive Data Center

NEW YORK--It was a larger and cheerier crowd that attended this year's Red Hat's analyst day at the New York Stock Exchange on Tuesday.

That shouldn't be surprising. At last year's meeting on October 7, Red Hat management had the dubious honor of ringing the closing bell on a day that saw the Dow Jones Industrial Average drop over 500 points.

This meeting took place in a time of what's probably best described as cautious optimism about the state of the economy. And in the context of Red Hat financial results that have continued to show growth at a time when so many companies in IT industry and elsewhere have not.

For the quarter ending August 31, its profit jumped 37 percent relative to the year-ago quarter, besting analyst estimates.

The day included a fair bit of discussion related to financial minutiae, as you'd expect for an event pitched primarily for financial analysts. However, it also included an overview of Red Hat's strategy and its technical direction. Here are a few things that caught my eye.

Jim Whitehurst, Red Hat's CEO, spent a fair bit of time talking about what boils down to fine-tuning of its go-to-market execution such as:

• Value of subscription. This includes what he called "education and compliance," essentially a euphemism for getting people using Red Hat Enterprise Linux (RHEL) without paying for it to purchase a subscription. It also encompasses improving renewal rates for those cases where RHEL has been preloaded by a system builder and bringing a greater focus to articulating the value of RHEL relative to free substitutes such as CentOS.
• Routes to market. This refers to a continued build-out of the channel so that system integrators and others who recommend and install systems for less sophisticated customers will specify Red Hat as part of their solution. This stands in contrast to how, historically, Red Hat was mostly pulled into accounts by technically-savvy users and IT departments.

The message I took away from this is that Whitehurst isn't looking to change Red Hat's direction in any major way but sees a fair number of areas where more focused execution could lead to financial improvements. Later in the day, we also heard that Red Hat is taking a more systematic approach to which products it allocates development dollars for work such as internationalization.

For his part, Paul Cormier, executive vice president of products and technologies, reiterated Red Hat's belief that virtualization (which should be taken as hypervisor in this context) belongs in the operating system. This argument has been in evidence for a while as my fellow analyst Stephen O'Grady discussed after last year's event. 

It stands in stark contrast to VMware's desire to make the operating system irrelevant. Or, to put it another way, VMware's ambition to make the VMware ESX and ESXi hypervisors the model for a new type of operating system. This is too fraught a debate to tackle here; I largely agree with Stephen's take in his post.

However, one of the interesting outcomes of this battle is that Red Hat has been cozying up to Microsoft, the other big gun on the "hypervisors belong in the OS" side. This includes Red Hat's announcement Wednesday "that customers can now deploy fully supported virtualization environments that combine Microsoft Windows Server and Red Hat Enterprise Linux."

This sort of interoperability is certainly a customer desire and both Red Hat and Microsoft can legitimately present it in those terms without anyone smirking. However, the enemy of my enemy is also my friend, at least up to a point.

I also took note that Red Hat finally seems to be making some progress on the management front.

The product in question is RHEV Manager (RHEV-M); it's covered in detail in this video from the Red Hat Summit in September and is currently being tested by customers.

One reason I think it's important is that Red Hat apparently, if belatedly, recognizes that it is. CTO Brian Stevens admitted that RHEV-M "has been a huge missing ingredient."

The one customer speaker at the analyst day was Dave Costakos of Qualcomm and he focused on his company's experiences with testing RHEL-based virtualization and the associated RHEV Manager which he describes as "hits the mark."

I caught up with Dave at a break to get a bit more detail. He told me that they wanted a Web-based interface, which RHEV Manager has. He also liked the integration with Active Directory and other directory systems, and the role-based access controls. He said that it could perform the provisioning operations that Qualcomm requires and otherwise meets their needs.

Management has historically been a relatively weak part of Red Hat's offering that was mostly focused on updating packages. This is really a reflection of the broader Linux and open-source ecosystem in general. Projects like Nagios and, more recently, GroundWork notwithstanding, management doesn't play well to the strengths of open source. It touches too many parts of an IT infrastructure and requires too much cooperative work with the vendors making the things that need to be managed.

It's reasonable to ask whether Red Hat is too late to win big with RHEV Manager and its associated KVM-based virtualization play. But it had to attack management from some angle unless it was prepared to just cede that area of differentiation and potential point of control to system makers and others.

Finally, no technology discussion today would be complete without at least a mention of cloud computing. Brian Stevens jokingly called it a "shiny thing that people are looking at how to monetize."

The cloud discussion covered several angles, not least of which was standardization efforts such as Deltacloud. Like most other standardization efforts, this focuses on what is often called Infrastructure-as-a-Service; Amazon EC2 and S3 are perhaps the best known examples. Stevens admitted that it's going to be much harder to define a standard set of higher-level services (platform as a service in the vein of Microsoft Azure) that are portable.

Red Hat's distinctive play in the infrastructure cloud essentially circles back to its approach to virtualization. In cloud infrastructure as imagined by Red Hat, the operating system matters in important ways.

That's because applications matter; indeed, applications are ultimately what matter most. And in on-premise computing, one of Red Hat's greatest values and differentiators is the vast number of certified applications that it runs. This certification matters to users because, if they encounter a problem, it means that they can call the application vendor to get support. Otherwise, they'd get a "sorry, that's not a supported configuration."

One can argue whether the software layering of which the historical operating system is a part is the most appropriate choice for cloud computing. Fellow CNET blogger James Urquhart dives deeply into this topic in a pair of recent posts.

However, whether it's the way it should be or not, it is for now. And for Red Hat to be able to enable users to carry the certification of applications into a cloud model is a significant differentiation.

Last week's big virtualization news was Red Hat's purchase of Qumranet for $107 million.

By way of brief background, Qumranet has two overlapping, but somewhat independent, technology sets. The first--for which it is probably best known--is KVM, an open-source hypervisor that is in the process of being added to the Linux kernel. The other is its SolidICE virtual desktop solution that uses a back-end Linux server (virtualized with KVM) connecting to clients with the company's own Simple Protocol for Independent Computing Environments (SPICE) protocol. The virtual desktops themselves can be Windows, as well as Linux.

Some aspects of this buy are pretty straightforward and obvious. Others less so. As a result, I held off writing until I had the chance to discuss some of the specifics with Red Hat and my colleagues.

My conclusions? What seemed straightforward is straightforward. What didn't seem straightforward? Well, that's going to need some time to play out. Nonetheless, I got some good color and food for thought, which I share here.

My first observation is that virtualization remains a hot acquisition property. Now, $107 million may not seem like a huge sum. After all, Citrix bought XenSource for something closer to $500 million about a year ago. But XenSource was the well-known entity behind the Xen Open Source hypervisor project, and its commercial XenEnterprise product was gaining at least some market traction. By contrast, Qumranet is largely unknown by all but the most serious virtualization watchers--$107 million for a company whose "acquisition is not expected to contribute materially to revenue in the fiscal year ending February 28, 2009, but should add up to $20 million in revenue in the following year" has to be seen as a nice cash-out for Qumranet investors.

It seems clear that KVM was the major impetus behind Red Hat making this buy. Red Hat CTO Brian Stevens has been making favorable noises about KVM for a while. And, last June, Red Hat announced that it would be releasing an embedded hypervisor based on Xen. Red Hat prefers KVM over Xen for both technical and business reasons. I won't rehash them here (see this previous post), but suffice it to say that KVM plays a key role in Red Hat's OS strategy. Given that, and given how virtualization-oriented companies are being gobbled up at a torrid pace, Red Hat probably felt that there was considerable risk in not having some level of control over its prime virtualization asset--especially as almost every major Red Hat competitor does have at least some degree of such control.

Given that, it's tempting to suggest that Qumranet's desktop products just came along for the ride.

In contrast to Novell (with SUSE) and, especially, Canonical (with Ubuntu), Red Hat has never shown much of an interest in the client side of computing. True, virtual desktop infrastructure (VDI) clients run on a virtualized server; they're basically VMs that get delivered to a thin client or other client endpoint rather than "fat client" Linux desktops as they've been most commonly promoted. But, in some ways, this would seem to make the technology even a worse fit for Red Hat, given that the vast majority of deployed virtual desktops run Microsoft Windows, whatever the back-end infrastructure delivering them is.

My impression is that even Red Hat isn't certain quite how the desktop end of things will play out. On the one hand, it's clearly less of a clean fit than is KVM. At the same time, there's more than one reason to think that VDI and Red Hat aren't exactly oil and water.

• VDI is a hot technology area, and Qumranet's products are, by many accounts, solid offerings.
• As an established data center infrastructure software player, Red Hat is much better positioned to bring VDI to market than a start-up selling only VDI.
• In general, pretty much all the major server virtualization and operating system vendors seem to have accepted that they need to display at least a base level of interoperability and compatibility. (Thus, Windows and Linux guests have to play with pretty much every virtualization platform whether Windows-based, Linux-based, or something else.)
• It is at least Red Hat's hope that general client computing trends will make Microsoft's current desktop dominance a less compelling  factor as more computing moves into the network.

So, yes, the obvious reason for Red Hat to do this deal--KVM--does indeed appear to have been the main reason. But a number of folks within Red Hat, are genuinely excited about leveraging Qumranet's VDI assets as well.

"Real world" examples of some trend or business model are great. Theory is fine up to a point but eventually it's awfully nice to connect up with a concrete example that gives the theory some real cred.

At the same time, examples can mislead us. Often they turn out to be anomalies. Maybe a company is some sort of historical quirk, a product of a very specific time and place. Or maybe some technology approach is valid enough--but only for a very narrow set of needs. One warning sign is seeing the same tired examples trotted out for every discussion, every news article, and every conference.

I see some of that in all the following cases. I certainly won't go so far as to say that the underlying trends or business models are illusory. But I do think they're more limited or further away than their most overenthusiastic proponents suggest.

The Long Tail, as popularized by Wired's Chris Anderson is a hot meme of the blogging and Web 2.0 crowd. Simply put, the Long Tail states that bestsellers aren't in the majority when you tally up the sales at Amazon or Netflix. Rather it's the total of the far more numerous other 80 or 90 percent of content. From a business perspective, the significance is that there's money to be made selling what's in the long tail.

However, the number of true long tail businesses gets thin outside of aggregators of digital media--the companies who have minimal costs to acquire, inventory, and sell incremental low-volume products. Amazon, in particular, is a highly atypical, if not unique, retailer in terms of scale. In fact, we're starting to see a body of evidence that suggests that the long tail is, if not necessarily wrongheaded exactly, more limited in applicability and degree than some of its proponents have suggested.

We've also seen pure Open Source much touted as a viable business model. By "pure," I mean a model that doesn't hold any software back for paying customers only. The hope is that enough users will elect to pay for support and other services to cover a company's cost and profit. Red Hat, a profitable and growing company, is the poster child here.

But Red Hat is exceptional really. It's emerged as the unquestioned leader among enterprise Linux distributions, one of the most visible and core elements of the entire Open Source world. And its financial success is helped, in no small part, because it's selling a value, ISV application certification against Red Hat Enterprise Linux, that doesn't have the equivalent in layered software products. Other pure Open Source plays have also been modestly successful, but we're certainly not talking Oracle or Microsoft levels of success--nor, indeed, Sybase or SAS levels. Even Red Hat pulls in well under $1 billion in annual revenues, and may also be starting to hit the limits of low-cost customer acquisition enabled by free downloads.

Other cases involve long-term trends that almost certainly will have an increasing impact over time. More software is moving out into the network "cloud," and--in an at least peripherally-connected shift--thin clients of various stripes are beginning to move beyond their historical ghettos in call centers and other narrow use cases.  However, the oft-cited Salesforce.com and many Citrix case studies aside, these shifts will be far more gradual and incremental than the enthusiasts would have us believe. Enterprises will be slow to adopt Software as a Service for anything they consider even vaguely core and the traditional fat client PC model may be flawed in a lot of ways, but it is familiar, well-understood, and has huge inertia.

I love examples. They help give me confidence that something has at least a patina of reality. But, in the singular, they constitute anecdotes and not data. And anecdotes don't really prove anything. In fact, they can mislead by giving the atypical more weight than it deserves.

I spent the past couple of days at the Red Hat Summit in Boston. Good-sized crowd--over 1,500 and more than Red Hat expected I gather. The two major topics that I found most interesting at the event were Real-Time Linux and embedded KVM-based virtualization. I'll cover Real-Time in a future post; here's my take on Red Hat's KVM announcement.

CNET News.com's Andrew Donoghue has more details, but basically Red Hat is releasing--into beta test--a small (< 64 MB) standalone hypervisor based on the KVM project. The idea is that users (or system makers) will be able to load this hypervisor into a flash memory device. A system then booting off this device will go straight into the hypervisor and be ready to start creating virtual machines and loading guest operating systems without any further preparation.

Red Hat's been a fan of KVM for a while. There are a couple of major reasons for this: one business, one technical. Both involve Xen, the Open Source hypervisor project that underpins most server virtualization on Linux today.

The business reason is that, while Red Hat contributes to and works on Xen, competitors are far more associated with the project. Novell, the owners of the only other major enterprise Linux distribution, ran especially hard with Xen early on. And Citrix--not a direct competitor but certainly a major virtualization player--bought XenSource, the commercial entity formed by Xen's creators.

From a technical perspective, Red Hat's issue is that it's hard to keep Xen and the Linux kernel in sync. Xen's a standalone hypervisor layer but it has deeply invasive hooks into the Linux kernel and, therefore, keeping the two working together takes a lot of development and testing effort. It's a bit reminiscent of how new versions of the VERITAS filesystem had to be carefully matched to new versions of Solaris or HP-UX.

By contrast, KVM is kernel-based. This means that it is actually part and parcel of the Linux kernel rather than a quasi-independent piece of software.

Red Hat's embedded KVM hypervisor is actually a stripped down version of Fedora, Red Hat's community version of Linux. Why not Red Hat Enterprise Linux? Well, for one thing, getting things down to a reasonable size means taking lots of components not needed for a hypervisor out of the distribution. A minimalist RHEL wouldn't be RHEL. Furthermore, Fedora incorporates kernel changes faster than RHEL, which speeds up support for new hardware and the like.

It's worth noting here that a standalone hypervisor is an operating system that also incorporates a virtual machine monitor in some way and a means to manage virtual machines. It differs from a conventional operating system in what it doesn't do; it doesn't provide the interfaces required by programs to run.

However, in addition to supporting programs running on top of it, Linux also offers a wide breadth of hardware support, sophisticated memory management, scheduling and the like. Thus, kernel-based virtualization effectively gets a lot of capabilities for "free" that otherwise have to be developed for and added to an independently-developed standalone hypervisor.

Although Red Hat will continue to work on and contribute to Xen, KVM is clearly its strategic direction. Using an API (application programming interface) called libvirt, Red Hat plans to abstract low-level virtualization so that the choice of hypervisor is transparent to largely transparent to management software.

KVM is arguably late to the virtualization game. However the interest that it's garnering--and its adoption by a heavy hitter like Red Hat--is just another indication that we're fundamentally still in the early days of a virtualized world.