A comparison between the typical SAP S4/HANA and cloud-native architectures

SAP SE’s software manages critical business processes for many global organizations, including finance, sales, distribution, materials, warehousing, human resources, etc. 77% percent of global transaction revenue flows through SAP systems. Most of the public listed companies are SAP customers due to how friendly the software is for the audits required. And 98 of the 100 largest companies in the world are SAP customers.

Given these credentials, we can easily assume that SAP has a vital importance for most of the companies we interact with. It is extremely reliable and once stable, doesn't require constant interaction to ensure it's working properly. Due to how critical the software is, SAP typically has been risk-averse in terms of adopting new technologies and practices for its main platform, but mostly for evolving its architecture. And while the open-source world evolved at a rapid pace, the SAP core has remained unchanged for a long while.

Let's take a look at typical architectures, both of SAP and of a cloud-native micro-services application, and highlight a few of the most important differences and their consequences for the business running on it.

SAP Architecture

The SAP architecture is very similar to what is known in the software industry as a monolith. Let's take a look at the SAP architecture and analyze its core components, as well as its operation details.

Typical SAP S4/HANA architecture

The components - and more details:

• SAP HANA Primary — active database.
• SAP HANA Secondary — standby-database.
• SAP ASCS (ABAP Central Services) — works as a message server in the architecture.
• SAP ERS (Enqueue Replication Server) — is the HA component for ASCS. Takes over if ASCS fails.
• AS (Application Server) 1, 2, 3, N — this is where users connect to.

Important remarks:

• An SAP environment is very reliable and hardly requires intervention during regular operation.
• The typical required operations for the environment are patching the Operating System (OS) and the SAP software themselves. This does require to stop the entire environment and bring it back once the patches are completed.
• It is common to prepare and fine-tune some parameters when there's a large-scale event happening, such as a black Friday or a major public product announcement.
• When logging in, users reach out to ASCS, which assigns an application server considering the load across all the Application Servers. Once assigned to a server, all the user requests are processed by that same server, making it a stateful application.
• SAP HANA is an in-memory database. Usually it requires instances with TBs of memory, demanding the U family or the X family on EC2.
• SAP does not run on containers. So all the components run on EC2 instances.
• You cannot customize the S4/HANA stack. You can't change the code used for building the Application Server, ASCS or the HANA DB, as they are proprietary from SAP.
• The pipelines for deploying this environment are going to be conceptually very simple: infrastructure layer and application installation.
• Regular cloud-native autoscaling is not supported for out-of-the-box SAP installations.

Cloud-native micro-services Architecture

Now, let's take a look at a high-level cloud-native architecture.

Simple micro services architecture

The components:

• MS (MicroService) X DB — Database available in one availability zone.
• Read replicas and/or standby databases available in the other availability zones.
• Application Load Balancer — directs users to the best available pod at the moment, regardless of where the last request was sent into, making it a stateless application.
• Pods running on some sort of Kubernetes represent the application layer.
• Important: this simple approach doesn’t show any messaging/queue server, cache layer for the database, in-memory databases and other components that could make the architecture more complex.

Important remarks:

• A micro services architecture by design is made for constant change. And since everything in this architecture is customizable, it is expected that the environment operates under some level of expected failure.
• When patching any layer of the architecture, it is possible to prevent any downtime.
• It's fairly expected that this application will use small instances, that are going to be cheaper than the aforementioned U or X family.
• Given the flexibility of containers, modern deployment strategies can be applied to the application layer, such as Blue/Green and Canary.
• The pipelines are going to be quite complex in this scenario, depending on how stable the environment has to be, and there will be quite a few: a few for the common infrastructure and SaaS configuration, at least one for each application deployment. Steps in these pipelines will include different layers of testing, deployment strategies, and etc.
• You can and it's very simple to autoscale the application following traffic demands.

The comparison

Looking from the business side, both architectures will be invaluable for corporations. SAP brings the stability of a renowned software, while the micro services architecture allows companies to create the tailored experience their customers demand. Them both work side by side. Having that in mind I want to highlight some key differences that will help to understand when one is required versus the other:

1. Time to deploy/investment — SAP is much faster to deploy than to create a micro services architecture in the cloud.
2. Stability — SAP is and has been extremely reliable for decades. On a micro services architecture you have to expect some instability while the software is maturing.
3. Downtime — In mature organizations, the downtime required for the maintenance of an SAP landscape is going to be acceptable (2 ~ 12h) for a software as stable and critical as it is. But, there's still downtime. In a micro services architecture, you can expect to have no downtime.
4. Flexibility — In a micro services architecture, since every layer of the application is built/crafted, it's highly flexible and customizable from day one. On SAP, there's no customization allowed on the infrastructure side or the components that run the application. So, adopting some new technology to make the environment run faster/smoother/easier to manage, is not an option for SAP.
5. Autoscaling — Since micro services are very friendly to be run in the cloud, these applications can benefit from the pay-as-you-go model, fine tuning the application behavior to save money during low-utilization periods. On SAP, you will size the architecture once and will pay for that same amount of hardware for the whole month without any optimizations.

Conclusion

In this blog post I'm presenting the differences for both SAP natives and open source/micro services native decision makers, who want to take a look at how the other side of the wall works. Understanding the differences helps to understand why/how some decisions are made on each environment, such as investment size, preparation for large scale events, downtime situations, and etc.

PS 1: Even though I mentioned application pipelines for the micro services architecture, blue/green, canary and etc, I didn’t mention the software development inside of an SAP environment using the ABAP programming language. This is the subject for a future blog post.