Cloud
May 10, 2019 By Mukul Tuteja
Atul Daherkar
7 min read

Sharing resources in IBM Cloud

The IBM Cloud Platform offers a rich catalog of services across many categories that can be leveraged by your business applications running in any Open Service Broker (OSB)-compatible cloud environment. There might be various scenarios in which you may want to share the same service instance between multiple business applications using native capabilities offered by the IBM Cloud platform.

As an example, if you are developing a solution which consists of two business applications and they have a need to use a messaging service, you can provision a single instance of the messaging service and share it between your applications using the “Connections” capability provided by the IBM Cloud platform.

In order to share a cloud resource instance, you need to create a “symlink” to the global resource instance into the environment’s namespace where the application is running. This link is termed as a Resource Alias. You can create multiple resource aliases to share a cloud instance with many applications across many environments. The lifecycle and access control of all these resource aliases is managed within the IBM Cloud platform.

Resource Aliasing and sharing of resource instances

A resource alias is similar to a symlink, which holds reference to a remote resource instance and enables interoperability and reuse of that resource instance across the IBM Cloud platform. Resource aliasing thus provides resource instance sharing capabilities across different deployment environments in IBM Cloud.

A resource instance is created in IBM Cloud when you provision an instance of the desired plan of a service in a resource group. The provisioned resource instance is not scoped to any particular space in Cloud Foundry or namespace in a Kubernetes cluster. Therefore, you can reuse a resource instance by creating an alias into any OSB-compatible cloud environment (Cloud Foundry- or IBM Cloud Kubernetes Service-based).

If you are using IBM Cloud Kubernetes Service, the IBM Cloud provisioning engine internally creates a namespace-scoped resource in your target environment and links it to the resource instance.

If Cloud Foundry is your desired deployment environment (public Cloud Foundry or Cloud Foundry Enterprise Edition), the IBM Cloud provisioning engine creates a service instance in the specified space in your desired Cloud Foundry regional deployment. Once the resource alias is created, your business applications can natively connect to it by using your deployment environment semantics.

When you connect or bind the resource alias to your application, the IBM Cloud provisioning engine generates the required credentials that are needed to access the resource instance. These credentials are then made available to the application in the target environment in its platform-native way. For example, in Cloud Foundry, a service binding object is created and the credentials are made available to the application by means of the VCAP_SERVICES environment variable.

Cloud Foundry native sharing capabilities

Cloud Foundry natively provides a couple of options to share service instances across spaces. Your Cloud Foundry administrators can enable the service_instance_sharing feature, where a user having “Space Developer” role in both source and target spaces can share a service instance from the source space to the target space. However, it has the following limitations:

  • Sharing is limited to a single Cloud Foundry location. For example, a service instance in the “us-south” location cannot be shared into a space in the “eu-gb” location.
  • Developers cannot rename a service instance until it is unshared from all other spaces.

The user provided services in Cloud Foundry allow you to access services not available in the current location or marketplace. This feature can be exploited for sharing service instances across spaces or even locations.  However, it is completely unmanaged in terms of user access and service lifecycle, so any changes must be propagated manually.

IBM Cloud Resource Sharing for any Open Service Broker-compatible platforms

While Cloud Foundry service sharing capabilities are limited, the IBM Cloud platform enables sharing by using resource aliasing for the following cloud environments:

IBM hosted environments:

  • IBM Cloud public
  • IBM Cloud Foundry Enterprise Environment
  • IBM Cloud Kubernetes Service clusters

Private environments:

In Cloud Foundry Enterprise Environment, IBM Cloud Kubernetes Service, IBM Cloud Private, and BYOE environments, the resource alias is an instantiation of a special alias (named) plan. This removes synchronization overhead when the cloud instance configuration or plan is changed. In IBM Cloud public, third-party service aliasing works in a similar fashion using the alias plan.

Access management

All resources organized in resource groups in the user’s account are managed by IBM Cloud Identity and Access Management (IAM). Account administrators for services or resource instances can manage policies for other identities in the account.

  • A user with Platform Editor role or higher on a service (or all IAM-enabled services or resource group) can create instances of the service.
  • A user with Platform Operator role or higher on a resource instance (or resource group or all resources in the account) can alias a resource.
  • A user with Platform Operator role or higher on a resource instance (or resource group or all resources in the account) can bind the alias to an application or create a resource key (credential).

Similar authorizations are needed to delete the resources. Refer to IBM Cloud documentation for more details.

Since aliases are links into a target environment, the access policies and resource restrictions enforced by the target platform are still applicable. For example, in a Cloud Foundry space, the user should have Developer role and visibility to the service plan (in the local environment’s catalog) in order to create an instance.

Note: Binding operations also have target-specific action, and similar platform-specific policies and restrictions apply.

Lifecycle management

The IBM Cloud platform maintains the relationship between resource instances, their aliases, bindings, and keys. The following rules are enforced by IBM Cloud to manage these resources:

Create resources

  • Typically, you need a single alias of the resource instance in a target space (or namespace). IBM Cloud console and CLI enforce this rule; however, when using native, platform tools (e.g., CF CLI), a user for the target platform can create more aliases if desired.
  • There are no restrictions on the number of bindings that can be created for an alias. In other words, an alias can be bound to as many applications as desired.

Update resources

  • When a cloud instance’s plan is updated, its aliases don’t need to be updated as their targets are instances of the alias plan.
  • The alias name change is propagated to target.

Delete resource

  • A cloud instance cannot be removed until all its aliases and keys are removed.
  • An alias cannot be removed until all its connections and keys are removed.

