Skip to Content

The second heresy: Does SAP have to own the IaaS layer in the HANA Enterprise Cloud?

I recently blogged about porting Cloud Foundry to the HANA Enterprise Cloud (HEC).  As I was writing that blog, I began to think about other aspects of the HEC that might be interesting to explore.  This blog examines a different layer in the HEC and suggests that there is potential for the platform to move to the next stage in its evolution.

Architecture of the HANA Enterprise Cloud

Here is detailed diagram provided by SAP of the architecture of the platform.


Let’s simplify it a bit:


Before we simplify the architecture even more, it is interesting to note that customers also have the ability to purchase SAP HANA Infrastructure without the other Managed Service portions.  This service offering is available currently via three partners: SAP, AWS and Saavis.

If you associate this pure-infrastructure offering to our HEC architectural drawing above, you get this diagram:


Let’s continue the simplification of the HEC architecture:


In this blog, I’d like to focus on the interface between the Management / Orchestration layer and the underlying IaaS environment.

Lessons learned from Cloud Foundry’s Cloud Provider Interface

As I described in my last blog, the PaaS Cloud Foundry uses the Cloud Provider Interface to make it IaaS-agnostic.

A Cloud Provider Interface (CPI) is an API that BOSH (Foundry’s deployment installer and operations manager) uses to interact with an Infrastructure as a Service (IaaS) provider to create and manage stemcells and VMs. … A CPI abstracts an underlying virtualized infrastructure from the rest of BOSH, and is fundamental to Cloud Foundry’s model for deploying and running applications across multiple clouds. [SOURCE] (my emphasis / addition)

The Orchestration layer in the HEC has the potential to perform a similar role.

This feature is already envisioned by SAP as depicted in this diagram:



Note: Although the diagram only describes HANA systems, the Orchestration layer must also have the ability to deal with other non-HANA environments inasmuch as it already manages other virtualized servers that are necessary for application servers, etc.

Therefore, the Orchestration layer could theoretically support multiple IaaS’s


Which IaaSs could possible be supported by the HEC?

Obviously, SAP’s own Cloud infrastructure is being used as a IaaS – let’s look at some other possibilities.


A few recent investments in this area are interesting.

An investment in Virtustream may be seen as being linked to OpenStack

VIrtustream fields two architectural cloud platforms — one is based on VMware vCenter and ESX and the other is the KVM-based Elastic Computing Platform (ECP) that came out of Virtustream’s acquisition of Enomaly two years ago. Virtustream is working to migrate the ECP option over to OpenStack in the next few years., a migration that the new money will help power.

Our goal is to offer the same services and service level agreement (SLA) atop VMware or Openstack architecture — you choose,” said Rodney Rogers, CEO of Virtustream. [SOURCE]

It is also critical to remember that VIrtustream was one of the very first partners to be certified on HEC.

An investment by SAP Ventures in Mirantis – the largest OpenStack systems integrator – also reveals some intriguing aspects.

Investment proceeds will be used to solidify Mirantis’ leading position in the OpenStack market by enhancing the engineering roadmap for Fuel, its tool for management and deployment of OpenStack clouds, and driving integration with technology and products from Mirantis’ partners.

Enterprise software giant SAP is investing heavily in cloud technology. Mirantis has already built an OpenStack cloud for SAP using Fuel and the companies will explore further use of OpenStack by SAP.

The ability to support OpenStack would allow SAP to deal with a criticism from Forrester analyst Stefan Ried that arose soon after the HEC was furst announced:

Although it’s good to have advanced management capabilities for large Hana environments, the mainstream large-scale cloud providers are evaluating or already following OpenStack. For example, Oracle acquired cloud management expert Nimbula so that it could build its future public and private cloud offerings on the open-source-based OpenStack. SAP is restricting its ecosystem to the certified hardware vendors and is trying to deliver the full software stack on bare metal on its own this time – this should give some cause for concern. [SOURCE]


As I mentioned above, AWS is also a provider for HANA Infrastructure. This service is available as a virtual appliance rather than a physical box. The architecture in this offer shows that it can also provide more complicated environments (multi-node) as well.

This support of AWS in the HEC would lead to this architecture:


The Cloud Frame / Orchestration layer

Although the Cloud Frame / Orchestration layer plays such central role in the HEC, there is very little information regarding what it really contains.

A patent from SAP submitted in 2012 provides some more details:

In general terms, a “cloud frame” in accordance with principles of the present disclosure provides a hardware and software product delivery framework to deliver a range of products and services into an enterprise. A cloud frame supports an architecture of hardware nodes, applications (e.g., business software), and services to orchestrate the collaboration of hardware components and applications using a specific collection of hardware nodes to provide resources and services such as computing resources, storage resources, networking resources, and management resources.

These cloud frames provide a more uniform building block for orchestration purposes.

The limited description of the Orchestration layer currently publicly available reminds me of Mirantis’ Fuel framework (mentioned above):

Fuel is an open source deployment and management tool for OpenStack. Developed as an OpenStack community effort, it provides an intuitive, GUI-driven experience for deployment and management of a variety of OpenStack distributions and plug-ins. [SOURCE]

Perhaps, we’ll see some interesting collaboration in this area so that SAP’s orchestration layer is no longer a proprietary environment but rather one that reflects a more open-source approach.

Why is this topic important?

In my opinion, SAP shouldn’t necessarily be the one supplying the IaaS for the HEC.  The HEC should be IaaS agnostic.


As long as the IaaS provider meets the necessary SLA-related requirements and provides the necessary functionality, then which provider is used is largely irrelevant.

