The complicated relationship between Cloud Foundry and SAP’s HANA Cloud Platform

Profile picture for user rhirsch By Dick Hirsch October 21, 2015
Summary:
Dick Hirsch unravels the hairball of relationships that SAP enjoys within the context of Cloud Foundry and discovers that SAP developers can benefit - provided SAP contributes.

It all started with a single slide from Sam Ramji’s (Cloud Foundry Foundation CEO) keynote at the recent GE Minds & Machines 2015 conference.

GE cloud foundry

NoteI have written about the important relationship between Cloud Foundry and SAP’s PaaS - HANA Cloud Platform (HCP) in the past and the recent product roadmap shows the future direction of HCP is moving towards a runtime environment that is completely based on Cloud Foundry. The recently-released YaaS platform from Hybris which will provide business services for HCP in the future is also based on Cloud Foundry.   

As I looked at the slide, I was intrigued for various reasons:

Based on the critical importance of the relationship between Cloud Foundry and HCP, I thought it would be useful to take a closer look at this topic.

Cloud Foundry SIGs

SIGs are often present in enterprise software settings and allow individuals with a common vertical / industry to collaborate and share best practices. For example, ASUG has a wide variety of mature SAP-related SIGs that span technology-process-industry topics, which have very active members.  SIGs are usually open arenas where competitors as well as partners collaborate together to achieve the goals of the SIG.

Cloud Foundry SIGs are excellent examples of such group efforts.

We decided vertically focused SIGs are one way to help gather requirements from all users. These SIGs are meetings where Cloud Foundry users from an industry get together to discuss objectives and requirements. [SOURCE]

The intention is to enable companies to be able to get together to talk about their experiences using Cloud Foundry (operating it, deploying it and using different distributions). Chip said the hope is that these companies will also share stories on how they are changing their organization to take advantage of Cloud Foundry. [SOURCE]

The fact that Cloud Foundry has SIGs is representative of its increasing maturity.

At the current time, there are three Cloud Foundry SIGs:

  • Finance
  • Industrial IoT
  • Telecommunications

A quick look at the initial SIG – Financial Services – provides more clarity on the topics which such SIGS will cover:

The first instance of a "SIG" happened on New York City for the financial services industry. It involved 12 companies from different parts of this industry. Chip said it was interesting to see the open and thorough discussions about some of the things they are looking for from Cloud Foundry. Financial services are notoriously heavily regulated and there were discussion on "how are you approaching the development-production pipeline?" Some of them are approaching it by having separate Cloud Foundry clusters for development and test and then another in production. Others are providing a common system and then expect the application team to effectively organize themselves around the compliance rules. Chip is hoping they can clean up the feedback and make it public once they are sure that the notes they took reflect that specific industry as a whole. They will also be looking for commonality across different industry groups, especially between ones that are heavily regulated. [SOURCE]

As an example, the requirement for specific role based permissions that financial organizations need to comply with regulations is unique to the financial services industry. In order to meet financial regulations, sometimes the same person that starts a process isn’t allowed to stop it and vice versa. [SOURCE]

Unfortunately, I don’t have access to the full list of requirements that the Financial SIG presented but I found it interesting that there was a mixture of pure technology (“development-production pipeline”) as well as more business-relevant (“specific role based permissions”) requirements.  Thus, the activities of such SIGS might be broader than might be expected.

Note:  All these SIGs are present on LinkedIn as private groups (for example, here is the group for Industrial Internet Technology) so a list of members isn’t available publicly.  Perhaps, SAP is already member – if so, I have yet to see any news about it.

Note:  SAP is also participating in other IoT –related associations (Dr. Tanja Rueckert, Executive Vice President IoT & Customer Innovation Unit just joined the board of the  Industrial Internet Consortium along with representatives of AT&T, Cisco, GE, IBM, and Intel) so it is fully aware of the critical importance of such entities- especially in areas that are evolving rapidly – such as IoT. 

GE’s TCP Router

At the moment, Cloud Foundry activities largely focus on the underlying foundation (BOSH, etc) necessary for the PaaS to be successful but one reason that the SIGs are so significant is the recognition that industry-specific functionality is also important. One example of such technology (in this case “Industry-IoT”) is the TCP Router which has been contributed by GE.

In order to address this limitation in Cloud Foundry, we (GE Software) proposed adding TCP routing capability to Cloud Foundry. The main motive behind this move by GE Software was to enable its own cloud offering (Predix) to accept data from myriad of industrial devices that GE manages and is expecting to connect to each other and with applications running on cloud to form the so called "Industrial Internet". Predix is based on Cloud Foundry and hence enabling that capability in Cloud Foundry is the right thing to do. GE Software has joined hands with Pivotal and is now developing this capability in OSS Cloud Foundry.

We announced TCP routing OSS project in this year's (2015) Cloud Foundry summit during the talk I had opportunity to give. As highlighted in that talk we decided to choose layer 4 (TCP) routing because of number of different protocols (MQTT, DDS, XMPP...etc) being used in IoT space as well as due to limitation in terms of the protocol headers to determine the final destination of the connection (due to lack of host headers in many IoT protocols). With layer 4 we remove all that complexity and just decide the final destination of the traffic/connection based on the port. [SOURCE]

NoteSAP is working with Siemens – a GE competitor – regarding IoT activities and Siemens’ HCP-based efforts in this area are based on Cloud Foundry.

