Skip to Content
Technical Articles

Developing Applications in a Multicloud Environment

This blog post series is about developing applications in a multicloud environment.

Any good? Post a comment, share on social media, and/or give a like. Thanks!

/wp-content/uploads/2016/02/sapnwabline_885687.png

Going Multicloud

Embracing the Hyperscalers

The multicloud concept was introduced at SAP back in 2017 when Cloud Foundry was added to the SAP Cloud Platform (and which lost its HANA epithet as a result). Until then, SAP’s enterprise platform-as-a-service (ePaaS) was hosted exclusively from its own data centers. Now it could be hosted on different clouds.

SAP enthusiasm for multicloud continued with the launch of the Business Technology Platform aiming for maximum business impact.

At SAPPHIRE 2019, the “Embrace” project was announced and although in particular Microsoft responded favourably, it was targeted originally at the cloud’s Big Four.

Cloud Foundry

We already did some digging into the past of the SAP (HANA) Cloud Platform in a blog trilogy about the origins of PaaS and Cloud Foundry, SAP’s involvement, and the latest development with Kubernetes.

In brief, SAP’s ePaaS started with SAP NetWeaver Cloud, then evolved into SAP HANA Cloud Platform when merged with SAP HANA database services, and next into SAP Cloud Platform when open-source Cloud Foundry was added. The original neo (NetWeaver OnDemand) code name got its comeback as label for the proprietary part of the platform, now considered an “environment”.

/wp-content/uploads/2016/02/sapnwabline_885687.png

SAP Cloud Platform

Environments

As defined (SAP Cloud Platform Glossary):

Each environment provides at least one application runtime and comes with its own domain model, user and role management logic, and tools (for example, command line utility). Environments are self-sufficient and integrated into the platform at the subaccount level, which means that each environment can be used on its own without the need to use another environment.

Put that in a table and you get something like this:

Environment Neo Cloud Foundry
Application Runtime(s) Java, HTML5/SAPUI5, XS Buildpacks
Domain Model Orgs and Spaces
User and Role management Authorization and Trust UAA
Command line > neo > cf
Subaccount SAP-hosted Hyperscalers

Domain Models

Although the Cloud Foundry documentation does not use the term domain model, we can imagine this to reference Orgs and Spaces. Neither is there a description of the Neo domain model but what we do have is a model for the platform as a whole when it was updated to make space (and orgs) for Cloud Foundry. This is the domain model users of the platform will be familiar with.

Previously, the domain model was regionally based. In the current model we have a global account representing the commercial contract and sub-accounts representing the environment with a one-to-one mapping of cloud provider and region.

Except for Neo, as mentioned, the infrastructure for the environment is provided by the “hyperscalers”, a.k.a cloud infrastructure providers, i.e. Amazon Web Services, Microsoft Azure, Google Cloud, and Alibaba Cloud.

The SAP Cloud Platform Regions and Service Portfolio shows the regional coverage of each platform service. The Cloud Foundry environment is not hosted in all regions where the cloud providers have a presence. For example, Cloud Foundry with Google Cloud is only hosted from Iowa (US Central) and Alibaba only from Shanghai. For future plans, see the SAP Cloud Platform Road Map.

For those new to the topic, how this all works is explained in the award-winning onboarding tutorial series where you can dive straight in.

 

/wp-content/uploads/2016/02/sapnwabline_885687.png

How to Run an App

Application Development and Runtime Environments

Like most PaaS of the early days, Neo started out with Java and JavaScript (HTML5 / SAPUI5) including the runtime for the XSJS JavaScript dialect of SAP HANA XS when this became available. Back in 2012, XS, short for extended application services, was conceived as development and runtime environment for the SAP HANA platform, including a repository and Eclipse-based development tools. Although successful and used for the development of a whole generation of SAP HANA Live, Analytics, and SAP Smart Business applications, there were some limitations to the technology and a replacement was found in Cloud Foundry.

Polyglot Push

Cloud Foundry provides several other runtimes besides Java and JavaScript (Node.js) like Go, Python, PHP, Ruby, and .NET. Bring-your-own-buildpack (runtime) is also supported but then we are heading in the IaaS direction (and may be tempted to switch to Kubernetes).

Besides the difference in runtimes, however, it is in particular the ease to deploy applications with the magic of ‘cf push’, that distinguishes the Cloud Foundry environment from Neo.

Distributions

For those less familiar, or maybe as a reminder, Cloud Foundry is the industry-standard open source cloud application platform for developing and deploying enterprise cloud applications (as advertised). If it helps, you can think of Cloud Foundry as a Linux distribution. You can run it on your laptop, on a virtual machine, host it in the cloud, or consume it as-a-service from a cloud provider.

Cloud Foundry as hosted on the SAP Cloud Platform is one of seven certified platforms.

In case we do not want to host a Cloud Foundry environment ourselves but consume it as a service, why not select IBM Cloud, or run Tanzu (Pivotal) on Google Cloud, AWS, or Azure. Why get it from SAP?

/wp-content/uploads/2016/02/sapnwabline_885687.png

Hybrid Clouds

In with the New

For some time, the answer was HANA (now there are others too). This started with an SAP HANA service broker (enabling you to bind your application to the SAP HANA database) and evolved into a Cloud Foundry distribution integrated with SAP HANA. Although the suffix was popular at the time, the name chosen was not CF/4HANA but XS Advanced model, in short XSA, with the original application server runtime and development environment now labeled as XS classic (in the spirit of Java and JavaScript).

source: Java vs. JavaScript: What’s the Difference?

The objective of Cloud Foundry is to make it easy to develop and deploy applications. With the Cloud Foundry environment hosted on the SAP Cloud Platform and a local Cloud Foundry environment available on the SAP HANA platform (XSA) this objective was met. It is very easy to develop your applications locally and deploy to the cloud. The HANA Deployment Infrastructure (HDI) and multi-target application (MTA) programming model (2015) supported this design (although technically not dependent).

In true hacker fashion, blogs were also posted explaining how to make XS Advanced behave like Cloud Foundry or how deploy MTA apps to the Neo environment.

Out with the Old

With this new environment in place, XS classic model (with repository and SAP HANA studio) was set to deprecated (2018) and developers were encouraged to migrate their applications to XS Advanced, i.e. changing the XSJS JavaScript dialect to Node.js. For those applications where migration would be too much effort, an XSJS compatibility layer was provided. This made it possible to run an XS classic app as-is as Node.js app on Cloud Foundry or XS Advanced.

For the record, although deprecated for two years, the classic model and tools are still supported for the on-premises platform with the current SAP HANA 2.0 SPS 05 release until 2025 but no longer included with the database service SAP HANA Cloud.

Multicloud

Of course, what makes the SAP Cloud Platform, Cloud Foundry environment unique is not only the integration with SAP HANA. In fact, you can bind your application to any database (does not apply to XS Advanced). There is also the multicloud factor. Without going into the details here again (see the above-mentioned trilogy), projects like Gardener focus on providing the technology to deploy applications in a multicloud environment.

Punks Not Dead

After Cloud Foundry, a third environment was added to the platform: ABAP PaaS, a.k.a. Steampunk (another internal code name), officially “SAP Cloud Platform, ABAP environment”.

Dual stack? Not really, technically, the ABAP environment runs on Cloud Foundry but this is under-the-hood. In the documentation and elsewhere it is considered a separate environment.

The focus of the ABAP environment is on ABAP development and ABAP extensions (and leverage 37 years of development experience). To try it out, we recommend:

The ABAP environment comes with its own development mode (RAP):

/wp-content/uploads/2016/02/sapnwabline_885687.png

Here Comes the Next Wave

It is all G(r)eek to Me

