Embracing a Multi-Cloud Strategy with SAP BTP
By James Wood, Principal Consultant, Bowdark Consulting
The SAP Business Technology Platform (SAP BTP) has been subject to several key transformations over the years. While cynics are quick to point to marketing shenanigans with all the product name changes (“SAP BTP: Now with 63% more awesomeness…”), there has absolutely been a method to SAP’s madness: openness.
While many of SAP’s competitors continue to fight for territory in the ultra-competitive and ever-changing platform-as-a-service (PaaS) space, SAP has gone all in with its commitment to open-source projects such as Cloud Foundry and Kyma in an effort to give its customers more choice when it comes to building out a (hybrid) cloud strategy.
In this article, we’ll take a look at some different ways that SAP BTP can be used to develop a multi-cloud strategy that maximizes your existing cloud investments while simultaneously extending the reach of your SAP business systems – SAP S/4 HANA or otherwise. Here, we’ll see that SAP BTP can be used side-by-side with PaaS services provided by hyperscalers such as Microsoft (Azure), Amazon (AWS), or Google (GCP) to create many new and exciting solutions to accelerate your digital transformation journey.
Open For Business: Understanding Cloud Foundry and Kyma
Although most PaaS providers offer similar types of services, these services are mostly proprietary in nature. To put this phenomenon into perspective, consider the fairly common “functions-as-a-service” (or FaaS) service used to allow developers to build serverless functions. While capabilities are generally similar across provider offerings, functions built using the Microsoft Azure Functions, AWS Lambda, or Google Cloud Functions environments are not 100% compatible.
Among other things, the Cloud Foundry project was designed to bridge these types of gaps by defining a layer of abstraction on top of pre-existing cloud infrastructures. In some ways, you can think of Cloud Foundry as a blueprint for building a PaaS: clearly defining key PaaS components and their relationships and providing a template for deploying this PaaS on top of existing infrastructure-as-a-service (IaaS) platforms such as AWS, Microsoft Azure, or GCP.
To developers, the end result is an on-rails development experience that promotes a “bring your own language” (BYOL) approach to cloud-native development. Whether you’re building a web app using SAPUI5 or React, an API using .NET Core or Java, or a microservice using Python or Node.js, there are no proprietary hoops that you need to jump through. And, as long as developers are following best practices for cloud-native development (specifically the twelve-factor methodology described at The Twelve-Factor App), apps built on Cloud Foundry should be highly portable.
The open-source Kyma project – built on top of the SAP BTP, Kubernetes environment and comprised of a collection of projects – takes a similar approach to defining a platform for building extension apps using serverless functions and microservices. With a wealth of open connectors and a secure infrastructure for building out service meshes, Kyma unlocks many compelling integration scenarios to complement commercial iPaaS solutions such as SAP Cloud Integration (as part of the SAP Integration Suite).
SAP BTP: The Dime Tour
These days, the SAP BTP is loosely organized into runtime environments and services. In terms of runtime environments, there are three options to choose from:
- SAP BTP, Cloud Foundry environment: This environment is essentially the flagship runtime environment for SAP BTP, replacing the proprietary NEO environment. With Cloud Foundry, developers can build just about anything – from SAP Fiori apps with SAPUI5 to apps and APIs built on Node.js, Java, Python, and so forth. Basically, if there’s a standard or community buildpack for a given programming environment, then Cloud Foundry can host it.
- SAP BTP, ABAP environment: This environment is targeted at customers that wish to leverage pre-existing ABAP skillsets to create extension apps and the like on SAP BTP. Although it has ABAP in the name, it’s worth noting that the ABAP environment is fundamentally different than the on-premise ABAP environments many ABAP developers may be familiar with. In particular, many legacy language constructs/technologies (e.g., procedural programming elements, Web Dynpro, etc.) are not supported in the cloud-based ABAP environment. Instead, the focus is more on microservice development and integration.
- SAP BTP, Kyma runtime: Developers can build microservices using Kyma and its underlying technologies. Although there is some natural overlap between Cloud Foundry and Kyma, you can think of Kyma as being sort of like a serverless cousin to Cloud Foundry. This relationship is similar to the relationship between general-purpose app hosting services and serverless hosting services on hyperscaler platforms such as Microsoft Azure or AWS. For example, with Microsoft Azure, you can build apps using the general-purpose Microsoft Azure App Service or the serverless Microsoft Azure Functions environment. Similarly, with AWS there’s AWS Elastic Beanstalk for general-purpose development and AWS Lambda for serverless functions.
A plethora of backing services complement the apps developed in these environments. As SAP BTP continues to evolve, the catalog of services is ever-expanding. The list starts with common technical services such as security/identity management, managed database environments (e.g., SAP HANA), file/object storage services, caching services like Redis, job scheduling services, and so forth. From there, SAP offers additional SAP and/or business-specific services that make it easier for developers to access SAP business systems (especially on-premise systems). Collectively, these backing services provide developers with the tools they need to create enterprise-grade apps in the cloud.
SAP BTP – Now Running on Hyperscalers
Although SAP has been running parts of its cloud platform on hyperscalers for several years now, this hybrid landscape remains a territory that many customers still have not yet explored a great deal. In our experience, this is in no small part due to the fact there’s still a perception out there that you have to make a choice when it comes to PaaS adoption: either we go all-in with SAP BTP or we go with our enterprise standard hyperscaler platform (e.g., AWS, Microsoft Azure, or GCP).
However, if we zoom in a few clicks, we can see that SAP BTP’s new open architecture makes it highly complementary to its host hyperscaler platform. This concept is illustrated in the simplified diagram contained in Figure 1. In this example, we’ve depicted an SAP BTP tenant account running inside of a hyperscale platform (Microsoft Azure in this case). Although it’s not (yet) possible for customers to directly deploy SAP BTP tenants within their own hyperscaler subscriptions, they can run in the same data centers near customer data and other cloud-managed services.
Figure 1 – SAP BTP running on Microsoft Azure
The upshot of all this is that such openness enables customers to standardize around their preferred hyperscaler PaaS and then strategically leverage SAP BTP services to simplify SAP access or tap into SAP’s rich set of business-centric services. This enables customers to bring a much wider audience of developer resources to bear towards building SAP-centric apps. It also unlocks many compelling app scenarios, including (but not limited to):
- Extension Apps & Mashups: Using open APIs, developers can build web and mobile apps using whatever programming environment they deem most productive. Furthermore, they can mix and match SAP technology with other cloud or on-premise business systems to create mashup apps that create more productive app experiences. For example, imagine a mobile mashup that integrates SAP Enterprise Asset Management (EAM) with geospatial capabilities of Esri’s ArcGIS service.
- Cross-System Workflows and RPA: In this scenario, developers can take advantage of iPaaS services like Microsoft Azure Logic Apps or Amazon AppFlow to integrate SAP with a host of enterprise systems and services. These include cloud-based SaaS solutions like Salesforce, other on-premise or homegrown business systems, and even front office solutions like SharePoint and Office 365. These workflow and integration solutions can come together in a fraction of the time it would take to build similar solutions using traditional enterprise application integration (EAI) tools like SAP Process Integration, etc.
- Machine Learning Solutions: With simplified access to SAP system data and close proximity to other company data assets (e.g., data lakes), data scientists can harness the power of tools like Amazon SageMaker or Azure Machine Learning to quickly build machine learning models and create intelligent business solutions.
- Self-Service Portals: In this scenario, customers can host customer or supplier self-service portals on their preferred hyperscaler and then seamlessly integrate with SAP to fetch the real-time status of service orders, shipments, etc.
- Internet of Things (IoT): In this scenario, customers leverage best-in-class IoT services such as Azure IoT Edge to roll out complex and secure IoT landscapes and then screen/filter the millions of messages through highly scalable stream processing services. Then, where applicable, business rules could be established to send notifications to SAP implementations through BTP.
Ultimately, the goal with these exercises is to let developers and tools play to their respective strengths. PaaS selection doesn’t have to be a one-size-fits-all proposition. In today’s complex hybrid cloud landscapes, customer IT teams need to be able to consolidate resources and skills to keep pace with business demands. Realistically, hyperscaler PaaS solutions offer the most comprehensive platforms for driving these consolidation efforts. By strategically positioning SAP BTP as a complementary suite of services, SAP has made it easier for customers to align their SAP development teams with the larger development ecosystem, and this is a very good thing.
Embracing a Multi-Cloud Approach
While we hope that the multi-cloud strategy we’ve described here sounds appealing, we also recognize that such efforts are easier said than done. Depending on the makeup of your SAP Center of Excellence (CoE), the cloud world that exists outside the SAP biosphere may be an unfamiliar place. Fortunately, open-source frameworks like Cloud Foundry and Kyma offer clean integration points between apps running in SAP BTP and services provided by the host hyperscaler platform (e.g., GCP or AWS).
Accessing Hyperscaler Services from Cloud Foundry
Besides hosting applications, one of the other key responsibilities of the SAP BTP, Cloud Foundry environment is to provide app builders with a marketplace of services needed to build enterprise-grade apps. This marketplace offers a layer of abstraction between apps and their corresponding backing services (e.g., databases, storage systems, etc.).
If a developer wants to use a particular service, all they need to do is create a binding between their app and that service. Behind the scenes, a service broker component will manage the connection between the app and the service. This is all made transparent to the developer in the sense that while they will know which service they’re binding to, they don’t know (or care) where the service actually lives or how it’s provisioned.
Out of the box, the SAP BTP, Cloud Foundry environment provides developers with some common services needed to build SAP-centric apps. For example, developers can leverage the built-in Connectivity Service to facilitate secure access to on-premise SAP systems. However, developers aren’t limited to the out-of-the-box services – they can also tap into services provided by the host hyperscaler platform.
This concept is illustrated in Figure 2 with Google’s GCP environment. Here, we can see an app running on the SAP Cloud Foundry environment binding to popular GCP services such as the Vision API or Cloud SQL. Although the developer should be generally familiar with those services to consume them, they are shielded from many of the complexities of connecting to these services by hand. For developers familiar with the concept of dependency injection (DI), these service bindings should feel quite familiar.
Figure 2 – Accessing hyperscaler services in Cloud Foundry using service brokers
In addition to the services provided via the service marketplace, Cloud Foundry also allows developers to define their own user-provided services. These user-provided services can be used to define an abstract service that apps can leverage to simplify access to non-standard or external services.
To put this concept into perspective, let’s spin out our GCP scenario from above a bit further. In Figure 2, you can see where we have an SAP BTP tenant account running on GCP and leveraging a mix of SAP and Google-hosted services. However, imagine that one of the apps we’re building also needs to access a managed SQL Server database running on Microsoft Azure. Since the Azure SQL service is not provided as part of the service marketplace on GCP, we can create a user-defined service that specifies all of the connection details required for an app to connect to this instance. However, we can create a user-defined service encapsulating all the connection details needed to connect the apps to the Azure SQL service.. This is accomplished using the cf create-user-provided-service command, as shown in Figure 3. This is likely a step a company system administrator would be perform on behalf of the development team.
Figure 3 – Using the Cloud Foundry CLI to create a user-defined service
Once the user-defined service is created, developers can then bind to this service as per usual – either in the command line or in the YAML-based deployment descriptor. At runtime, the service details (i.e., the JSON included in the service definition) can be accessed via the app’s environment variables. This shields the app developers from worrying about how/where a given service is provisioned and lets developers focus squarely on solving the business problem(s) at hand.
Accessing Hyperscaler Services from Kyma
Much like the service marketplace concept with Cloud Foundry, the Kyma runtime for SAP BTP includes a Service Catalog, making it easy for developers to consume services offered by hyperscaler platforms. These services are backed by registered service brokers which provision the services and facilitates bindings from would-be consumer apps. As you might expect, service brokers are available for Microsoft Azure, AWS, and GCP. Figure 4 shows the service broker for Microsoft Azure. This service broker opens up access to a host of Azure services, including Azure SQL, Azure Redis Cache, CosmosDB, Event Hubs, IoT Hub, Key Value, Service Bus, and Azure Storage.
Figure 4 – Provisioning the Azure Service Broker to access Azure services in Kyma
Although a deep dive on how to set all this up in Kyma is beyond the scope of this article, there are a number of detailed tutorials available online at the SAP Developer Center and the Kyma Project. There, you will find that once you get past a few setup steps that it’s basically just cloud-native development as usual.
Up to this point, we’ve talked a lot about how SAP BTP supports an open, multi-cloud strategy. However, you might be wondering why these capabilities are important. Although the answer to this question could take up an entire book, I’ll summarize here by saying that such openness allows customers to tap into a much larger ecosystem of developers, tools, and services to enhance and extend the reach of their SAP business systems.
In my 20+ years of experience working with SAP customers, one constant I’ve found is that the IT backlog grows at a much faster pace than what any ABAP development team can manage. However, if we look carefully through the backlog, there are many cases where backlog items are only tangentially related to SAP. For example, creating a vendor record in SAP might help an accounting team by automatically triggering a new process flow. . Here, while getting the data out of SAP may be tricky, many developers could probably pick up and run with the process from there.
This is precisely what frameworks like Kyma were designed to do. By encapsulating access to systems like SAP, developers can solve problems using the most familiar (and productive) programming environment. In our vendor example, we might have an integration flow where the vendor message is routed to a serverless function built using Node.js. In this case, the Node developer doesn’t know or care about the origin of the vendor message. Instead, the focus is on taking a JSON payload and routing it wherever the business wants it to go. This concept also works in the other direction with inputs coming into SAP from upstream mobile or IoT integration scenarios.
In order to keep pace with the business, IT teams need to be able to get the most out of every resource they have available. While assembling and coordinating multidisciplinary teams may feel foreign for many SAP CoEs, there’s a real opportunity there for customers to tap into new resources to accelerate innovation cycles.
Now that the dust has finally settled on what we now know as SAP BTP, we’re finally able to witness the culmination of a multi-year journey towards openness. There are no more barriers or restrictions in place. SAP has provided customers with all the necessary tools; the only thing left is to use these tools to aggressively work down IT backlogs and deliver value into the hands of the business faster and cheaper than ever before.
Best-selling author and SAP Mentor alumnus James Wood is CEO of Bowdark Consulting, a management consulting firm focused on optimizing customers’ business processes using SAP, Microsoft, and cloud-based technologies. James’ 20 years in software engineering gives him a deep understanding of SAP products and technologies including ABAP, SAP NetWeaver, SAP BTP, HANA, and Fiori. Before co-founding Bowdark in 2006, James consulted on SAP NetWeaver at SAP America and IBM, where he was involved in multiple global SAP implementations.