OpenStack: ‘We Continue to Get Dinged On Complexity’
It was only one T-shirt amongst the crowd of attendees at Monday’s opening day of OpenStack Summit 2017 in Boston, but it spoke on behalf of a good many others: “Make OpenStack Great Again.” The crowd was noticeably scaled back over the Austin show the previous year, due in some part, organizers said, to a decoupling of events from one another, and a convergence of other Boston tech events – Red Hat Summit among them – in the matter of just a few weeks.
But scaling back may not be a bad thing. In fact, for this particular organization which already has a reputation for forthright talk and a minimum of marketing-speak, one step back may be the first step to taking two new steps forward.
“We continue to get dinged on the complexity of operating OpenStack,” stated Lauren Sell, vice president of marketing for the OpenStack Foundation, not quite 11 minutes into the keynote session. Sell was speaking about the feedback the Foundation has been receiving from users since several of the system’s contributors recently came together for an extensive set of workshops.
“This is something we’re really taking to heart,” continued Thierry Carrez, the Foundation’s vice president of engineering. “Shortly after the workshop, we started to more actively identify areas where we can address this complexity in projects, by removing unused features, or pruning extraneous configuration options, or cutting projects that were not going anywhere.”
Loud and Clear
There is no subtlety about the Foundation leaders’ admission that they’re getting the message, loud and clear, from their users and contributors. Although Executive Director Jonathan Bryce led the keynote by citing figures from last month’s OpenStack users’ survey, and making the case that the rumors of its death are greatly exaggerated, he quickly ceded the floor to Carrez and Sell. Immediately, they addressed pressing concerns about the infrastructure software’s evolutionary path.
“Another perception concern that we identified is this view that OpenStack is an all-or-nothing monolith,” said Carrez, “that you have to actually install all the OpenStack projects, or that you can’t really plug any other technology into an OpenStack deployment. Which is, if you think about it, weird, because OpenStack was always an open stack. We always integrate lots of different technologies that were not produced within the OpenStack community.”
In Douglas Adams’ “The Hitchhiker’s Guide to the Galaxy,” a frequently used form of punishing citizens was to expose their brains to a full-scale map of the universe, complete with a minuscule dot marked, “You Are Here” – thus revealing the scale of their insignificance.
Revealing a similarly gut-punching map of the role of OpenStack in modern network deployments, Mirantis Chief Marketing Officer Boris Renski depicted OpenStack as just one horizontal layer in a veritable crêpes soufflé of networked systems – a big stack where OpenStack wasn’t even a stack.
Renski’s case was that vendors – even the vendors that contribute to OpenStack – have as their principal goal the distribution of their customers across the given horizontal layer of their market, such as the network or the application or the management layer. OpenStack fulfills the infrastructure role, but that’s just one layer. By contrast, the goal of an individual working in enterprise IT may be to deliver one function, which transcends all of these layers.
In this way, he argued, the goals of vendors and service providers tend to run orthogonally to those of IT admins and integrators. Oftentimes, OpenStack has been portrayed as having taken the perspectives of its contributors into account – contributors who include IT personnel relegated to single functions. Here, Renski stopped just short of saying the Foundation’s own marketing has been self-contradictory. To their credit, vendors do try to resolve the issue by developing modes of interoperability. But then, he said, all those development trials and experiments end up conflicting with one another.
“If I am an enterprise hypervisor vendor,” said Renski at one point, “or an enterprise Linux vendor, part of the enterprise is really about making sure that my enterprise stuff interoperates well with all of the other enterprise elements of the stack.” That feat is typically accomplished through certification, which gives purchasers assurances that a chain of products should work well together.
“Of course, all of that work of interoperability testing, and then packaging all of this interoperability with elegant product marketing collateral, costs money,” Renski continued. “And the same goes for enterprise network, and the same goes for enterprise storage, etc., etc.
“Now, if I’m an enterprise systems administrator or an enterprise Linux administrator, this is great, because what that means is that I can learn one SDN from the top number one vendor that is interoperable with all the other enterprise stuff, I get certifications to put on my résumé, and my skill set is applicable across all different silos, and even outside the place where I work. So I, naturally, will push this horizontal design pattern across all the elements of the stack, to build this private cloud.”
When a vendor certifies an IT professional, those certifications usually match the chain of products that comprise that vendor’s given horizontal layer, he noted. But take for instance that single-function fellow, asked to build an enterprise cloud.
“This guy is on the hook to deliver business results, business outcomes. And this guy doesn’t really care about whether the SDN or the storage will interoperate with all different kinds of things. The most important thing for this guy is that the storage, the SDN, and all the other elements that go into the stack, work really well together,” he said. “That’s the only thing that matters. But if I’m this [other] guy inside the traditional enterprise, unfortunately, I can’t just say, ‘Hey, I’m going to build my own stuff out of open source I’ll find somewhere. I have to deal with the unfortunate enterprise pattern that has been primarily dominated by the notion of selling enterprise software licenses, or enterprise software subscriptions.’”
The talk summed up, if not succinctly then still neatly, the intensity of the problem facing any organization whose goal is to bring together the leading engineers and the leading vendors. It revealed why the two realms perceive their goals somewhat differently. Rensky did propose the beginning of a solution, which he described as altering the “customer-obsessed” mantra of Rackspace to reflect a better understanding of who the customer is, and where she stands with respect to the world we think we’ve built for her.
As Jonathan Bryce assumed the stage again, for a moment, he was noticeably speechless.
Also Starring OpenStack
One peek at the sessions list for OpenStack Summit this week would give one the impression that this was KubeCon, the user conference for the Kubernetes open source container orchestration software. Kubernetes may not have sucked all the air out of the Boston Hynes Convention Center just yet, but there is a very noticeable draft. Even though Tuesday is officially “Kubernetes Day,” there were overlapping Kubernetes sessions on the Monday docket, including one whose presenter suggested that the orchestrator can, and perhaps should, be deployed in two layers of the network simultaneously, with OpenStack between them.
“Kubernetes on OpenStack seems like a strange thing to do,” explained Eric Wright, a solutions architect with Toronto-based network services provider Turbonomic, “when you can run it further down onto bare metal and such.
“This is the question we should always ask ourselves: When have we gone from, ‘Can we do this?’ to ‘Should we do this?’ So why, why-y-y-y-y, would you run Kubernetes on top of OpenStack?”
Wright offered three compelling reasons, one of which is the need to move an application from the development to the production stage without having to requisition a half-ton of spare hardware. Kubernetes can ease the shift, he argued, even while OpenStack manages the underlying infrastructure layer.
Wright expounded on the benefits of meshing Kubernetes and OpenStack together into what he called a “club sandwich.” We will continue to investigate whether or not attendees and other presenters feel that’s an appetizing approach.
