Cloud Foundry, Hybris and the HANA Cloud Platform: Microservices and Beyond

Two recent sessions at the Cloud Foundry (CF) Summit provide some interesting insights into possible developments concerning the HANA Cloud Platform (HCP). The first session was entitled “Future of Enterprise PaaS” from Steve Winkler and Dirk Basenach. The second session was entitled “Commerce as a Service with Cloud Foundry” from Hybris’ René Welches.

I’ve blogged about HCP and the Cloud Foundry in the past but the new material provides some additional insights into the potential synergies between HCP and CF.

Here is the session from Winkler and Basenach:

There was one slide in particular from Basenach’s presentation that must be examined in more detail.

[SOURCE]

Let’s take a closer look at some of the important points:

• Hybris on the HCP

Although I’ve blogged about the possibility of Hybris running on HCP, I’ve never see any official material about such migration efforts.

• Use of CF services in the existing platform

One of the most important insights is the presence of CF-based microservices in the existing landscape.

My assumption is that this sceanrio would only work if the HCP was based on CF (more on this topic later).

• Common API Layer

I’ve been thinking about what the depicted “common API layer” might contain. I think we should be looking for some sort of API Gateway in the near future in the HCP.

The API gateway sits between the application’s clients and the microservices. It provides APIs that are tailored to the client. The API gateway provides a coarse-grained API to mobile clients and a finer-grained API to desktop clients that use a high-performance network. In this example, the desktop clients makes multiple requests to retrieve information about a product, where as a mobile client makes a single request.

The API gateway handles incoming requests by making requests to some number of microservices over the high-performance LAN. Netflix, for example, describes how each request fans out to on average six backend services. In this example, fine-grained requests from a desktop client are simply proxied to the corresponding service, whereas each coarse-grained request from a mobile client is handled by aggregating the results of calling multiple services. [SOURCE]

An API Gateway would complement the existing Fiori / OData / mobile story.

• Domain-specific Hybris microservices

The microservices mentioned above originate from Hybris’ Commerce as a Service efforts (YaaS).

[y]aaS is a multi-tenant cloud platform which allows everyone to easily develop, extend and sell commerce services and apps. [y]aaS is based on a steadily growing micro service architecture running on Cloud Foundry as foundation. All services within [y]aaS are exposed through a consistent RESTful API. Besides the API, [y]aas also includes a Marketplace for hybris services as well as 3rd party services, an On Demand Store Front and a Back office application, all running on Cloud Foundry. [SOURCE]

[SOURCE]

What is interesting is that they reflect a particular domain (in this e-commerce) rather than technology (mobile, ID Service, etc) as in the existing HCP services.

• PaaS hosting by Customer and Partners

Currently, the HCP only runs in SAP Data Centers (DCs) –Basenach states that in the future the HCP might be able to run in private clouds (either in the DCs of customers or partners). I could imagine scenarios where partner-run HANA Enterprise Cloud instances could be complemented with HCP PaaS instances in the same environments.

Virgo and the transition to Cloud Foundry

In his presentation at the CF Summit, Basenach mentions something very interesting about the future of CF.

SAP “We expect @cloudfoundry to become the Linux of the cloud era” #cfsummit

— James Watters (@wattersjames) June 10, 2014

I kept thinking about this statement and what it might mean in terms of SAP’s PaaS strategy.

A step back

There is very little documentation about the internal HCP architecture but I found an old drawing that provides some details.

Matthias Steiner confirmed that this fundamental architecture still exists (with name changes and the presence of HANA).

The existing HCP architecture uses the Eclipse Virgo project as its foundation yet much of the lowest layer (“NW Cloud Infrastructure”) appears to be proprietary. This lowest layer is the best candidate for a shift to CF.

The Virgo project has had its share of problems including a change of leadership last year when long-time leader Glyn Normington left the project.

Interestingly, Normington works for Pivotal developing “buildpacks” for running Java applications. Indeed, he has already built a build-pack for Virgo for CF.  Thus, a HCP transition to CF appears possible (even with the continuation of the use of Virgo) though I have no idea regarding the efforts involved.

Why would SAP want to use CF in HCP?

The use of CF is currently booming and exciting things in the community are happening

The enterprise use of CF is increasing exponentially as demonstrated by a number of new offerings (IBM’s BlueMix, HP PaaS, etc). With this high level of activity, the re-use of a rapidly evolving feature-set is definitely preferable to a proprietary stack.

Features such as recently announced cooperation between Cloud Foundry and Docker (where Normington will also be working!) would also allow SAP / HCP to transition more easily towards the new container-focus in the PaaS arena.

Improve the ability of partners to host HCP instances

As mentioned above, HCP installations in private clouds are also planned. Partners would probably be more familiar with CloudFoundry-based PaaS’ operations rather than the proprietary PaaS stack currently in use in the HCP.  The active promotion of CF in such private clouds is also one of the contributions of SAP to the broader CF community.

Increase the developer ecosystem for HCP

HCP still uses a propriety command line interface to interact with the underlying Paas.  For example, here is the command concerning hot deployments:

neo hot-update –host us1.hana.ondemand.com –account myacc –application myapp –source samples/deploy_war/example.war  –user mymail@example.com –strategy replace-binaries

The use of a CF as the underlying PaaS framework would make the lives of developers easier in that there is a much larger community that already has experience with CF. For example, IBM’s CF-based BlueMix Paas, the deployment process uses the well-known CF commands.

SAP’s competitive advantage in the Cloud Foundry market

CF is just the fundamental technological framework for a PaaS. It is not, however, a PaaS offering that customers can purchase.  As mentioned above, there are a variety of CF-based PaaSs available.  Pivotal also has its own version of a CF-based offering entitled Pivotal Web Services.  Thus, the use of CF itself really isn’t the main selling point of such environments. Some vendors such as IBM with its BlueMix are pushing their proven IBM infrastructure (“Open Cloud Architecture”) with hard SLAs and global DCs as its competitive advantage.

In this environment with many CF-based PaaSs, how could a CF-based HCP distinguish itself?  Comparing the marketplace for Pivotal Web Services with its services that are focused on technology and the developer (Cloud Forge, IronMQ, SendGrid, etc), you already have something similar in HCP (HANA DBs, Hana Cloud Integration, SMP, etc). I think domain-specific / industry-specific microservices –  such as Hybris’ e-commerce services – must be the main focus to provide a competitive advantage.  This is an area that other vendors can’t cover. Imagine a microservice for supplier (Ariba-based) or employee (SuccessFactor-based) or contract-worker (FieldGlass-based) or invoice (HANA Enterprise Cloud ERP-based).  These are scenarios in which only SAP can truly excel.