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...
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.
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.
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.
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:
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.
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).
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."
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.
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.
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 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.
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:
Brought to you by the SAP S/4HANA Customer Care and RIG
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 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:
| Build a web API | Implement an endpoint for your web applications using the HTTP trigger |
| Process file uploads | Run code when a file is uploaded or changed in blob storage |
| Build a serverless workflow | Create an event-driven workflow from a series of functions using durable functions |
| Respond to database change | Run custom logic when a document is created or updated in database or storage |
| Run scheduled tasks | Execute code on pre-defined timed intervals |
| Reliable message queue systems | Process message queues using Queue Storage, Service Bus, or Event Hubs |
| And many more... |
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
We have provided a brief overview of the evolution of software architecture, from monolithic applications to microservices and serverless computing. Additionally, we have described how SAP is also on a gradual journey to adapt SAP S/4HANA and the Intelligent Suite software to these architecture patterns.
In our upcoming blog posts, we will delve into the practical application of these patterns to build scalable, reliable, and high-performing large-scale systems. We will demonstrate how various technologies can be combined to create an application that can scale from a single user to potentially millions of users. Additionally, we will compare how SAP leverages these same patterns to address the same scalability issues.
Stay tuned for more!
Brought to you by the SAP S/4HANA Customer Care and RIG
- SAP Managed Tags:
5 Comments
