Main content

Is Kubernetes SAP Leonardo's Mona Lisa? The role of Kubernetes in the SAP Cloud

Dick Hirsch Profile picture for user rhirsch November 12, 2017
Just in time for SAP TechEd Barcelona, Dick Hirsch unearths the surprising connections between Kubernetes, Cloud Foundry and the SAP Cloud. The kicker question: what does the mean for customers, and the developer community?

The recent SAP TechEd Las Vegas keynote was so packed full of announcements that many of them went by so fast that you didn’t have time to reflect on what they really meant - for example, SAP’s decision to join the Cloud Native Computing Foundation.

This organization is the controlling body behind Kubernetes (the open source project that acts as an orchestration layer for containers). In the associated press release, Björn Goerke (president SAP Cloud Platform and chief technology officer) stated:

SAP is investing in partnerships that we believe will modernize the enterprise. Cloud native technologies like Kubernetes and containers are key to enabling that process. We have found Kubernetes to be a modern, matured cluster management software and orchestration engine for SAP’s own projects designed with container-based architecture.

This statement was pretty general. What exactly was the role of Kubernetes in SAP’s cloud and product strategy? What were its concrete activities in this area? I decided to do some digging to better understand the role of Kubernetes in SAP. SAP Leonardo is the foundation of SAP’s innovation-related activities and is based on a varied set of technologies (Machine Learning, IoT, Blockchain, etc.). The role of Kubernetes in these solutions is a great starting point to start exploring.

Note: Kubernetes isn’t the only operational/deployment mechanism for containers. AWS has EC2 Container Service (ECS), Azure has Azure Container Service (AKS) which also supports Kubernetes , Docker has Swarm and Oracle IaaS has the Oracle Container Engine. SAP, however, appears to have focused on Kubernetes although there are exceptions such as the use of Docker Swarm in the SAP Cloud Platform’s ServiceFabrik.

Kubernetes and SAP Leonardo

Before we start our analysis regarding SAP Leonardo, it is useful to mention that Kubernetes already plays an important role in SAP’s internal cloud environment (“SAP Converged Cloud”).

Running OpenStack to power your enterprise cloud infrastructure is not new of course. There are numerous corporate giants doing so already. What is more interesting, is SAP’s approach to the architecture with which the Converged Cloud is deployed. We deploy OpenStack 100% containerised as an automatic system on Kubernetes. This gives us low-touch operations for our OpenStack implementation due to Kubernetes’ self-healing capabilities, as well as a consistent operation model right across the deployments

This effort demonstrates that SAP is experienced with the operation of such containerized environments. As we will see later, this experience has provided SAP an excellent foundation to use this technology in the Leonardo portfolio and other offers.

Note: Other SAP companies and business units also have experience with Kubernetes (for example, Concur with its containerized microservices, SAP Labs , or FieldGlass).

Big Data
The ability to act on operational data - in all its varied forms – represents a central position in SAP Leonardo and the presence of SAP’s Big Data solutions in the SAP Leonardo portfolio is evidence of this critical role.

As per a recent SAP job posting, the recently announced SAP Data Hub “enables customers to efficiently manage and coordinate big data scenarios in a complex system landscape spanning classic SAP applications, data warehouse installations and new Hadoop-based setups.” Kubernetes is part of its distributed processing engine through the use of SAP Vora (a new version (2.0) uses Kubernetes for deployment and cluster management).

Vora 2.0 will be installed in Kubernetes as Docker containers. The Vora applications will get deployed as pods/services and can be accessed using Kubernetes host: port url combinations. This makes the cloud and on premise deployment easier and help in maintaining/upgrading/installing Vora applications easier. []

Machine Learning
As the LinkedIn profile of fellow former SAP Mentor Darren Hague demonstrates, Leonardo Machine Learning also uses Kubernetes. Darren was involved in a Machine Learning Fellowship early this year which involved “getting Kubernetes to run on an NVIDIA DGX-1 deep learning supercomputer in order to enable scheduling of GPU-accelerated TensorFlow training jobs, and contributing to the development of the ML Training platform."

Then in October, Darren started a new position as Global deployment architect, SAP Leonardo Machine Learning Foundation where he is “responsible for ensuring that SAP's Machine Learning platform can be deployed to any cloud provider or data center with a high degree of automation”.

Darren’s previous position at SAP is also interesting inasmuch as he was heavily involved in the Operational aspects of the SAP Converged Cloud.

I work in the Converged Cloud team at SAP, part of the Cloud Infrastructure Automation & Engineering group. The team is responsible for building a global multi-datacentre cloud for the development and automated deployment of SAP's software. The team uses, contributes to and even creates several open-source projects, primarily in the area of OpenStack, Kubernetes and Docker.