Leveraging resource sharing using the IBM Cloud console

You can use the IBM Cloud console to connect an application to an existing cloud resource instance. IBM Cloud console implicitly handles alias creation using IBM Cloud Resource Controller (RC) APIs into the namespace of the application followed by a Create Binding API call to connect the alias to the application.

Navigate to the Connections tab in your Cloud Foundry application and select Connect on the cloud resource instance you want to use. The following screenshot shows connecting a cloud resource instance—”Text to Speech-0s”—in the default resource group to an existing application:

Leveraging IBM Cloud CLI for resource sharing

You can also use the IBM Cloud CLI to explicitly create resource aliases and connections if you have access to the cloud resource instance and target namespace.

The following screenshot shows a user creating an alias of the cloud instance “Text to Speech-0s” targeting a “dev” space in Cloud Foundry:

You can further connect this alias to an application deployed in “dev” Cloud Foundry space.

Using native tools for Cloud environment

If you prefer, you can use native tools that are available in the cloud environment’s target platform (e.g., CF CLI for Cloud Foundry or svc-cat for Kubernetes). Resource aliasing works seamlessly when these tools are used as well by defining parameter extensions exposed by the Open Service Broker API.

Provisioning parameters (used when using the non-alias plan)

  • instance_name: The cloud instance name to use.
  • resource_group: Choose which RG the cloud instance is associated with—short or long ID.  Defaults to the default RG of the account.
    • Refer to the following IBM Cloud CLI command to list out your available groups: ibmcloud resource groups
    • Refer to the following IBM Cloud CLI example for retrieving the available targets  for a given service’s plan: ibmcloud catalog service <service name>
  • target: Choose which deployment location to use for the cloud instance. If a global deployment is available for the plan, it will be used by default.
    • e.g., cf create-service cloud-object-service standard my-cos-alias -c “{“instance_name”: “my-cos-instance”, “target”: “global”}

Binding parameters

  • role: The serviceRole role to assigned during credential create. This is only valid for IAM-compatible services and the list is particular to each service. It defaults to Writer, but if the service doesn’t support this role, no policies will be created. It’s recommended that one sets it explicitly.
    • Use the following IBM Cloud CLI command example to list out the supported service roles that a particular service supports: ibmcloud iam roles –service <service name>

Aliasing parameters (used when using the alias plan)

  • instance: The cloud instance short or long ID.
    • e.g., cf create-service cloud-object-service alias my-cos-alias -c “{“instance”: “cloud-instance-short-or-long-id”}

When you create a service instance using Cloud Foundry CLI, the IBM Cloud provisioning engine intercepts that request and it provisions a cloud instance and an alias. The instance created in this way is restricted and controlled by the corresponding alias. There are no restrictions on sharing this cloud instance, but the lifecycle operations related to this instance (such as updating the plan, deleting the instance, and more) can be carried out only by the controlling alias. When the controlling alias is deleted, meaning the link has been removed, the instance is free to be updated like any other cloud instance.

To tell if a cloud instance is controlled by some alias, you can retrieve the cloud resource instance,from the Resource Controller APIs and look at the controlled_by property.

Resource Controller APIs

The Resource Controller APIs provide even more fine-grained control for managing resources in IBM Cloud. The IBM Cloud Console and CLI call these APIs underneath.

The following example shows an alias named “text-speech-dev” created by a user. It links the “source” cloud instance identified by its short ID to the the “target” space in Cloud Foundry identified by its full Cloud Resource Name.

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_aliases \
  -H 'Authorization: Bearer <IAM_TOKEN>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "text-speech-dev",
    "source": "8d7af921-b136-4078-9666-081bd8470d94",
    "target": "crn:v1:bluemix:public:bluemix:eu-gb:o/e242c7f0-9eb7-4541-ad3e-b5f5a45a1498::cf-space:f5038ca8-9d28-42a1-9e57-9b9fdd66bf8e"
  }'

Additional references

Was this article helpful?
YesNo
Mukul Tuteja
Architect, IBM Cloud Core Platform BSS Service
Atul Daherkar
IBM Cloud BSS Development

More from Cloud
July 19, 2024

IBM Cloud Virtual Servers and Intel launch new custom cloud sandbox

4 min read - A new sandbox that use IBM Cloud Virtual Servers for VPC invites customers into a nonproduction environment to test the performance of 2nd Gen and 4th Gen Intel® Xeon® processors across various applications. Addressing performance concerns in a test environment Performance testing is crucial to understanding the efficiency of complex applications inside your cloud hosting environment. Yes, even in managed enterprise environments like IBM Cloud®. Although we can deliver the latest hardware and software across global data centers designed for…

July 18, 2024

10 industries that use distributed computing

6 min read - Distributed computing is a process that uses numerous computing resources in different operating locations to mimic the processes of a single computer. Distributed computing assembles different computers, servers and computer networks to accomplish computing tasks of widely varying sizes and purposes. Distributed computing even works in the cloud. And while it’s true that distributed cloud computing and cloud computing are essentially the same in theory, in practice, they differ in their global reach, with distributed cloud computing able to extend…

July 16, 2024

How a US bank modernized its mainframe applications with IBM Consulting and Microsoft Azure

9 min read - As organizations strive to stay ahead of the curve in today's fast-paced digital landscape, mainframe application modernization has emerged as a critical component of any digital transformation strategy. In this blog, we'll discuss the example of a US bank which embarked on a journey to modernize its mainframe applications. This strategic project has helped it to transform into a more modern, flexible and agile business. In looking at the ways in which it approached the problem, you’ll gain insights into…

IBM Newsletters

 Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters