Discussions about the Linux industry
Posts 1-2 of 2
-
Muli Koppel(not a XING member)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.07 Oct 2005, 1:49 pmSmells Like Teen Spirit? (Enterprise Linux Distros)
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.
-------------------------------------------------------------------------------------------------------
This post figures also at
http://mulikoppel.blogspot.com, an Essays blog on Enterprise IT, Internet and more, by Muli Koppel, CTO & Chief Architect of Architecture To Go LTD.
-
Enrico Weigelt(not a XING member)Muli Koppel wrote:06 Jun 2007, 11:12 pm
Re: Smells Like Teen Spirit? (Enterprise Linux Distros)
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.
Very buerocratic and inflexible.
Why not just hiring good operators ?
I really don't see the value in that whole "certification" issue. I never ever had
any need for that. Some time ago I've developed, installed and maintained
large parts of an realtime stock trading application almost alone. That application
did automated trading and moved around Millions of Dollars a day.
We were two persons, the customer (who gave the principle application concepts
and did testing) and me (did the whole development and maintenance). Sometimes
there was a third person for some minor frontend coding stuff.
We did it without major trouble. The critical server systems were built completely
from scratch, without any distro.
There never was an need for some kind of "certification". If something did not work
right, I had a look and fixed it.
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
Differs in one CFLAG. Trigger an complete rebuild and you're done.
At least if you're using an good source-based distro.
If you insist in an binary distro, you have to face bad performance.
2. The Operating system
Oracle 8i is supported just on RH 2.1; Oracle 9i is only supported on RH 3 etc.
Well, I never really used Oracle. Never had the need. PostgreSQL had always been very fine.
Proprietary stuff always causes headaches. You should circumvent it where you can.
BTW: Putting the Oracle blob in a jail should do the trick.
3. Database Features
Some database features have their own interoperability matrix
Depending on what ?
5. Monitoring agents
Not all monitoring frameworks have an agent for the Linux distro of choice. Sit down and code it ?
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.
What's wrong with tar ? ;-)
7. Middlewares
Adaptors, connectors, listeners etc – yet again, these are limited to a specific Linux distro in a specific version.
You simply should circumvent such crappy products.
If some vendor only supports one specific distro, he really did not understand
the fundamental concepts of OSS and no sane people would ever expect
production-grad quality from those vendors.
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).
Drop such equilibrium phantasies and hire someone who can handle these systems,
instead of blindly trusting some "certification".
When all pre-requisites are in place, distro alternatives sometimes don't exist (!); if we're lucky, though, they do exist, though highly constrained.
Well, most of these prerequisites are, by my personal experiences (of the last decade)
just stupid buerocratism of people who fear the reality. Or maybe it's the strange
tendency of certain managers to prefer monolithic products with well-sounding names
over qualified humans.
cu