Earlier this year, environment number four was added: the SAP Kyma Runtime. Kyma does not rely on Cloud Foundry but runs on Kubernetes. The official name is “SAP Cloud Platform Extension Factory, Kyma runtime”.

To get started, we can recommend

Kyma is used to power the Extension Factory of the SAP Cloud Platform.

Kyma is also the name of the open source project, which provides a platform for extending applications with serverless functions and microservices, as mentioned on the project website, a selection of cloud-native projects glued together to simplify the creation and management of extensions.

For the non-g(r)eeks, κυβερνήτης is the helmsman, κύμα the wave, Helm the package manager; a nautical theme started with Docker to run containers. Cloud Foundry started in 2011 with its own container technology but there now are different approaches to bring both worlds together like Eirini (Ειρήνη), the goddess of peace (see Cloud Foundry and Kubernetes).

/wp-content/uploads/2016/02/sapnwabline_885687.png

What about Neo?

Service Evolution

With SAP embracing open-source Cloud Foundry and Kubernetes for some time now, and partnering with cloud providers for the infrastructure, the proprietary SAP-hosted Neo environment is losing its relevance. As with its on-premises NetWeaver counterpart, most of the services once provided by “NetWeaver Cloud” have now evolved and are available in the new environment(s).

One recent example is the new content management solution for Cloud Foundry.

Another is the merging of SAP Cloud Platform Identity Authentication service (IAS) and SAP Cloud Platform Identity Provisioning service (IPS) into SAP Cloud Identity Services.

Not every service has made its way to the new world. Some services have been deprecated like oldskool virtual machines. For a comparison, see

Open-source “backing” services like MongoDB or Redis were already retired last year. For the fine print and how to leverage the cloud provider services on the cloud platform, see

Migration

Recently, the Neo documentation was carved out of the core set. The SAP Cloud Platform documentation now only covers Cloud Foundry, ABAP, and Kyma. For the SAP Cloud Platform, Neo Environment, a new (retirement?) home was created on the SAP Help Portal.

Prominently displayed on the Neo Help Portal is the new migration guide with the main sections explaining what it is, why you should migrate, and how to get started.

A good example of how service migration can look like is explained for OData Provisioning

Not new, but highly relevant in this context is the documentation about how to develop applications and manage their lifecycle on the Cloud Foundry environment.

There still is a trial for the Neo environment but something tells me if you want to try it out, you better hurry up (the button is hidden a bit if you scroll down on the cloud platform home page).

/wp-content/uploads/2016/02/sapnwabline_885687.png

Discovery Center

There is a Service for that

To learn more about the latest service offerings for the SAP Cloud Platform, visit the SAP Cloud Platform Discovery Center. Here we find all 90+ services listed, bundled either in the Extension Suite or the Integration Suite.

Did you notice the new domain name?

Who knows, we may be visiting this domain in the future more often.

You can filter on the services for which a trial is available.


/wp-content/uploads/2016/02/sapnwabline_885687.png

Building in the Cloud

Cloud Application Programming

At the tail end, but we could not leave the topic unmentioned, the recommended programming model to develop cloud applications in a multicloud environment is CAP. It is best understood as an extension of the multi-target application (MTA) model SAP conceived for the Cloud Foundry environment.

To build MTAs in the cloud, a new tool is available.

Business Application Studio

The tool of choice to develop CAP applications is the Business Application Studio, which brings me back where we started: maximum business impact.

For an overview of all the material recently published on the “app studio”, see

For our topic, of particular interest is that you can use Business Application Studio to migrate applications previously created with SAP Web IDE.

/wp-content/uploads/2016/02/sapnwabline_885687.png

Share and Connect

Enjoyed the blog? Post a comment, share on social media, and/or give a like. Thanks!

If you would like to receive updates, connect with me on

Best,

Denys van Kempen

6 Comments
You must be Logged on to comment or reply to a post.