Just about anything that was being delivered to clients by server was being portrayed as “the cloud” until September 2011, when the National Institute of Standards and Technology published its three-part definition of things that the U.S. Government would legitimately consider “as-a-Service.” Fundamental resources such as storage and processing constituted infrastructure services, and the applications built with those resources were built on platform services.
It’s as simple a distinction as a boat from the person in the boat. The new stack, such as it is, began making sense that day.
But as we continue to stack things atop one another like a toddler in a room full of blocks, whatever we use to support whatever else we’ve stacked on top becomes “the platform.” And when commercial interests get involved in the stacking process, you often find they like to offer all-in-one “integrated” stacks, touting maximum value and minimum effort.
Last Monday, Red Hat kicked off its participation in this year’s OpenStack Summit in Vancouver with an announcement that it will soon be offering its OpenShift applications platform, its own edition of OpenStack (based on RHEL), and its CloudForms management service as an “integrated” Cloud Suite for Applications. Although part of the whole premise of open source is the preservation of the user’s options for choice, as one Red Hat official explained to me, its customers are choosing these platforms together anyway, so why not make it official?
Actually, Red Hat’s logic runs a bit deeper than that. For well over a year, the company has held an open dialogue with the public over the subject of whether IaaS and PaaS are merging — or, seen from another angle, whether the distinctions between them have grown trivial in the light of evolution.
Granted, one has just cause for suspicion whenever a vendor raises the prospects of “merging” or “converging” or “integrating” one platform that’s open among different vendors, and one that’s pried open to some extent by a single vendor. (More ActiveX, anyone?) But the question of whether the infrastructural and interpretive components of the stack must remain separate products when offered commercially, is a valid one to be asking, even if there ends up being a valid answer.
It’s a topic that came up in a discussion last Tuesday in a discussion with Red Hat strategy leader Lars Herrmann, who spoke with The New Stack from the OpenStack Summit. Given that Red Hat has announced at various times over the past two years that it has “reworked” its OpenStack-relevant components, including OpenShift PaaS, for Docker container support, and that they announced the same thing just this week, I asked Herrmann for a better understanding of what was reworked and when.
Lars Herrmann, general manager for Red Hat Enterprise Linux and Containers: There is an aspect of maturity of the technology universe. Specifically, if you go back four or five years when we started going big as an industry, we started doing big things about cloud, dynamic workloads, self-service, to overcome the slowness and obstacles that existed in enterprise IT. That was when the categories were created that we still use today: infrastructure-as-a-service, platform-as-a-service, etc. And they were largely defined along, how much abstraction do they provide from the underlying hardware?
It was kind of a bottom-up view. And what we find is, five years later, this bottom-up view is no longer most important. What is now most important is actually working its way from the application down. It has become [a matter of] top-down rather than bottom-up. And as such, what we used to call “platform-as-a-service,” which was specifically associated with runtime applications — dynamic, scalable, auto-scale, HTTP front-ends, programming languages and frameworks — every PaaS was basically providing value along these lines, targeting these applications. Cloud Foundry would talk to you about “12-factor applications,” which is a very tiny subset of applications.
Now, as an industry, we have matured the cloud content to reach much further than just these next-generation applications that need this high degree of agility and elasticity. Customers realize that they need the same benefits of agility, of efficiency, of a high degree of automation, across everything they do, which puts pressure on the platform.
We have reacted to this by completely re-innovating around the container stack, to make it more general-purpose. There is a maturing of what customers think they want to do with these solutions and platforms. At the same time, there is an expansion in scope towards a more general-purpose set of workloads, starting from a relative niche focus to going really broad. That’s one dimension; I would probably label it a maturity of the category of the technology stack, but at the same time, the driving force is the expansion of scope.
The second dimension connects to what I said earlier about the bottom-up: The reason why we had this conversation five years ago from the bottom-up — looking at infrastructure-, then going to platform-, then reaching into software-as-a-service, or eventually to anything-as-a-service — is that, from a technology and innovation point of view, you actually have to work your way up. That’s exactly what our opportunity has been over the last two or three years. In driving that next-generation technology stack, we had to solve a lot of underlying, plumbing-level problems.
Linux containers are pretty solid now. It’s enterprise-grade; we’ve had years of experience, and large-scale infrastructures are built on it. Then you get to the next level, which is the basic OS-level plumbing that allows you to take things like networking, storage, and identity across those boundaries into the cluster. That’s what OpenStack does very well, and it took some time to reach that level of maturity that it’s really ready for the enterprise. Now we’re bringing this up into the container level, and marrying it with the technologies and workflows that the developer will use to achieve continuous integration, to achieve a segregation inside the organization so they can manage independently all the different projects and applications without getting in the way of each other.
They had to work their way from the bottom up, from the technology stack point of view, in order to have the right problems solved at the right time.
[Herrmann goes on to explain that, over the last eight months, Red Hat has been working on giving OpenShift a complete view of the foundation of the containerized ecosystem, when OpenStack already achieves this through RHEL, since Linux is that foundation. OpenShift has typically been deployed on single hosts, but now that it can be deployed on multiple hosts, it provides a single cluster view for applications. It’s a foundational task, but it’s being pushed further up the stack, he says. Then CloudForms, as part of Red Hat’s new suite, provides an aggregate view of infrastructure being purposed for microservices as well as for conventional VMs — a simplified, yet abstracted, view of the underlying plumbing.
His point is, when all three of these components have fully evolved, the dividing line between whether they serve the infrastructure or application layer is substantially blurred.]
Scott Fulton, The New Stack: If we’re flipping things to look at them from the top down, from the application level down rather than from the infrastructure level up, should we be considering, in that new model, that we’re looking from the container level down? Or is that the wrong level?
Lars Herrmann: That becomes a function of whom you talk to. If you talk to somebody in the organization whose primary responsibility is the infrastructure — basically, “Here’s your customer profile, here’s all the applications and business lines you have to support, here is all your existing legacies that you already have, all the vendors, all the technologies, all the skill sets and the staff you have … now go build something.” For this group, the ops-centric group, yes, they probably look from the container down, because that is the point of where they offer their services. They basically offer to the apps people, to the line of business, “You deliver your applications in this mixed container paradigm, and I know how to run it well; and, by the way, here are the rules for how you have to do this in order for me to manage things like security and scale.” They look from the container down, because the container defines their service levels that they offer to their internal or external customers.
The line-of-business doesn’t really care how the service is provided by IT. In fact, we’ve seen over the last five years that, if IT wasn’t able to do a good job of providing these services to serve the needs of the application, they just went elsewhere — public cloud, or something like that. They found a way to serve their needs. So from a line-of-business or application development perspective, it is actually from their business objective backwards or down. They say, “I need an application that scales dynamically, that can serve millions of users one day, and a lot less than that another day. And I want to be agile and nimble in driving change into my application.” These are their requirements, and they will need a way for them to be satisfied.
From the apps side, they look from the app code down; from the infrastructure guys, from the container down. And yet, they are basically managing the same entities in a very similar way, which creates extra synergy inside the organization, and allows them to overcome the agility gaps that they had been battling for so long.
Red Hat is a sponsor of The New Stack.
Feature image via Flickr Creative Commons.