Indeed, the ability to switch between IaaS providers would provide added benefits.

  • Competition between providers regarding price or other feature-sets
  • The ability to choose particular providers who are able to supply special features – higher SLAs, etc.
  • The ability to use multiple IaaS providers reduces dependency on a single provider

The main motivation, however, is that such a decision would allow SAP to concentrate on other aspects of the HEC. As the IaaS layer becomes more of commodity, SAP could focus on layers that are higher up the value chain (for example, AMS-related features – consulting, etc).  SAP already got out of the hosting business once before (in 2009 in an agreement with T-Systems), I’d hate to see it bogged down again in providing such services when it could exploiting its more application-related expertise where it has real competitive advantages.

You must be Logged on to comment or reply to a post.
  • Some of this goes over my head 🙂

    My sense is that SAP isn't too sure which HANA strategy is going to stick, so it is backing all the horses.

    I've always felt like HEC was an attempt to move the market forward rather than move into the hosting market wholesale. JHS told us in June it was intended to be a short term business whilst there were margins to be made.

    And Huawei entered the market today...

    These guys are experts at low-cost IaaS, which speaks to your point.

    Perhaps SAP should license or bundle the HEC IP to the IaaS vendors to ensure consistency between the layers?

    • John,

      Very much agree that SAP has to move the market forward by enabling partners (as they have done in the past). Then partners can then compete on the level of security, performance, compliance, automation and speed that provide the agility that customers need to reduce time to value.  

    • Some of this goes over my head 🙂

      I have same experience when I read a few of your blogs ;->

      I've always felt like HEC was an attempt to move the market forward rather than move into the hosting market wholesale. JHS told us in June it was intended to be a short term business whilst there were margins to be made.

      In my opinion, "moving the market forward" means bringing the greater SAP ecosystem "up-to-speed" to be able to participate more aggressively in the broader cloud-based HANA marketplace. The necessity of quickly getting HEC into the market meant that SAP had to perform much of the "heavy-lifting" itself. As partners (for example, Huawei) start becoming active in this area, SAP can look more closely at its long term goals and determine what parts of the solution that it can delegate to others. 

      Perhaps SAP should license or bundle the HEC IP to the IaaS vendors to ensure consistency between the layers?

      That is an excellent point. As more players get involved (SIs, IaaS providers, etc), the complexity increases. Having a single provider of the entire HEC stack is probably the optimal approach.  The question is whether anyone but SAP is currently able to provide both the technology and the AMS-related skills.


  • Hi Dick,

    thanks for this blog.

    First, I agree that with the choice of vendors and providers on the infrastructure level, there is opportunity to reduce cost for customers. And reducing cost for customers is always a good idea.

    Second, I agree that on the pure infrastructure level we already see massive commoditization happening. So why would anyone try to reinvent the wheel here?

    Also, if it comes to an SAP business solution, we talk about more than HANA systems. We talk about system landscapes that do require a set of additional servers, network capabilities and storage requirements. All of this infrastructure needs to be consistently managed.

    When we look at the Cloud Management infrastructure required for an SAP solution, we basically have two big layers: One is the lower level technical infrastructure stack. The other is the management layer above that addresses the specifics of the application and business solution level.

    My intent is to focus my team's energy on the upper layer and provide the best possible Cloud Management infrastructure for the SAP "content". Based on standard products that we evolve into or build from ground up as Cloud-optimized, i.e. scalable, fully software controlled, components and that we combine with SAP specific content for massive automation. Thus driving cost of operations down and easing the task of managing powerful business solutions across a hybrid solution landscape. This Cloud management infrastructure will also be made available to partners and customers. So the benefit of that infrastructure will not only be to SAP's HEC advantage, but help partners and customers operating SAP solutions in a highly effective and efficient manner as well.

    On the lower layers, we seek to go for as much openness as possible. OpenStack is actually my favorite target as it sees broad acceptance and adoption already. At the same time, we have to acknowledge that OpenStack in itself is not a ready-made, standardized solution one can assume to find everywhere. So there's a bit more intelligence that needs to be brought to the table here before we can say we can exchange IaaS providers underneath... Nevertheless, going for something like OpenStack as a unifying IaaS toolkit will allow us to bring in "choice" on the lower IaaS layer while focusing our energy on enriching the upper layers of the Cloud Management stack. Ideally, but this is not a promise yet ;-), we will also contribute parts of our efforts into the OpenStack community. But this is still too early to say. But my history somehow keeps getting back at me 🙂

    At the same time, let's not forget that HANA infrastructure, especially if you want to flexible scale out HANA systems in a Cloud environment, does require more sophisticated compute, network and storage architecture and Hardware than your everyday web server. HANA Cloud Cell (the hardware architecture) / Frame (the software layer managing the Cell) is our approach to standardize that particular aspect of HANA power managed in a cloud-optimized way. We're working with several vendors here. We will continue to invest into driving the hardware architecture of HANA cloud infrastructure -- together with our hardware partners -- to maximize performance and minimize cost (both in hardware and operations). I believe it is crucial that SAP keeps being in the driver seat here.

    Hope that shed a bit more light on where things are currently going with HEC...

    Björn Goerke

    Head of HANA Enterprise Cloud & SAP CIO

    • My intent is to focus my team's energy on the upper layer and provide the best possible Cloud Management infrastructure for the SAP "content".

      I think this is an excellent idea and the strategy will allow SAP to concentrate on building innovative applications based on the HANA platform rather than infrastructure-related topics.

      HANA Cloud Cell (the hardware architecture) / Frame (the software layer managing the Cell) is our approach to standardize that particular aspect of HANA power managed in a cloud-optimized way

      The HANA Cloud Cell / Frame sound interesting and I'm curious to see how this fits into your broader OpenStack / IaaS activities.