It is a common scenario that cloud applications need to connect to remote systems to fulfil the business goals of their creators and those of their end users. This is essential for enterprise applications, which are generally complex and consume data from and/or push data to a variety of sources or destinations – systems that are directly accessible, systems hosted in public or private cloud, or such that are hosted in the customer premises. This use case is called hybrid connectivity.
Sounds complex, right?! With this blog post, I show you that it has never been easier to solve this problem. Let’s get started and see how SAP BTP Connectivity can help with this challenge, more specifically, in SAP BTP Kyma environment.
Well, complex things cannot be made simple without proper preparation work. Therefore, I need to setup the environment. For the purposes of this blog post, I don’t get into details on how each step is done, if interested, you can follow the links:
Image: Scenario Schematic Overview
This solution diagram depicts the high-level architecture and layout of the SAP BTP tools, software components, services listed above in the Prerequisites section. The focus on the scenario is on the Application side. The rest is depicted for completeness and better end-to-end understanding.
In this blog, I showcase how I can connect my cloud application to the following target systems. I start with the trivial and then continue with the more advanced use cases:
I pick those systems to showcase what I claimed in the begging of this blog - It has never been easier!
Note: For the creation of the destination pointing to XSUAA in step 4 of the scenario, I followed these two simple steps in BTP cockpit:
To get the scenario in action, at first I need to configure the target systems as technical connection configurations, a.k.a. destinations. In this way I control to which systems the application has access to and can switch the used technical authentication and authorisation mechanisms on the fly – changing the destination attributes without affecting the experience of the end user, and without affecting the lifecycle of the application.
For the destinations pointing to systems hosted in the customer premises (points 5 and 6 of the scenario overview), I need to securely expose those to the cloud.
You guessed it, for this I configure the respective Access Controls in my SAP Cloud Connector:
Image: Access Control entries in Cloud Connector
In this example, the two systems hosted in the on-premises are simple HTTP and HTTPS servers:
One of the best practices for cloud-native applications is to externalise any configuration and avoid coupling it with the lifecycle of the application, e.g. via hard-coding it. I use Destination service for managing the technical connection configurations (a.k.a. destinations), as guided by the Golden Path defined in Cloud Application Programming model of SAP BTP.
In the context of my SAP BTP subaccount, I create the following destinations, pointing to the variety of systems I’ll connect my cloud app workload running in my Kyma instance.
Image: Destinations in BTP cockpit
To allow an application to consume the defined destinations, I declaratively expose only those I'm interested in, and are specific for this particular use case. For this, I create specific Destination Custom Resources, a common practice for cloud-native applications based on Kubernetes. In Kyma environment, I can do this either via Kyma Dashboard, or via command-line using Kubectl.
Image: Creation of a Destination CR in Kyma Dashboard
Shortly after the Destination CR is created, Transparent Proxy process it and updates the status of the Destination CR with a message that the technical connectivity is successfully configured, and this destination is ready to be consumed.
Image: Status of a Destination CR in Kyma Dashboard
Using the same approach, I expose all the destinations required specifically for this use case.
Image: Destination CRs in Kyma Dashboard
It's all set now, let's play with the application.
As described in the status message of the Destination CR, the Transparent Proxy exposed the referenced destination via the specified name in the form of locally accessible host, leveraging the concept of Kubernetes Service.
As a result, it’s trivial for the application to connect to those local hosts, and this is the only task needed to be performed. It’s that easy!
For simplicity and versatility reasons, my application is represented by a local terminal attached to a container running in a Kubernetes Pod in the Kyma Instance. Then I use cURL command-line tool for executing HTTP requests towards the target systems.
How it’s done? Once connected to the Kyma instance via Kubectl, I run a sample cURL image as a Kuberenetes Pod and open a terminal session via the following command:
This is a trivial direct invocation of the public web page of Google:
This is an example reaching the same public web page of Google, but this time via destination, locally exposed and served by Transparent Proxy, and centrally managed via Destination service:
This is an example of reaching the same public web page of Google via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The destination is configured to point to an on-premises system, exposed to the cloud via Cloud Connector:
This is an example for getting the registered service instances of the current subaccount via destination, locally exposed and served by Transparent Proxy, and centrally managed via Destination service.
This is an example of connecting to a simple on-premises HTTP server via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The destination is configured to point to an on-premises system, exposed to the cloud via Cloud Connector:
This is an example of connecting to an on-premises HTTPS server via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The HTTPS server requires the cloud user identity to be propagated. The destination is configured with PrincipalPropagation as authentication type, and to point to an on-premises system, exposed to the cloud via Cloud Connector:
As you can see, it’s that simple! No matter of the type and hosting location of the target system, from the application development perspective the user experience is the same – simple, unified, virtually transparent, and the technical complexity is handled by the usage of software components and services part of SAP BTP Connectivity product portfolio:
Тhis simple yet powerful approach enables application developers to focus more on their business goals and delegate the technical complexity to SAP BTP Connectivity, and at the same time the application administrators can manage the outbound technical connections (via destinations) without affecting the lifecycle and availability of the application itself.
Stay tuned and subscribe to What's New for SAP BTP Connectivity page.
Sounds complex, right?! With this blog post, I show you that it has never been easier to solve this problem. Let’s get started and see how SAP BTP Connectivity can help with this challenge, more specifically, in SAP BTP Kyma environment.
Prerequisites
Well, complex things cannot be made simple without proper preparation work. Therefore, I need to setup the environment. For the purposes of this blog post, I don’t get into details on how each step is done, if interested, you can follow the links:
- Setup the cloud environment:
- Create a SAP BTP subaccount - the PaaS context in the domain of SAP BTP, i.e., an account enabled to instantiate cloud application development environments, create and manage service instances, etc.
- Enable Kyma environment - the cloud-native application hosting environment
- Enable Connectivity Proxy for cloud to premise technical connectivity, an integrated component in Kyma environment
- Enable Transparent Proxy for unified, virtually transparent technical connectivity to any destination or data source, an integrated module in Kyma environment
- Setup the local environment
- Install Kubectl - the command line interface for connecting to and interacting with the Kyma instance
- Install Cloud Connector for controlled and secure exposure concrete systems or resources, hosted in a VPC on Hyperscalers or on-premises - in my case, on my PC.
- For each scenario use case, create the relevant destinations in SAP Destination service using SAP BTP cockpit.
Overview of the scenario
Image: Scenario Schematic Overview
This solution diagram depicts the high-level architecture and layout of the SAP BTP tools, software components, services listed above in the Prerequisites section. The focus on the scenario is on the Application side. The rest is depicted for completeness and better end-to-end understanding.
In this blog, I showcase how I can connect my cloud application to the following target systems. I start with the trivial and then continue with the more advanced use cases:
- Google - direct connectivity without using any of the SAP BTP Connectivity software and services
- Google via destination - direct connectivity with usage of SAP BTP Connectivity software and services
- Google via destination and Cloud Connector - indirect cloud to premise connectivity - in my setup Google is directly accessible via my local Cloud Connector
- Note: this use case is presented only for the purpose of showcase and ease the perception of the reader, it is not expected to be done in production
- SAP Authorization and Trust Management Service (XSUAA) via destination - OAuth based REST API
- An HTTP system hosted on-premises via destination and Cloud Connector - indirect cloud to premise connectivity
- An HTTPS system hosted on-premises via destination and Cloud Connector - indirect cloud to premise connectivity with Principal Propagation enabled, i.e., end-to-end secure user context propagation, a.k.a Single Sign On (SSO).
I pick those systems to showcase what I claimed in the begging of this blog - It has never been easier!
Note: For the creation of the destination pointing to XSUAA in step 4 of the scenario, I followed these two simple steps in BTP cockpit:
- Create a service instance of service "xsuaa", plan "apiaccess"
- Create a destination pointing to the service instance via destinations UI - just a few clicks job!
Configure the scenario
To get the scenario in action, at first I need to configure the target systems as technical connection configurations, a.k.a. destinations. In this way I control to which systems the application has access to and can switch the used technical authentication and authorisation mechanisms on the fly – changing the destination attributes without affecting the experience of the end user, and without affecting the lifecycle of the application.
Expose the on-premises system to the cloud
For the destinations pointing to systems hosted in the customer premises (points 5 and 6 of the scenario overview), I need to securely expose those to the cloud.
You guessed it, for this I configure the respective Access Controls in my SAP Cloud Connector:
Image: Access Control entries in Cloud Connector
In this example, the two systems hosted in the on-premises are simple HTTP and HTTPS servers:
- System #1: localhost:8000 - serves HTTP, returns status code: 200 with the received HTTP request line as a message.
- System #2: localhost:9000 - serves HTTPS, returns status code: 200 with the received HTTP request line as a message, and the subject common name (CN) of the received X.509 client certificate as part of the HTTP request - the user context propagated from the cloud, achieving Single Sign-On (SSO).
Manage the technical connection configurations
One of the best practices for cloud-native applications is to externalise any configuration and avoid coupling it with the lifecycle of the application, e.g. via hard-coding it. I use Destination service for managing the technical connection configurations (a.k.a. destinations), as guided by the Golden Path defined in Cloud Application Programming model of SAP BTP.
In the context of my SAP BTP subaccount, I create the following destinations, pointing to the variety of systems I’ll connect my cloud app workload running in my Kyma instance.
Image: Destinations in BTP cockpit
Expose the destinations in the Kyma instance
To allow an application to consume the defined destinations, I declaratively expose only those I'm interested in, and are specific for this particular use case. For this, I create specific Destination Custom Resources, a common practice for cloud-native applications based on Kubernetes. In Kyma environment, I can do this either via Kyma Dashboard, or via command-line using Kubectl.
Image: Creation of a Destination CR in Kyma Dashboard
Shortly after the Destination CR is created, Transparent Proxy process it and updates the status of the Destination CR with a message that the technical connectivity is successfully configured, and this destination is ready to be consumed.
Image: Status of a Destination CR in Kyma Dashboard
Using the same approach, I expose all the destinations required specifically for this use case.
Image: Destination CRs in Kyma Dashboard
It's all set now, let's play with the application.
Scenario in action: Connect the application to the remote systems
As described in the status message of the Destination CR, the Transparent Proxy exposed the referenced destination via the specified name in the form of locally accessible host, leveraging the concept of Kubernetes Service.
As a result, it’s trivial for the application to connect to those local hosts, and this is the only task needed to be performed. It’s that easy!
For simplicity and versatility reasons, my application is represented by a local terminal attached to a container running in a Kubernetes Pod in the Kyma Instance. Then I use cURL command-line tool for executing HTTP requests towards the target systems.
How it’s done? Once connected to the Kyma instance via Kubectl, I run a sample cURL image as a Kuberenetes Pod and open a terminal session via the following command:
kubectl run mycurlpod -n sap-transp-proxy-system --image=curlimages/curl -i --tty -- shExecuting request to Google:
This is a trivial direct invocation of the public web page of Google:
~ $ curl www.google.com -v
* Trying 142.250.179.164:80...
* Connected to www.google.com (142.250.179.164) port 80
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 200 OK
...
<
<!doctype html><html...<title>Google</title><script...Executing request to Google via destination:
This is an example reaching the same public web page of Google, but this time via destination, locally exposed and served by Transparent Proxy, and centrally managed via Destination service:
~ $ curl google -v
* Trying 10.111.255.220:80...
* Connected to google (10.111.255.220) port 80
> GET / HTTP/1.1
> Host: google
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 200 OK
...
<
<!doctype html><html...<title>Google</title><script...Executing request to Google via destination via Cloud Connector:
This is an example of reaching the same public web page of Google via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The destination is configured to point to an on-premises system, exposed to the cloud via Cloud Connector:
~ $ curl mypremisegoogle -v
* Trying 10.111.159.5:80...
* Connected to mypremisegoogle (10.111.159.5) port 80
> GET / HTTP/1.1
> Host: mypremisegoogle
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 200 OK
...
<
<!doctype html><html...<title>Google</title><script...Executing request to XSUAA API via destination:
This is an example for getting the registered service instances of the current subaccount via destination, locally exposed and served by Transparent Proxy, and centrally managed via Destination service.
~ $ curl xsuaa-api/sap/rest/authorization/v2/apps -v
* Trying 10.106.192.162:80...
* Connected to xsuaa-api (10.106.192.162) port 80
> GET /sap/rest/authorization/v2/apps HTTP/1.1
> Host: xsuaa-api
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 200 OK
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< content-length: 10621
...
<
[{"appid":"app123!b13","serviceinstanceid":"15442f82-7d82-11ee-b26d-ab53f17d39a5","planId":"HWEgt9/213f90b0+/7d82-11ee=","planName":"broker"...Executing request to an on-premises HTTP server via destination via Cloud Connector:
This is an example of connecting to a simple on-premises HTTP server via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The destination is configured to point to an on-premises system, exposed to the cloud via Cloud Connector:
~ $ curl mypremserver/test-path -v
* Trying 10.110.23.19:80...
* Connected to mypremserver (10.110.23.19) port 80
> GET /test-path HTTP/1.1
> Host: mypremserver
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 200 OK
...
<
Response generated by HTTP server:
GET /test-path HTTP/1.1
Executing request to an on-premises HTTPS server via destination via Cloud Connector with Single Sign-On enabled:
This is an example of connecting to an on-premises HTTPS server via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The HTTPS server requires the cloud user identity to be propagated. The destination is configured with PrincipalPropagation as authentication type, and to point to an on-premises system, exposed to the cloud via Cloud Connector:
~ $ curl myppserver -H 'Authorization: Bearer eyJhbGciOiJSUzI1Ni...bwKMpAGKbhECqvkyibC7Q' -v
* Trying 10.105.101.106:80...
* Connected to myppserver (10.105.101.106) port 80
> GET / HTTP/1.1
> Host: myppserver
> User-Agent: curl/8.4.0
> Accept: */*
> Authorization: Bearer yJhbGciOiJSUzI1Ni...bwKMpAGKbhECqvkyibC7Q
>
< HTTP/1.1 200 OK
< server: envoy
< date: Tue, 07 Nov 2023 15:17:47 GMT
< content-type: text/plain; charset=utf-8
< content-length: 1956
< x-envoy-upstream-service-time: 657
<
>>>>>>>>>
Response generated by HTTPS server:
GET / HTTP/1.1
=========
Received X.509 client certificate with Subject: <Name(CN=manol.valchev@sap.com)>Summary
As you can see, it’s that simple! No matter of the type and hosting location of the target system, from the application development perspective the user experience is the same – simple, unified, virtually transparent, and the technical complexity is handled by the usage of software components and services part of SAP BTP Connectivity product portfolio:
- Destination service for managing the technical connection configurations (a.k.a. destinations)
- Transparent Proxy for unified, virtually transparent technical connectivity to any destination or data source, an integrated module in Kyma environment, also available in Docker Hub.
- Connectivity Proxy for cloud to premise technical connectivity, an integrated component in Kyma environment, also available in Docker Hub.
- Cloud Connector for controlled and secure exposure concrete systems or resources, hosted in a VPC on Hyperscalers or on-premises.
- Connectivity service as the backbone for the multitude of Connectivity Proxy and Cloud Connector instances serving thousands of SAP BTP customers
Тhis simple yet powerful approach enables application developers to focus more on their business goals and delegate the technical complexity to SAP BTP Connectivity, and at the same time the application administrators can manage the outbound technical connections (via destinations) without affecting the lifecycle and availability of the application itself.
Stay tuned and subscribe to What's New for SAP BTP Connectivity page.
- SAP Managed Tags:
14 Comments
