It all started with my misinterpretation of a Sapphire session announcement from Microsoft with the title “SAP HANA and SAP Cloud Platform on Microsoft Azure."  I got excited and thought that we had an early indication that SAP or Microsoft would be announcing the availability on Azure of SAP’s PaaS (Sap Cloud Platform or “SCP”). Unfortunately, a closer reading of the associated session description (“Organizations with SAP and HANA deployments can now leverage single sign-on authentication features to securely drive mission-critical applications and data analytics on a global scale”) suggested that the focus would be on the authentication-related integration between SCP and Azure-based Active Directory.

I must admit that I was a bit disappointed. The ability of SCP to operate on various infrastructures is a critical element that will have a major impact on its future success.

The idea of the multi-cloud

Earlier this year, SAP changed the name of its PaaS from “Hana Cloud Platform” to “SAP Cloud Platform”.  As SCP Evangelist Matthias Steiner described at the time, this shift was also associated with an increased awareness of the importance of moving beyond the solution only being hosted in SAP data centers.

By leveraging the so-called Cloud Provider Interface (CPI) it is possible to run Cloud Foundry on various infrastructure. SAP has teamed up with SUSE to co-lead the open-source development of the BOSH OpenStack CPI (see SAP leading Cloud Foundry project “BOSH OpenStack Cloud Provider Interface”) and many of the big IaaS providers provide their own CPI implementations (e.g. Amazon AWS, Microsoft Azure and Google Cloud Platform).

Together these technologies are the foundation for SAP’s multi-cloud strategy going forward, which will tremendously accelerate the roll-out of SAP Cloud Platform into more regions and at the same time, establish co-location of the platform and other cloud assets of enterprise customers within one datacenter.

SCP-related job offers (“Expert Developer: Cloud Platform Enablement Team and Area Product Owner for the SAP Cloud Platform Persistence Team) showed that SAP was hiring individuals who would assist in this effort:

SAP Cloud Platform is based on open standards, such as Cloud Foundry and runs on different Infrastructure as a Service (IaaS) layers, such as OpenStack, AWS, Azure and Google Cloud Platform.

And another job opening:

The Persistence Service, developed in our team, is one of core services in SAP Cloud Platform Core providing the complete database lifecycle (automated provisioning, database administration, backup & recovery handling, high availability & disaster recovery, testing new database versions, ….) for SAP HANA and SAP ASE. As a core component, the service is used to manage all internal as well as customer facing databases. Besides providing databases in SAP owned data centers, we are currently extending the reach of the service to also operate on public cloud infrastructures like AWS, Azure and Google Cloud Platform.

Additional details about this strategy emerged in the partnership announcement between Google and SAP where SCP’s ability to run on Google Cloud Platform (GCP) was disclosed (as depicted in a diginomica blog from Jon Reed and Brian Sommer).

SAP also intends to integrate their SAP Cloud Platform (formerly the HANA Cloud Platform) with GCP. Leukert announced plans to tie the Cloud Foundry-based version of SCP into the Google Cloud Platform. The goal? Provide developers with a host of “scalable” services via APIs they can utilize to build new apps.

Yet, these were just plans and no concrete timelines were ever mentioned.

Note: When we talk about supported IaaSs, we mean more than just the public cloud. SCP already runs on OpenStack. Indeed, the use of OpenStack in the SCP allows flavors of SCP to be hosted by customers. Perhaps, the most prominent example of this scenario is Siemens’ MindSphere. Thus, the multi-cloud strategy also provides SAP the ability to support customers with requirements that might prevent them from moving to the public cloud.

Multi-cloud functionality in other PaaS solutions

There are a variety of other PaaSs that already offer multi-cloud capabilities. Usually, such offers are based on Cloud Foundry (CF) which itself is available on a variety of IaaS environments (Azure, AWS, OpenStack, vSphere, etc.).

One example of such a PaaS is IBM’s Bluemix which is also CF-based and has a variety of deployment models.

• Public: [This is best / short description that I could find] Infrastructure is built on SoftLayer and is available in over 30 SoftLayer Datacenters across the world. All of which are interconnect with our unmetered private network.
• Dedicated: Bluemix Dedicated provides physically isolated hardware in an IBM data center. Single-tenant and provisioned on a combination of bare metal and virtual machines, your Bluemix environment is created just for you. With the syndicated catalog, you can power your apps and services with a combination of dedicated compute and services, as well as services from the public Bluemix catalog.
• Local: Bluemix Local is delivered as-a-service on your own hardware or on a pre-integrated converged infrastructure. While in constant collaboration with your IT team, we partner with you on updates, platform health, patches, and security fixes to ensure your environment is always current, available, and ready for your apps and services.

What is interesting is that Bluemix doesn’t appear to be available on other public IaaS environments. I also looked at Oracle’s PaaS (“Oracle Cloud Platform as a Service”) and didn’t find any indication that they support such scenarios. Pivotal Cloud Foundry (Pivotal’s commercial PaaS based on CF) is an exception (Azure, Google Cloud Platform, AWS, etc). I get the feeling that IBM and Oracle are less inclined to support such environments since they also have a hosting business (SoftLayer, etc).

In an interesting coincidence, Virtustream just announced its support of multi- and single-tenant instances of CF and the analysis of this announcement demonstrates the volatility of the market and the competition between the providers of private and public clouds.

