The Terraform provider for SAP BTP has caught quite some attention since its first announcement and was also called out at the last SAP TechEd. This also manifested itself in several blog posts from the SAP community:
Automating SAP BTP setup with the new Terraform provider for SAP BTP by mauriciolauffer
SAP BTP Entitlements Management with Terraform Module: sap-btp-entitlements by aydin.ozcan
Using the Terraform Provider for SAP BTP to simplify Subscriber Tenant Onboarding by martinfrick
Gitops with Argo CD & Kyma, Terraforming SAP BTP Kyma Clusters by maxi1555_2022
Quick account setup with SAP Discovery Center and Terraform by rui.nogueira
These blog posts show that Terraform provides value for companies of any size to provision and manage your infrastructure. Its strength originates from the multi-provider approach. You can combine several providers to fit your requirements and. One prominent example would be the combination of cloud assets with Microsoft Entra ID (the thing formerly known as Azure Active Directory). Even if you are using one single provider only, you should evaluate the advantages of the management and especially the governance of the infrastructure setup via Infrastructure as Code (IaC).
While currently still in beta these are already some cool use cases. Waiting for GA? You should keep an eye on the GitHub repository, especially on the milestones and releases to not miss any important news.
With that said I would also state that while the Terraform provider itself is already a great (and let us be honest overdue) addition that helps the community in provisioning and managing the cloud assets on SAP BTP there is so much more to explore around it. And this blog post hopefully gives you some ideas what this contribution could enable.
What’s up Terraform?
The basic question is: “Does the journey around Infrastructure as Code (IaC) stop at Terraform per se?”
I am convinced that the answer is “No”. The Terraform provider opens a lot more options around the topic of Infrastructure as Code and beyond.
Before we start exploring this some words of warning since there is this little SAP icon attached to my name: be aware that the following statements are from the point of view of me as a contributor to the Terraform provider for SAP BTP and do not represent an official statements of SAP which should be clear as this is a blog post and not a press release 😉, but … well now you cannot say you did not know that.
This Isn’t Flying. This Is Falling With Style!
Although Terraform is the de-facto industry standard it is not the only offering to make IaC happen. Does the Terraform maybe even enable other options?
Pulumi
Maybe Terraform isn’t your preferred way of dealing with Infrastructure as Code and you are more into the approach Pulumi is taking. While Terraform is based on its own configuration language, Pulumi gives the “as Code” part a bit of a different spin by allowing you to describe your infrastructure in the most common programming languages like TypeScript, Python, Java or C#. 🤯
There is no SAP BTP provider for Pulumi but there is an option to create one from a Terraform provider by a so-called bridge implementation. I tried that out and although the process is not super-smooth I could get things running and spin up a very simple scenario in TypeScript as you can see here doing the setup of a directory via Typescript (yes, it is a VERY simple scenario):
The output after running pulumi up:
And the result in SAP BTP:
I really like that approach and if you want to play around with that, here is the repository https://github.com/lechnerc77/pulumi-sap-btp.
OpenTofu
OpenTofu is a project that was founded around the event of Hashicorp moving away from the Mozilla Public License (MPL) towards the Business Software License (BSL/BUSL) for some of their products. While this has no impact on the majority of Terraform users (see FAQ - https://www.hashicorp.com/license-faq), you might be planning to evaluate this OpenTofu as a replacement for Terraform.
OpenTofu and the Terraform provider in its current shape and form can be used as a drop-in replacement. I played around a bit and the basic setup works (see also https://github.com/SAP/terraform-provider-btp/issues/460). However, several points remain open from my perspective:
You cannot use the setup as of today in conjunction with the Hashicorp registry due to the changed terms of use. The OpenTofu team is working to close this gap, but as of today there is no official OpenTofu registry available (see https://github.com/opentofu/opentofu/issues/741).
While the OpenTofu team can certainly keep things compatible with the upcoming releases of Terraform and their impact on the providers this will be a challenge. Combined with the setup of OpenTofu and the community to decide what to integrate and build into OpenTofu this can become a serious gap and the maintainers of the providers may also need a fork that then needs to be maintained.
I also doubt that Hashicorp will sit and watch how OpenTofu leverages their provider frameworks that are currently still under MPL and reuses the providers built upon this framework. No idea where this could end, but something to keep in mind.
After all, OpenTofu is certainly something that needs to be observed, but as of today I do not see any need to decide on that quickly as too many things remain unclear for organizations to make the switch. Nevertheless, the Terraform provider would as of today work in this scenario.
Crossplane
While Crossplane per definition is representing the Infrastructure as Data (IaD) paradigm (see e.g., https://infrastructure-as-code.com/book/2023/08/12/infrastructure-as-data.html for a more in depth description), I think it is fair to mention it here.
The overall approach of Crossplane originates in the concepts of Kubernetes. I would say that it targets a very specific set of requirements. Before blindly buying into it, I highly recommend to evaluate if this is the right tool for you and you can deal with the tradeoffs.
Maybe you are evaluating or already making use of it and the question arises if you can use SAP BTP with it. As for Pulumi there is not official Crossplane provider, but Crossplane offers the reuse of Terraform providers via a bridge implementation. The corresponding project is called upjet.
Although the official documentation states how to create such a bride-implementation there is currently too much movement around the topic and merging of different sources into the Crossplane repository. Checkout the #upjet channel in the Crossplane Slack for the details. When writing this blog, I failed in creating the bridge implementation and I also must state that in its current state this is a bumpy ride. Pulumi does a better job here.
Nevertheless, once the transition for this topic is done, it makes sense to revisit this.
One more thing …
The recently released Project Radius is a new citizen in cloud-native development that includes infrastructure provisioning e.g., via Terraform. That might already be something to take a closer look at, but what is even more fascinating is that it seems to push the IaC language “Bicep” forward towards becoming extensible. Bicep until now was restricted to Microsoft Azure, but there seems to be something going on here to enable other clouds:
Keeping my fingers crossed for some bridging implementation towards the Terraform world.
Something I will keep an eye on. And by the way I think Project Radius itself is worth to take a closer look at.
Okay, so Terraform does not only enable Terraform but opens up opportunities for other IaC offerings. What else can we benefit from the provider?
Keeping my fingers crossed for some bridging implementation towards the Terraform world.
Something I will keep an eye on. And by the way I think Project Radius itself is worth to take a closer look at.
Okay, so Terraform does not only enable Terraform but opens up opportunities for other IaC offerings. What else can we benefit from the provider?
To infinity and beyond!
Maybe you company has a high level of maturity when it comes to the cloud and DevOps, and you want to apply GitOps or you are already on this track (you find a good intro about GitOps in the article of GitLab "What is GitOps?").
The obvious question is if you can level up your GitOps game with the Terraform provider for SAP BTP. And the answer is: Yes, you can. Let us check out in which ways.
One main representative of GitOps tools is Flux (graduated project of CNCF). Flux offers a Terraform controller that enables you to “GitOps-ify infrastructure, and application resource”. If you would like to learn more about this, I recommend the blog post “How to GitOps Your Terraform” that elaborates the details of this setup.
Another representative in the GitOps tools ecosystem is ArgoCD. While there is no direct way to integrate Terraform into ArgoCD you can use Flamingo as Fluxsubsystem for ArgoCD. This brings Flux into the ArgoCD world and this way you can use the Terraform controller mentioned above. This is by the way the setup described in the blog post "Gitops with Argo CD & Kyma, Terraforming SAP BTP Kyma Clusters" by Maximiliano Colman mentioned in the beginning.
From IaC to enabling GitOps, that’s nice! What about bringing the things together?
Let’s Caboom 🤯
What about providing self-services for your developers when creating new applications and extensions. I am not talking about providing some code templates but provisioning the whole setup including e.g., a new subaccount on SAP BTP with a fitting configuration with the right set of entitlements, role collections assignments etc.. This way making the start of new development projects easy and ensure that they stay compliant. Yes, as a self-service for your dev teams (no more Jira tickets!).
I think Backstage as the current number one for developer portals would be a great starting point to evaluate what could be achieved when bringing things together here.
I did not yet dig too much into this, but I liked what I saw up to now in the Backstage area (pun intended). Evaluating this further is currently high on my to do list.
Summary
I think it became clear that the Terraform provider for SAP BTP per se is already a great addition to the toolbox in the SAP ecosystem. On top it enables so much more that could improve your development and DevOps setup being it leveraging IaC alternatives like Pulumi, setting up GitOps or enabling self-services in Developer Portals and living the DevOps idea.
Nothing more to say from my side than so long, dear friends of the Terraform provider for SAP BTP. See you at my next blog post.
[Originally posted on LinkedIn: Link to article ]
- SAP Managed Tags:
4 Comments
