OpenStack developers have taken their first key steps to reduce interdependencies between the different parts of OpenStack, allowing some of the pieces to be more easily used individually and alongside other open source tools.

Executive director of the OpenStack Foundation, Jonathan Bryce, laid out a strategy to make the open cloud management software more modular and “composable” at its Boston summit earlier this year.
The move, in effect, mirrors the way some end users already treat OpenStack: rather than running it as a whole suite, they want to pick and choose the bits that suit them, and incorporate them into existing environments alongside other open source or proprietary tools.
CBA is a case in point. Underpinning an artificial intelligence and machine learning effort that spans several bank functions is understood to be a platform consisting of OpenStack’s Ironic for bare metal provisioning, Apache Mesos for containerisation, and the Google-developed deep learning algorithmic library Tensorflow.
The bank uses other parts of OpenStack alongside different open source technologies as part of a new private cloud environment.
Though the various parts of OpenStack have always been tightly integrated, customers have been traditionally on their own if they wanted to integrate OpenStack components with anything else.
“You sort of had to put it together yourself,” Bryce said.
But this mindset is shifting, not just in the OpenStack community but in open source in general, he claims.
“A few years ago I think a lot of people in the OpenStack community thought about what services are we going to build, whereas now it’s what are the services that our users want to run,” Bryce said.
“One of the shifts we’re really seeing this year is this view of how do we integrate open technologies in the best way for users.”
While open source has been around for decades, Bryce said there had been a historical tendency to develop in silos.
The problem is many potential users struggle with or aren’t excited by the prospect of integrating all the pieces they needed.
“The reason that proprietary technologies have often succeeded against open technologies has been because the proprietary companies do a really good job of integration. If you look at Oracle or Microsoft for instance, or even Google and Amazon in the services world, they deliver things tightly integrated and pre-packaged,” Bryce said.
“Historically I think the open source world has built a lot of great technology but in some ways we’ve built these technologies isolated from each other versus integrated.
“I think the shift now, not just in OpenStack but across the open source ecosystem, is an understanding that users want all these capabilities but they want them to work well together and they want to have a good experience.
“That’s why it’s important that we see this concept of composability making its way into the upstream developer community and into the way that our developers are building software.”
OpenStack’s latest release, codenamed Pike, sees two products in the stack - Ironic, which is used for bare metal provisioning, and Cinder, the project’s block storage component - reworked so they can better exist standalone and natively integrate with other common open source technologies.
“Where we see Cinder being integrated in a standalone way a lot [is] with container technologies,” Bryce said.
“A lot of times one of the areas people have difficulties ... on their own is how they connect them securely and in an automated way into their enterprise storage or network.
“This was something that people have been doing for years through different unsupported or unofficial plugins, but in Pike the development team put some effort into really supporting that kind of standalone model as a native deployment mode for Cinder.”
Cinder “can now act as a standalone storage service for virtual machines, bare metal, or containers using Docker or Kubernetes”, the OpenStack Foundation said in a statement.
Next steps to composability
Makings other elements of OpenStack - outside of Ironic and Cinder - composable is anticipated in future releases of the software.
The next two releases are codenamed Queens and Rocky.
“I think we’ll see good progress with it on both those releases,” Bryce said.
“Where I think we can still do better on some of that composability is around components like the identity management piece and the networking piece.
“Again we have users that are using those pieces with other technologies but it’s not built directly into the way they operate in a really standard and supported way.
“You could say we’re doing pretty well with composability in a couple of areas and we have some more work to deliver on this idea that you can mix and match Openstack technologies really easily with open source technologies.”
While composability is likely to aid a lot of traditional enterprise projects by making it easier to incorporate elements of OpenStack, Bryce also expects the rise of edge computing to drive composability across open source ecosystems.
“I think edge computing - this whole move to put compute resources out [at the edge] but where you still want them to be automated and accessible - is going to be a force for some of this work,” he said.
“The reality is that right now none of the technologies any of us are using are capable of doing that, whether open source or proprietary.”
For OpenStack, this meant facing up to the realisation that no-one - itself included - “gets to control the whole stack anymore”.
“We have to work with a lot of other technologies and in order to do that it means breaking down some of the tight integrations inside of OpenStack components so that external components have better access and cleaner APIs and more consistent experience as they try to work with those OpenStack services,” he said.