I've been an IT industry analyst for almost 10 years. I've seen many technologies come, go, or fail to even arrive in the first place. However, during that time, a few techs have emerged that play a big part in fundamentally defining how businesses do computing. Most first emerged prior to 2000, but it has been during the past decade that they've truly changed things.
1. x86 processors were already well entrenched in corporate computing by the end of the 1990s, especially in their role as the "(In)tel" part of "Wintel" servers running Windows NT. However, their dominant designer and manufacturer, Intel, was heading in a different direction to handle the inevitable transition to the 64-bit processors and operating systems needed to keep pace with growing memory requirements.
That new direction was Itanium, a clean sheet processor design by Intel and Hewlett-Packard intended to get away from all the legacy features of x86 and--not incidentally--cut the x86-compatible processor makers out of the picture. The Itanium family remains with us but primarily as a processor for high-end HP servers. It was AMD that first added 64-bit extensions to x86 but Intel felt compelled to follow. And it was this backwardly compatible version of x86 that is the mainstream 64-bit server processor, not Itanium.
2. The other big processor story of the decade is multicore. Near the end of 2000, Intel introduced the Pentium 4 processor based on the NetBurst microarchitecture. It was intended to eventually hit about 10GHz. In fact, it never got beyond 4GHz and came to be viewed as the last gasp of performance scaling through frequency.
AMD introduced its first multicore x86 Opteron processors for servers in 2005 which helped it gain market share for a time while Intel made major changes to its development plans and processes. IBM and Sun also aggressively pursued multi-core in their RISC lines. Specialty processors such as Azul's Vega and Tilera's TILE lines went even more radically multicore. In short, frequency is largely dead as a path to higher system performance, which will require a combination of more cores and specialty accelerators working in parallel.
3. When I first met Diane Greene, co-founder and then-CEO of VMware in the fall of 2000, VMware was already selling a product to developers that let them run multiple operating systems on a single workstation. But Diane was in town to pitch me on something new, a pair of new server virtualization products--GSX and ESX Server--that made it possible to consolidate multiple workloads on a single physical server and to provision them more quickly.
The basic concept goes all the way back to IBM's involvement with early developments in time-shared computing in Cambridge, Mass., during the early '60s. And all the RISC/Unix vendors of the time had their own approaches to slicing and dicing servers. However, it was VMware that brought server virtualization to the masses. Its product ran on standard x86 servers and it provided a way to consolidate workloads right at a time when IT purchases were dramatically slowing and anything that could save money was in vogue.
EMC bought VMware in 2003 for $635 million, a figure which it's hard to believe today was widely viewed as an overpayment. Today, server virtualization--an area where VMware remains the 800-lb. gorilla despite Microsoft's entry--continues to fundamentally change the way IT departments think about operating their data centers. Virtualization also underpins much of cloud computing, another major developing trend.
4. Linux and other open source were a big part of the dot-com and service provider build-out of the late 1990s.
But enterprises? Not so much. This 2001 research note had to argue that Linux was, in fact, ready for serious production use. And, whether "ready for the enterprise" is a meaningful question in the abstract, the fact remains that the Linux 2.4 kernel was widely regarded as the first version deserving of that description and it wasn't released until mid-2000. IBM began its big Linux push at about the same time.
Thus, I'd argue that it's been this past decade and not the prior one that has seen Linux and open source truly become a pervasive part of computing. That's not to say that open-source has replaced all other software. But it has heavily influenced how companies do development, engage with user and developer communities, and provide access to their products--even when the software in question is proprietary.
5. My last entry has the greatest overlap with the consumer space. That's not a coincidence, given that mobile devices are a very visible example of what Citrix CEO Mark Templeton calls the "comsumerization of IT."
Mobile devices encompass at least a couple of different things. The most obvious entrant is probably the smartphone--first in the guise of the BlackBerry and more recently the iPhone. We are now at the point where you can carry a bona-fide computer in your pocket, complete with GPS and other sensors, and can run applications that you install. As my colleague Jonathan Eunice has noted, it really is a transformational experience relative to, say, my older Treo. It also represents the reality of the modern smartphone that, for many, it's increasingly about mail, texting, and social media and not, you know, phoning.
However, the smartphone doesn't deserve all the limelight. The noughts have also seen the laptop computer transform. I'm not talking about the form factor so much--although Netbooks have gotten their share of attention. Rather I'm talking about the way that we can use them.
I've had laptops since the 1990s but it wasn't until about 2001 that conferences and other venues started to put up Wi-Fi networks. They worked fitfully (some things haven't changed as much as we might like), but this was the beginning of the connected laptop rather than the merely mobile laptop.
And that's why I see the smartphone and the laptop as part of the same mega-trend. It's not about a particular form factor or usage model. It's about (almost) always being connected to applications that increasingly live largely in the network.
Correction at 7:15 a.m. PST November 4: At one time, Red Hat had planned to ship an embedded KVM hypervisor based on Fedora. But the Red Hat Enterprise Virtualization Hypervisor uses the RHEL 5.4 kernel and thereby picks up the same hardware verification portfolio.
With Tuesday's release of Red Hat Enterprise Virtualization Hypervisor and Red Hat Enterprise Virtualization Manager (RHEV-M) for servers, the company has completed the first phase of a server virtualization rollout that effectively now puts KVM front and center. Red Hat released KVM commercially for the first time in September as part of Red Hat Enterprise Linux 5.4.
KVM is a server virtualization technology that Red Hat acquired when it bought Qumranet in 2008. Red Hat favors KVM over the other primary open-source hypervisor, Xen, for both business and technical reasons. (Although, as of version 5.4, Xen remains the default hypervisor for RHEL.)
The business reason is that, while Red Hat has made contributions to 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 file system 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. In part for this reason, it's KVM that is now included in the mainline Linux kernel as of version 2.6.20.
As of version 5.4, an instance of RHEL can host guest virtual machines running RHEL 5 and other operating systems including Windows Server 2008. This announcement adds Red Hat Enterprise Virtualization Hypervisor, something that is often referred to as an "embedded hypervisor." It uses the same RHEL 5.4 kernel as Red Hat's full enterprise distribution.
Embedded hypervisors have taken off more slowly than many of us expected. But all the major virtualization players offer one so Red Hat needed to as well.
From my perspective, the Red Hat Virtualization Manager is more significant. On the one hand, management is important to--indeed central to--virtualization. On the other hand, it's an area where Red Hat has lagged. CTO Brian Stevens admitted as much to me when we spoke at the company's financial analyst day last month when he said that RHEV-M "has been a huge missing ingredient."
Red Hat historically mostly focused on updating packages. This is 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 because it's such a "high surface area" application. But Red Hat 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.
RHEV-M is Red Hat's first step toward remedying this deficiency. It seems a necessary move especially given that KVM is likely to be used, at least initially, as part of a Red Hat software stack and therefore Red Hat pretty much has to support the tools to manage KVM if it's to gain any market traction.
That said, this is very much a first step. The initial product only manages KVM. Furthermore, the management server has to be running Windows Server 2003 which you would rightly think a rather odd decision from a company that is one of the pioneers of open source. (Apparently, this was a decision by Qumranet and Red Hat has not yet developed a version that can run on Linux.)
Red Hat has clearly prioritized getting a usable if limited product into customers' hands. They trotted out one such at their financial analyst day. Dave Costakos of Qualcomm was happy with what he saw. 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, the role-based access controls, and the provisioning capabilities.
Overall, Red Hat's virtualization play remains less filled in than do the plays of others. But it's now started in a systematic way.
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.
[Update: Additional commentary from Stephen Hemminger added.]
Microsoft set off a barrage of commentary earlier this week when it released three drivers under the GPL v2 to be part of Linux. The main purpose for doing so appeared to have been to make Windows Server and Hyper-V more effective as a virtualization foundation for Linux guest operating systems.
I was less shocked by the news than some. It struck me as a smart business move by Microsoft to further dispel both the reality and appearance of not playing well with other operating systems and tools. From a practical perspective, offering technology to Linux that lets it work better with Windows pretty much had to be done in the form of open-source code. At the same time, the Microsoft of today is far more accepting of the fact that like it or not, Linux is going to be a fixture at many of its customers and they're going to have to live with that.
Thus, releasing these drivers seemed to make a lot of sense and, while it was clearly a big step on the part of Microsoft, it certainly wasn't inconsistent with the company's recent posture toward open source, especially since Sam Ramji came onboard to be senior director of platform strategy.
However, it now turns out there's another layer to the story.
On Monday, Stephen Hemminger made a posting to his blog, Network Plumber's Journal. Stephen is a principal engineer with Vyatta, an open-source networking infrastructure vendor. Prior to Vyatta, he was with the Open Source Development Labs (and then the Linux Foundation) and was one of the largest contributors of Linux kernel code (PDF).
This saga started when one of the users on the Vyatta forum inquired about supporting Hyper-V network driver in the Vyatta kernel. A little googling found the necessary drivers, but on closer examination there was a problem. The driver had both open-source components which were under GPL, and statically linked to several binary parts.
The GPL does not permit mixing of closed- and open-source parts, so this was an obvious violation of the license. Rather than creating noise, my goal was to resolve the problem, so I turned to Greg Kroah-Hartman. Since Novell has a (too) close association with Microsoft, my expectation was that Greg could prod the right people to get the issue resolved.
It took longer than expected, but finally Microsoft decided to do the right thing and release the drivers.
By way of brief background, the GPL under which Linux is licensed considers static linking--the combination of software components by a developer--to create a "derivative work" of those components. There are a lot of complexities, nuances, and ambiguities, but for our purposes here, the bottom line is that if you statically link GPL libraries or other GPL'd code into your program, the entire program has to be released under the GPL.
Which Microsoft had not done.
I had a conversation with Stephen Hemminger, who initially reported the potential issue with Microsoft's driver, and he provided me with some additional technical specifics. According to Stephen, the issue revolves around a feature of the Linux kernel called EXPORT_SYMBOL_GPL that allows for interfaces to be marked as only available to modules with a GPL-compatible license. From Stephen's perspective, Microsoft's proprietary code had to use some of these interfaces that "the kernel did not want to offer to non-GPL [code]."
If that all seemed a bit geeky technical, well it is. Very possibly a violation of the GPL but hardly one that is simply flagrantly flouting the law. And, from Hemminger's perspective, "once Microsoft was aware of it, they were eager to resolve." He said that he first discovered this in March, so four months is actually fairly rapid resolution as such things go in large companies.
Greg Kroah-Hartman, who is a fellow at Novell and was very involved in the open-sourcing of the Hyper-V drivers, certainly seems to believe the licensing problem played a role in Microsoft's decision. In an e-mail exchange with ZDNet's Mary-Jo Foley, he writes:
MJF [Mary-Jo Foley]: Hemminger is claiming Microsoft put the LIC code under the GPL because it was in violation of the GPL. Is this true? Did you have to suggest to (Microsoft Platform Strategy Chief Sam) Ramji & Co. that they were in violation in order to get them to agree to release the code under GPLv2?
GKH [Greg Kroah-Hartman]: I didn't have to "suggest" anything, I only had to merely point out the obviousness of the situation :)
MJF: If this isn't accurate, could you let me know how to interpret (Hemminger's) comments on his blog.
GKH: No, that sounds accurate.
Microsoft itself hasn't commented on the matter.
Based on what we know at this point, I draw a couple of conclusions. The first is that if Microsoft were the Microsoft of five years ago, it would have found some way to mitigate the problem that did not involve releasing code for Linux under the GPL.
At some level, it is now philosophically attuned to working with Linux in a way that it wasn't when one of Sam Ramji's predecessors, Martin Taylor, could be described as "Microsoft's Top Anti-Linux General."
But that said, it seems more than likely that their little license problem provided, at the very least, a forcing function to make their GPL contribution happen.
I had planned to leave the Google Chrome OS discussion to others. It's not that I don't have strong opinions about it but with a commentariat noise level approaching the Michael Jackson ruckus of Tuesday, I figured I'd try to wrap up a client project instead. I did so and I've been getting questions all day, so I thought it would be useful to put down my thoughts in a systematic way rather than answering every query ad hoc.
Let me start out by making what is probably a controversial statement. I don't see this as a big deal. Microsoft is not now radioactive. The Force has not been disrupted. The computer industry does not look different than it did yesterday.
Look. Just about everyone has been assuming that Google was going to bring the Google Android operating system that it developed primarily for smartphones to low-end notebooks. While Chrome OS is different from Android, it's conceptually pretty much the same thing--an open-source operating system built atop a Linux kernel.
So now Google has pre-announced that it's going to do basically what everyone figured it was going to do. Sorry, but that doesn't make me want to run through the streets shouting and hollering.
This is, in many respects, just another Linux distribution. And Linux has (speaking charitably) not had the impact on the general-purpose PC market that its supporters once hoped it would. Sure, enthusiasts load Linux onto PCs and it can work quite well, but even at an open-source developer conference you'll often see far more Macs than PCs running Linux. I can't say that I understand why Chrome OS would succeed where Ubuntu has, if not failed, largely played to a niche.
It's Google we're talking about here to be sure. To which I say that Google has had plenty of failures: Orkut, Google Video, Knol, and Google Base anyone?
Fundamentally, I'm skeptical that anyone is in a position to seriously displace Microsoft and Apple from effective ownership of the general-purpose desktop and notebook space. There's so much ecosystem, most of all software ecosystem, in place that a new entrant would have to offer just overwhelming advantage. Which Linux didn't and doesn't.
There's a story here but it's not about displacing Microsoft.
Rather, I see Chrome OS as reflecting a change in the client and the way we access applications. To the degree that Chrome OS further illuminates and, by doing so, accelerates such change it may indeed be important in its own right. However, this is largely a change that's happening with or without Google--and certainly with or without anything Google does with respect to client operating systems.
And it's this macro-trend that's the real threat to Microsoft, not Chrome OS. Microsoft's franchise is built in no small part on having become the de facto standard API for programs running on another de facto standard that we colloquially call the PC. That franchise may be hard to crack (although Apple has had a degree of success) but that franchise doesn't necessarily carry over to new areas where far less software is locally installed and therefore a "standard API" becomes much less important.
The Linux desktop (whether Chrome OS, Ubuntu, or whatever) won't be your father's PC and it may not even look like a PC at all. That's the far bigger threat to Microsoft. Not that it won't be able to defend its existing franchise but that it will be cut off from extending that franchise into computing that happens over the Net rather than locally.
We most associate hypervisors and virtualization with servers from their beginnings as tools for development and testing, through their widespread adoption as a means to reduce the number of physical servers needed, to their current stage as a foundation for dynamic IT architectures. Virtualization on the client side has been more of a niche although application virtualization continues to grow in importance and some specific uses, such as running Windows applications on Macs, have proven quite popular.
As for embedded devices, special-purpose computers, virtualization has had essentially no impact.
That's beginning to change. Wind River, one of the major players in embedded operating systems and recently purchased by Intel, today announced the availability of Wind River Hypervisor. From the press release:
Wind River Hypervisor enables virtualization for devices across a broad range of market segments, including aerospace and defense, automotive, consumer devices, industrial, and networking. Within these markets, embedded developers are adopting hypervisors to enable the replacement of multiple boards or CPUs with a single board and/or a single CPU, create innovative new devices that leverage multiple operating systems, and reduce complexity when integrating multicore processors. The benefits of using the Wind River Hypervisor include reduced hardware costs and power consumption, opportunity for innovation, and accelerated time-to-market.
This hypervisor can be employed in a number of different ways on a multicore processor. For example, it can be used to run multiple operating system (OS) and application instances on a single processor as a way of enabling single-threaded applications to access multicore performance.
However, what's probably the most interesting use case is consolidating different operating systems on a single processor--and thereby potentially reducing the otherwise need for separate chips or devices. This hypervisor targets two primary operating systems: Wind River's VxWorks and Wind River Linux. To understand why mixing these two might be interesting and useful, consider the differences between them.
VxWorks is Wind River's proprietary "hard real-time" operating system. It's widely used in places like aerospace and defense (think radar, avionics, and so forth) and the data processing of network gear.
Real-time, in general, refers to operating systems and software that have a very predictable response time to events. Predictability runs in opposition to overall throughput so commercial operating systems have historically not been real-time operating systems. Hard real-time typically refers to the need to have truly guaranteed response with the possibility of failure or damage if a response is not made in time.
Wind River Linux is the company's version of Linux optimized for embedded devices. In 2007, Wind River acquired FSMLabs, a real-time Linux vendor, to augment its Linux efforts. Wind River had earlier had a partnership with Red Hat, now discontinued.
Without going into all the gory details of schedulers and so forth, suffice it to say that the real-time characteristics of Linux have improved considerably over the years. Furthermore, various patches can further optimize Linux for real-time uses. Today, we see Linux in applications (such as this IBM/Raytheon deployment) that would have historically been well outside the realm of even customized general-purpose software.
That said, an operating system like VxWorks retains a specialized focus on real-time and comes in versions that carry stringent certifications. Thus, there are many situations where it may make sense to use VxWorks for those parts of an application that require those certifications or are otherwise better served by the specialized real-time OS. At the same time, Linux may be a better fit for other parts of the application that can leverage the Linux ecosystem for components such as user interfaces.
In addition to having different technical requirements, embedded systems make for a somewhat different virtualization use case than in enterprise IT. In embedded, operating systems remain far more specialized and bespoke and this makes the ability to mix and match them on increasingly powerful and multicore processors very useful. This is another face of increasingly pervasive virtualization.
The enterprises, vendors, developers, analysts, and journalists I speak with regularly are mostly pretty savvy about the basics of open source at this point. Even if they're not licensing geeks or otherwise expert in all the minutiae and subtle implications of open-source development, community, and usage, they generally have the important basics down.
However, as I read Rice University computer science professor Dan Wallach's detailed and thorough critique of an Election Technology Council white paper on open source in voting systems, I'm reminded that there are still a lot of misperceptions about open source among the broader public.
A lot of people are quick to dismiss such confusion as evidence of sinister plots to deliberately undermine open source. No doubt, some is indeed willful misunderstanding, or simply disinformation.
But certainly not all. I've personally heard longtime friends from outside the tech industry voice many of the same beliefs. Many of these fall into one of two buckets: open-source software depends on the support of some nebulous "community," and open-source is less secure because bad guys can use the code to find vulnerabilities.
With respect to the first point, this discussion in the ETC paper is typical:
Due to the volunteer nature of an open source model, the issue of accountability in this environment provides a stark contrast to the accountability within a traditional proprietary offering. In commercial product offering, the individual company is held accountable for delivering a product that meets all applicable standards and for meeting project milestones. Contract requirements are often used to establish performance milestones and clearly delineate the responsibilities of a provider. Within a corporate structure, liability is clearly delineated to the company. In an open source environment, a volunteer group of collaborators will not be so clearly subject to financial liability or have a clear line of accountability. It is possible that a hybrid approach could be undertaken for an open source project which is launched in partnership with a private company, but the issue of intellectual property investment and concerns over the long-term viability of the company's product will likely trigger a need to adopt a more restrictive licensing approach, one more indicative of a traditional proprietary model.
In part, this is a case of conflating open source of circa 1997 or so with open source of 2009. It also reflects that most of the people who are loudest about open source as a social movement emphasize hobbyist communities rather than corporate sponsorship and in-house professional development. Indeed, these people often decry the latter as a betrayal of free-software principles.
The reality for most commercially important projects is much different. The bulk of the development is directly funded by IT vendors for self-interested reasons. In the case of the Linux kernel, the work is shared by a large number of companies. Other software, such as JBoss and MySQL, are primarily worked on by developers at a single company.
Support for major open-source software is similarly commercialized. Although "community support" (that is, forums, blogs, Twitter, etc.) may often in fact be pretty good mechanisms to track down fixes, they're not the only one. A Red Hat Enterprise Linux customer, for example, can get support in exactly the same way that someone with a support contract for Microsoft Windows would.
As for the security question, I look at it largely as a case of analogies gone bad. Typical is this line from a paper on Linux security by a public policy expert that I was asked to review a few years back: "it would seem to stand to reason that if keeping passwords, access numbers, and other aspects of system security secret, keeping code secret might be one way to enhance security."
It all sounds reasonable. After all, even if I think I have a solid security system installed in my office I don't stick its specifications and layout on a piece of paper and nail it to my front door.
However, as Wallach notes:
What we learned from the California Top-to-Bottom Review and the Ohio EVEREST study was that, indeed, these systems are unquestionably and unconscionably insecure. The authors of those reports (including yours truly) read the source code, which certainly made it easier to identify just how bad these systems were, but it's fallacious to assume that a prospective attacker, lacking the source code and even lacking our reports, is somehow any less able to identify and exploit the flaws. The wide diversity of security flaws exploited on a regular basis in Microsoft Windows completely undercuts the ETC paper's argument. The bad guys who build these attacks have no access to Windows's source code, but they don't need it. With common debugging tools (as well as customized attacking tools), they can tease apart the operation of the compiled, executable binary applications and engineer all sorts of malware.
In short, access to software (whether open source or just disclosed source) is not the unlocked door that many non-developers assume it is.
Cryptography provides another example. The mechanisms used by most protocols to encrypt and decrypt data are well-documented. They don't depend on secrecy to work. They depend on an untenable amount of computational power being required to decrypt in the absence of private keys.
And the converse offers further proof. Weak encryption algorithms that depend largely on secrecy are often compromised relatively easily; the Content Scramble System (CSS) used on DVDs is a textbook example.
I take all this as a reminder: don't assume things that "everyone knows" really are.
MOUNTAIN VIEW, Calif.--For me, one of the more interesting discussion threads at the CloudConnect event I'm attending here is that of lock-in.
If you move an application or write a new one targeting a specific cloud provider, are you pretty much committed to that provider, for better or worse, through good service and through bad, until your application becomes obsolete or the provider closes shop?
The answer is not a simple one. And it's made no easier by, on the one hand, vendors blithely throwing around terms like open, standard, and interoperable. And, on the other, by calls for an interoperability nirvana that's hard to see ever existing absent software becoming an undifferentiated commodity.
One of the problems with this discussion is that "interoperability" or "portability" in the "cloud" covers such a wide gamut that it's very difficult to make meaningful general statements. IBM's Bob Sutor noted in a panel on the topic that there are different taxonomies for interoperability. For example, you can migrate content, migrate processes, migrate code, or migrate machines.
And, as you move beyond the automagical movement of running applications from one cloud to another, there's a lot of vendor gloss around interoperability issues. Any application can (more of less) be moved from one platform to another. It's a ";simple matter of programming," as the joke goes--which is to say that there's nothing necessarily trivial or quick about something as simple as moving from one vendor's Linux distribution to another (or even between versions) when real-world factors like testing qualification are factored in.
Thus claims that "all" that's needed to move off one vendor's cloud platform to another is to remap some of the value-added application programming interfaces (such as to a specialized database) or to integrate with a different management framework ring a bit hollow. IT shops stick with legacy platforms today because of far less onerous porting requirements to move to something new.
If there is one sine qua non though, it's the ability to extract the data that you own. On that, there is broad agreement, even if there are practical issues over formats and, sometimes, what data is "yours," exactly.
The discussion is further complicated because cloud computing takes place at several levels.
Roughly, the emerging consensus is that we can throw it into three big buckets: complete applications such as a hosted Microsoft Exchange or SharePoint service; a developer platform such as Google App Engine or Microsoft Azure; or something that's more akin to a bare-bones operating system, storage, or a database such Amazon Web Services.
Common shorthand for these three levels are software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). (Hardware as a service is sometimes used for this last category, but given the role now played by virtualization here, infrastructure seems the more accurate term.)
And, as Alistair Croll of Bitcurrent noted on the panel, the higher you move up the stack--the more abstractions you make use of above the basic infrastructure--the more lock-in you tend to inherit. The fact is that those abstractions (such as mechanisms to handle scaling for you automatically) save you work, but they also tend to be platform-specific.
As Alistair put it: "Developers are lazy in a good way. That's another word for optimization. Any cloud is going to evolve a set of value-add services. And that's the devil's payment. You have to be conscious of the lock-in you inherit."
But this is nothing new. It's not specific to cloud computing. It's not even specific to proprietary software. Want to move from a PostgreSQL to a MySQL database? Want to be renegade, switching from Linux to FreeBSD? Want to switch open-source content management systems? No one is keeping you. It's just a simple matter of programming and a little thing called time.
I just ran across this video from Sun Microsystems that demonstrates a source of disk latency that we usually don't think about. It's short and quite amusing. Take a look.
But being the analyst that I am, I also wanted to highlight some of the pieces that make the demonstration possible.
The technology that's under the covers, measuring the disk latency and so forth, is DTrace, a component of Solaris, originally developed by Bryan Cantrill. By way of background, here's what I wrote upon its introduction in Solaris 10:
DTrace stands for "Dynamic Tracing" and, indeed, it's that dynamism that most distinguishes it from other approaches. A developer, administrator, or performance tuner uses the DTrace scripting language to dynamically establish monitoring points of interest, whether in the OS kernel or user processes.
A probe is a location or activity to which DTrace can bind a request to perform a set of actions, like recording a stack trace, a time stamp, or a function argument. Think of them as programmable software sensors that gather interesting information about the system, and report it.
DTrace in Solaris 10 comes with something like 37,000 predefined probes; users can also define their own. Probes come from a variety of kernel modules that Sun calls providers, each of which creates a unique type of instrumentation.
For example, there's a provider that creates a simple time-based counter (profile) and another to understand lock contention and other sorts of locking behavior (lockstat). But essentially any function entry or exit is a potential probe location; DTrace hot-patches the function entry point in memory to insert the probe.
DTrace is an incredibly powerful tool in that it can do all this monitoring and measuring while minimizing its impact on a running system. (SystemTap is a Linux analog that's considerably less mature.) This allows DTrace to be used in conjunction with production systems--and thereby look for performance bottlenecks under real loads rather than synthetic test cases. The downside of DTrace is that you have to be a bit of a Solaris performance guru to actually make effective use of it.
Enter Fishworks, which Bryan calls DTrace-based appliance analytics.
With analytics, we sought to harness the great power of DTrace: its ability to answer ad hoc questions that are phrased in terms of the system's abstractions instead of its implementation. We saw an acute need for this in network storage, where even market-leading products cannot answer the most basic of questions: "what am I serving and to whom?" The key, of course, was to capture the strength of DTrace visually--and the trick was to give up enough of the arbitrary latitude of DTrace to allow for strictly visual interactions without giving up so much as to unnecessarily limit the power of the facility.
You can also find a more detailed overview of the analytics in this Sun presentation (PDF).
Fishworks is a big part of the secret sauce and value-add of Sun's recently introduced Storage 7000 Unified Storage Systems. It also reflects Sun's new, or at least "tweaked," software strategy. While DTrace is open source (under the CDDL license) along with the rest of OpenSolaris, the GUI dashboard, and other analytics software that makes use of DTrace, is not. This is consistent with a more pragmatic approach to open source on the part of Sun that allows for keeping proprietary modules and components mostly aimed at large-scale production deployments.
Fishworks is one of those--and an impressive one at that. It will know if you shout at your disks!
This post by Michael Dolan at IBM is spot on:
Here's the thing, everyone who hears "Linux desktop" has a knee-jerk reaction and thinks of all the things they do on their own PC, laptop, Mac. The reality is you're probably not the target market for virtual desktops. The market is large desktop environments that have thousands (perhaps tens of thousands) of users and who are not doing consumer-oriented work (or shouldn't be). The cost savings of moving from physical PCs in a 1 user to 1 PC model to a managed model with virtual terminals can be significant. We'll see where the market goes for this model, but I know of a few very large companies that want to make this model very real. The economic situation and the impact on IT budgets may act as an accelerant.
Much of the time when I write about the evolution of Linux or the evolution of the client, I get lots of comments revolving around the lack of popular games for Linux or whether the GIMP can replace Photoshop. And, of course, the partisans for whom it's important whether Linux "wins" or "loses" to Windows or Mac OS X jump in with their various ideological objectives.
Idealogues and fanboys aside, however, part of the problem is terminology. "Desktop" gets used to refer to at least a couple of different things. One is the traditional, general purpose PC as we've come to know it over the past 20 years or so. The other is a shorthand for any client device with a keyboard and monitor. The former is a "fat client" with all that implies for a broad range of hardware support and available applications. The latter is more specialized. It may run only a limited subset of applications. Or it may run primarily network-based applications through an interface, such as a browser. Whatever the details, it's effectively much thinner--whether or not it's actually a thin client.
I'm not going to argue that Linux can't function as a reasonably general-purpose PC operating system. For example, developers who want a desktop, or more commonly a notebook, that runs Linux have lots of good distributions to choose from that (mostly) install straightforwardly. Ubuntu is a current favorite. But that's not mainstream mass market. And for reasons that I've gone into previously, such as the dynamics of independent software vendor support, I never expect it to be such if we're talking an operating system in today's Windows or OS X mold.
But the way that we access applications is changing. Many clients are predominantly platforms for browsers or they serve a very specific purpose. Virtualization could also change how we run an operating system or systems on our PCs and other devices. In short, there are plenty of roles for Linux on the "desktop," but it's not the desktop as we've historically known it.
