During the Cloud Foundry Summit 2015, Pivotal’s David Sabeti and IBM’s Michael Maximilien reviewed the latest Cloud Foundry Service Broker Updates. These new features offer new opportunities to provision and customize services which were previously difficult to implement. Recently, the Cloud Foundry Service Broker API was updated to version 2.7, and some of the experimental API features went from experimental to GA.
I thought this is good time to review of those new features, using a real-life example. What would happen if we enable application developers to easily create and manage self-service AWS RDS DB Instances of Aurora, MariaDB, MySQL and PostgreSQL directly from the Cloud Foundry marketplace? To answer this question, I created an experimental AWS RDS Service Broker for Cloud Foundry to highlight all the recent Service Broker updates.
AWS RDS Service Broker
The Amazon Relational Database Service (Amazon RDS) makes it easy to set up, operate, and scale a relational database in the cloud, providing you several familiar database engines to choose from, including Amazon Aurora, Oracle, Microsoft SQL Server, PostgreSQL, MySQL and MariaDB.
Perhaps you have deployed Pivotal Cloud Foundry on AWS, or Pivotal Cloud Foundry® on-premises, but want to leverage an already scalable solution for an application’s data persistence. Having a broker that allows application developers to spin up relational databases on-demand and bind them to their applications without having to manually configure all the specifications is a good fit.
Leveraging all the new Service Broker updates, this experimental AWS RDS Service Broker will have the following goals:
For Platform Operators:
- To allow application developer to spin-up RDS Databases without exposing any AWS details (credentials, networks, etc.)
- To expose a catalog of different pre-defined RDS configurations, including the Database Engine of choice (MariaDB, MySQL or PostgreSQL), the DB Instance Type, the type and size of the storage to allocate
- To enable/disable application developers to supply additional configuration parameters on provision, update, and bind time
For application developers:
- To spin-up the preferred RDS Engine with a simple and well-known command
- To update the RDS Engine to a different pre-defined configuration (more allocated storage, more CPU/Memory performance, etc.)
- To tune some specific RDS configurations, like the database name, the character set name, on provision, update or bind time
- To bind dynamically RDS databases to applications without dealing with the usual AWS configuration (networking, security groups, etc.)
- To get database credentials without binding an application
Let’s look at these features in detail.
Asynchronous Provisioning
Until now, one of the major constraints when provisioning new services is that when an application developer provisions a service, the broker must respond pretty fast—usually in less than 60 seconds—due to the synchronous nature of the broker provision API call. This pattern has worked well for services already running that only required simple instructions to provision, but doesn’t work smoothly when the service’s provision needs extra time to be available.
One of these examples is when provisioning a MySQL database. Spinning up a full production MySQL server in less than 60 seconds is unrealistic, so, usually, Platform Operators have enabled this service by having it pre-provisioned. By doing this, the service broker provision API call should only trigger a “create database” statement followed by a “granting access to the database” message when the application developer binds the provisioned service to the application.
One of the downsides of this approach is that it is difficult to have single-tenant services. In the above example, the MySQL server is shared among all the users, and although the databases are single tenant, sharing the same server with all applications might lead to security concerns and noisy neighbor problems. Having already-provisioned servers waiting to be used also becomes costly, so this is a path that few customers want to follow.
With the new Asynchronous Provision API, Platform Operators have now the ability to expose a catalog of services that will be created on demand when an application developer requires it. It also allows isolated service instances and reduces the cost of having pre-provisioned services.
From an application developer point of view, the workflow is be the same, except that provisioned service will not be available immediately. While the service instance is being provisioned, no one can perform any other action against it (like updating, binding, etc.). The application developer has a new CLI command that allows querying the state of the provisioning call.
Let’s see this in action using the AWS RDS Service Broker. An application developer will perform a “create-service” request, and then will periodically query the status of the provisioning process:
Arbitrary Parameters
Another useful feature introduced recently is Arbitrary Parameters. Platform Operators can now enable application developers to declare configuration options for service instances at create, update or bind time (if the service broker implements supports for this).
Having the ability to inject arbitrary parameters will allow application developers to set the character set name, the backup retention period, or the preferred maintenance or backup window. After all, who better than the application developers will know how their application behaves with certain configurations?
Another example, being able to provision a RDS database with a simple command, sounds great. The disadvantage is that customers would have to pay for a full RDS Server for each application, even when using small tables. So now, when application developers need to create a new database, instead of provisioning a new RDS Server, they can choose to reuse an existing one. To make things cleaner, users may choose to create a new database, so every application—even those reusing the same RDS Server—will use a different database. Using Arbitrary Parameters during the bind time will allow application developers to specify what database name they want to use.
Let’s see an example using the AWS RDS Service Broker. The application developer will bind a service to an application, but instead of letting the broker pick up a random database name, it will instruct it to create a database with a specific name:
Service Keys
Until now, the only way to get the credentials for a provisioned service was to bind an application and then check its environment variables. With the new Service Keys feature, application developers can now create specific credentials for a service instance without binding an application.
There are multiple use cases for this feature. These include getting credentials to perform some action to the database before an application is bound to the service, and to expose those credentials to an external application and/or service.
Service Keys also accepts Arbitrary Parameters. Depending on what the service broker accepts, it might be useful to generate read-only keys, or to get credentials for a particular database.
Let’s see this in action using the AWS RDS Service Broker. An application developer will create a Service Key in order to connect to the database using an external tool. Later, the application developer will create another Service Key. In this case, they will also Arbitrary Parameter to get credentials for a specific database, in order to check the contents generated by a bound application.
Updating Service Plans
Capacity planning is always a complex exercise. application developers might plan for a certain amount of data and/or number of requests, but sometimes they fall short (or exceed) the estimated requirements.
The good news is that the Service Broker now has the ability to update the Plan for an existing provisioned Service. Platform Operators can expose Plans of the same Service with different configurations (i.e., the allocated storage, the allocated CPU/Memory, etc.) and make those plans updateable. application developers, with a simple command, can now upgrade or downgrade the Plan so the service meets the real requirements required by their applications.
Since an update process may not happen rapidly, some updates require some time to be performed. In such a case, the update process can also be executed asynchronously, following the same protocol as that the provisioning requests we demonstrated before.
The Service Brokers API also allows application developers to send arbitrary parameters for the update request, depending on whether they should apply the changes immediately or if wait until the next maintenance windows.
Let’s watch an example using the AWS RDS Service Broker. An application developer detects that the application has some bottleneck issues while accessing the database, so they decide to use another Service Plan that has more resources (CPU, Memory, Storage, etc.) and apply this change immediately. With a simple command, the broker will update the service instance in the background:
Conclusion
The new Service Broker updates allows us to expand the type and capabilities of the services that Platforms Operators can expose to the application developers. They allow the latter to start using and configuring services in a friction-less way. For more information on these features and how to build your own service broker, check the Cloud Foundry Services documentation.
The AWS RDS Service Broker has been released as an Open Source project under an Apache 2.0 License, and although it’s just an experimental broker to demonstrate the new Service Broker updates, feel free to use it, clone and/or enhance it, or use it as an example of new services brokers.
About the Author
