Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Remarks on containerisation and other topics in relation to SAP

dylan-drummond
Contributor
‎11-16-2021 8:26 AM

Introduction


We will discuss containerisation (and virtualisation) wrt. various SAP products. This is just a collection of remarks, and is not intended to be some kind of PhD-like paper that would be covering everything in great detail, with all references and statements triple-checked and so on, as that would take months. Instead the idea is just to comment on the relevance of containerisation for SAP products, and point out SAP’s current official stance. 

[Disclaimer: Any opinions expressed are the author’s own. No responsibility or liability will be accepted for inaccuracies, nor for any actions taken by others on the basis of the remarks expressed. Also note that I am not an expert in the history of computer science, and not an employee of SAP, so I have no privileged visibility into SAP’s current or future planning wrt. containerisation].

 

Quick recap


On the internet you can find plenty of useful definitions of what virtual machines and containers are. Anyway, now follows a brief description of virtual machines, containers, and their history.

Virtual machines


Basically, a virtual machine (commonly known as a VM) is an abstraction of a physical machine’s hardware. So one main practical consequence is that many virtual machines can run on a real physical machine. Another benefit is the ability to shift VMs (manually, and/or nowadays often in automated manner) from one rack or blade server to another - thus improving continuity for when some planned or unplanned maintenance needs to occur to physical hardware.

Now, when SAP systems in the 1990s switched mostly from mainframe to client-server paradigm, at that time the servers which SAP ERP (a.k.a. “SAP R/3”) was running on were usually physical machines. 

As it happens, virtualisation has been around for many decades - think LPARs from fifty years ago - but for many people, the rise into the enterprise IT sphere of first VMware virtual machines and then similar offerings from other vendors in the early 2000s, is considered the start of the “proper” era of virtualisation. And sure enough, SAP systems were also soon* certified to run on VMware virtual machines, typically Unix and Windows. (A quirk of SAP documentation is that they often say “Unix” when they mean “Unix or Linux” - I’m not taking any sides on these Posix-related naming debates, just pointing this out in case you are ever weeding through SAP Help 🙂 ),

[* Well, as a friend pointed out recently, it took a few years from the virtualisation boom before SAP got around to certifying virtualisation products, though here in our blog we’ll avoid speculation about the history of that delay].

Also worth mentioning here is that the rise of virtual machines in the enterprise, was a breakthrough that saved the enterprises plenty of money, because now there was better utilisation of the actual hardware in the datacentres - so instead of having 5 applications each running on its own physical rack server, with each server utilising (say) 5% of its compute power, we could have 5 applications running on 5 virtual machines running on 1 physical server. Also the decoupling of VMs from underlying hardware made planned and unplanned maintenance much more efficient, increasing uptime.

Last VM recap point: it was the rise of virtualisation in the enterprise, particularly of virtual machines and storage networks, that made it possible for the rise of the public cloud providers, beginning with AWS sometime around 2006 - Amazon basically realised that since most of the year they had lots of spare (virtualised) compute, network and storage capacity, they could rent out most of that compute power to customers, as the customers were by now used to the idea of running their workloads on virtual servers… and so a huge industry trend began to emerge.

Containers


A container is an abstraction of an operating system. So the main practical consequence is that many containers can run on the same operating system, and containers function as the practical layer for running microservices (smaller programs which tend to only provide a small subset of the overall functionality of an application or system, and outsource statefulness to e.g. a database). 

There were various precursors to modern-day containers; in any case, the main idea here is that instead of an application commanding a whole VM, it’s enough for the application to specify as a “container image” for some OS, which packages and programs it specifically needs for itself, and then to let the underlying VM and the OS on that VM handle all the “generic OS” stuff. This meant that applications (often now a set of microservices) are then running safely in separate runtime containers (“container instances”), with typically multiple containers on the same VM. Which again leads to efficiencies in the use of compute power.

Now a corollary of the rise of containers and the microservices paradigm for application design, was that there comes a need for stable and effective “networking for the applications”, since the microservices in the containers need to communicate between themselves… this had at least two main consequences: firstly, networking in datacentres had to improve - and it did: in the end, the leaf-spine “Clos topology” architecture running on TCP/IP won out against the older architecture concepts such as the agg-access layer architecture - so cloud providers and other firms such as Cisco had a big advantage over legacy datacentres; the other, related consequence, was that application design in many cases swung towards the idea of having many microservices running as containers, usually with some kind of orchestration tools such as Kubernetes and/or the wrapper services providing Kubernetes, and these container-based applications were easier to implement and run on modern datacentres… and that often meant and means today, running in the public cloud. So in effect this move towards container-based app architecture, has been a driving force in enterprise public cloud adoption.

 

SAP’s main products and their architectures


SAP ERP and ERP-like systems


SAP’s most important product, for the almost fifty years of its existence, has been (and still is) SAP ERP. There are also SAP products which are running on the same “ERP chassis” - for example SAP EWM (Extended Warehouse Management), SAP SCM (Supply Chain Management) and so on, are typically based on an SAP S/4 platform.

The name of the main ERP platform has changed over the years... SAP R/2... SAP R/3... SAP ECC... to the latest platform, which is SAP S/4HANA. The functionality has also evolved, and so has the technical deployment architecture of the SAP system.

In the 80s and early 90s, SAP R/2 was a mainframe-based application, with the database and the logic layer on a mainframe, and users accessing SAP using text-based GUI on terminals. Then in the 90s came SAP R/3 which adopted the client/server architecture i.e. database on one server; logic layer now as 1...N application servers, with one application server also handling the users’ Abap (or Java) sessions, work process assignments, and database locks for the sessions, and then the program logic either running on the same server or on additional app servers. (The “third layer” was the introduction of SAPGUI). With minor modifications and some extras not highly relevant to our discussion, the same client/server deployment architecture is used today, and is the basis of deployment reference architectures (as well as the actually implemented architectures of many thousands of SAP environments) for both on-prem as well as cloud provider IaaS scenarios.

As a minor historical note, the book “SAP R/3 System: A Client/Server Technology” (Rüdiger, Buck-Emden, Jürgen, Galimow; Addison-Wesley, 1996) was the first book this author read about SAP. It’s still available for purchase, so if you are into that kind of thing then get yourself a copy.


 

If we look at examples of SAP reference deployment architectures from AWS, Microsoft Azure, and Google Cloud Platform, we see that the paradigm established in the 1990s continues to be valid today:

https://docs.aws.amazon.com/sap/latest/sap-netweaver/architecture-options.html 

https://docs.microsoft.com/en-gb/learn/modules/utilize-azure-sap-workloads-reference-architecture/ 

https://cloud.google.com/solutions/sap/docs/architectures/sap-s4hana-on-gcp 

So the main observations are that the database is usually on its own server, and the application servers are on their own servers. (We ignore occasional sandbox-system architectures where many components can be squeezed onto one server for cost reductions).

Then an observation we will return to later: for the reference architectures, as well for all the actually implemented for customer SAP ERP or ERP-like System architectures around the world, these are done mostly on virtual machines, sometimes on bare metal servers (i.e. physical machines) for the larger databases, and as of November 2021 never using a containerisation and orchestration layer involving e.g. containers and Kubernetes (Kubernetes is the most popular container orchestration toolset). 

SAP Note 1122387 “Linux: SAP Support in virtualized environments” 


SAP Notes are official statements or technical corrections or advice maintained and released by SAP for SAP Customers. In the SAP Note 1122387 “Linux: SAP Support in virtualized environments”, SAP states which virtualisation products are SAP certified, and then states that containerisation products are not SAP-certified. The SAP Note describes its purpose thus:

“You want to run SAP NetWeaver-based application servers (ABAP, J2EE) on a virtualized or a containerized Linux platform. This note provides information about the support of all SAP applications on Linux to which the General Support Statement for Virtual Environments applies (see SAP note 1492000).”

In the next two sections we see what it says about virtualisation and containerisation respectively.

 

Reference List of SAP-certified virtualisation products


FYR as of 09.11.2021 (formatting a bit sketchy as copy-pasted from the SAP Note PDF):

“

  • Xen based virtualization products 

  • SUSE Linux Enterprise Server 

  • Red Hat Enterprise Linux

  • Citrix XenServer

  • Oracle VM - see SAP notes 1808268 and 1817065

  • Huawei FusionSphere

  • KVM based virtualization products

  • SUSE Linux Enterprise Server

  • Red Hat Enterprise Linux (RHEL)

  • Red Hat Virtualization (RHV)

  • KVM for IBM z Systems

  • Nutanix AHV

  • Oracle Linux KVM

  • Huawei FusionSphere KVM

  • VMware virtualization products

  • In virtual and private cloud environments: VMware ESXi Server and vSphere versions 5.x, 6.0, 6.5, 6.7 and 7.0



  • In public cloud (IaaS) environments, the use of virtualization technology on top of the VM is only allowed with the following partner offering: SAP on IBM Cloud Infrastructure

  • Before installing or upgrading to VMware ESXi 5.5 U3 and 6.0, check the patch levels required which are listed in SAP Notes 2229228 , 2237937, 2293740 and 2381942!



 

Containerisation not currently SAP-certified


SAP makes it quite clear, that as of the latest version (at the time of writing) of this SAP Note 1122387 (02.11.2021, retrieved on 09.11.2021), containers and Kubernetes etc are not supported platforms for running SAP’s main products:

“Container and Container Orchestration Environments

Currently it is not supported to run SAP application servers inside a container

or a container orchestration environment, such as Kubernetes.

Unsupported Container solutions:

  • Parallels Virtuozzo Containers

  • Linux Containers (LXC, Docker, CRI-O, etc) 

  • and all others 


Unsupported Kubernetes products and services:

  • Red Hat Openshift

  • SUSE Caas Platform

  • Google Cloud Platform Kubernetes Engine (GKE)

  • Microsoft Azure Kubernetes Service (AKS)

  • AWS Elastic Kubernetes Services (EKS)

  • Alibaba Container Service for Kubernetes (ACK) 

  • and all others ”


 

Now the “SAP NetWeaver-based application servers” the Note discusses, are the controlling logic servers of the main SAP products. And it’s quite explicitly stated that all container solutions, and in addition all of the various Kubernetes products such as Red Hat Openshift, SUSE Caas, GCP/Azure/AWS Kubernetes services etc “and all others”, are not supported. 

A corollary is that when these NetWeaver-based servers, which are much more lightweight than the servers and databases used as components of SAP Systems, are not to be run productively (nor generally at all, for any system where SAP support is required, e.g. QA systems) on containers or container orchestration environments, then we can safely assume for now that the same prohibition applies to for example SAP HANA databases. Actually, that brings to mind another point about virtualisation and SAP, which is…

Large SAP HANA installations often use physical hardware


Although virtual machines are getting gradually more capable of hosting very large databases, still, as of 2021, many of the larger SAP Customers run their large SAP databases on physical hardware (often called “bare-metal”). This occurs in on-premise datacentres frequently, and also occurs in the public cloud SAP installations, for example in Azure a specific product is available for exactly this use case:

https://docs.microsoft.com/en-gb/learn/modules/utilize-azure-sap-workloads-reference-architecture/6-... 

“The architecture of SAP HANA on Azure (Large Instances) provides an SAP TDI-certified hardware configuration, which is a non-virtualized, bare metal, high-performance server for the SAP HANA database.”

So the point here is that SAP databases are even further away for containerisation than other SAP main product components, since some of them are even running on non-virtualised machines. The reason is again more or less the same: that there is no business or technical advantage from containerisation of databases that are typically taking up all the compute resources of a virtual server, and sometimes even need to strip away the virtualisation layer to fully utilise the physical compute resources of a non-virtual server.

Ok, before we more on, we point out one more relevant section from the SAP Note 1122387...

Nested virtualisation not currently SAP-certified


“Nested Virtualization

Nested virtualization (running SAP applications on a VM in a hypervisor within another hypervisor stack) is not supported by SAP.”

I would interpret this as saying that if (say) you are using the SAP-certified VMs of a Hyperscaler or of VMware, then you may not install another virtualisation product from the reference list and then run SAP in this nested virtualisation mode. (Which makes sense really: there is rarely any benefit, but there are often problems, when using nested virtualisation compared to using non-nested virtualisation).

 

Some example cases where containerisation of SAP products is valid


