In part 1, we demonstrated the “Brooklyn Bridge” service broker for bringing Apache Brooklyn managed services into the cloud foundry ecosystem, showing how to install the broker and import the Brooklyn catalog into the cloud foundry marketplace. I’d like to take a moment now to reflect on what Apache Brooklyn managing the services that your Cloud Foundry applications consume brings.
Bringing new services into Cloud Foundry no longer requires writing a service broker and is simplified to writing a Brooklyn Blueprint.
Writing a service broker for each service may lead to the duplication of effort. Each service broker will encode the specific configuration logic its authors needs, this in turn will lead to a proliferation of subtly different projects. Writing a Brooklyn blueprint, however, only requires a yaml file with application specific configuration. The benefits of this go beyond minimizing duplication: blueprints with different configurations can be quickly written, tested and refined.
Brooklyn managed services benefit from Autonomic management that will autoscale, replace failed nodes, load balance as well as the ability to specify custom policies.
Once a service is running, Brooklyn’s autonomic management system can ensure that the service continues to run as intended. Policies can be specified in your blueprints to decide how to react to certain events. For example. new nodes created to handle additional load or replace any that go down. Brooklyn has a number of policies that you can use out-of-the-box, or you can even write your own.
Brooklyn provides the ability to specify complex topologies or configurations that suit your needs, and deploy them to a wide range of locations.
Not only are the blueprints simple to write, but they are composable. So you can specify topologies where services talk to each other or have dependent configuration. Combined with policies this provides a powerful way to ensure you always have what you need. And these topologies can be deployed across multiple datacenters or even to bring-your-own-nodes (BYON) locations, so you have what you need, where you need.
You can receive sensor data about your services.
Running services in Brooklyn emit data about themselves through what is known as sensors, these sensors allow you to keep track of the health status of your service, or make informed decisions about their running such as whether a change of policy is required.
You can model existing/legacy services in Brooklyn and bring them into Cloud Foundry.
Although you can bring existing services into Cloud foundry with user-provided services, modelling them in Brooklyn brings them into the service broker lifecycle and gives you the control, information and autonomic management features described above.
In part 2, we demonstrated the companion CLI plugin that simplifies the creation of services by allowing you to specify your blueprints directly in your application’s manifest file. Behind the scenes the plugin sends the blueprint to Brooklyn via the service broker to add it to the catalog, and updates the cloud foundry marketplace. It then asks the service broker to create an instance of service and replaces your manifest with a traditional one that contains the name of that instance listed as a service.
The plugin also gives you a way to talk to Brooklyn via the service broker to find out about your running services, as we demonstrated in part 2 and part 3. In particular we were able to get sensor data and invoke effectors. We saw with a sharded MongoDB deployment how to scale out and back in again using the plugin.
In part 4, we saw how to write a more complicated app that uses multiple datastores for differing purposes including MongoDB to store the product catalog, Redis to store Session data, Riak for a shopping cart, and Cassandra to keep some statistics about page visits, each created with a blueprint in your application manifest.
Update & roadmap
Since writing the first four posts, the Service Broker has been accepted into the Cloud Foundry Incubatorand we aim to work closely with the community to build on what we have contributed. There are a couple of new features not mentioned in the original features: a login command to remember the broker username and password, and the ability to specify blueprints directly in the services section rather than a separate Brooklyn section. (You can still use the Brooklyn section if you want to though.)
Moving forwards, we plan to provide another profile that brokers running Brooklyn applications rather than catalog items. Create attach, start and stop policy commands for the plugin. Allow onBind, onUnbind for services that tells Brooklyn to perform a specified action at bind/unbind time. And integrate with the new Async and Parameters APIs.