Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
This week was a big week for SAP.

This week the SAP Converged Cloud went live!

What do you mean, you have never heard of the SAP Converged Cloud?!!?

Well, maybe you can be forgiven, since the Converged Cloud is SAP's private cloud strategy and is currently only expected for internal consumption.  However, if you are an SAP employee, then shame on you!

The Converged Cloud is SAP's solution to consolidating 23 individual in-house cloud infrastructures.  These 23 infrastructures were never the intention of course, but instead have come about for a number of reasons which include anything from being a by-product of rapid innovation in various areas of the business, to the numerous acquisitions which SAP has made over the past few years.  SuccessFactors, Ariba, Concur, being successful companies in their own rights, all came with their own extensive cloud infrastructures.

Bringing these together under one common umbrella is no mean feat and the Converged Cloud strategy hopes to achieve this by making the transformation from complex and diverse to simple and standardised.


And standardisation really is the name of the game here.

At its core, the Converged Cloud builds on the proven software eco-system of OpenStack, the global, open source standard for large clouds.

'Northbound' we converge around the OpenStack APIs.  Enabling us to incorporate all of the existing, legacy cloud infrastructures, whilst at the same time supporting SAP's current and future cloud businesses, providing a foundation for solutions whether running virtual, bare metal or KVM workloads.

We also standardise 'southbound', by converging on SAP Kubes.  SAP Kubes are highly standardised hardware pods.  These are pre-built, integrated racks containing industry standard components for compute, network and storage.  These are built to a repeatable design pattern based on SAP's blueprint in a factory and delivered as a complete unit directly to the SAP data centre.  The SAP Kube is placed in situ and is then cabled to the network backbone, where it is now ready to have the required software remotely installed on it.


Once the racked, stacked and patched SAP Kube is operational, remotely accessible and handed over to the team to install the software on it, we are now only 90 seconds (or so!) away from having a running and operational OpenStack system.

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 due to the standardised orchestration of the containers.

Operating an OpenStack environment is still a challenge in itself though.  The system is complex with many distributed but interconnected services.  Installing it is a major undertaking.  An upgrade of one service, generally has a dependency on another service and ultimately requires a full down-time of the entire environment.  Needless to say, even a minute's down-time of a productive system is never acceptable.

To alleviate this issue we have split the architecture, into the control plane on one side and the data plane on the other and made them independent of each other.  In this way, OpenStack is only the API layer, the remote control, for orchestrating the hardware beneath it.


The data plane is purely hardware and completely separated from the software that is OpenStack.

What this actually means in practice is that the customer payload on the data plane, will continue to run even if the connection to the control plane breaks, because for instance the control plane is offline.  Performing maintenance such as an upgrade of the software components on the control plane are now less critical and the customer need not be affected by it.

For a more detailed explanation and demonstration of the power of this control / data plane split, I highly encourage you to take a look at this excellent presentation by one of our chief architects and Kubernetes expert Michael Schmidt, as presented at the OpenStack Summit at the end of last year in Barcelona:

The go-live this week was for the Asia Pac region with an availability zone in Sydney, Australia.

Next week is already the next go-live.  This time in Europe with our availability zone in Rot, Germany.  Followed by another planned go-live the week after that, again in Europe with Amsterdam in the Netherlands.

To fulfil our plan of the SAP Converged Cloud being truly global, our projected roadmap will give us 19 data centres, across 13 Regions spread all the way across the Globe by the end of 2018.

So I encourage you to keep an eye on this space.  Our team has been and will continue to travel to conferences to talk about SAP’s drive at the cutting edge of enterprise cloud technology with the SAP Converged Cloud.

We hope to see you there!
  • SAP Managed Tags: