Important Links |
Hello and welcome to another blog post and step-by-step tutorial on the topic of building a multitenant SaaS application on SAP BTP using CAP. Following the joined blog post series (of Alper Dedeoglu and myself) on building a multitenant SaaS application in the Cloud Foundry environment, today’s journey is all about the SAP BTP, Kyma runtime. So, buckle up, it’s going to be a great ride!
SAP BTP, Kyma Runtime & CAP – Tried and true!
Let’s dive right in and explore how to develop a multitenant SaaS application that meets essential Software as a Service requirements. While the application logic and coding remain almost unchanged from our Cloud Foundry scenario, SAP’s managed Kubernetes offering, Kyma, provides a wealth of additional flexibility options and enterprise features. Trust us, this is something you don’t want to miss, especially since you can try it for free using the SAP BTP Free Tier service plans!
We have good news for you! Anyone with access to an SAP BTP account eligible for Free Tier Service usage can join today’s journey. If you prefer a hands-on approach and would like to jump right into the action, you can click here for the source code repository and follow our step-by-step guide!
By examining the following visualization, you can gain an initial understanding of what to expect during our upcoming adventure. As you can see, the SAP BTP, Kyma runtime offers a wealth of additional features and components that are mostly operating behind the scenes in comparable Cloud Foundry scenarios. Good News – Our step-by-step guide contains a detailed section providing a resource overview, including Istio Service Mesh, Ory, API Rules and a lot more. However, as the saying goes, with great power comes great responsibility! Welcome to the world of SAP-world of Kubernetes and containerized SaaS business applications!
SaaS Sample Application – Kyma & Kubernetes Components (more details)
Cloud Foundry to Kyma
As a successor to the Neo environment, the SAP BTP, Cloud Foundry runtime has become the “top dog” for building SAP enterprise applications in the cloud. The runtime is easy to use, and many complex requirements are handled automatically under the hood. All in all, it is an undoubtedly convenient way to develop extensions and solutions in an enterprise context. So, you may ask yourself, “For heaven’s sake! SAP? Why do I need another environment again?!”
Well, that question is legitimate, and before porting our existing Cloud Foundry scenario to Kyma, we also wondered whether it is worth the effort… After having beaten the track, we can answer this question with the following advice: Give it a try! You won’t regret it! The possibilities using Kyma are (almost) endless!
From our perspective, the SAP BTP, Kyma runtime is the top-notch choice for requirements that go beyond simple UI extensions. Whether it’s due to your development team’s expertise in Kubernetes-based scenarios or your desire to use a state-of-the-art technology stack that gives you more flexibility, features, and lower-level configuration options than a managed Cloud Foundry runtime ever could. Kubernetes is just a completely different level!
If you have never worked with Kubernetes before and Helm still relates to the German translation of “helmet” for you, it may be a tough start. But once you gain speed, you won’t want to miss it anymore! Having said this, I highly suggest reading the upcoming blog post by my teammate Alper (available soon), who elaborates on our journey from Cloud Foundry to Kyma in detail, including a lot of experiences we gathered along the way.
SAP BTP, Kyma runtime
Given the overall complexity of Kubernetes, we assume that you are capable of searching for and learning the basics on your own. Our step-by-step tutorial includes a brief section with additional links and tips to help you get started on this journey. Since this SaaS scenario focuses on other aspects, let’s summarize the main point briefly.
The SAP BTP, Kyma runtime is a managed Kubernetes cluster that can be provisioned via Gardener to any supported hyperscaler of your choice, including AWS, Azure, and GCP. You can learn more about Gardener on their official website. What sets this service apart is that the Kubernetes cluster is equipped with the latest version of the open-source Kyma project, which is a true game-changer, particularly for scenarios requiring integration with other SAP BTP services, cloud solutions, or on-premises applications.
SAP BTP, Kyma Runtime – Global Availability
So, besides offering a pre-installed Istio Service Mesh and providing useful custom Kubernetes resources, Kyma’s true strength lies in the out-of-the-box SAP BTP Service Integration. Kyma offers a straightforward and convenient method of combining Kubernetes workloads with almost any SAP BTP Service! From foundational services like XSUAA or SAP HANA Cloud up to essential services required for Software as a Service scenarios like the SaaS-Registry or Service Manager.
SAP BTP, Kyma Runtime – SAP BTP Service Bindings
Integrating your Kubernetes workloads with SAP BTP Services is made easy with Kyma, using the well-established Service Bindings, similar to Cloud Foundry. The process does not require any modifications to your existing CAP application built for Cloud Foundry.
As CAP supports the SAP BTP, Kyma runtime deployment, also check out their great documentation to get an in-depth understanding, in case you’re planning to start your own project from scratch! I just say – cds add helm…!
CAP – SAP BTP, Kyma Runtime Support
So much for the introduction! Let’s see what’s in it for you as a developer or partner who’s following along with this sample scenario and our step-by-step guide. Therefore, let’s summarize the requirements of our Software as a Service sample use case once again.
Scenario and Requirements
As SAP has been doing for years, an increasing number of SAP BTP partners and customers are working on applications that can be licensed to their own consumers or reused by internal stakeholders. Consider a hypothetical SAP partner who wants to create a new multitenant SaaS application and sell it to their customers. Using our sample scenario, this partner can get an idea of how to deploy such a CAP-based multitenant SaaS application to the SAP BTP, Kyma runtime, and how to achieve integration with other SAP and third-party systems.
All in all, the sample customer has the following requirements:
- A scalable multitenant SaaS app with easy tenant on and offboarding
- Secure data isolation across consumer tenants
- A multitenant SaaS API for 3rd-party system integration
- Options to monitor and manage the SaaS API endpoints
- An in-app user management for each Consumer Tenant
- Flexible autoscaling features of the application components
- Notifications that may be of interest to the business and operations
- Frontend applications compliant with SAP Fiori Design Guidelines
- A central identity provider (IDP) managed by the SaaS Provider
In addition to these foundational requirements, the sample partner has expressed some further Expert Feature needs to SAP. These needs are similar to those addressed in our existing Cloud Foundry scenario and cover topics such as:
Develop locally or in a hybrid setup – Deploy to multiple regions – Custom Domain usage – Backup tenant containers – Extending SaaS applications – Send in-app emails – Integrate a Subscriber IdP – Automated creation of Destinations – and a lot more…
A few words for those of you who are new to the world of Kubernetes. Like Cloud Foundry, Kubernetes is not an SAP proprietary technology. However, the entry barrier is a bit higher, and the learning curve in the beginning is substantial. Therefore, if you are a novice in these topics, we highly recommend getting started with some initial tutorials on Kubernetes and Docker. A basic understanding will help you follow along our step-by-step guide. The amount of available free learning materials is endless, and we highly recommend acquainting yourself with at least some introductory material. Check out the Kyma introduction of our step-by-step guide to find further details. Another great read in this context is the following blog post written by my colleague Maximilian Streifeneder.
Having said that, let us examine the Kyma-based architecture of our SaaS sample application!
The application components
The architecture diagram of the Kyma-based SaaS sample scenario has not changed much, but looks even leaner compared to our Cloud Foundry scenario. This is due to the fact that some SAP BTP services have been replaced by native Kyma or Kubernetes features, such as the Custom Domain or Autoscaler services. To get a full picture of what is going on under the hood, please also consider the visualization at the beginning of this blog post, which provides further Kubernetes and Kyma-related component insights. Check out the respective step-by-step guide resource overview to learn more!
Furthermore, not all aspects of the Cloud Foundry setup are covered in the Kyma scenario yet, such as the usage of SAP Theme Designer, or SAP Transport Management. This is primarily related to the fact that not all SAP BTP Services can be natively consumed from within Kyma yet.
SaaS Sample Application – High-Level Architecture
While you can learn many more technical details about the various Kyma and Kubernetes resources involved in the respective step-by-step guide chapter, let’s for now stick to a brief high-level overview.
Component Overview
The following section will introduce you to our solution components and demonstrate how our Kyma-based SaaS sample application addresses the requirements of the SAP sample partner, leveraging the Cloud Application Programming model. You are welcome to explore the GitHub links provided along with the components to find more details or follow the respective step-by-step guides.
The SaaS Business Application Service is a multitenant business application developed using the SAP CAP (Cloud Application Programming Model) framework. Choosing CAP and @sap/cap-mtxs as a framework helps us to meet the partner requirements. CAP provides built-in support for schema separation with the help of SAP Service Manager. Data isolation across consumer tenants, automation of SAP HANA HDI Container creation and deletion on tenant lifecycle hooks (on and offboarding), also come out of the box. In addition to that, CAP has built-in support for SAP Fiori Elements, which is compliant with the SAP Fiori Design Guidelines. Check out the following part of our step-by-step guide to learn more.
Our Kyma-based multitenant SaaS application’s central entry point is the famous Application Router. Currently, a standalone Application Router is a must-have when developing multitenant applications on SAP BTP. Nothing changes with Kyma here. Leveraging a XSUAA Service Binding (yes – also in Kyma it is called Service Binding), the Application Router provides a built-in support for login isolation across consumer tenants. Find more details in a separate part of our step-by-step guide. The Alert Notification Service provided by SAP BTP supports the requirement to trigger notifications for administrators or operators in real-time.
The multitenant SaaS API is an important component in our Kyma-based SaaS application, as it allows for easy integration of data from SAP or third-party systems. To meet this requirement, we deploy a CAP-based backing service that can proactively push data from an SAP S/4HANA system. This backing service is simply a service that is consumed by an application. We create a separate SaaS API service instance for each tenant with unique credentials, which allows them to push business data to the multitenant SaaS solution. By using these credentials in an ABAP program on the SAP S/4HANA side, the SaaS tenants can easily integrate data from any third-party system into their applications. Learn more about the SaaS API and how to push data from SAP S/4HANA in our respective step-by-step guides.
In the Advanced Version of the tutorial, the SaaS API is enhanced with enterprise-level qualities using the API Management capabilities of SAP Integration Suite. This is another great example of how to integrate third-party systems with Kyma. With API Management, developers can choose from various policy options to add additional features to their API endpoints, such as IP whitelisting, rate limiting, regex protection, and more. Using the sample policy provided in the respective docu section of our Github repository, you will be able to allow different numbers of requests for a given time interval to your SaaS API according to the service plan chosen by the subscriber tenant. And guess what – we also included some API monitoring features! Again, further details can be found in our step-by-step guide.
In order to implement the centralized user storage requirement, the step-by-step guide shows how to configure the SAP Identity Authentication Service (IAS) as the primary identity provider for the multitenant SaaS application. This allows the application to manage its consumers without relying on the default SAP ID service, and also provides flexibility to adapt the login flow and user interfaces according to the SaaS provider’s requirements. Given that SAP IAS satisfies all these needs, you will learn in our step-by-step guide, how to configure a central SAP IAS instance, as the primary identity provider for your multitenant SaaS application. The details are explained in another extensive chapter of our step-by-step guide.
To finish this up, the expert requirements addressed in this SaaS sample application cover chapters on local and hybrid development, considerations on multi region deployment, the setup of a Custom Domain as well as guidance on how to manage and backup the HDI database containers of your SaaS tenants. Same applies for the introduction of data model updates, consumer extensibility features and feature toggles, as well as how to send emails from within your application. These aspects are similar to those in Cloud Foundry, and the step-by-step guide provides detailed instructions on how to achieve these requirements in Kyma. All these topics are covered in various chapters of our Expert Features step-by-step guides.
As a picture is worth a thousand words, check out the following screenshots, giving you a brief impression of our Sustainable SaaS application, as well as some of the essential components covered in this sample scenario.
Sustainable SaaS (SusaaS) Sample Application
Kyma specifics
While the application coding itself is almost similar, a major difference between the Cloud Foundry and SAP BTP, Kyma runtime is the deployment process. A dedicated part of the step-by-step guide will elaborate on this in greater detail. The focus is on so called Helm Charts, which are extensively used for an automated deployment of our SaaS sample scenario. New to Helm? Then start by checking out our great Helm introduction – another great part of our step-by-step guide.
Additionally, Kyma requires the usage of a few more essential components acting under the hood like Horizontal Pod Autoscalers and Istio Service Mesh resources required for a Custom Domain, proper Routing and reliable Network Security. As said in the beginning – more power brings more responsibility. These components are combined with further custom resources like API Rules and a proper role and authorization setup using objects like Service Accounts and Role Bindings. As already mentioned in the beginning of this blog post, you can find way more details in the following section of our step-by-step guide.
As mentioned, in Cloud Foundry, the platform takes care of most of the technical components such as network security, routing, and autoscaling. However, in Kyma, you have more flexibility to manage these components yourself, but it also requires additional maintenance effort. Still, there’s no need to worry – we will get you covered! The major components are explained in our comprehensive step-by-step documentation, and we provide guidance on how to manage and deploy them
Summary
For detailed information and an extensive step-by-step guide on how to set up the SaaS sample application in your own SAP BTP, Kyma instance, please refer to our SAP-samples GitHub repository.
To gain an even deeper understanding of the architecture and all the components involved, we highly recommend deploying the SaaS sample app to your own SAP BTP account and experimenting on your own. You can follow the steps described in the related GitHub repository’s step-by-step guide to get started.
Alper Dedeoglu and myself are looking forward to hearing your thoughts and feedback!
