CoreOS Is New Linux, Not A RHEL Classic Killer

One of the most important lessons in marketing is that you don’t change something that is working, but that you also have to be able to carefully and cautiously innovate to protect against changing tastes or practices that might also spell doom for the business.

Two and a half decades ago, Coca-Cola famously made a mistake in trying to push New Coke, a different formula that was sweeter and more like Pepsi, replacing the original Coke, which had to be brought back as Coke Classic and which, eventually, killed off New Coke completely. Coca-Cola was not just changing things for the sake of changing things. When pop drinks took off after World War II, Coca-Cola had 60 percent market share in this drinks category and by 1983, when the New Coke plan was hatched, its share had dropped to 24 percent, mainly because Pepsi-Cola had a sweeter and less fizzy recipe that appealed to at least some of the masses. Coca-Cola was not wrong when it wanted to introduce a new variant of Coke; it was wrong in killing off the original beverage that so many people still liked. And, interestingly, Cherry Coke, which competes with Dr Pepper, added to the reintroduction of Coke Classic, is what got Coca-Cola’s market share back on track.

This has become an object lesson for all product development and marketing, and it is with this in mind that we consider, in the wake of the annual Red Hat Summit last week in San Francisco, the fact that Red Hat shelled out $250 million back in January to acquire upstart Linux operating system and container platform maker CoreOS for $250 million. Up until now, Red Hat has not been terribly specific about its plans, but we got the low-down from Brian Gracely, director of product strategy at the world’s largest open source software peddler.

New Linux And Linux Classic

The first thing to realize about the CoreOS deal is that Red Hat does not want to mess up – in any way –what CoreOS has spent years building with its immutable Linux platform. The way that Red Hat sees it, there is a way to keep the classis Red Hat Enterprise Linux distribution for the kinds of applications customers currently have deployed and to make some adjustments to CoreOS Linux so it can be better supported by Red Hat’s processes and still provide that modern, container-friendly, minimalist Linux substrate that hyperscalers and cloud builders have created for themselves and that CoreOS was inspired by when it created its eponymous Linux distribution and built it out into a container platform with the Tectonic Kubernetes container controller, the etcd system management tools, the Prometheus system monitoring tool championed by Google for Kubernetes, and the Quay container registry add-ons. Central to the CoreOS stack is this idea of “immutable infrastructure,” which as we explained several years ago means creating systems and application software in such a way that you never update running code but rather always push new instances of code out as it is tweaked and run it. (It is a subtle but important difference.)

Red Hat took a stab at building something akin to what CoreOS built, with its Atomic Host variant of minimalist Linux, which had a different deployment from the regular Enterprise Linux but which was covered by Enterprise Linux subscriptions.

“At a host level, when CoreOS started to get recognized and gain some prominence, it was because there was this distinct thing happening around immutable infrastructure, with tiny footprint hosts and so forth. We came out with Atomic, and it never really gained any traction in terms of brand awareness or a lot of customer usage, and a lot of the reason for that is that because RHEL customers did not understand why they would want to do it that way because they had years of experience with RHEL and RPM-based software. But there were a distinct set of companies that believed immutable was where they wanted to go.”

The heart of CoreOS, which was rebranded to Container Linux but which people still call CoreOS because marketeers don’t always get their way, was a Linux kernel based on a heavily modified variant of Gentoo Linux and with some of the online updating features inspired by Google’s ChromeOS for notebooks. “The over the air updates was what was really interesting,” Gracely continues. Atomic, by contrast, had the Fedora development kernel that is out on the cutting edge and that eventually gets frozen and put into the heart of RHEL, and it has a slew of applications that are certified by software companies to work on that kernel, which gives enterprises the comfort that they can move to it without having to do a massive amount of regression testing on their own. “There aren’t anything new or novel about the way that Atomic was going to do operations, other than the fact that instead of patching it like a pet, you treated instances like cattle.”

