TL;DR: The Service Catalog inside SAP BTP, Kyma runtime is being removed and replaced by the SAP BTP Service Operator. Existing service instances are migrated. Secrets created via the service catalog will stay in the cluster. Until October 2022, the same goes for all PodPresets which inject those secrets to given pods.
Update Jun 10, ’22: Migration has finished. It means all serviceinstances.servicecatalog.k8s.io and servicebindings.servicecatalog.k8s.io instances created via Service Catalog are right now available via SAP BTP operator custom resources: serviceinstances.services.cloud.sap.com and servicebindings.services.cloud.sap.com.
What’s going to happen these days?
On September 9, 2021, it was announced via “What’s new for SAP BTP” that the Service Catalog inside Kyma runtime is going to be deprecated and replaced by the SAP BTP Service Operator (link to archive). This is now going to happen on all Kyma runtimes as written end of April (link).
During the migration, BTP Service Operator will be installed on your cluster. It will be managed by the Kyma team and this will be the only way of using SAP services on the Kyma Runtime.
The migration will have the following impact on your cluster
You will see both Service Catalog and BTP Operator-related views in the left-hand navigation of your Kyma Dashboard. However, you won’t see any resources in the Service Catalog and Addons views. Your SAP services and bindings will now be available in the BTP Service Instances and BTP Service Bindings views accordingly. This transition is temporary and after the migration process is completed, only the BTP views will be visible in Kyma Dashboard.
Important: If you already installed BTP Service Operator, the migration will fail, since you cannot have two instances of BTP Operator in one Kyma cluster. Uninstall the BTP Operator and let us manage it for you so that it’s always up-to-date and security compliant.
Helm Broker-related resources (such as instances, bindings, ServiceBindingUsages, AddonsConfigurations and ClusterAddonsConfigurations) are no longer available. However, you can still use the Helm releases created by Helm Broker beforehand.
Take action soon!
For now, we keep your PodPresets and Secrets but we already recommend using Kubernetes-native approach to consume secrets. Read the Migrate your PodPreset Resources to Kubernetes-native Secret Consumption migration guide to learn how to migrate your resources. Note that PodPresets will be removed from all Kyma runtimes by the end of October 2022. Make sure to migrate your resources until then.
If you are using the application connectivity to SAP Customer Experience solutions, migrate to the recently introduced way of consuming these APIs. It has the advantage of using a URL to API plans which is constant and foreseeable, hence better for releasing your developments via stages. Read all about it here.
When you want to consume 3rd party services (e.g. by hyperscalers) from within Kyma runtime, use additional service operators as described here.
Creating instances of SAP BTP services
From now on to create instances of SAP BTP services, users open “BTP Service Instances” and click on “Create Service Instance”. Pick any “Name”.
The “Offering Name” and “Plan” can be found in the central “Service Marketplace” of your SAP BTP subaccount. This centralizes all the information in one place because you can filter in that catalog as well for “Environment” > “Kyma” to see all services consumable from within Kyma runtime.
SAP BTP Service Marketplace
Further details are documented here.
…and why all this?
You might be wondering why we take this effort and even ask users to take action in the next couple of months. The reason is that the operator pattern is much more Kubernetes-native “to manage applications and their components. Operators follow Kubernetes principles, notably the control loop.“ (source)
