The New Stack Context

It wasn’t all that long ago — not quite a year — that the leaders in the OpenStack community were openly discussing whether their platform should be expected to support both conventional and cloud-native workloads simultaneously. Some expressed their fear that customers were demanding an evolutionary path, and vendors may be answering demands for such a path, that the platform wasn’t intended to take — and that contributing developers didn’t want to follow.

And on the other side of the fence, the rapid rise of Docker led some prominent voices to declare the impending death of OpenStack.

Fast-forward to last August, when Markus Riedinger, a cloud architect for SAP — an OpenStack customer, not a producer — demonstrated how he and his team produced an automated, containerized, CI/CD-compatible OpenStack in their own enterprise. It seemed as though OpenStack’s own customers couldn’t compel the platform community to adapt to the path they wanted, so they took matters in their own hands.

How SAP accomplished this was not by staging Kubernetes through an OpenStack component, or alternately, by cramming OpenStack into a container. Rather, the team re-architected the division of labor in OpenStack among multiple containers, as though it were created that way to begin with. It deliberately separated operations along the control and data planes, to maintain that division. And it created redundancies along both planes as a way of accomplishing immutable operations.

“To clearly separate control and data,” Riedinger told attendees, “allows an independent, service-level objective for the data path compared to the control [path], which also implements independent processes and procedures to scale each of the aspects — the control and the data — separately, leading to extending and fixing and improving the existing model to operate the vendor gear. SAP is quite the classical organization… no self-developed hardware. And the existing operating model should be persisted, and just fixed and extended.”

Very cleverly, Riedinger’s team leveraged the concept of decoupled services to untangle all the OpenStack components that muddle each other in the typical enterprise, along SDN-style lines of control and data. This way, it’s never a case of whether the service level of the application is being met by the underlying layer of infrastructure. Rather, it’s as if OpenStack were architected as an SDN system from the very beginning.

SAP’s project may not be the first to successfully containerize OpenStack, but it may well be one of the first to be migrated fully into production.

The subject of open source customers using open source processes to openly make software work the way they need it to — rather than to suit the marketing requirements of vendors — is the subject of the latest edition of The New Stack: Context, produced by Scott Fulton and Luke Lefler.

“Serverless computing,” at the time of this writing, is an emerging ideal that’s past the embryonic stage, yet not quite fully formed. It has a variety of advocates, some of whom make more sense than others.

But what does the term “serverless” mean, exactly? We speak with two such advocates who put forth the most sensible cases thus far: Michael Hausenblas, a developer and developer advocate at Mesosphere, and author of a recent New Stack article entitled, “Making Sense of Serverless Computing”; and Chad Arimura, the CEO of Iron.io and a previous guest of our podcasts with Alex Williams.

Our conversations with Hausenblas and Arimura were separate, but they made much the same case: specifically, for eliminating the appearance of dependencies between software currently under development, and its underlying resources and infrastructure. If you remember the era where you turned on your personal computer, saw a “READY” prompt, and everything you’d ever need to reference was on a memory map — it’s like the modern evolution of that.

When we started the whole cloud-native development paradigm, it was with the idea that the cloud could mask the details of deployment and implementation from the developer. Then when we started the whole container orchestration business, it was with this notion that the developer was the person doing the deployment and implementation. Arimura and Hausenblas suggest that, if the details of software implementation can be condensed to a more basic form, a developer could conceivably produce a draft that meets a basic requirement of a service-level agreement. This way, an automated deployment pipeline could test its container, fail it or pass it, and in the latter case, re-attach the necessary details and deploy it to production.

Imagine an operator petitioning a developer for an app that performed a function whose performance rated, say, a 7 on a 10-point scale. The developer wouldn’t need to know why, just that the performance level sits about mid-way between average and maximum. It’s not so much “serverless,” therefore, as “less server-ish.” Maybe we should attach an asterisk to “serverless,” followed by a footnote: “May contain some traces of server.”

The bigger question, though, is whether this is really “DevOps.” That is to say, does server-less-ness suggest that developers and operations professionals collaborate, or just participate in the same pipeline?

Four years ago, the virtualization industry was blown wide open by the arrival of Docker — a format which made it possible to stage workloads and scale them without the overhead of VMware, Xen, or KVM virtual machines. Last year, Docker Inc. graciously donated its container standard to the Open Container Initiative, run by the Linux Foundation — a neutral governing party. The idea was to end all the bickering over what the container format should be. Instead, what’s happening is a fresh re-opening of the debate over why there should be just one.

“I think, a couple of years down the road, people are going to be talking less and less about containers, and people are going to be talking more and more about applications again,” said Ben Hindman, the founder and lead engineer of Mesosphere.

