Context: Kubernetes, OpenStack and How SAP Built its Own Containerized Platform
In this episode of The New Stack Context, we look at the question of Kubernetes, OpenStack and the role that the enterprise has in using open source software to build their own infrastructure.
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 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.
CoreOS, mentioned in the podcast, is a sponsor of The New Stack.