Darren is an excellent example of the Kubernetes-related synergy that exists between Leonardo offers and other related corporate activities (including internal ones) at SAP. Another example of such synergy is the use of machine learning in the Data Hub where the Data Hub Orchestration Team is responsible for a Node.js based backend that is based on Kubernetes.

Other Leonardo offers
References to other Kubernetes-based SAP Leonardo components are also present but the evidence isn’t as strong as that regarding machine learning or big data. For example, the use of Kubernetes-based SAP Vora (running on GCP’s Google Container Engine!) for IoT scenarios. Regarding blockchain technology in SAP Leonardo, I was unable to find any evidence of Kubernetes involvement but other providers such as IBM have demonstrated the advantages of such architectures (in this case, for IBM Cloud).

Kubernetes plays a critical role in SAP Leonardo offerings primarily assuring that SAP can operate those solutions in a professional fashion that is flexible enough to meet different workloads in a resilient and cost-effective manner. Furthermore, the use of Kubernetes provides a standardized mechanism with which many customers are familiar making the use of such SAP solutions in private clouds more easily deployable maintainable.

Partners (for example, those offering SAP Vora for customers) may also benefit from such scenarios. With Kubernetes and containers playing such an important role in its Leonardo-related activities, SAP’s more active role in Cloud Native Computing Foundation is better understood.

Beyond SAP Leonardo, containers and Kubernetes also impact other aspects of SAP’s portfolio. Cloud Foundry places a critical role in the SAP Cloud Platform (SCP) and an important strategic shift in Cloud Foundry architecture was announced at the recent Cloud Foundry Summit in Basel. At this event, the Cloud Foundry Container Runtime (CFCR) was introduced as “the default Cloud Foundry approach to deploying containers using Kubernetes and BOSH”. How does this new offer impact SAP and in particular SCP?

Cloud Foundry Container Runtime

This new functionality complements rather than competes with the existing Cloud Foundry Application Runtime (CFAR) (previously Elastic Runtime) inasmuch as there are different workloads that are best suited for each respective environment.

"There's a desire to blend these two levels of abstraction -- Container Runtime isn't about pushing code, but about moving packaged software wrapped in container images into the cloud," [Cloud Foundry Foundation CTO Chip] Childers said. While Application Runtime abstracts container management completely from the user, Container Runtime's abstraction stops at the point of health management, log aggregation and network routing for containers that customers bring to the cloud themselves, he said. [TechTarget]

Although this definition focuses on the characteristics of the container, a video with Ian Andrews, Vice President of Products at Pivotal, provides a more nuanced distinction.

Stateless applications (“12-factor apps”) belong on the CFAR while data-centric workloads (Spark, databases, etc), stateful applications as well as prepackaged software provided as containers (for example via an ISV) belong in the CFCR.

How this might work in practice is if you have an older, monolithic application that you want to wrap as a Linux container. It may work quite well in Application Runtime but it may not – depending on its attributes. "We don't require that you follow all 12 factors in Application Runtime – we know a lot of apps don't fit those 12 factors. So, we may decide that to deploy that in the same environment, it's going to be wrapped in a container and then deployed in Container Runtime – we've given the users the choice [Chip Childers in The Register]

A presentation by Cornelia Davis (Pivotal) provides additional details on the advantage of using CFCR including multi-cloud via BOSH or the ability to easily deal with Kernel and Kubernetes upgrades via CFCR.

Note: Based on this analysis regarding theto have data-centric/stateful applications running on Kubernetes, I found that it was interesting that we have yet to see Hana containers supported by Kubernetes. You can find Hana Express as Docker images and it looks like RedHat has experimented with Hana in Linux containers. There is also a service broker for Hana that exists for CF. Based on recent job offers, there appears to a new DBaaS solution in the works in which Kubernetes experience is recommended – maybe, we will see such scenarios supported in the future for HANA.

A presentation from Emamurho Ugherughe (Software Engineer, SAP) at the recent CF summit concerning SAP Leonardo Machine Learning activities shows an architecture that bridges both worlds and combines CF-based stateless components with Kubernetes-based TensorFlow-based components:


At the moment, the CFCR is too new to know whether SAP is considering moving to it. My assumption is that SAP has created home-grown tools to operate Kubernetes clusters. The shift to CFCR would enhance SAP’s ability to easily provide its SAP Leonardo components to a wider variety of clouds allowing it to focus on the creation of the involved containers rather than dealing with multi-cloud support.

Tying the knot

If we consider the scenario that the SAP Leonardo services would be available in CFCR-based environment combined with stateless applications running in CFAR-based environments, how would the integration between such environments take place so that such “backing services” would be made available for consumption?

Last year, the Open Service Broker API project was spun off from Cloud Foundry and it provides distinct advantages for developers using services in a variety of environments.

First, for the developer, this means they can focus on the business logic of their app and not have to worry about the details involved with deploying and managing a critical service they need. This will all be handled for them – either by their cloud provider or by a 3rd party service provider. This also includes not having to worry about where its hosted, how its backed-up, etc… To the developers its “just there” and ready to be used. []

What is interesting is that Open Service Broker API project not only standardizes within a platform but also between platforms via a shared service catalog.

The goal of this project is to broaden the scope of this API definition so that other Cloud platforms (such as Kubernetes) can support it as well. This means that service providers can now make their services available (ideally w/o any code changes) to both a CF and Kubernetes platform. This also means that app developers will get a similar user experience in both platforms with respect to connecting up to these services. []

In the scenarios we are discussing, you might see Kubernetes-based services using service brokers and publishing via a shared service catalog that could be consumed by CFAR–based 12-factor applications.

For developers using SAP Leonardo APIs, the combination of stateless CFAR-based applications easily accessing CFCR-based services via Open Service Broker API is a pretty potent combination.

One example of this scenario might already be appearing for SAP IoT services.

With one of our next releases we will provide service broker to avoid the trust setup between the applications - via the service broker, IoT AE can be bound to your backend application you will get the credentials and service endpoints to create JWT for the authentication. []

Note: The architecture presented by Ugherughe is a bit different in that the Leonardo APIs made available to the client applications are based on CFAR-based components rather than the underlying Kubernetes-based components. So the description of the Open Service Broker API scenarios might be even more nuanced than I suggest.

Should SAP provide this technology for its customers?

Containers are obviously relevant for a variety of scenarios in IT. As evidenced by the widespread usage of Kubernetes in SAP Leonardo, SAP has recognized the importance of this technology. Yet, as the orchestration of containers becomes more of a commodity, the question becomes if and how should SAP offer this functionality to the developers in its ecosystem? Are containers necessary for those use cases that SAP supports? Should SAP meet this need via software solutions that are part of its portfolio or allow other providers to meet these requirements?

The direct provision/availability of CFCR functionality in the SAP Cloud Platform (SCP) is an interesting option. In this scenario, SAP would integrate Kubernetes functionality more tightly in the SCP (similar to the Kubernetes offer in IBM Cloud).

This addition to the existing SCP CF-related functionality would provide SAP customers with the ability to use SCP for other types of workloads (for example, prepackaged software that are available as containers). Partners might also provide software as Docker images that could then be deployed to different IaaS providers. Or machine-learning software originating from partners based on TensorFlow might be deployed to Kubernetes environment.

Note: You can actually deploy SAP software (for example, Hybris, SAP Convergent Charging, or the Netweaver ABAP Engine) via Docker and you can already deploy Docker images via CF in SCP but this is largely associated with developers creating their own development environments rather than productive deployments.

The question is whether SAP wishes to evolve the SCP in this direction.

My take

In this situation, it is imperative that SAP assists customers and their developers to decide which technology best fits what scenario. One manner that SAP is working to meet this requirement is through its SAP Cloud Platform blueprints which “provide proven, comprehensive scenarios to showcase the power of SAP Cloud Platform to solve various business challenges." These design patterns, however, should be expanded to help customers decide what workloads are best on a bare metal or VMs or what are the advantages of using Docker or Kubernetes.

As a recent RedMonk blog from Stephen O'Grady eloquently states:

To be successful in the Kingmakers’ era, then, is more than simply making intelligent choices about packaging. The Job to be Done is about helping customers to understand those choices. It’s about helping them to appreciate how the world is changing around them, and how they need to change with it. In some contexts, these types of conversations are called digital transformation. But at heart, conversations about digital transformation are really conversations about developers. Who, after all, is behind the actual transformation?

At the moment, Kubernetes is all the rage but the next trend/buzzword in enterprise software is already surfacing: Serverless computing which involves executing code on-demand via event-driven computers. Examples of this technology include AWS’ Lambda and BlueMix’s OpenWhisk. SCP has yet to support such scenarios but conceptual work (“Cloud Extension SDK”) is present which shows the possibility of “cloud functions”. The exact usage scenarios are still being disputed.

Serverless computing is an excellent example which demonstrates that the constant evolution of technology requires enterprise vendors to constantly adjust their portfolio to take into account broader changes in the market. One of the advantages of cloud computing is that software enterprise vendors/providers can improve underlying technological platform and customers gain the benefits of such evolution.

The ability of SAP to leverage its Kubernetes experience that emerged from its internal Converged Cloud project to support its SAP Leonardo solutions demonstrate that SAP understands the underlying value of containers and is able to apply the technology to a variety of real use cases. Although this internal experience might be value for corporate IT dealing with the typical container-related scenarios, the greater challenge will be supporting developers in their use of CFAR + CFCR scenarios.

As this piece goes to press, SAP TechEd Barcelona is about to kick off. If this story advances during the conference, I'll post a follow up afterwards.

A grey colored placeholder image