Technical Articles
SAP Private linky swear with Azure – running Cloud Connector and SAP Private Link side-by-side
|
This post is part 8 of a series sharing service implementation experience and possible applications of SAP Private Link Service on Azure. Find the table of contents and my curated news regarding series updates here. Looking for part 9? Find the associated GitHub repos here. |
Dear community,
Continuing with the implementation journey of SAP Private Link Service (PLS) for Azure we will have a closer look at the “ins and outs” of running both SAP Business Technology Platform (BTP) connectivity options that SAP offers.
This post builds upon part 1 of the series in terms of comparing SAP Cloud Connector (SCC) with the new SAP Private Link for Azure.
Fig. 1 Combining PLS and SAP Cloud Connector gets you the best of both worlds
Looking under the hood
The SAP Cloud Connector was purpose-built for SAP BTP integration with traditional data centre or on-premises based workloads with emphasis on creating a private tunnel from within the customer’s network. That way opening problematic inbound channels on the customer firewall could be avoided. Till today it is a common pattern to connect to BTP also from cloud based Hyperscaler environments.
Since then, the SCC has evolved on the application layer with SAP specific connectivity features.
| SAP Cloud Connector (SCC) | SAP Private Link (PLS) | |
| Workload type | SAP owned Java software running on a Virtual Machine or Container, requiring OS and JVM patching and upgrades | Built upon Microsoft’s managed PaaS Azure Private Link 👍 |
| Integration Concept | Reverse Invoke Proxy (outbound Internet connection required) | Traffic travels privately via Microsoft backbone (no Internet connectivity required) 👍 |
| Service availability | Independent, can be installed anywhere including on-premises, a Raspberry PI, or any hyperscaler 👍 | Requires BTP and target workload to be run on Azure by design |
| Location on the OSI model | Software-based connectivity with Layer 7 features 👍 | Layer 4 device as interconnected with Azure Standard Load balancer |
| High Availability / Disaster Recovery | VM redundancy with master-shadow concept / Azure Backup and DR | Built-in, because PaaS. See SLA for details 👍 |
| Scalability / Sizing | Limited by JVM, SAP T-Shirt sizes recommended (VM resize requires restart) | Practically unlimited because PaaS utilizing Microsoft backbone 👍 |
| Monitoring | OS level commands for hardware metrics, or Admin UI and SCC APIs. VM monitoring on Azure | Built-in with Azure and Azure Monitor, because PaaS. 👍 |
| Bandwidth | Limited by host running SCC and network path to BTP | Practically unlimited because utilizes Microsoft backbone 👍 |
| Transport Layer Security (SSL/TLS) | SSL/TLS termination built-in, virtual + physical hostname mapping. Only virtual hostnames are used in BTP masking true names if desired with added benefit of somwhat simpler TLS setup.👍 | SAP-generated hostnames for PLS require a dedicated trust setup with BTP Trust Store and SAP Personal Security Environment (PSE) including Server Name Indication (SNI). See this dedicated post for more details. |
| Device Security | Apply SAP’s guidelines for a secure setup. Consider configuring Azure AD as Identity Provider for SCC Admin Cockpit and add your own trusted domain and cert for the SCC URL. | Built-in, managed PaaS by Microsoft 👍 |
| SAP RFC support | native👍 | Only WebSocket RFC so far. Read more on that here. |
| SAP Principal Propagation | native | supported, potential flow simplification addressed with SAP. |
| SAP app specific Audit Logging | Built-in, solves the task for all connected BTP scenarios in one place 👍 |
Requires workaround with involved components: Either SAP WebDispatcher and Azure immutable storage for example, or BTP app integration with BTP Audit Logging Service before reaching through the tunnel. |
| SAP Endpoint specific access control | Built-in support for RFC and OData path allow listing as well as restrictions for LDAP and TCP. Restrictions can be applied to pre-registered target systems too. 👍 | Requires configuration in multiple components on the integration path: SAP Web Dispatcher Access Control List (ACL), http path allow list, SAP UCON for RFC on the ERP (downside all-or-nothing approach, compared to SCC fine-grained options). See more details here. Last resort is the Azure Network Security Group to block complete port ranges for RFC for instance. |
|
Message Round Trip Time1 (RTT) (Not statistically significant! Only rough indicator) |
Average RTT: 280ms Max RTT: 902ms Min RTT: 138ms
RTT seems to have a larger spread due to less predictable routing via public Internet. I assume the lower min outlier happened due to the SSL termination at SCC and final call via http instead of https. |
Average RTT: 201ms Max RTT: 315ms Min RTT: 177ms
RTT more stable and 28% faster on average. 👍 |
| Pricing2 per month (1 GiB data transfer) | for free 🎁but secondary cost for maintenance (patching/upgrade)
🤑110.09€ |
Customer’s Azure Subscription:
Customer’s BTP Subscription:
🤑69.46€ |
1Sequence of 10 requests from BTP CF Java app in West Europe (Amsterdam) to SAP Gateway in North Europe (Dublin). Measured via java.time.Instant class. Java Heap space 1GB, VM SKU B2ms: 2CPU/8GiB memory
2 Snapshot of pricing at time of writing the blog with no claim for correctness or completeness. Assumed smallest SKUs in West Europe wherever possible. Check Azure Price Calculator and SAP Estimator for reference and recent pricing info.
3 SCC T-Shirt-Size S: 2cores, 4GB memory, Azure VM SKU D2as with 3 year reserved instance
Fig.2 Moving from public outbound to fully private access
|
Note on the side If you implement SCC and PLS side by side make sure to pay attention to the different access control capabilities and scopes. Let’s say you put an OData path allow list for “/sap/opu/odata/” in the SCC but didn’t make any adjustments on the SAP WebDispatcher path restrictions exposed via the PLS: Congratulations🥳 you just created a likely undesired gap in your access control 😜 |
Which option should I pick?
As you can see both approaches have merit in their own regard.
Sven Kohlhaas from SAP shared on the SAP on Azure YouTube channel during our joint webcast session more insights into the roadmap. We are working closely together to make sure to combine the best of both worlds and offer a “third configuration option” so to say:
Fig.3 Screenshot from roadmap shared by Sven
To mitigate the public outbound requirement (see fig.2) and profit from the SAP opinionated app layer features, it makes sense to offer the SCC functionality through the Private Link instead of via the public Internet. Compared to the existing scope of the PLS, that means the reverse integration direction is required (see fig.3 with emphasis on the initial communication flow).
Once that combined option becomes available you would be able to leverage it for scenarios like SAP Analytics Cloud using the SAC Agent, Data Warehouse Cloud (DWC) and Hana Cloud for example.
Comments from the “ground”
Customers I spoke with liked the isolation and SAP-only purpose of the Cloud Connector within their IT and networking landscape. SAP Basis and Azure IT or general IT are often strictly separate teams. Since SAP Private Link engages Azure Private Link and touches multiple components in its path, SAP Basis folks need to get in contact more with those other IT departments within the company. That often increases the governance and negotiation efforts.
Before that you could gotten away with two VM instance and a one-off conversation about your path out into the Internet. You could say the SAP Private Link for Azure brings together SAP Basis and general IT. That comes with a set of challenges for established organizational structures.
Thoughts on production readiness
SAP Private Link is generally available and therefor completely ready for prime time (quoting Gowri from the SAP engineering team 😊).
My blog series adds details to SAP’s standard docs to get you up and running smoother.
Final Words
Not too bad, huh? You saw today how SAP Cloud Connector and SAP Private Link differ in terms of scope, functionality, and service layer. Furthermore, you gained insights in the roadmap of the SAP PLS looking to combine both approaches to offer the best of both worlds.
The next part of the blog series will discuss connecting to Azure Kubernetes Service hosted apps via PLS.
Do you agree SAP @Developers and @Architects?
Find the related GitHub repos here.
Find your way back to the aggregator blog post here.
As always feel free to ask lots of follow-up questions.
Best Regards
Martin
Hi Martin,
Thanks for a great blog. Utilizing private link is a good option for lots of customers who run their SAP workloads on hyperscalers. I am particularly interested in the third option BTP->Private Link->SAP Cloud Connector->??? which offers lots of flexibility, especially for customers that are using SCC already. Do you have any update on the availability of this option? Any documentation on how to set it up? Thanks.
Rivers
Hi Rivers,
such Roadmap questions need to be directed at SAP. I collaborate with SAP engineering from the Microsoft side but SAP owns the service.
Gowri any comment from your side?
KR
Martin
What an amazing post Martin. PLS connectivity via Cloud connector with makes perfect sense when BTP has to be connected to Onprem
Cloud connector only setup makes sense when we have traffic inbound /outbound via internet.
Only PLS setup, its too cumbersome from an organisational perspective and also has outbound traffic limitations.
Do you agree with that?
Thank you,
Saurabh