October 5, 2014 | Written by: Alberto Atusi Miyazaki
Share this post:
The interest around hybrid cloud has been rising, but many companies have a low level of confidence about moving workloads to the cloud. There are a lot of factors to be discussed around this issue, but I agree with IBM SoftLayer CEO and Founder Lance Crosby, who said that hybrid cloud represents the best of both worlds.
IBM Bluemix is a great choice of platform to create and deploy cloud applications, but it is not a “one size fits all” solution, as many of the applications around today were not developed to be self-contained and infrastructure agnostic. You can read more about the methodology behind creating this type of application here (ePub download also available).
Even if you rewrite your application, you may still need that “old fashioned,” traditional database, either because you have a large dataset that cannot be moved or just want it to be kept on premises.
The clients I talk to tend to agree on a common topology that meets their security and privacy standards. It has the application running on a public cloud, but keeps the client’s data on premises (a traditional data center or a private cloud). Let’s explore a less common alternative to that.
Bluemix has IBM Cloud Integration for Bluemix service, based on Cast Iron and DataPower technologies. These integrations focus on protecting the data and making it easier to bind these on-premises services to the applications running on Bluemix. But there’s a catch: who will create and deploy these services to be consumed?
Thinking about this and a client proof of concept I was working on, my team decided to create a new kind of integration. In Bluemix, a service can be a user provided service where you just need to map the connectivity information (host IP, port, user, password and so on) or a service can be managed by a service broker.
Cloud Foundry has a service broker service that can be customized using a specific application programming interface (API) as described in its documentation: “Services are integrated with Cloud Foundry by implementing a documented API for which the cloud controller is the client; we call this the Service Broker API.”
That means anyone who wants to create a service broker is allowed to, as long as the development follows the API methods so the cloud controller can use the service as a client.
For this proof of concept, we had some services being provisioned by IBM SmartCloud Orchestrator in a private cloud environment. SmartCloud Orchestrator is a very robust and flexible cloud orchestration solution that uses OpenStack technology as its foundation. SmartCloud Orchestrator can manage different hypervisor technologies such as KVM, VMware vCenter, PowerVM and zVM, and has two REST APIs that can be used to integrate with external systems.
The orchestration and workflow engine has a REST API that can be used to trigger different workflows that interact not only with the virtual environment but also with other pieces like governance systems, monitoring systems, Configuration Management Database (CMDB) or routers and load balancers that are usually placed on the edge of the networks. This has a great value for large environments, but it was not optimal for us.
We had a small system, so our decision was to use the provisioning engine’s REST API. That allowed us to call the system patterns we were using to deploy services like cache and databases.
One of our team members, Ricardo “Rabbit,” wrote the service broker that would call the specific services that were mapped by a JSON file I created. This integration was a little tricky as both Ricardo and I had never done it. With some help from the IBM lab and community documents, it worked!
That was possible because the Bluemix environment we used was a separate internal instance, and we had the necessary administrator permissions to make such changes in the Fabric. The Bluemix catalog now includes a service called IBM SCO that can be used to deploy a new instance of a service such as cache in a private cloud. How cool is that?
In the end, it’s more than good technology working together; it’s a solution for those clients who want to keep using their already mature services and keep their data inside their physical data centers.
Thanks to Ricardo “Rabbit” Sousa for his contribution to this article and assets developed. Some say that Bluemix is a place for developers to act like kids in a sandbox, except the sandbox is enterprise grade. I agree with that. Do you?
Please leave your comments below! You can follow me on Twitter @aamiyazaki.