- SAP Managed Tags:
The SAP Community team is also coming to SAP TechEd 2017 Bangalore to share some knowledge about its microservices architecture:
The lecture presents the microservices architecture that consists of multiple individual applications of different size and technology. The architecture focuses on a separation of the functionality into independent applications. Therefore, the SAP Community Platform is a collaboration of many smaller applications. Even such complex scenarios as the SAP Community with thousands of users are supported by the SAP Cloud Platform.
Over the past few years, we have seen the benefits of this approach when it comes to constant grow, scalability and resilience. Let’s look at these benefits in more detail:
The SAP Community avoids large monoliths that grow constantly over time and get slower and harder to maintain when new features are added. Instead, we add new applications for major new features that do not naturally fit into existing applications. The new applications provide their own user interface or an HTTP API to connect it to the other applications. The SAP Cloud Platform helps us adding and managing new applications including persistence and security.
The SAP Cloud Platform runs applications on compute units, which are virtualized hardware resources with certain central processing units, main memory, and disk space. Depending on the need of the application, we have chosen the appropriate configuration. If the need changes, the configuration can be easily changed. The number of processes can also be chosen depending on the application’s needs.
The applications of the SAP Community Platform are independent deployment units. If one of the application fails, the fault is isolated in the failing application. If necessary, a bug fix could then be deployed without shutting down the whole SAP Community Platform. In fact, small issues in the past have been fixed almost unnoticed since only a part of the whole system was affected. There is one crucial component in the architecture to support resilience: the messaging system. The default integration is based on lightweight messaging since the messaging system decouples message producers and message consumers. If a message consumer is temporarily unavailable, the messages will be stored by the messaging system until all consumers received the data.
If you’re interested in the topics or simply want to meet one of the architects, check out the session or contact me directly.
| CPL219SAP | Community: Real-World Microservice Architectures on SAP Cloud Platform |
The lecture presents the microservices architecture that consists of multiple individual applications of different size and technology. The architecture focuses on a separation of the functionality into independent applications. Therefore, the SAP Community Platform is a collaboration of many smaller applications. Even such complex scenarios as the SAP Community with thousands of users are supported by the SAP Cloud Platform.
Over the past few years, we have seen the benefits of this approach when it comes to constant grow, scalability and resilience. Let’s look at these benefits in more detail:
Constant grow
The SAP Community avoids large monoliths that grow constantly over time and get slower and harder to maintain when new features are added. Instead, we add new applications for major new features that do not naturally fit into existing applications. The new applications provide their own user interface or an HTTP API to connect it to the other applications. The SAP Cloud Platform helps us adding and managing new applications including persistence and security.
Scalability
The SAP Cloud Platform runs applications on compute units, which are virtualized hardware resources with certain central processing units, main memory, and disk space. Depending on the need of the application, we have chosen the appropriate configuration. If the need changes, the configuration can be easily changed. The number of processes can also be chosen depending on the application’s needs.
Resilience
The applications of the SAP Community Platform are independent deployment units. If one of the application fails, the fault is isolated in the failing application. If necessary, a bug fix could then be deployed without shutting down the whole SAP Community Platform. In fact, small issues in the past have been fixed almost unnoticed since only a part of the whole system was affected. There is one crucial component in the architecture to support resilience: the messaging system. The default integration is based on lightweight messaging since the messaging system decouples message producers and message consumers. If a message consumer is temporarily unavailable, the messages will be stored by the messaging system until all consumers received the data.
If you’re interested in the topics or simply want to meet one of the architects, check out the session or contact me directly.
4 Comments
