In today’s rapidly evolving technology landscape, staying up-to-date with the latest advancements is more important than ever. This is especially true for SAP architects, who are faced with the challenge of integrating complex SAP systems with native cloud services and applications running on Hyperscaler’s technology platforms.

On the other hand, there is a new generation of cloud architects who are experts in cutting-edge technologies, but may lack experience with large and complex ERPs, making it challenging for them to understand the complexities of enterprise applications.

My objective for these blog posts is to explore the patterns employed in constructing large-scale applications that are scalable, reliable, and high-performing. I will provide a detailed step-by-step explanation of how these patterns can be utilized to scale an application, enabling it to support millions of users. Additionally, I will highlight how similar patterns are utilized at SAP to develop our SAP applications.

Part 1 – Software architecture trends (this blog post)
Part 2 – How to build a scalable application – From 1 to 10K users
Part 3 – How to build a scalable application – From 10K to 100.000K users
Part 4 – How to build a scalable application – Up to Million users

But before we start to talk about how to build modern cloud applications, let’s have a look how software architecture has evolved over the years…

Software architecture trends

The trend in technology has evolved from large, tightly-coupled applications to smaller, independent services called microservices architecture. Currently, the focus is on serverless and event-driven architectures.

Software architecture patterns

Simultaneously, there has been an evolution in the complexity and requirements of applications. Present-day applications are cloud-based, requiring the processing of enormous amounts of data that usually surpass the capabilities of traditional relational databases, and mandate global and instantaneous access.

ERP vs Native Cloud Applications

Traditionally, large enterprise applications have been monolithic in origin. Such monoliths have limited scalability and can become challenging to develop as the application expands. Nevertheless, there are some notable exceptions, including mainframes utilized in banking, insurance, and stock markets since the 1960s and the Linux Kernel, which runs on a wide range of devices. These examples demonstrate that monolithic applications, despite their limitations, remain relevant.

Monolithic Applications

It’s worth to mention that Monolithic, in this context, means composed all in one piece, designed to be self-contained. Components of the program are interconnected and interdependent rather than loosely coupled. We can see how SAP ERP software, despite being monolithic, have evolved over the years:

Different types of monoliths

Service-Oriented Architecture (SOA) became popular in the early to mid-2000s as a response to the limitations of monolithic architectures. This was a time when organizations were starting to build more complex and distributed software systems, and there was a growing need for greater flexibility, scalability, and reusability in application design.

The main idea behind SOA was to separate the application into smaller, independent components or services that can be developed, deployed, and maintained independently. This approach allows for greater flexibility, scalability, and fault tolerance, making it easier to adapt to changing business needs and technological advancements.

The rise of web services and the increasing adoption of XML as a standard for data exchange also contributed to the popularity of SOA during this period. While the popularity of SOA has since waned, many of its principles and concepts continue to influence modern software architecture and development practices.

Service Oriented Architecture (SOA)

SAP was no exception, and during the mid-2000s, we introduced the concept of SAP Netweaver as a business process platform, along with the Enterprise Service Repository and Composable Applications. The goal was to maintain a stable ERP core adding innovation through Enhancement Packages (Enterprise SOA by Evolution) and, at the same time,  also enabling the development of side-by-side extensions through composable applications (Enterprise SOA by Design).

Service Oriented Architecture (SOA) at SAP

SOA was a step on the right direction, I remember the “hype” around SOA and how promising it was but as many technologies, SOA was also an overused term that meant different things to different people. But as a common denominator, SOA meant that you structured your application by decomposing it into multiple services (most commonly as HTTP services) that can be classified as different types like subsystems or tiers.

Microservices architecture and SOA are related, but there are key differences between the two.

While SOA involves decomposing applications into multiple services, it often relies on large central brokers, central orchestrators, and Enterprise Service Bus (ESB) implementations. In contrast, microservices architecture emphasizes the use of small, independent services that can be deployed and scaled independently. As one popular saying goes: “The microservice architecture is SOA done right.”

Microservices

One of the main ideas behind the microservice architecture is that each microservice owns its own data and its own domain logic. This is also one of the main design flaws for enterprise applications as architects must decide between request data from other microservices or duplicate the data introducing the idea of “eventual consistency” which is typically not a good idea in large enterprise applications.

SAP, like many other software vendors, has embraced the concept of microservices and embarked on a gradual journey to adapt their software to this architecture pattern. As illustrated in the accompanying image, SAP S/4HANA was first “simplified” by removing any unnecessary elements from the original ERP core. After that, in an ongoing iterative process, modules are being decoupled from the core and made available as new native cloud applications or alternatively, smaller functions have been delivered as services on the SAP BTP platform.

SAP S/4HANA – How SAP is peeling the monolith

Next step in the evolution of the software architecture has been the idea of serverless computing.

Microservices and serverless computing serve different purposes and are not mutually exclusive.

While microservices provide benefits in terms of scalability and flexibility, they still require developers to manage and scale the infrastructure.

Serverless computing completely removes the need for infrastructure management, allowing developers to focus solely on writing code. With serverless functions, cloud providers manage the infrastructure and automatically allocate computing resources as needed in response to events or requests. Developers write code in the form of functions, which are executed in stateless containers and charged only for the time they run.

Serverless computing

Why Serverless if we already had microservices? The key feature of cloud-native architectures is their capacity to scale dynamically and support large numbers of users, events, and requests across distributed applications and teams. Serverless computing can assist in managing these challenges without burdening developers with concerns about infrastructure or the entire application.

This approach enables multiple and diverse use cases like:

Serverless functions

Serverless functions and event-driven architectures are closely related concepts that are often used together to build modern applications.

As mentioned before, serverless functions are a type of cloud computing service where the cloud provider manages the infrastructure and automatically scales resources as needed.

Event-driven architectures, on the other hand, are a software design pattern where the flow of data and processing is determined by events, rather than by a centralized control structure. In an event-driven architecture, different components of the system communicate with each other by publishing and subscribing to events. When an event occurs, the system triggers the appropriate response, which could include running a serverless function.

Therefore, serverless functions are often used as a key component of event-driven architectures. For example, a serverless function could be triggered by an event such as a new record being added to a database, or a message being received from a queue. This allows the application to respond quickly and efficiently to events, without the need to manage servers or maintain complex infrastructure.

Native cloud web services – Serverless and Event driven

Similarly, SAP is also embracing this architecture trend and enabling customer to develop side-by-side extension on the SAP Business Technology Platform which can be develop using the SAP Kyma runtime and SAP Event Mesh services to implement serveless + event driven applications:

Serveless and Event Driven architecture at SAP

Final thoughts and next steps

Brought to you by the SAP S/4HANA Customer Care and RIG