What a bank in New York City really wants, said Hindman, is the opportunity to test an application on its data center the same way one of its executives tries out an e-mail client on her laptop. If data center apps became more analogous to mobile or desktop apps, the entire business of serving large enterprises could be revolutionized. “At the end of the day, what people care about. . . is being able to run these sophisticated, distributed applications. At least what I hope, in five years’ time from now, everyone is talking about that as an ecosystem.”

What we’ve been calling “container architecture” deals primarily with the packaging and constitution of containers — small, firmly packed virtual machines without the hypervisor. Up to now, a lot of folks thought container architecture and container orchestration were the same topic. They’re not. The critical issue that data centers are facing today is how to network their workloads. In a container network, each container has its own address. Natively, Docker creates a subnet of containers, each of which has its own port number.

For data centers where port numbers have specifically designated purposes — like port 80 for Web traffic — that won’t work. They’d already be violating compliance frameworks just for trying this. That’s why Kubernetes and Mesosphere and Docker have all adopted different means of orchestration, where each container is given its own IP address. There are different ways of doing this through network overlays, some of which scale better than others. But this does solve the problem with Docker’s native networking. However, it also solves a broader class of problem, because VMs have their own IP addresses too. As long as IP addresses provide a layer of abstraction between virtual components and their orchestrators, the substance to the argument in favor of a single container format, disappears.

In May 2015, analysts at Gartner rejected OpenStack as a viable platform, for reasons which boil down to its being disruptive. Not quite a year later, analysts at Gartner appeared on stage at OpenStack Summit in Austin, Texas, to embrace OpenStack as a viable platform, for reasons which boil down to its being disruptive. It sounded a little two-faced, as though the analysts group were presenting both a negative and a positive view of a cause-and-effect relationship simultaneously.

But when Gartner analyst Donna Scott showed up last April to make peace with OpenStack, what she said outright struck many attendees as startling. She offered bimodal IT to IT professionals as a metaphorical tool, quite literally to give their business managers the perception that the IT department was moving at warp speed, when not everything actually is.

Gartner and OpenStack have kissed and made up. And in a clear and sharp clarification of the emerging battle lines, two weeks ago at DockerCon in Seattle, Docker CEO Ben Golub told attendees that Gartner will not be invited to any of his parties soon.

“The data is also clear,” Golub explained, “that as people are adopting Docker, it’s no longer simply for next-generation, greenfield microservices applications. While clearly the top use cases are in areas like that… one of the most common use cases for Docker is migrating legacy apps to microservices. And an equally common use case is containerizing legacy apps. You might say, ‘Containerizing a legacy app? That’s heresy!’ But in fact, there are really good reasons to take a legacy app, Docker-ize it, and then move it around.”

Docker’s customers are looking to employ containerization as a way to mix applications in a unified environment, he explained, not partition them into metaphysical states of being. He singled out bimodal IT specifically as a “fallacy,” suggesting that the effort involved in making old applications coexist with new models could be described as “Mode 2,” and that the migration process requires careful consideration and planning that Gartner would describe as “Mode 1.”

The reconciliation between the old and the new models, and the disagreements with the bimodal concept — which extend to OpenStack and OpenShift leader Red Hat as well as Docker — are the subject of this week’s edition of The New Stack: Context, a podcast produced by Scott Fulton and Luke Lefler.

Our latest edition of The New Stack: Context dives nose-first into three sides of the container security pond simultaneously, to see which side cracks first. In this podcast, you’ll hear more from our visit to the Cloud Security Alliance summit at the last RSA Conference, where we’ll talk to the cloud service provider community and the security services community. And we’ll compare their vantage points to that of Docker, which so far has had to go it alone with respect to forging a new model for infrastructure security.

The one most prophetic, emerging fact of life in a technological world where open source is the most prominent ethic, is that there may always be more than one open methodology contending for the same market space, at any one time. The moment enough factions come together around a single methodology, such as pooled storage or application orchestration, another group of factions come together around a viable competitor. An open source world will perpetually be a contest of ideas.

For OpenStack, which has just emerged triumphant in the battle for the open source hybrid cloud platform space, its next great contest has already begun. It needs to become capable of scaling high-availability, high-bandwidth workloads, including the network functions used by customers in the telecommunications space, with a mechanism other than the ones it has now. AT&T has surged into a leadership position very rapidly, having thrown down the gauntlet last March, pushing open source developers to help it build its next-generation data network services. It uses OpenStack now, but it can’t deploy OpenStack in any of the ways it’s been designed.