Arguably, the most significant aspect of the emphasis that is being put on Virtustream within the Dell Technologies group of companies is that it signals that the new entity plans to compete much more aggressively against cloud service providers that, rather than buying equipment from Dell Technologies, rely more on their own engineering expertise to build clouds based on white boxes. From the perspective of Dell Technologies, the application workloads running on those public clouds represent lost business that otherwise would be running in an on-premise data center.

Thus, SCP’s plans to support different public clouds would appear to be an important strategic advantage that sets the solution apart from its competitors.

The missing clue: The multi-cloud realized

I had just decided to end my blog when I conducted a new search for “Azure and SCP” and found a new link to a SCP help page that hadn’t been there a few days earlier. Scrolling down the page to the Infrastructure Providers section, I let out a little giggle and did a fist-pump with the imaginary Sherlock Holmes who accompanies me as I research my blogs:

The SAP Cloud Platform runs on several underlying Infrastructure as a Service technologies.

Currently, it runs on SAP's own infrastructure, on Amazon Web Services, and on Microsoft Azure (beta).

The product scope and the available services vary depending on the infrastructure provider.

Here was the evidence for which I had been searching – SCP running on Azure. Even better, SCP running on AWS as well (though to be truthful, I couldn’t find any indication that this hadn’t been supported earlier).  This is not the Hana DB running on these infrastructure providers – this is SCP supporting these environments.

After the initial satisfaction of finding the content, I started mining the linked pages for more details.  An important screen concerns which SCP services are available in the Azure environment:

Note: This picture only shows a partial list of all the services.

The first thing that is evident is that the majority of services are currently not supported in Azure. Note: This probably isn’t restricted to Azure but is probably present on other infrastructure providers as well. Their absence demonstrates a very important aspect of Multi-Cloud functionality – the ability to support another infrastructure provider via CF doesn’t mean that all services will or can be supported.

As I mentioned above, CF itself already supports Azure. To better identify which are the SAP-specific services in the above mentioned graphic, it would be interesting to add one more aspect in the legend - which of these services are standard CF functionality and not SAP-created services.

If you recall the two job offers depicted earlier in the blog, one offer concerned a particular SCP service.   We can expect that other SAP-created services will also be analyzed to be understand whether they can also be CF-ized so that they can made available in other infrastructures.  Examples of SAP-created services that already support CF already exist: for example, the Portal Service. The SAP Web IDE also has multi-cloud support.   There are other services whose absence surprised me – for example, the YaaS business services since they are already CF-based and run on AWS.

The technical viability of such migrations may not be the only angle to consider. There are some services that SAP may only want to offer in the SAP-hosted environment.  Partners that are considering developing services on SCP must also make the same analysis – develop for Neo or CF.

Note: One other interesting aspect of this solution is that only Docker-based services are supported in Azure which means that all those SAP-created services available on Azure are also using Docker.  The use of such containers will gain increased importance as SCP evolves. In view of this development, the departure of Steve Singh to become the CEO of Docker should be viewed less as a short-term loss of cloud DNA for SAP but rather as a sign of a long-term closer strategic partnership between the two companies.  SAP is actively bringing Docker and CF closer together, as evidenced by its work on the Service Fabrik which is a “Cloud Foundry service broker which provisions service instances as Docker containers and BOSH deployments”.

My take

The title “The missing clue: The Multi-Cloud realized” might have been too enthusiastic in that SAP’s “Multi-Cloud” hasn’t really been completely realized.  The availability of a beta on Azure is an important first step. There are variety of challenges, however, that SAP may experience as it moves forward.  Many of these challenges will occur as SCP moves beyond the public cloud to private clouds. Here are a few examples:

Operations

There has been a great deal of buzz recently regarding the difficulty in finding CF developers.  If the demand for CF developers is high, what does the market look like for individuals who know how to operate CF?  I’m not talking about operating CF as a developer working in his own personal CF environment. I’m talking about running a productive instance of CF in a private data center. SAP has an entire Cloud Architecture and Engineering (CAE) organization working on this topic.

It is true that many organizations are becoming increasing competent in operating public cloud infrastructures but my assumption is that SAP will have to assist customers and partners regarding CF-specific operations relations topics. Many of the Bluemix deployment scenarios involve IBM taking care of the operation of the PaaS. Perhaps the relative youth of CF is also a motivation for this strategy.

SCP isn’t the only SAP Cloud product on this journey – another example is S/4HANA.  There are already examples of customers installing S/4HANA on AWS where internal IT operates the application.  The architecture of S/4HANA (ABAP-Stack, etc) is similar enough to other existing SAP solutions with which customers and partners are already familiar. SCP is built on CloudFoundry which is still very new in comparison.  The necessity of using Docker (for example on Azure) – will also be new for many.

Release management

At the moment, SCP is usually hosted by SAP which makes the release process relatively easy. As installations start popping up in private clouds – controlled by entities other than SAP, the release management process becomes more complex.  Yes, there may be one set of CF code / services but how do you deal with older versions of the code that are running on platforms controlled by customers or partners. This is similar to S4 with its various cloud versions and a large number of customers running On Premise installations.

End note: I am on site this week at Sapphire Now, along with fellow diginomicans Jon Reed and Den Howlett. If we learn anything that expands on this, you can expect an update - with any luck, at my traditional end of week podcast with Jon Reed. We'll add that here when it's ready.

Updated with several minor clarifications, 11am PT Monday May 15.