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:
[SOURCE]
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.
OpenStack
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]
AWS
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.
- SAP Managed Tags:
6 Comments
