This article is part of the Introduction to IBM Cloud Code Engine series.
Service binding in IBM Cloud Code Engine
When developing an application, you frequently need to connect it to a service to extend your application’s capability, such as a database to persist data. We can call this a service binding. When you develop an application and batch job in IBM Cloud Code Engine, you can bind various kinds of services offered by the IBM Cloud Catalog, such as database, AI or machine learning, and analysis services.
Think about how you deploy applications and batch jobs in “vanilla Kubernetes.” If you want to bind your application to a service in a public cloud, generally you must do the following:
- Provision a service instance and get service credentials such as the URL, username, and password.
- Copy the service credentials.
- Create a ConfigMap and Secret in Kubernetes to persist the service credentials.
- Mount the Config file and Secret when you deploy the application.
You can imagine that if you have multiple applications and services, the configuration and maintenance of the binding relationships between applications and services can be a tedious and inefficient process. Manually copying and editing YAML files to define binding information is error-prone and can introduce failures that are difficult to debug.
The purpose of service bindings in IBM Cloud Code Engine is to make it easier for you to bind applications to services in the IBM Cloud Catalog. Service bindings in IBM Cloud Code Engine offers the following capabilities:
- Retrieve the existing service instance in IBM Cloud and create the service credentials if they do not exist.
- Retrieve the service credential and save it directly as a secret within your IBM Cloud Code Engine project.
- Inject the secret into the selected application automatically.
- Provide two kinds of service credential formats: JSON string and plain environment variables.
Service binding design
IBM Cloud Code Engine service binding is built on open source technology, including the IBM Cloud Operator and the Red Hat OpenShift Service Binding Operator. As the following diagram illustrates, the IBM Cloud Operator helps connect to your service instance in IBM Cloud, creates and receives the service instance credentials, and persists as a secret in your IBM Cloud Code Engine project. The OpenShift Service Binding Operator injects the secret into your application and persists the relationship between the service instance with the application.
How to use service binding in IBM Cloud Code Engine
IBM Cloud Code Engine service binding offers an easy CLI experience for developers. When you create a service instance and application, you can use one CLI command to bind the service instance and application together. IBM Cloud Code Engine service binding also provides CLI commands to query which service instances are bound to the application and unbind a service instance. You have full life-cycle control for service binding.
For example, the CLI command
ibmcloud code-engine application bind --name servicebinding-helloworld --service-instance language-translator will bind the
language-translator service instance in IBM Cloud with your
servicebinding-helloworld application in IBM Cloud Code Engine. As result, environment variables are injected into your application, which include service credentials.
IBM Cloud Code Engine is built to provide an easy cloud development experience. IBM Cloud Code Engine service binding is one of the features that simplifies development work. It does not require you to have any Kubernetes experience. Instead, it provides an easy CLI for you to bind an application to a service instance and receive a binding relationship. And there is not an additional charge for service binding. Get started by registering for an IBM Cloud Code Engine trial and trying IBM Cloud Code Engine service binding.