Once upon a time when I was a fledgling Linux systems administrator, the distribution you used Really Mattered.
You used Gentoo or similar if you didn’t value your time, you used Ubuntu (once it came out) if you valued community, you went with Debian if you enjoyed having the crap kicked out of you in IRC channels and mailing lists, and so on.
But if you were a business that wasn’t a bank based in Europe (in which case SUSE was standing by eagerly for your call), you used either Red Hat Enterprise Linux or one of its free derivatives—most notably CentOS.
Red Hat was the name to beat, and it had it all: a thriving community in the form of Fedora, a free version in CentOS, and a paid licensed version in the form of RHEL. Home users might cut their teeth with Fedora before using CentOS or RHEL at the office, while folks exposed to RHEL at work might go home and install Fedora and CentOS on their personal computers. It was a virtuous cycle, with each platform feeding into the next.
From this point, nothing really changed overly much for a decade or two. Sure, there were new versions, and drama about systemd. But, overall, it was rock solid because it “just worked.”
And then that all changed last December when CentOS—which was a RedHat sponsored project for a while—changed its product substantially and inadvertently accelerated the seeds of their own destruction.
Isn’t that a bit dramatic?
I’m not talking about freeloaders here—or even the implicit promise that was broken by yanking away a 10-year support lifetime two years in. Those aren’t interesting to me for purposes of this article.
What this did was inspire a bunch of customers to reevaluate exactly why RHEL was running in their environments, and why they were paying a premium for it.
If you look at the EC2 pricing pages, you’ll notice that there’s a separate tab for RHEL, and it commands a healthy per-instance premium over using traditional Linux distributions that didn’t come with vendor support.
There used to be a bunch of reasons to make that selection. Many larger institutions had policies against running software that wasn’t accompanied by a support contract. Still others were running applications that were only supported / certified / licensed to run on top of specific operating systems, distributions, and versions.
Let’s be real here: If you were paying hundreds of thousands of dollars a year or more for licenses to some enterprise application, the cost of the RHEL licenses didn’t really make any difference. Further, some providers such as Rackspace only supported RHEL in their environments.
Enter cloud
Now, we’re in a time of cloud, and when I talk to AWS customers about their bills and highlight the premium they’re paying for RHEL instances, the answers are invariably the same.
Oh, we needed that with our last provider to get support and didn’t think about it when we migrated is one common answer. We used to have a requirement that every piece of software we ran required support, but that hasn’t been true in years is another.
In short, the primary reason our customers run RHEL isn’t for their support—because who’s called their operating system vendor for support recently? Effectively no one.
No, the reason they’re running RHEL is fundamentally inertia. “We were before, so why not keep doing it?”
Now that Red Hat has forced a reevaluation of support lifespans, customers are looking into this and discovering not just what Red Hat likely feared: that Canonical’s terms for Ubuntu are better and that Amazon Linux 2 isn’t as terrible as Amazon Linux the First was.
Instead they’re discovering something even worse: Customers are past a point of caring what operating system their workloads run on.
We’re in what looks like a post-OS world
“Linux or Windows? I don’t care, just run this application.” A scenario unthinkable 10 years ago is now commonplace.
With the rise of managed services and the clear ascension of cloud computing in a variety of different sectors and industries, this is simply much less of a concern than it once was. “Here’s a container, run it in whatever you want” means that there’s no perceived reason to ensure that the nodes that a container runs on are running any particular operating system at all.
In fact, with managed “run this container for me” service offerings—like AWS Fargate and Google Cloud Run—customers don’t even care what the node or nodes look like anymore; they just want their application to work.
In the serverless world where engineers throw code into some Functions as a Service offering, even the container libraries stop mattering. “Here’s the language my code is written in, now leave me alone and run it as instructed.” It’s a transformational time.
It goes beyond the OS
We’re even post processor architecture!
Amazon RDS (its managed relational database service) supports ARM or x86 processors? Good for you, you’re a freaking database service. I couldn’t possibly care less about that; just run my workload and stop bothering me with trivia.
I care about price, and I care about performance. But if you’re checking both of those boxes, then I don’t particularly care whether you’ve replaced the processors themselves with very fast elves with backgrounds in accounting. It’s akin to asking me to care about whether your servers are powered via AC or DC current; it doesn’t matter for any reasonable expression of a managed service.
All of this, of course, brings us to Kubernetes.
The Distro Wars are now about Kubernetes implementations
Now that Red Hat OpenShift is for some godforsaken reason available natively in the AWS console, you’d think that Red Hat was moving upstream to what’s fundamentally a Kubernetes distribution.
That’s because they apparently are, under the forlorn hope that this will somehow be enough to save them. Every story I’ve seen in the documentation that AWS provides about “why would I use this service” distills down to “migrating existing workloads”—not for anything that’s net new.
I even posit that Kubernetes itself will see this same pattern play out: specifically that its underlying technology is getting subsumed by the inexorable march of time.
It happened to the OS, it happened to the container runtime (Docker), it’s happening slowly to Kubernetes, and all of the enterprise vendors talking about those things are fundamentally pitching outmoded models to a slowly vanishing market.
If there’s no story in which a startup founded today becomes your customer during its rise to a publicly traded monstrosity, you don’t have a future in the longer term.
I’m expecting angry letters
This is going to generate angry feedback from folks who identify as the technology they work on. I get it; I once viewed myself as an email systems administrator. The sea is evaporating out from under those folks, and it’s a difficult transition.
You can either rail against things you can’t change, or you can expand your skill set into new and bold directions that embrace the winds of change and position yourself to take advantage of them, whatever those might be.
This involves placing a bet on where the industry is going, not purposelessly hoping for a return to the old ways. I’m sympathetic. But neither of us can turn back the clock.
Fundamentally, Red Hat is finding that its core market isn’t one that’s expanding, its new exploratory market is one that isn’t long for this world, and that its future is uncertain.
The abyss it was wandering towards is now closer due to its CentOS change. But that’s only because it jolted awareness among its customers that they didn’t really need their offering anymore.
For what it’s worth, this remains someone else’s problem to solve: specifically, IBM’s. Based on my recent experiences with the company, I won’t hold my breath.
[“source=lastweekinaws”]