So looking ahead, here is what Red Hat is going to do. The Gentoo-based Container Linux will continue as an open source project and a product that companies can get if they want to stick with it. The Atomic minimalist Linux platform based on the Fedora kernel will ride off into the sunset (Red Hat will continue to support existing customers, of course) and will be replaced by Red Hat CoreOS, which will swap out that Gentoo kernel for a Fedora kernel, thereby adding all of that RHEL certification to it without sacrificing the over-the-air updates and immutable infrastructure management technology that really made CoreOS unique and, frankly, worth lots of money.

The CoreOS team was way ahead of Red Hat in integrating the Prometheus monitoring tool into its stack, concedes Gracely, providing yet another reason for the Red Hat to do the deal and making CoreOS as valuable as it was. The etcd distributed key/value store was created by CoreOS to house telemetry from Linux instances and containers, and has found a life of its own out there in the open source community, and is also valuable.

Importantly, the OpenShift platform cloud software, which included Red Hat’s own implementation of the Kubernetes container controller, will be deployable on either the full-on Red Hat Enterprise Linux in pets mode or the minimalist Red Hat CoreOS in cattle mode. But it will be using the Tectonic version of the Kubernetes controller going forward as well as integrating the Prometheus monitoring tool and etcd for storing telemetry. Gracely tells The Next Platform that the implementation of Kubernetes had outside dependencies such as the CloudForms hybrid cloud management tool (formerly ManageIQ) and was not “native” to Kubernetes in the same way that Tectonic is, meaning free of outside dependenies.

The future OpenShift will support the Quay container registry, but it will be maintained as a standalone product, outside of OpenShift for the time being, but could be integrated into OpenShift over time. (The jury is still out on that.) The metering and chargeback functions are coming from OpenShift itself. The operator framework part of CoreOS Linux, which was recently open sourced by Red Hat, provides a native method of managing containers and related system software in a Kubernetes environment, and this is also being woven into the stack. This operator metaphor is a way to automate the installation of stateful software in Kubernetes, and the enterprise has a lot of such programs as well as the ephemeral infrastructure that comes and goes as needed. In any event, CoreOS didn’t have the same pull with the independent software vendors as Red Hat does, and now this container operator framework will probably take off. We will see.

All of this integration outlined will be done by the end of 2018, and we will see subscription pricing for the stack at that time, and as Red Hat always does, the entire reworked stack of software will be released as open source so others can see it or tweak it. The plan is to have a technology preview of the modified CoreOS and OpenShift this quarter, and general availability sometime in the fall.

In the long run, we would bet that the cattle mode represented by CoreOS will win out over the pets mode represented by RHEL, and that is another reason to buy CoreOS now rather than wait or try to build a petsy equivalent from Atomic and OpenShift. Clearly, CoreOS was going to be eaten by someone, or at least take a sizeable bite out of potential business for Red Hat, so it was going to pay one way or the other. That said, the bare metal and virtualized legacy applications that drive millions of subscriptions to Enterprise Linux are going to be around for a long, long time. Enterprise software tends to linger – and then some. Red Hat will sell support subscriptions for both RHEL and CoreOS as long as customers want to pay for them, and let the market decide. Unlike Coca-Cola.

Sign up to our Newsletter

Featuring highlights, analysis, and stories from the week directly from us to your inbox with nothing in between.

Subscribe now

2 Comments

  1. All the rationalization sounds good… IMO it’s nothing more than a defensive move where Google could take over the server with its Linux / Kubernates. Once that’s there, applications (whatever Redhat really peddles’ now — JBoss etc) can be easily substituted with a modern rev.

  2. The thing is, RHEL customers use something less like pets and more like fleets nowadays. You can basically similar machines, but any mechanic knows that each workload achieves a certain unique set of quirks.

    Honestly, I think this is a great acquisition, but I hope that some of the immutable (or dynamic + stateless and declarative — looking at you systemd) crap gets removed from normal RHEL. We never wanted to care how well someone’s laptop connects to the network at Starbucks, and Systems Engineers value their deterministic, predictable, O(1)-complexity Linux.

Leave a Reply

Your email address will not be published.


*


This site uses Akismet to reduce spam. Learn how your comment data is processed.