What is interesting is that SAP is currently planning to implement a related functionality via a proprietary technology: HANA Cloud Integration (“support of additional transport protocols, e.g. MQTT via integration with HCI messaging service”).  In such situations, the question will arise whether the use of proprietary technology should be replaced with standard technology on the underlying platform.

Cloud Foundry is a living project that will continue to evolve and the products based on Cloud Foundry must be adjusted accordingly.  As the scope of Cloud Foundry expands, there may be conflicts with these Cloud Foundry-based platforms where existing proprietary technology could be replaced with technology from Cloud Foundry.  This Darwinian (“survival of the fittest”) process will be fascinating to watch as vendors with Cloud Foundry-based platforms fine-tune their offering as core /standard functionality expands.  The ever-increasing standardization within Cloud Foundry (which is associated with its increasing maturity) is actually a benefit for such vendors since they can concentrate more on the elements that truly represent their differentiating qualities in the marketplace.

Why APIs are so important

In the typical (if there is such a thing) Cloud Foundry application developed using the preferred microservices architecture, APIs play a critical role.The critical importance of such services in the broader enterprise software market was recently depicted in an excellent piece by blogger Joshua Greenbaum:

This race to the top is taking two highly complementary forms. Form number one is the race to build out a business network strategy that promises to support the complex, matrixed networks of business interactions that have outstripped the inside-the-firewall, linear business processes – and software – of the 20th century. Form number two is the race to build out a set of componentized business services, cloud natives each and every one, that can be compiled into end to end services, or attached as services to the aforementioned business networks, or used to extend existing on-premise applications into the cloud. Both forms are hugely important in the quest to deliver genuine, and highly valuable, innovation in the cloud, and both are harbingers of a major inflection point in the value of the cloud in the enterprise.

I thought of my recent microservices-related explorations - for example, the excellent GE Predix site for developers  with its detailed descriptions of the supported IoT-related APIs (asset, classification, model, etc).  As I read the associated documentation for Predix, I was reminded of the commerce-related APIs supplied by YaaS and considered the role of such APIs to act as the differentiating aspect of such platforms.

The definition of Cloud Foundry SIGs is purposefully vague in order to provide such groups with maximum flexibility in their work.  Right now, these groups are primarily concerned with fundamental technology – albeit with a focus on requirements of the involved vertical industries.  Yet as such groups mature, it will be interesting to see if API definition doesn’t become a topic.  Standardized APIs would be a major benefit for developers in terms of application portability but would be difficult in terms of political wrangling necessary to push through such standards.

My take

A year ago, I wrote a blog entitled “Hey SAP – stop flirting with Cloud Foundry and propose”.  Since the publication of this blog, the relationship has evolved and its status might be described as “It’s complicated” – although I’d like to use this status without its usual negative connotations.  Like most relationships, the euphoric first period of falling in love must be replaced with the day-to-day realism of married life – not that this period can’t be filled with happiness – with the required ability to accept a “give and take” and the awareness that sometimes you won’t get your way.

The use of Cloud Foundry will play a significant role in HCP’s evolution.  Yet, the use of an open source software technology - that involves various competing interests with often conflicting interests - is not without its complexity. Cloud Foundry is more than just technology – it comes with an ecosystem as well.  This ecosystem is the foundation of its success / strength as well as containing a potential for conflicts.  This realization was one of the main reasons behind the creation of the Cloud Foundry Foundation (of which SAP is a Platinum member) and its intriguing governance model:

With the Cloud Foundry Foundation however a new approach is being tried. A group of companies, most of which have considerable experience in the good and the bad of open source, have come together to define a model of governance which is designed to allow broad participation and experimentation, but which is also is designed to ensure coherent technical architecture and evolution that will prevent the project from either becoming bogged down, or “forking” into a mess. Driving this approach is the principle of “governance by contribution” – a path to allow those who wish to meaningfully contribute, and exhibit real understanding, to earn the right to control the evolution. [SOURCE]

For SAP, the associated realization might be that other vendors involved in Cloud Foundry – such as GE regarding IoT – will also influence the platform’s development and these vendors have their own corporate interests / agendas that might not always be the same as those pushed by SAP.  This association is not specific to SAP – other vendors using Cloud Foundry (IBM with BlueMix, etc) have exactly the same issue.

SAP, however, has extensive experience using such open-source software – for example, the use of Apache Spark and Hadoop in HANA Vora, the use of Eclipse in HANA development environments, etc – and understands the necessary skills / tactics of participating in such ecosystems.

The fact that Cloud Foundry Foundation has a “governance by contribution” model means that SAP must be active (either by code contribution or via participation in various SIGs) to be able to influence the organization.  SAP’s decade-long experience in creating mission-critical software will hopefully flow into Cloud Foundry – hopefully with a focus on making Cloud Foundry even more “enterprise-ready”.  SAP should either participate in the various Cloud Foundry SIGs itself or promote active participation of HCP customers in such organizations.   GE and Cloud Foundry have started an Industry DoJo – perhaps SAP should work on establishing a Commerce Dojo based on the hybris microservices.  As the number of companies joining Cloud Foundry Foundation increases, SAP will have to work harder to stand out.

Developers and customers who use HCP, who could be regarded as the children of this relationship, should be shielded from such complications and can only benefit from the competitive evolution that results from the “governance by contribution” model.  Such parties will have a platform that represents the best ideas / contributions of the involved vendors.   Selecting the correct PaaS will then will be based less on the underlying core technology but rather on the differentiating characteristics (for example, industry-specific APIs).