The New Stack: Context
About This Show
Scott Fulton narrates stories about how app development and management at scale is creating a fast adapting, developer-oriented business that operates on services and software across distributed infrastructure to create market advantages. The series will focus on the issues companies face when scaling, with stories from people who have had to work through complex issues to create continuous delivery workflows and microservices architectures that fit with business requirements. These kinds of companies often face stressful cultural problems that affect the overall organization. The show will explore how the organization adapts and what it means to be a new stack organization.
Most Recent Episode
Show 6: Kubernetes and OpenStack: Who's On First?
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.