Evolve to Infrastructure as Code "Operator"

[jalibu]

Today, the BTP Setup Automator is a handy tool to script execution instructions in a declarative way for an initial BTP Account setup.
Unfortunately, the BTP Setup Automator does not really satisfy the requirements to implement an "Infrastructure as Code" approach where you can use your declaration files (usecases) to maintain a desired state of the target (BTP Accounts) after the initial setup.

I would love to see the BTPSA evolving to a tool, which implements the Kubernetes Operator pattern. It should be able to react on changes on the usecases files on GitHub (desired state) and take care to establish (sync) these changes on BTP (actual state).
This is not possible today.
If you change a previous submitted usecase, i.e. by adding a new service to a subaccount, the script detects (and skips) existing entities. But unfortunately it does not remove or patch them if they were changed in the usecase.

In simple words:
Can we change the concept behind BTPSA from "I tell you what you should do" to "I tell you what I want to have"?

[lechnerc77]

Speaking as a maintainer of this repo: there are as of today no plans to enhance the btpsa with an operator implementation.
So if you/the community wants to contribute/start such a project, feel free to do so.

On a side note: IaC improvements are under discussion, but nothing to share yet.

[lechnerc77]

We have released a first version of a Terraform Provider for SAP BTP (see Terraform registry and GitHub repository). As Terraform offers a declarative approach, contains a state of your resources and supports drift detection as well as GitOps, I would recommend to switch to this offering, to fulfill your requirements.