Introduction

In the past, we have built reliable software systems by attempting to avoid mistakes and breakdowns, but modern resilience-based techniques advocate accepting failure rather than attempting to avoid it.  There are different principles and patterns that may be used to make your applications more resilient. However, finding the combination that best fits your applications is not always easy. The Developing Resilient Apps on SAP BTP Guide provides an overview of your various options and detailed information about the particular patterns you may employ.

The majority of SAP BTP services support Availability Zones (AZ) for high availability. However, the Availability Zones (AZ) are limited to a single region, which is insufficient for mission-critical applications. This can be addressed by implementing the multi-region architecture, which can further reduce downtime, and regional latency, or simply using this architecture as a load balancer to distribute increasing traffic between regions.

This blog post primarily focuses on the application’s active-active (Distributed Resiliency) setup employing multi-region architectural concepts. Here, you will discover different patterns and services used together to reduce single points of failure and improve scalability.

Let us take a look at some of the patterns and services that are being utilized to boost resilience.

SAP Application Autoscaler service improves resilience by automatically increasing and decreasing application instances to meet the demand.

The following SAP BTP services improve operational resiliency.

SAP Continuous Integration and Delivery service assists with automated deployment, which helps to reduce the risk of human error.

SAP Cloud Transport Management Service helps to manage software deliverables between accounts of different environments.

SAP Application Logging Service enables application developers and operators to collect, store, and analyze application-related logs.

SAP Alert Notification Service automatically sends real-time notifications and alerts about events that may interest the business and operations.

SAP Automation Pilot helps to react based on the events. As an illustration, the SAP Alert Notification Service can automatically initiate predefined actions like restarting the application when an application failure alert is received from SAP Alert Notification Service.

To implement some of the resiliency patterns, we additionally use the following hyperscaler solutions.

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service that is utilized here to route traffic between regions in the event of an application failure.

Amazon Aurora is a global-scale relational database service built for the cloud with full MySQL and PostgreSQL compatibility.

SAP HANA may be the better choice in SAP CAP application projects closely related to other SAP systems (SAP S/4HANA, etc.). SAP CAP Java provides limited support for PostgreSQL, however, Amazon Aurora has a PostgreSQL compatibility engine that can be utilized to realize Read local/write global database patterns.

Solution Architecture

The conceptual solution diagram below shows an active-active (Distributed Resiliency) setup employing multi-region architecture.

SAP CAP application Distributed Resiliency using Amazon Aurora

In this setup, SAP CAP applications are spread across different regions and connected to Amazon Aurora global database cluster. The incoming requests are routed to the appropriate region using Amazon Route 53.

To optimize your application’s response time, we recommend deploying it across data centers where your target audience and back-end system are situated. For instance, consumers in Europe may select the Frankfurt and Amsterdam data centers.

Note: Be aware that there may be concerns with respect to legal data processing constraints if you wish to deploy your application in data centers that are not in the same region. For more information, see Data Protection and Privacy

High-level Implementation Steps

• SAP BTP, Cloud Foundry Runtime in two subaccounts from different regions or hyperscalers.
• A custom domain URL serves as the single point of entry to the SAP CAP Application.
• Using the SAP BTP Custom Domain service, configure and map the custom domain to SAP CAP Application routes.
• Amazon Aurora global database cluster is configured to span multiple AWS Regions.
• Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service, that monitors the application’s health and sends user requests to another region in the event of a failover.
• SAP CAP Applications are smoothly synchronized to several regions using the SAP Cloud Transport Management service.
• SAP Alert Notification Service is used for sending real-time notifications in the event of an application failure.

While implementing this architecture, consider the subscription costs for duplicate services in different regions and ensure that the applications are always in sync. It is also required to configure SSO for a seamless switch between the regions.

If you’re interested in trying this scenario out, we have a detailed step-by-step discovery center mission and blog post on dynamically switching databases based on region or read/write activity in order to reduce latency and boost availability

Related Blogposts

SAP BTP Multi-Region reference architectures for High Availability and Resiliency by Mahesh Palavalli

SAP CAP Application Dynamic Data Source Routing by Shanthakumar Krishnaswamy

Architecting solutions on SAP BTP for High Availability by Murali Shanmugham

In Closing