At the Cloud Foundry Summit event in Basel, Switzerland (Oct 9 – 12, 2018), there was a lot of talk about the impact of Kubernetes and Cloud Foundry technologies on each other. This is an area of great interest also for the SAP Cloud Platform developer community. If you are new to this topic or just feeling overwhelmed by all the discussion, you may find this blog useful. I am going to compare the basics of Cloud Foundry and Kubernetes technologies, and provide an overview of their potential integration.
SAP continues to be deeply engaged in the Cloud Foundry community. SAP has been a Platinum member of the Cloud Foundry Foundation, a regular sponsor of the Cloud Foundry Summit events as well as Cloud Foundry Days. More importantly, SAP has become the second largest contributor to the Cloud Foundry open-source code base. Today, Cloud Foundry environment of SAP Cloud Platform is utilized by customers for accelerated business innovation, via its support for agile, open and simplified cloud-native application development.
At the same time, the topics of containerization and Kubernetes as the standard container orchestration technology are not new for SAP. Several SAP solutions such as SAP Data Hub, SAP Concur and SAP Cloud Platform services such as Machine Learning and Blockchain have been using container technologies successfully. To represent the interests of its customers and ecosystem, SAP joined the Cloud Native Computing Foundation as a Platinum level member and became active in its open source projects. I gave a talk about why SAP cares about Kubernetes when we already have Cloud Foundry at an earlier event this year. At the recent SAP TechEd event in Las Vegas, we also announced private beta release of Kubernetes as a Service on SAP Cloud Platform.
It was therefore natural for SAP to promote an open dialogue in the open source community on the topics of Cloud Foundry and Kubernetes by sponsoring the Containers and Serverless track at the Cloud Foundry Summit in Basel. This blog is essentially a quick summary of the opening talk I gave to kick off the wonderful line-up of talks in this track.
So, let us start with a quick comparison of these technologies. How about lightening the mood with a bit of poetry! I think the Cloud Foundry haiku and the Kubernetes haiku noted below nicely reflect upon their key philosophies.
On one hand, Cloud Foundry allows developers to focus on the application code and frees them from the burden of lower level concerns — gathering the required binaries of runtimes and frameworks, creating deployments, configuring the infrastructure, standing up the instances, handling the plumbing between components, managing scaling, logging, security and all the good stuff typically needed for running a Cloud application. So, clearly, we all love the simplicity, power and abstraction offered by ‘cf push’. The Cloud Foundry community has been mastering this art since a long time.
On the other hand, the developers gathering around the Kubernetes technology do not need or like the idea of being distanced from the lower level decisions about scheduling of instances, allocation of resources, networking configurations, etc. These developers want to customize the infrastructure utilization to optimally suit the needs of their applications. There are lot of use cases that justify this approach.
Both approaches have their own merits and as you can imagine, it gets complicated when both options are good …
The simplicity provided by an opinionated platform is attractive as it shields the developers from the complexities of the underlying componentry and infrastructure. Simplicity leads to faster pace of innovation, which in turn enables businesses to become agile in responding to market demands. But not all applications are simple, stateless and so called ’12 factor’ apps. There are several scenarios where opinionated abstractions become hindrances for developers in applying their deeper domain knowledge and crafting systems with optimal design, consistent deployments and superior performance. Kubernetes has become the popular choice of technology for such scenarios.
Now let us look at these stacks a bit closely. We will still stay at a higher level, since a detailed comparison will be just too much to handle here.
In the Cloud Foundry world, the platform supports the simplified abstraction for developers and takes care of the heavy lifting involved behind the scenes for creating deployments, scheduling and running the applications at a cloud scale. Furthermore, Cloud Foundry technology has in-built abstractions, namely BOSH CPI, for running the platform on a variety of infrastructure options. Today, using this functionality, the Cloud Foundry environment of SAP Cloud Platform is made available on multiple hyperscale clouds like AWS, GCP and Microsoft Azure.
On Kubernetes, support for running the Kubernetes clusters on different infrastructure options is also well established. With its flexible and extensible architecture comprising of lower level constructs (in comparison to Cloud Foundry) like pods, replica sets and deployments, it becomes possible to containerize legacy applications or build new complex applications and stateful services. In addition, the Kubernetes community has also recently started to build PaaS functionalities via Knative and related projects so that you can now also push 12 factor apps to a Kubernetes cluster and let the platform manage the app instances, handle their autoscaling, blue-green deployment, etc. Similarly, the notion of Functions-as-a-Service is finding more traction with the ability of container-based environments to easily package discrete application code which can be instantiated only upon certain events or incoming requests, etc. In general, cloud platforms are offering capabilities with different levels of abstraction and programming paradigms such as – Container-as-a-Service (CaaS), Platform-as-a-Service (PaaS) and Function-as-a-Service (FaaS), which are better leveraged when offered in an integrated manner - an approach taken by SAP Cloud Platform (see Matthias Steiner’s strategy talk at SAP TechEd 2018 Las Vegas for details)..
Running the stacks together
Now, when we must run both of these stacks in parallel, the picture will look something like this.
While the picture isn’t necessarily bad, it does raise some questions.
Primarily, there are many areas with duplication of engineering efforts, since both stacks have some common functionalities like scheduling, routing, logging, scaling, etc. Some of these areas of duplicate efforts are already recognized by the Open Source community and we are seeing a decent amount of give and take between these communities. For example, similar to Kubernetes, there is increasing adoption of Istio and Envoy in Cloud Foundry. Likewise, some key concepts from Cloud Foundry like buildpacks are headed to become a citizen in the Kubernetes universe.
In addition, here are some main projects or workstream under the Cloud Foundry Foundation aimed at driving the needed integration between Cloud Foundry and Kubernetes technologies.
Amongst other topics, the first workstream is aimed to enable sharing of services via Open Service Broker API as well as reuse of components across the two stacks. SAP is currently leading the project peripli which allows for publishing and consuming services across disparate environments – a powerful concept which can help bridge not just the Cloud Foundry and Kubernetes environments but also Neo, ABAP and other environments in the future.
The second project aims at replacing Diego, the Cloud Foundry scheduler with Kubernetes scheduler so that workloads pushed to Cloud Foundry platform can be scheduled to run on Kubernetes clusters. This project, called Eirini, is led by IBM in collaboration with engineers from SAP.
Taking this further, the third project is aimed at containerized the entire Cloud Foundry control plane so that Cloud Foundry can run directly on top of Kubernetes. This project is led by SUSE with active contributions from IBM with SAP ramping up to support the project.
You can check out the recent update by Cloud Foundry Foundation for details of the above projects.
So, what is SAP’s take on the future of whether and how these stacks will come together?
As mentioned earlier, we see value in both Cloud Foundry and Kubernetes technologies as they each support different scenarios as their core offerings. At the same time, since both these technologies are platform technologies in a generic sense, there are concerns about duplication of efforts and more importantly confusion in the industry about their positioning and future.
As a responsible member of both Cloud Foundry and Kubernetes communities, we are taking a leading role in driving reuse of components, integration of technologies as well as alignment of positioning across these communities. SAP is engaged in all the three integration work streams described earlier, with a leading role for one of them.
Here is a take on SAP’s vision for how these stacks will come together. This was presented by Bernd Krannich during his talk on The Shape of Things to Come: Predictions on the Future of PaaS at the recent CF Summit Basel event.
Having worked at SAP for over 15 years, I can say that, for SAP, technology is always a means to an end – to deliver business value to customers and partners. In the case of SAP Cloud Platform, one of the main drivers is to help customers innovate faster by providing a wide array of choices for technologies and infrastructures.
We consider it important to abstract away the changes in the lower level technologies and provide a holistic, integrated, multi-cloud foundation which includes:
At the same time, the differentiation of SAP Cloud Platform is largely due to the services offered on top of the multi-cloud foundation -- a rich set of platform and innovation services (such as SAP HANA, IoT, Machine Learning, Blockchain, Analytics, Mobility and others) and more importantly business services (such as currency SAP Localization Hub Tax, SAP Cloud Business Partner, and SAP Watch List Sneering) based on the decades of experience SAP has in the enterprise application space. For further details, please check out this blog by Matthias Steiner about - How SAP Cloud Platform powers the intelligent enterprise.
If you are reading this blog until this point, then you must really be interested in this topic, and I would be quite interested in hearing comments from engaged community members like you ….
SAP continues to be deeply engaged in the Cloud Foundry community. SAP has been a Platinum member of the Cloud Foundry Foundation, a regular sponsor of the Cloud Foundry Summit events as well as Cloud Foundry Days. More importantly, SAP has become the second largest contributor to the Cloud Foundry open-source code base. Today, Cloud Foundry environment of SAP Cloud Platform is utilized by customers for accelerated business innovation, via its support for agile, open and simplified cloud-native application development.
At the same time, the topics of containerization and Kubernetes as the standard container orchestration technology are not new for SAP. Several SAP solutions such as SAP Data Hub, SAP Concur and SAP Cloud Platform services such as Machine Learning and Blockchain have been using container technologies successfully. To represent the interests of its customers and ecosystem, SAP joined the Cloud Native Computing Foundation as a Platinum level member and became active in its open source projects. I gave a talk about why SAP cares about Kubernetes when we already have Cloud Foundry at an earlier event this year. At the recent SAP TechEd event in Las Vegas, we also announced private beta release of Kubernetes as a Service on SAP Cloud Platform.
It was therefore natural for SAP to promote an open dialogue in the open source community on the topics of Cloud Foundry and Kubernetes by sponsoring the Containers and Serverless track at the Cloud Foundry Summit in Basel. This blog is essentially a quick summary of the opening talk I gave to kick off the wonderful line-up of talks in this track.
So, let us start with a quick comparison of these technologies. How about lightening the mood with a bit of poetry! I think the Cloud Foundry haiku and the Kubernetes haiku noted below nicely reflect upon their key philosophies.
On one hand, Cloud Foundry allows developers to focus on the application code and frees them from the burden of lower level concerns — gathering the required binaries of runtimes and frameworks, creating deployments, configuring the infrastructure, standing up the instances, handling the plumbing between components, managing scaling, logging, security and all the good stuff typically needed for running a Cloud application. So, clearly, we all love the simplicity, power and abstraction offered by ‘cf push’. The Cloud Foundry community has been mastering this art since a long time.
On the other hand, the developers gathering around the Kubernetes technology do not need or like the idea of being distanced from the lower level decisions about scheduling of instances, allocation of resources, networking configurations, etc. These developers want to customize the infrastructure utilization to optimally suit the needs of their applications. There are lot of use cases that justify this approach.
Both approaches have their own merits and as you can imagine, it gets complicated when both options are good …
The simplicity provided by an opinionated platform is attractive as it shields the developers from the complexities of the underlying componentry and infrastructure. Simplicity leads to faster pace of innovation, which in turn enables businesses to become agile in responding to market demands. But not all applications are simple, stateless and so called ’12 factor’ apps. There are several scenarios where opinionated abstractions become hindrances for developers in applying their deeper domain knowledge and crafting systems with optimal design, consistent deployments and superior performance. Kubernetes has become the popular choice of technology for such scenarios.
Now let us look at these stacks a bit closely. We will still stay at a higher level, since a detailed comparison will be just too much to handle here.
In the Cloud Foundry world, the platform supports the simplified abstraction for developers and takes care of the heavy lifting involved behind the scenes for creating deployments, scheduling and running the applications at a cloud scale. Furthermore, Cloud Foundry technology has in-built abstractions, namely BOSH CPI, for running the platform on a variety of infrastructure options. Today, using this functionality, the Cloud Foundry environment of SAP Cloud Platform is made available on multiple hyperscale clouds like AWS, GCP and Microsoft Azure.
On Kubernetes, support for running the Kubernetes clusters on different infrastructure options is also well established. With its flexible and extensible architecture comprising of lower level constructs (in comparison to Cloud Foundry) like pods, replica sets and deployments, it becomes possible to containerize legacy applications or build new complex applications and stateful services. In addition, the Kubernetes community has also recently started to build PaaS functionalities via Knative and related projects so that you can now also push 12 factor apps to a Kubernetes cluster and let the platform manage the app instances, handle their autoscaling, blue-green deployment, etc. Similarly, the notion of Functions-as-a-Service is finding more traction with the ability of container-based environments to easily package discrete application code which can be instantiated only upon certain events or incoming requests, etc. In general, cloud platforms are offering capabilities with different levels of abstraction and programming paradigms such as – Container-as-a-Service (CaaS), Platform-as-a-Service (PaaS) and Function-as-a-Service (FaaS), which are better leveraged when offered in an integrated manner - an approach taken by SAP Cloud Platform (see Matthias Steiner’s strategy talk at SAP TechEd 2018 Las Vegas for details)..
Running the stacks together
Now, when we must run both of these stacks in parallel, the picture will look something like this.
While the picture isn’t necessarily bad, it does raise some questions.
Primarily, there are many areas with duplication of engineering efforts, since both stacks have some common functionalities like scheduling, routing, logging, scaling, etc. Some of these areas of duplicate efforts are already recognized by the Open Source community and we are seeing a decent amount of give and take between these communities. For example, similar to Kubernetes, there is increasing adoption of Istio and Envoy in Cloud Foundry. Likewise, some key concepts from Cloud Foundry like buildpacks are headed to become a citizen in the Kubernetes universe.
In addition, here are some main projects or workstream under the Cloud Foundry Foundation aimed at driving the needed integration between Cloud Foundry and Kubernetes technologies.
Amongst other topics, the first workstream is aimed to enable sharing of services via Open Service Broker API as well as reuse of components across the two stacks. SAP is currently leading the project peripli which allows for publishing and consuming services across disparate environments – a powerful concept which can help bridge not just the Cloud Foundry and Kubernetes environments but also Neo, ABAP and other environments in the future.
The second project aims at replacing Diego, the Cloud Foundry scheduler with Kubernetes scheduler so that workloads pushed to Cloud Foundry platform can be scheduled to run on Kubernetes clusters. This project, called Eirini, is led by IBM in collaboration with engineers from SAP.
Taking this further, the third project is aimed at containerized the entire Cloud Foundry control plane so that Cloud Foundry can run directly on top of Kubernetes. This project is led by SUSE with active contributions from IBM with SAP ramping up to support the project.
You can check out the recent update by Cloud Foundry Foundation for details of the above projects.
So, what is SAP’s take on the future of whether and how these stacks will come together?
As mentioned earlier, we see value in both Cloud Foundry and Kubernetes technologies as they each support different scenarios as their core offerings. At the same time, since both these technologies are platform technologies in a generic sense, there are concerns about duplication of efforts and more importantly confusion in the industry about their positioning and future.
As a responsible member of both Cloud Foundry and Kubernetes communities, we are taking a leading role in driving reuse of components, integration of technologies as well as alignment of positioning across these communities. SAP is engaged in all the three integration work streams described earlier, with a leading role for one of them.
Here is a take on SAP’s vision for how these stacks will come together. This was presented by Bernd Krannich during his talk on The Shape of Things to Come: Predictions on the Future of PaaS at the recent CF Summit Basel event.
Having worked at SAP for over 15 years, I can say that, for SAP, technology is always a means to an end – to deliver business value to customers and partners. In the case of SAP Cloud Platform, one of the main drivers is to help customers innovate faster by providing a wide array of choices for technologies and infrastructures.
We consider it important to abstract away the changes in the lower level technologies and provide a holistic, integrated, multi-cloud foundation which includes:
- Flexibility of choosing public infrastructures such as AWS, Microsoft Azure, Google Cloud, Alibaba and SAP Data Center, as well as private cloud options via partnerships with IBM, Atos and others.
- An open-standards based simple, unified and enterprise-ready platform for serverless functions, stateless applications and containerized applications with its support for multiple, interoperable technical environments -- Cloud Foundry, Kubernetes, Neo and ABAP. Note that the Service Manager plays a central role in this vision and allows for cross-consumption of services regardless of their provisioning environment.
At the same time, the differentiation of SAP Cloud Platform is largely due to the services offered on top of the multi-cloud foundation -- a rich set of platform and innovation services (such as SAP HANA, IoT, Machine Learning, Blockchain, Analytics, Mobility and others) and more importantly business services (such as currency SAP Localization Hub Tax, SAP Cloud Business Partner, and SAP Watch List Sneering) based on the decades of experience SAP has in the enterprise application space. For further details, please check out this blog by Matthias Steiner about - How SAP Cloud Platform powers the intelligent enterprise.
If you are reading this blog until this point, then you must really be interested in this topic, and I would be quite interested in hearing comments from engaged community members like you ….
- SAP Managed Tags:
6 Comments
