Self-Onboarding Terraform Automation - Architecture
Important LinksGeneral
SAP BTP, Kyma Runtime scenario SAP BTP, Cloud Foundry Runtime scenario |
Hello everyone! 👋
Today, we're diving back into the world of Terraform, and I just can't contain my excitement! 😄 As you know, I'm all about developing Multitenant SaaS applications on the SAP Business Technology Platform, and I've been on this thrilling journey for a while now with my good friend and colleague, alperdedeoglu.
So, what's the buzz this time? 🤔 Well, we're here to introduce you to another fantastic Terraform infrastructure automation scenario that's going to make SaaS Self-Onboarding in Kyma and Cloud Foundry a breeze! 🚀 Again, all we present you here can be set up for free using SAP BTP Free service plans!
Self-Onboarding Automation using Terraform in Kyma and Cloud Foundry
A few months back, we rolled out a Self-Onboarding solution using the SAP BTP Setup Automator. It worked like a charm, but now, with the Terraform Provider for SAP BTP, we're taking things to a whole new level relying on the latest innovation by SAP! 🌟
Let's check out what we have in mind this time by having a brief look at the architecture diagram.
Let's start with a little introduction! 🌟
I must admit, at first glance, this might seem a tad complex. But fear not! Once we break down the architecture and sprinkle in a few insights, you'll see the incredible possibilities it unlocks for your SAP BTP solutions. And guess what? It's not just limited to the SaaS realm. 🚀
So, what's the scoop here? As a Software-as-a-Service provider, I'm constantly fielding interest in my solution, which means I have to onboard new customers. In SAP BTP, that translates to setting up new Subaccounts, creating Subscriptions, configuring Trusts, and ideally, onboarding the first Admin User for each new customer. Phew, that's a lot of manual work, especially when dealing with scenarios like trials or free offerings where folks can join or leave at will.
Now, here's the big question: Can't we simplify this process? Especially when we've got this nifty new thing called the Terraform Provider for SAP BTP at our disposal? As a SaaS provider, my dream is to steer clear of repetitive tasks like setting up Subscriber Subaccounts, especially in trial scenarios. I'd much rather focus on dazzling my users with new features and improvements! 🌈
Well, guess what? Good news is on the horizon! There are plenty of ways to automate this setup, whether through GitHub Actions or other Automation Tools. But here, we're diving into a 100% SAP BTP-based approach that works seamlessly in any environment, be it Kyma or Cloud Foundry. 🤖 Exciting stuff, right? Let's roll up our sleeves and explore the magic! ✨
Let's cut to the chase, shall we? 💥
The heart of this scenario beats to the rhythm of two key players: the Cloud Application Programming Model (CAP) and the trusty Application Router. These dynamic duo support user authentication through the SAP Identity Authentication Service (IAS) - (CAP, Application Router). Thanks to SAP IAS's self-registration feature, we're giving users the green light to sign up and unlock access to a user-friendly Self-Onboarding interface. 🌟
But how do we make this all happen? Well, it's all about that unique User ID nestled snugly within the JWT token handed over by SAP IAS. With that golden ticket in hand, we kickstart a Subaccount Setup process through Terraform. Picture this: it's like a well-oiled machine running within a Docker Container, either as part of a Cloud Foundry Task or a Kyma Job. Oh, and we've got a custom Container Image on our side, armed with all the tools we need, including the SAP BTP CLI. If you've never dabbled in Docker/Container Images, don't sweat it – it's not rocket science, I promise! 🚀
Now, here's where Terraform takes the reins. It takes charge of what we like to call the state of each self-onboarded subaccount. Where does it store this precious information? In a PostgreSQL database, leveraging the respective SAP BTP Service Offering. This isn't just about the here and now; it sets us up for potential upgrades or a smooth infrastructure teardown down the road. 🛠️
Hold on, we're not done yet! Our trusty Multitenant SaaS application's SaaS-Registry service instance has a crucial role to play. It's the gatekeeper, making sure a user doesn't end up with redundant subscriptions. By using a hashing approach in our backend, we consistently derive the self-onboarded subaccount name and subdomain from the User ID of the self-registered user. The SaaS-Registry APIs will inform us about any existing subscriptions for the respective subdomain 🤓 Stay with me; there's more to explore! 💪
Curious for a closer look? 👀
Let's dive into the nitty-gritty and peek under the hood to see what's cooking! 🚗🔧 First up, we've got self-registration. No big surprises here – it's all about that SAP IAS standard functionality. 🧩
 SAP IAS self registration |  Customizable user details |  Mandatory e-mail confirmation |
