Using SAP Application Router with Kyma runtime

[gabbi]

SAP BTP, Kyma runtime is used to develop applications and extensions.

This also brings in the following requirements:

• Serve static content


• Authenticate and authorize users


• Forward to the appropriate identity provider for login


• Rewrite URLs


• Dispatch requests to other microservices while propagating user information

All these and more capabilities are provided by SAP Application Router.

There are two options to use the Application Router capabilities in SAP BTP, Kyma runtime.

• Managed Application Router


• Standalone Application Router deployed on Kyma runtime.

Both options can be used by the customers, and they can choose either one of them depending on their requirements, business use-cases, and TCO.

 

Managed Application Router

With this option, the Application Router as a component is operated and maintained by SAP. It is part of the HTML5 applications runtime capability provided by one of the following services:

• SAP Work Zone


• SAP Launchpad Service


• SAP Cloud Portal

In the context of Kyma runtime, you can, for example, deploy your HTML5 applications in the HTML App Repository, and configure the site with the Launchpad service. Then, the microservices running on Kyma runtime are accessed using the Destination Service. See the following example scenario with such a setup:

Advantages of this setup:

• No software maintenance for Application Router components


• Seamless integration into cFLP. There is a single session provided and managed by the Application Router.


• High availability and external session management provided out of the box

Disadvantages of this setup:

• To integrate or forward requests to backing microservices running on Kyma runtime, they must be exposed with API Rules. That’s because managed Application Router is not running inside the Kyma runtime.


• The Application Router capabilities cannot be extended. Thus, for example, injecting a custom middleware won't be possible.

 

Standalone Application Router

In this setup, you deploy a dockerized version of the Application Router npm package on the Kyma runtime.

See the following example setup:

Advantages of this setup:

• Freedom to extend the Application Router with any custom processing as required


• Control over the version of the Application Router


• Only the Application Router is exposed with an API Rule. All backing microservices are running inside Kyma runtime, and the Application Router dispatches and forwards the request to them.

Disadvantages of this setup:

• An additional software component must be maintained and operated


• To achieve high availability and zero downtime, you must maintain multiple replicas and externally store the session. That way, the session is not lost when a Pod restarts. For external storage, you can, for example, use Redis as session storage. SAP BTP, Hyperscaler Redis is not yet consumable from Kyma runtime (on Roadmap for Q1 2022). As current alternatives, you can either use a hyperscaler Redis or run a Redis server within Kyma runtime.


• No integration in cFLP (Portal service is not supported in Kyma runtime)

In summary, both approaches are applicable and have their relevance depending upon the requirements and use cases to be implemented.