on 12-10-2020 9:48 AM
Hello,
I have a question about the XS() architecture in the HANA cloud. If I understood this correctly, HANA Cloud uses the XSA engine as an application server which is provided by Cloud Foundry. In comparison, HANA 2 uses XSA not as a integrated Cloud Foundry solution but to access the HANA DB On-premise. For a better understanding I have created the following architectural approach. Can anyone confirm the correctness of this ?
I am also grateful for further information about HANA Cloud (XSA) and related architectural approaches.
Best regards
Hi Torben,
Regarding your illustration, the runtime for most applications on SAP Cloud Platform is Cloud Foundry (as Kubernetes/Gardener managed containers). SAP HANA Cloud, SAP Analytics Cloud, and even the ABAP environment (Steampunk) run as containers on Cloud Foundry.
If it helps, you can view Cloud Foundry as an application server [*] "distribution" just like there are Linux distribs. You can run open-source CF on a VM (DIY) or license CF commercially as PaaS (Pivotal / VMWare Tanzu) hosted by AWS, Azure, GCP, or customized (IBM Cloud, SAP Cloud Platform) with several public/private options.
[*] CF is a lot more than an application server but in essence it is a polyglot runtime for apps and services.
XSA is CF integrated with the SAP HANA platform but very similar in nature to the CF Runtime on the SAP Cloud Platform.
SAP HANA Cloud is the first edition of the SAP without a built-in application server: no XS, no XSA:
Here are some blog post that explains this in more detail.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Denys, thanks for your answer. If I understand you correctly, this means that the Cloud Foundry development environment already includes an "XSA" application server, making it redundant in HANA Cloud. Is the application server used by Cloud FOundry also called XSA, or XSUAA ?
Hi Torben,
Correct; XSA = CF (almost, see the field guide).
Cloud Foundry hosts virtual machines called cells which run the containers. The container image is called a droplet and the component orchestrating the droplets is called Diego (originally in Ruby as Droplet Execution Agent (DEA) later architected to Go (DEA+Go); the xsexecagent process on the SAP HANA platform. The container provides the application runtime (i.e. "application server") with support for many languages (polyglot).
UAA (user account and authentication) provides both authentication and authorisation. Authentication is delegate to an IdP on the SAP Cloud Platform (SAP ID service) and to the database on the SAP HANA platform. To support the latter the UAA was "extended": Extended Services for UAA, XSUAA.
See Cloud Foundry, UAA, and XSUAA | Migrating from the Neo Environment to the Multi-Cloud Foundation | https://blogs.sap.com/2020/09/01/securing-applications-in-a-multicloud-environment/
User | Count |
---|---|
85 | |
10 | |
10 | |
9 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.