Red Hat OpenShift Part 1: From Gears to Docker
Red Hat’s OpenShift helped change data centers by enabling applications to be developed independently from the underlying platforms that support them. At a time when PaaS was thought synonymous with “public platform,” OpenShift helped popularize the concept of the private PaaS: a system for easily deploying and maintaining applications written in any number of common languages, on available infrastructure starting on-premises and extending into public resources.
OpenShift v3 has the same brand as v2. Both let developers deploy modular, and to one degree or another, distributed software using the same languages. But the concept behind version 3 — the mental model, or metaphor, behind how resources are managed and delivered — has completely changed.
Put in a more metaphorical manner, the whole idea of being a passenger in a Ford Thunderbird changes radically from the ’57 model to the ’61 model, with the addition of a back seat. You didn’t have to go back to driving school when you exchanged your two-seater automobile for a four-seater. Similarily so, you don’t have to learn how to develop all over again when you move from OpenShift v2 to v3. But once you take on extra passengers, you may find you’re driving places and making stops you wouldn’t have before.
On Supporting Docker
“This is a major architectural shift,” states Joe Fernandes, Red Hat’s director of product management, in an interview with The New Stack. “In fact, we’ve been working on it for two years. All the way back in September 2013, three months after Docker had been publicly announced, Red Hat put out a press release saying that we were endorsing Docker, that we were working with Docker, Inc.”
Fernandes recounts a press conference at the time, in which he was joined by Docker (then dotCloud) CEO Ben Golub, when he declared Red Hat’s intention to bring Docker architecture to OpenShift and Red Hat Enterprise Linux (RHEL).
Some analysts concluded that Red Hat made the architectural shift from the system it had pioneered to a Docker-oriented system as a concession that Docker containers had become the partitioning system of choice among developers. Fernandes tells us Red Hat had started in that direction long before such a choice was made. But in between those two milestones, there has been one very significant evolutionary development: Kubernetes, Google’s orchestration system for container architectures. Google has taken all the steps it’s needed to take to make Kubernetes the orchestration system of choice among developers, including making deals with companies that could have become Kubernetes’ competitors: with CoreOS last March, and with Mesosphere in April.
In any event, Red Hat’s decision in 2013 to support Docker has led it to incorporate Kubernetes with OpenShift v3 in 2015.
Red Hat did decide to produce a miniaturized version of its Enterprise Linux, called Atomic, for use inside containers, but even that doesn’t re-invent the wheel.
What does change — perhaps entirely, for many OpenShift developers — is the environment their software components are being modeled for. They’re the same language, but they function in a new world, and as such, in a new way.
The changes made to OpenShift reflect an understanding among the practitioners in the PaaS industry, including Red Hat, that without interoperability, competing PaaS platforms will be rejected.
“Our struggle — much like other PaaS vendors — has been how to keep up with demand that developers have,” explains Fernandes. “No matter what you provide, they always want the next great new framework, or the next new version of something you already support. We’d support one version of Node.js, and another version comes out.”
Whenever the community improves a language, the platform that supports that language must adapt. If the act of adaptation is different for every platform, then adaptation won’t happen in an agile way (for more, look up “Fragmentation, Android“). For OpenShift to stay competitive, it had to support one method of adaptation that the rest of the community would support in turn.
What’s more, the founding of at least two consortia — the Open Container Initiative and the Cloud Native Computing Foundation, with Red Hat’s charter membership in both — indicates that too much differentiation in one vendor’s PaaS platform will get it singled out, and not in a good way.
Gears Shift
From here on out, differentiated value in PaaS platforms will come in the form of whatever services the vendor can apply to the core platform to make it seem special to the customer. Some have taken to calling this the “secret sauce,” after the marketing practice of promising consumers something so special they won’t even understand what it is when they get it.
OpenShift v3’s “secret sauce” is best understood by looking at the platform’s original value and differentiation.
Up until the spring of 2012, the one thing OpenShift was not, was open. It had been an independent, proprietary product up until its acquisition by Red Hat. What Red Hat acquired was a novel way of partitioning applications, built around a kind of mechanical mental model.
Imagine all the servers that contributed to an OpenShift installation as a kind of pool, divided into two principal types: brokers and nodes. A broker facilitated management requests from the applications running on nodes, for resources those applications may need. Applications were hosted on nodes. It’s the simplest division of labor you could possibly have.
In each node are the components an application needs to be able to run. Now, almost everyone involved in data center computing claims to have invented the container, or some critical aspect of the container. There was indeed some containerization going on in OpenShift nodes, but the metaphor was based around what was being contained. OpenShift called these isolated clusters “gears.” Something that was capable of producing work without tearing down the entire mechanism, was a gear. An individual gear was associated with a user. It included the resources that this user would require to fulfill its basic function — that being, to run. (Outside resources could be connected through libraries.) Those resources were grouped together using Linux cgroups.
In an abstract sense, the work that gears produced was called the “application.” Rather than a branded piece of software, an application was a job performed by gears.
A construct made up of reusable gears that other gears might need, was called a cartridge. Here again, we see a concentration on function rather than the compartment where functions reside. Red Hat engineers described cartridges as “defined technology stacks” which were readily identifiable, such as Python, JBoss, or MySQL, or the MEAN stack (MongoDB, Express JavaScript, AngularJS, and Node.js.). From a retailer’s perspective, you can see how the cartridge idea makes it easy for a proprietor to make services available on an a la carte menu. You assemble the ready-made cartridges you need for constructing original functionality, and you build on top of them.
Just a few years ago, Red Hat engineers touted that at least 80 percent of the development work being contributed to OpenShift by the community was comprised of cartridges. In fact, since the principal content difference between the commercial OpenShift Enterprise edition and the free-to-use OpenShift Origin edition was the greater extent to which Enterprise components were tested and perfected (no doubt, by users of Origin), the Origin users were making greater use of experimental cartridges.
Road Forks and Merging Traffic
The infrastructural motif of OpenShift helped Red Hat push the concept of PaaS as infrastructure, and to promote at least an open discussion on the subject of whether IaaS and PaaS should continue to be treated separately.
That discussion came to a head last year in an article by Gordon Haff, Red Hat’s senior cloud manager, entitled “Will IaaS and PaaS Converge?”
“Simply thinking of PaaS as a higher level of abstraction than IaaS for a generic consumer of computing resources of various types,” wrote Haff, “misses an important distinction. PaaS presents an abstraction that is primarily of interest to and used by application developers. IaaS can also appeal to developers seeking more options and control, of course.”
Haff went on to say that OpenShift was specifically designed to present developers with the tools they needed to deploy applications, and then to get out of their way. PaaS may be infrastructural, in a sense, but only to developers who would not be the ones paying too much attention to its presence. For consumers of business services, by comparison, PaaS may be noticeable, ironically, for its irrelevance to their basic needs. Put another way, it’s a part of the infrastructure that everyday cloud service consumers don’t care about, so its distinction from IaaS is important primarily for that reason.
“The bottom line here is that there’s a continuum between a bare-bones IaaS and a full-fledged development platform,” concluded Haff. “This continuum can be thought of as laying along an axis from complete fine-grained control on one side to various hosted PaaSes on the other.” Even so, he reasoned, presenting both services as part of a single monolith may not be the best approach.
With version 3, OpenShift has moved away from the mechanical model that it pioneered, and completely into a Docker-based deployment model based around Kubernetes as the orchestrator.
Next in part two: The Kubernetes angle.
