Friday, October 07, 2005

Smells Like Teen Spirit? (Enterprise Linux Distros)

It seems so fantastic and it smells like teen spirit: 386 Linux distributions (and growing) to pick from! The truth is, though, that in the Enterprise sphere, there's no need for DistroWatch, as the number of alternatives is aggressively squeezed into two or three. As Todd Oseth, EMC's Software VP, told me earlier this year, EMC will only support Red Hat, SuSe and Asianux, the Asian Linux. We can assume than that other software and hardware vendors will follow the same course.

This decision (to support a 3 out of 386) is highly logical from both the Vendors and the Enterprise perspectives. I'd even claim that our industry would do much better with two operating systems only (and, of course, with a similar number of hardware architectures). The reason is that the distro per-se has no intrinsic value; it is the ecosystem of the distro that counts. And the ecosystem is the outcome of the different vendors' interoperability matrices.

Before vendors can release an Enterprise-grade product, they have to run it through massive testing in a standalone, as well as interoperability modes. These tests yield the sometimes annoying but highly essential interoperability matrix, reflecting a final set of authorized variations. Each variation is static, in the sense that its constituents cannot be altered, not even on their patch level (let alone their release version).

If a vendor is to support RH, SuSe and Asianux in each of their released versions (RH 2.1, 3, 4; SuSe 8,9 etc) it practically implies a dozen or so new variations to the interoperability matrix. That's a prolonged time-to-market and naturally a lot of testing money every year! Therefore, vendors have to have a very clear business-case before a new variation is introduced. I suspect that 386 Linux distros are far from being justifiable.

In the Enterprise realm the story becomes even more complex. The Enterprise maintains its own interoperability matrix, with each variation holding much more constituents than that of any single vendor. Each component used in an Enterprise-scale deployment has to meet some pre-requisites that form the Enterprise Interoperability matrix.

Let's take a database server as a case study. Its ecosystem, i.e. the database server in its surrounding, comprises at least of the following constituents:

1. The Hardware platform
X86 64-bit Opteron or 64-bit Itanium – these two hardware architectures have completely different vendors ecosystem
2. The Operating system
Oracle 8i is supported just on RH 2.1; Oracle 9i is only supported on RH 3 etc.
3. Database Features
Some database features have their own interoperability matrix
4. The Enterprise Storage mini-eco-system
This is one of the most painstaking interoperability issues. File systems and volume managers, SAN directors and switches, Enterprise Storage Boxes and so forth. Most of the obstacles I have encountered as part of Enterprise Linux adoption have issued from this source.
5. Monitoring agents
Not all monitoring frameworks have an agent for the Linux distro of choice. Here's another aspect of the Enterprise Linux reality – sometimes, there's no choice but to introduce another infrastructure element – such as a new monitoring framework – so that the chosen Linux distro server would be monitored. While easy to solve on the tactical level (Nagios, Big Sister etc), these ad-hoc solutions have their toll on the strategic Enterprise Management level.
6. Backup agents
Backup's another major issue. Backup agents of Enterprise Backup solutions are highly selective in their Linux distros and versions. Moreover, some special backup techniques, such as those used by Storage vendors (EMC direct backup, for instance) are not supporting volumes mounted on (some flavors of) Linux servers.
7. Middlewares
Adaptors, connectors, listeners etc – yet again, these are limited to a specific Linux distro in a specific version.
8. COTS packages or bespoke Applications
Finally, the application(s) that use the database sometimes insist on a contextual certification, i.e. not just Oracle 10g, but rather Oracle 10g on Sun Solaris (and not on HP-UX, for some reason).

When all pre-requisites are in place, distro alternatives sometimes don't exist (!); if we're lucky, though, they do exist, though highly constrained.

There's no wonder than, that Jonathan Schwartz, chief operating officer and president, Sun Microsystems, has been so excited last month, when Sun new line of X86 AMD-based servers were announced: "Never in Sun's history have AMD, Microsoft, MySQL, Oracle and Red Hat stood behind a new line of products from Sun", he said. Well, that's the dark side of the interoperability matrix: sometimes, it's not only (testing) money, but also politics, competition etc. And paying close attention to Sun's announcement, it is clear which Linux distro is the one to be first supported.

Having said all that, one could wonder if Enterprise Linux worth the hassle. And the answer is evidently YES. Cost, scalability, performance and readiness for the future – all these make Enterprise Linux worthy already today. It's just that teen spirit and freedom of distro choice are somewhat irrelevant to the Enterprise Linux story.


Post a Comment

<< Home