Solaris vs. Linux

In my latest InfoWorld column ("Solaris takes on Linux"), I explore my thinking over the past few years as I've been one of the many IT folks who have replaced a lot of my Sparc Solaris infrastructure with Linux on Intel. That column was sparked by a recent post on Jonathan Schwartz's weblog that effectively points at some of the weaknesses in "linux" (as Jonathan calls it -- fairly, I think, since there really isn't one Linux) and why IT folks should reconsider Solaris:

So if you're running Red Hat, and feeling frustrated by their support, exorbitant pricing [see Solaris 9 pricing - CD], or weak security, it's time to look at Solaris, on any of the more than 200 hardware platforms we support. From HP, Dell, IBM and, of course, Sun (and a host of others). The migration is a very easy one. So is the free download.

In my column, I point out a couple of specific examples where Linux (I'll stick with the capitalized spelling out of comfort, but again, the "linux" spelling makes a clever point) has caused a bit of operational pain for us at InfoWorld. Jonathan's points against Red Hat are roughly defensible, although Red Hat's pricing doesn't seem so far out of line that it can't be adjusted to deal with any market challenges that might arise and the security claim could have been bolstered by a well-placed link or two.

While we're mostly a Linux/Intel shop here at InfoWorld, I don't feel nearly as fired-up and evangelical about Linux as I did five years ago when I convinced the marketing department at my then-employer to issue a press release trumpeting our migration to Red Hat Linux (spawning a Slashdot posting, a Webmonkey article, a piece in PC World, and a mention in a News.com story ). Despite the flurry of attention that migration brought, the dirty little secret of this Linux proponent was the Sun E450 I had in the server room running our content management system (which was open-source based and ran great on Solaris) and our mission-critical Oracle database. Linux was a bit risky at that time, so I wasn't foolish enough to migrate *everything* to Linux -- we had a content business to run, so the core content-producing system stayed on Solaris/Sparc. An excellent choice, but no one issues press releases about rock-solid Sun boxes running Oracle. They were just too commonplace.

Fast forward to the present. The Red Hat Linux I run isn't free (as in beer) anymore, and though the mission-critical Oracle I used to run on Solaris is now humming away on Red Hat Advanced Server on HP hardware, it's not officially supported on Debian, our Linux distro of choice for our front-end web servers, mail servers, etc., so I'm stuck working with two Linux distributions. Though I can get plenty of advice on how to make Oracle work under Debian (see here, here, and here), I find the thought of fooling around with a Debian system (even minimally) to make a five-figure software package function. . . . well, it registers somewhere between "aggravating" and "pointless." Might as well just cough up the money to Red Hat and go through as normal an install as possible. (And speaking within the "social movement" context that Jonathan asserts in his original post -- if you've already "sold out" to Oracle, why try to be righteous by using a free Linux distribution anyway? Seems a little like wearing a shiny new leather coat to a PETA rally.)

Quandaries like the one I outline above led me to conclude this week's column this way:

If I’m going to be paying license fees and support to a commercial OS vendor, what difference does it make whether the core is a well-tested Linux or a well-tested Solaris? I don’t think I would lose sleep at night going with either.

I don't think I've ever written anything dealing with this kind of ambivalence, but I think we've gotten to the point (at least with RedHat and commercial products that run on Linux and generally require Red Hat) where there's just not much technical or business difference between choosing Red Hat or Solaris. While Jonathan argues that Solaris is cheaper and Red Hat can arguably stake a stronger claim to open source, neither is free for commercial use and both run great open source software like Apache, PHP, Perl, Python, MySQL, PostgreSQL, et. al. quite well. Setting aside Red Hat's open source roots for the sake of argument is not intended to diminish Linux itself and the efforts of the many generous Linux kernel hackers, nor am I intending to discount the benefits of the bazaar over the cathedral (InfoWorld has been a direct beneficiary of open source development). It's just that most folks working in IT never get down to the low level of the kernel, much less the actual *code* from the kernel, so the availability of Linux source code means little to most in corporate IT. In IT, it's all about getting particular applications to work reliably on top of your chosen (binary) OS, and once you've got a compiler like gcc, it's off to the races. Moving beyond the Linux-specific discussion, having source code for applications *is* actually quite useful at times, even for average IT departments, but I don't think Solaris has ever been behind in terms of applications (and likely ahead when you count all the commercial packages). On an application level, Sun never really failed open source proponents. It's just that Sun lost a lot of us a few years ago when we faced the choice of Solaris on an expensive Sparc or Linux on a cheap Intel box (made cheaper by stiff competition among the many vendors of Intel-based servers). Not to mention that Linux was the underdog and, frankly, being on the side of the underdog can be fun and invigorating (as movements can be) -- especially when you're delivering performance and cost-savings.

Back to Jonathan Schwartz, who continues his earlier train of thought discussing the meaning of the word "open." The post should be read in its entirety, but two nuggets stand out for me:

1. Only a customer can define the word "open." That's my view.
2. Ask a customer - open describes the level of effort it takes to enable substitution. If it's tough, it ain't open.

Towards the end of his post, Jonathan references my column with these words:

And before I conclude, I'd like to make one final point - one that I've skipped over, above. It's that the true cost of substitution is, as Chad Dickerson points out, seldom defined simply by the technical effort to port. It is as much, or moreso defined by the economic cost of qualifying or requalifying applications running on one production stack to another production stack.

and after an example from Sun, writes:

Were I a CIO facing these issues, I'd stay focused on the one thing definitively under my control - keeping the cost of substitution, of at least application portability, as close to zero as possible.

How?

You guessed it, I'd write to Java. And I'd keep my options...

open.

We're 100% in agreement on limiting the cost of substitution and application portability. These issues are not so much particular challenges of the CIO or CTO's role as the very essence of the role itself. Java is definitely as solid a choice as any to achieve this (we're a Java shop here at InfoWorld), but it's not the only one, particularly for web applications. You could also replace Java with PHP (as Friendster did) and run it all on Linux. If you're Overture, you might be looking for people who can write Perl on Solaris or Linux because Perl apps run fine on both (side note: interesting that Overture's ad states: "The team does not use IDE's to develop applications." But that's another topic.) They're hiring Perl hackers over at Amazon, too. Each of these companies' approaches more or less guarantee application portability across operating systems and give their respective companies the ability to easily switch out the OS running under the covers.

If I was forced to migrate my systems from Red Hat Linux to Solaris tomorrow. . . well, no problem. Solaris to Red Hat Linux? No problem. Firm differentiation between Red Hat Linux and Solaris? Problem.