The New Stack Podcast

Show 6: Kubernetes and OpenStack: Who's On First?

Episode Summary

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.

Episode Notes

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.