[For a more expansive and accurate look at SAP, Cloud Foundry and Kubernetes, see this nice blog by Denys van Kempen:

https://blogs.sap.com/2020/05/21/cloud-foundry-and-k8s-sap-hana-2.0-an-introduction/ 

In this blog I just give some examples, rather than a proper overview as such. 

For those interested in how SAP came to Cloud Foundry and Kubernetes, see this blog: 

https://blogs.sap.com/2021/01/15/back-to-the-future-cloud-foundry-on-kubernetes/  ].

SAP BTP


SAP’s Business Technology Platform (“BTP”; formerly known as SAP Cloud Platform or SAP HANA Cloud Platform - SAP likes to rename things frequently) is a Platform-as-a-Service cloud offering from SAP. Originally the “Neo”-flavour was built using OpenStack as the virtualisation technology, with Linux containers orchestrated through the Diego engine. The “Neo”-flavour has been largely superseded by the “Cloud Foundry” flavour though - Cloud Foundry is part of The Linux Foundation, supported by major software companies (contributors include SAP, IBM, and VMware), and according to their own marketing “Cloud Foundry provides a highly efficient, modern model for cloud native application delivery on top of Kubernetes.” (https://www.cloudfoundry.org/).

SAP Analytics Cloud, which is a SaaS product for BI and Analytics, built on the SAP BTP platform, is a good example of a containerised SAP product. (Note that with SAP Analytics Cloud, the customer does not directly interact or configure the containers or orchestration).

SAP also makes the Kyma runtime available via BTP - Kyma is an extra abstraction on top of Kubernetes giving developers choice in how they structure and deploy their applications:

https://kyma-project.io/ 

(Kyma is an interesting project, although not yet (at time of writing) having a large footprint in the SAP Developer community).

So with the SAP BTP PaaS product, and other SAP products built on top of the BTP Cloud Foundry edition, SAP participates in the world of cloud computing, containerisation, and orchestration of containers (using Kubernetes). 

SAP Hybris


A few years ago (2013) SAP acquired a CRM and Marketing Platform software company called Hybris, their platform was built primarily as a set of Java-based modules. So for this SAP Product, the containerisation was considered both feasible and desirable, and thus nowadays Hybris can e.g. also be installed and run as a containerised deployment using Kubernetes - see for example this documentation for SAP on Google Cloud, in this case the orchestration is done using GKE (Google Kubernetes Engine… btw Kubernetes itself was originally provided to the world by Google, as the open-source spinoff of their Borg engine…):

https://cloud.google.com/solutions/sap/docs/sap-hybris-deployment-architecture#deploying_sap_hybris_... 

(You’ll note that the SQL Server and Replica are outside of the Kubernetes Engine though… probably because they are databases, which are the “engines of statefulness”).

SAP ABAP Platform, Developer Edition


SAP offers a free product for SAP developers and admins to practice their skills with, it’s called SAP ABAP Platform, Developer Edition, and is delivered as a docker image with a (very small) HANA database plus an ABAP Platform (successor to SAP NetWeaver) application server or to be exact application servers (one is the ASCS, and one is the PAS). You can get this image by registering with Docker Hub:

https://hub.docker.com/_/sap-abap-trial 


So this is a really useful product for certain purposes, assuming the SAP developer or admin has a reasonably powerful local machine: to run the above “mini-SAP” developer edition, you need 16 GB of memory and around 170 GB of storage space.

[Well, 15 GB of memory may be enough, at least I got by on that amount, as described in this blog:

https://blogs.sap.com/2021/05/31/install-abap-platform-developer-edition-on-docker-for-macbook/ ].

SAP decided to containerise this developer edition, probably because it makes both distribution of the image, and then local installation, a bit easier than it was before 2021 (before, for the SAP NetWeaver Developer Edition, it was necessary to download 11 very large .rar files, unrar and merge the files, then install a small SAP system, usually on a virtual machine on a Type 2 Hypervisor - though if you ran a Linux laptop with suitable specs and OS, then a bare-metal installation was also possible).

Two things worth mentioning: the first is that there was a “business case” for this, as this developer edition, unlike the real-life SAP systems, is not requiring all kinds of certification from SAP and vendors to be acceptable for SAP customers (as the SAP developers, admins, and hobbyists are not SAP customers with an SAP Customer Number etc). There is actually zero support from SAP in case this developer edition crashes, after all it is a free product and that is what free buys you in terms of enterprise support from SAP, fair enough really. 

The other thing is that this developer edition obviously does not scale for any real-life scenarios: the product is designed for Abap programmers and Basis administrators to experiment with, and no actual SAP business functional modules are included in (nor are those to be installed on) the developer edition. The product is just a free SDK, and won’t be the base on which real-life deployments are roadmapped or planned.

A POC by some SAP developers


This is quite interesting, a blog on the SAP Community pages:

https://blogs.sap.com/2020/05/22/proof-of-concept-sap-on-kubernetes-deployment-application-and-datab... 

So we can see that SAP, as a large software company, certainly has the technical ability to containerise and kubernetise things when they want to. The point remains though, that there isn’t in my opinion any business or technical driver, that would be currently actively pushing SAP towards even roadmapping containerisation of their major traditional products. As the blog itself makes clear:

“Please note that this document is not official solution or ongoing development update. Always refer to SAP official documents for any related information. Official support information of SAP on kubernetes ( virtualized environments ) is documented in SAP Note 1122387 ”

...and that SAP Note is exactly the one we just discussed above, i.e. the one saying officially “no” to any form of containerisation for the ERP-like products. So although the blog is a nice POC demonstration, it doesn’t imply any kind of further actions by SAP on this topic (in fact the blog explicitly denies any such implication).

Conclusion


SAP, explicitly and officially, does not currently support the use of any containerisation technologies, for any of its main-line ERP-like products.

Currently, the main “real-life” SAP products where containerisation configured by customers or their partners can be relevant, are SAP Hybris and SAP Kyma runtime.

SAP uses containers and orchestration to provide SAP BTP and products such as SAP HANA Cloud and SAP Analytics Cloud, however this containerisation is managed by SAP and is mostly invisible to the SAP Customer base.

It seems to me that SAP does not have any published roadmap (or plans for a roadmap) in the containerisation topic, and if so this is then indicating that the situation vis-a-vis containerisation technology support wrt. ERP-like products is not going to change much in the next few years. (However, we may recall that back in the days, SAP waited for some time before certifying virtualisation products for SAP, so let’s see, if at some point they decide to spring a surprise in the containerisation topics also).

 

 
2 Comments
Labels in this area
Popular Blog Posts