What's next? Another old old hat - Logging in to a CAP-based application through an Application Router tied to the same SAP IAS instance used for self-registration 🚀 combined with a snazzy SAPUI5 Freestyle app, displaying available subscriptions and featuring a couple of buttons to start an Onboarding process. Nothing too complex, I promise! 🎉
 SaaS Home-Page |  SAP IAS based login |  Self-On/Offboarding Screen |
Okay, but now 🤔, what happens when a Self-Registered customer (interested in trying your SaaS solution) clicks on Trigger Onboarding? Well, it is also fairly simple. A Docker Container is spinned up as a 🌐 Cloud Foundry Taskor a 🚢 Kyma/Kubernetes Job, setting up a new Subaccount with all the necessary Subscriptions, Trust configurations, and User-Role Assignments. 🛠️
 Job triggered in Kyma |  Terraform Container running in Kyma Job |  Terraform Container running in Cloud Foundry Task |
Exploring Cloud Foundry's Docker Container capabilities, we can perform similar tasks in both Kyma and Cloud Foundry, without the need for GitHub Actions or other automation platforms. Instead, we can leverage our existing runtime. Terraform handles the setup of all the essential components and subscriptions, making it seem routine. 🌐🔧
But, there's a noteworthy twist - we can also utilize the SAP BTP CLI in our automation scenario. How? By integrating it into our custom Docker Image, built upon the official Terraform Docker Image. This takes us beyond the features offered by the Terraform Provider for SAP BTP. Theoretically, you can easily install any required tool as part of your Onboarding Automation within the Container Image and put it to work! 🪄🛠️
The Trust Configuration settings you see below, for instance, were configured using the SAP BTP CLI since, as of today, they aren't supported by Terraform. 🚀🔐
 New Self-Onboarded Subaccount |  Subscription and |  Trust configuration Setup |
So, here we are – the account setup is complete, and the user initiating Self-Onboarding has been granted the Administrator Role to kickstart their journey with the SaaS application! Similarly, upon the successful validation of the SaaS solution offering, the Subaccount can be effortlessly off-boarded once more!
Terraform will seamlessly connect to our PostgreSQL backend, retrieve the most up-to-date state of the corresponding SaaS tenant, and swiftly dismantle the Subaccount within minutes. 🚀🔒🌐
 Users and Roles assigned automatically |  Tenant access through On-/Offboarding UI |  Self-Offboarding handled by Terraform |
Sneak peak of what's stored in the PostgreSQL database? Well in this scenario, we create a separate schema for each of our Self-Onboarded Tenants, holding the infrastructure details of the respective subaccount.
PostgreSQL database handling the Terraform states
Eager to try this yourself?👨💻
If you've already taken the bold step of deploying the Sustainable SaaS sample application in your Kyma or Cloud Foundry environment and are now up to testing this Self-Onboarding concept? 🌟 Your adventurous spirit is truly commendable. You can dive right into our detailed step-by-step guide, which we've thoughtfully included as part of our Expert Features. 📚👨💻 Enjoy the journey!
Self-Onboarding Automation using Terraform in Kyma and Cloud Foundry
The expert scope is your treasure trove of essential code components and Terraform objects, all set and ready to kickstart your own journey. Simply follow our comprehensive guide for Kyma and Cloud Foundry, and you'll be on your way. Start today, and don't forget to share your experience with us! 🚀🌟 We can't wait to hear about your journey!
Ready for a summary?
In this blog post, we explored an innovative approach to streamline SAP Business Technology Platform automation processes, especially for Software-as-a-Service (SaaS) scenarios. Whether you're a SaaS provider or not, a 100% SAP BTP-based automation solution, driven by the Terraform Provider for SAP BTP, is available to simplify and automate infrastructure operations. 🤖🔧
We discussed the challenges of manual processes involved in setting up Subaccounts, creating Subscriptions, configuring Trusts, and onboarding Administrative Users for new customers. These complexities are even more pronounced in scenarios like trial or free offerings, where user numbers can fluctuate. 📈🤯
Our approach eliminates these complexities, allowing you to focus on improving user experiences and delivering new features. We appreciate your interest in this integration with Kyma and Cloud Foundry environments, which offers automation opportunities beyond traditional methods. 🚀🌐
We invite you to try the sample scenario by setting up the Sustainable SaaS application in your SAP BTP environment and experiencing the simplicity of Self-Onboarding Automation with Terraform. Please share your feedback on the usefulness of this blog post and suggest future SaaS-related topics for us to explore. Your input is highly valued! 💡📝
Special thanks to the passionate Terraform folks around rui.nogueira, lechner and v0lkc who are constantly improving the Terraform Provider for SAP BTP!
PS: Yes I love emojis 😍 and AI makes it so easy to add them to your texts 😂
- SAP Managed Tags:
