After reading a recent blog entitled “Cloud Foundry, aiming for ubiquity, sets sights on Google Cloud”, I decided to examine the Cloud Foundry in more detail to understand how it might fit into the broader SAP cloud environment.
The area of the greatest potential appears to be the HANA Enterprise Cloud (HEC).
Architecture of the HANA Enterprise Cloud
Note: In this blog, the Application Management Services (AMS) portions of the HANA Enterprise Cloud aren’t going to be considered. I’m more interested in the broader architecture of the platform.
Let’s take a quick look at the architecture of the HANA Enterprise Cloud.
Here is detailed diagram provided by SAP
Let’s simplify this diagram a bit.
The last step reduces HEC to its simplest structure and shows that HEC is more than just an IaaS. One recent presentation about SAP's cloud offerings refers to HEC as ERPaaS which isn’t really true since other applications are also offered in this environment.
It also important to remember that the IaaS layer currently contains a mix of physical boxes for HANA and virtualized servers for other components such as application servers, etc.
Enter Cloud Foundry
Cloud Foundry is an open source cloud computing platform as a service (PaaS).
Here is a very high-level portrayal of the Cloud Foundry architecture.
[SOURCE]
The interface with various clouds types (Private, Public, etc.) is where we want to focus our attention.
It is first important to say that Cloud Foundry is designed to be IaaS neutral. This goal is achieved via the Cloud Provider Interface (CPI).
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)
Note: For a deep dive into how a CPI works, I recommend this blog.
Currently, CPIs exist for the following IaaS environments
IaaS | Status |
CloudStack | |
Azure | |
VMware vSphere | |
VMware vCloud Director | |
AWS | |
Google Cloud Platform | |
OpenStack |
Let’s create a simple diagram of the CPI-related architecture.
Porting Cloud Foundry to the HANA Enterprise Cloud
Note: Before we examine this scenario in more detail, it is useful to remember the announcement regarding Cloud Foundry at the Las Vegas TechEd. I’ve analyzed this announcement and my assumption is that applications running on Cloud Foundry will soon be able to use HANA as a database.
A port of Cloud Foundry to the HEC would have this general architecture:
Here is a a more detailed representation of the target architecture:
The only necessary implementation would be the creation of the CPI for this integration. If the virtualized machines used in HEC were from a vendor (VMWare?) already supported by another CPI, then only support for the HANA boxes would be necessary to implement from scratch.
The question would be whether the optimal solution would be direct CPI access to the virtualized machines / physical HANA Servers. Another option that might be easier to implement would be the use of the existing SAP HEC Orchestration tools.
This orchestration layer has its own REST APIs that could be the entry point for the CPI integration.
[SOURCE]
Concerning the difficulty in creating a CPI, one blogger made this remark:
With that said, it is rather amazing that one could encapuslate all of the infrastructure-specific implementation necessary to deploy and manage a distributed system as powerful as Cloud Foundry in less than twenty classes and 1700 lines of code.
Thus, a CPI for the HEC seems like a possible / realistic undertaking.
But why?
“If we have no heretics we must invent them, for heresy is essential to health and growth.” - Yevgeny Zamyatin [SOURCE]
Just because something is theoretically possible, doesn’t mean that it should really be done. I’ve just described how Cloud Foundry might be able to run on the HEC architecture – yet, the question might arise: why would you do this?
As I’ve stated before, the HEC gains in value if extensions to the hosted applications can be hosted in a single environment rather than multiple platforms. Thus, the combination of a PaaS and the HEC might be quite valuable to customers.
SAP already has a PaaS -the HANA Cloud Platform (HCP) – if any PaaS should run on the HEC, then it should probably be the HCP. Indeed, there may already be ongoing activities in this area. This evolution appears to be the natural evolution for the HEC hosted by SAP.
There are, however, a variety of other HEC partners who have other options / perspectives / requirements. These partners might already have Cloud Foundry experience. The viability to port HCP to other environments – either OnPremise environments from customers or cloud environments hosted by others besides SAP – really hasn’t been addressed yet. Thus, the ability to run Cloud Foundry in these partner-hosted environments would provide benefits / increased flexibility for customers in those environments.
- SAP Managed Tags:
3 Comments
