In this post I describe our investigations related to Cloud Foundry services. In particular, we explore options to make an existing enterprise application available as a service in a CF environment.
This can be useful for building new cloud native apps which rely on legacy systems, and express these dependencies in a clean way. It can also be useful in the context of rewriting a legacy app in a cloud native way. If like some of our apps there are millions of lines of code involved, a big bang approach is unrealistic. It would take very long, and we just can’t stop our business during that period, i.e. we can’t tell our customers requesting new features that we’ll gladly implement them in the new version, which should be available in 18 months. A more realistic approach can be to componentize the legacy app, make the components available as CF services, and incrementally rewrite components in a cloud native way, while relying on these services.
For this test we used on purpose an application which is not cloud friendly. It was written before the cloud era, it does not follow the 12 factor app methodology, it assumes a local file system is available, it uses EJB… For these reasons, this application cannot run inside Cloud Foundry, and we deployed it in BOSH, next to the CF VMs. The application transforms payment orders XML messages into the Swift format.
User Provided service
The most straightforward way to achieve our goal is to use User Provided Services. They allow us to specify connection information, such as url and credentials, and to provide them to applications through binding.
After binding and pushing our client application, we can see the service information is injected in the environment next to the mySql service.
In our transform-order-sample app, we then just have to extract the credentials from the environment, and we can call the swift transformation service, which is a secured SOAP service in our legacy app.
A note about security
If you are running everything on a local network, you’ll have to enable a route by creating a security group (cf create-security-group) and binding it to your space or org. More info about this can be found in the Cloud Foundry documentation.
For example, this is what we used to allow access to our legacy app located anywhere in 192.168.8.x
[
{
"destination":"192.168.8.0/24",
"protocol":"tcp"
"ports":"8080"
},
{
"destination":"192.168.8.0/24",
"protocol":"icmp"
"ports":"0"
},
]
Managed Service
A more elaborate way to provide our enterprise application as a service is to use Managed Services. This requires that you provide a Broker which implements a Cloud Foundry specific Service Broker API.
This is more work but offers the following advantages
-
Your app is visible in the Marketplace, and you can specify usage plans.
-
Provisioning and binding is managed by Cloud Foundry, through the service broker you provided
-
If you app offers configuration screens, they can be accessed seamlessly through the use of the dashboard feature. By seamlessly I mean no further login is required, user identity is handled through Single Sign On. This will be detailed in a future post.
To develop our service broker, we used cf-java-component which greatly simplified the code needed.
For example, defining our service metadata and plans was very easy:
@ServiceBroker(
@Service(id = "6c555ac6-c1df-46f5-b2f3-c8b7ff59f415", name = "swift-transformation",
description = "Swift Transformation Service.", bindable = "true",
metadata = {
@Metadata(field = Metadata.PROVIDER_DISPLAY_NAME, value = "Vermeg"),
@Metadata(field = Metadata.LONG_DESCRIPTION, value = "This service allows you to transform payment message to SWIFT format. "),
@Metadata(field = Metadata.IMAGE_URL, value = "http://www.vermeg.com/VermegFirstSite-theme/images/VermegSite/vermeg_banking_solution.png")
},
plans = {
@ServicePlan(id = "c7a678d6-d7fd-4334-9c05-5c593f1b63c1", name = "eval", description = "Basic plan for evaluation purpose. Max 100 calls per month."),
@ServicePlan(id = "fd6f812f-037e-432f-a677-2bb1f737afa7", name = "pro", free = "false", description = "Production ready plan. Unlimited number of calls.")
}
)
)
In the provision, bind, unbind and unprovision methods we essentially store and update information related to the swift transform instances, i.e. the legacy app instances, and the bindings with apps, in a mySql database.
@Provision
public ProvisionResponse provision(ProvisionRequest request) {
LOGGER.info("Provisioning service with id {}", request.getInstanceGuid());
if (!isPlanExists(request.getPlanId())) {
throw new NotFoundException("The service plan with id [" + request.getPlanId() +
"] does not exists for service with id [" + this.getManagedService().id() + "].");
}
//We currently only work with one Swift Transform instance
if (swiftTransformRepository.count() == 0) {
swiftTransformClient.advertiseServiceInstanceId(request.getInstanceGuid().toString());
SwiftTransformInstance swiftTransformInstance = new SwiftTransformInstance(request.getInstanceGuid(), swiftTransformClient.getSwiftTransformInstanceAddress());
swiftTransformRepository.save(swiftTransformInstance);
return new ProvisionResponse(swiftTransformInstance.getInstanceAddress());
} else {
//We should return 409 if service id is already registered, but we might also return 200 if the request is exactly the same
//as the previous one that first created the service (see https://github.com/cloudfoundry-community/cf-java-component/pull/5)
//Here, as we ony manage one service instance of Swift Transform, we can choose to either raise conflict or return the same response
throw new ServiceBrokerException(HttpServletResponse.SC_CONFLICT,
"An instance for this service already exists. Only one instance of this service is permitted.");
}
}
@Deprovision
public void deprovision(DeprovisionRequest request) {
LOGGER.info("Deprovisioning service with id {}", request.getInstanceGuid());
SwiftTransformInstance swiftTransformInstance = swiftTransformRepository.findOne(request.getInstanceGuid().toString());
if (swiftTransformInstance == null) {
throw new MissingResourceException();
}
swiftTransformRepository.delete(swiftTransformInstance);
}
@Bind
public BindResponse bind(BindRequest request) {
LOGGER.info("Binding service instance {} to application {}", request.getServiceInstanceGuid(), request.getApplicationGuid());
SwiftTransformInstance swiftTransformInstance = swiftTransformRepository.findOne(request.getServiceInstanceGuid().toString());
if (swiftTransformInstance == null) {
throw new NotFoundException("Could not find service instance with id[" + request.getServiceInstanceGuid() + "] to bind to");
}
SwiftTransformInstance brokerInstance = swiftTransformRepository.findByApplicationBindingsBindingId(request.getBindingGuid().toString());
if (brokerInstance != null) {
//We should return 409 if binding id is already used, but we might also return 200 if the request is exactly the same
//as the previous one that first created the binding (see https://github.com/cloudfoundry-community/cf-java-component/pull/5)
throw new ServiceBrokerException(HttpServletResponse.SC_CONFLICT,
"Binding with id [" + request.getBindingGuid() + "] already exists for service [" + brokerInstance.getInstanceId() + "]");
}
String username = RandomStringUtils.randomAlphanumeric(32);
String password = RandomStringUtils.randomAlphanumeric(32);
swiftTransformClient.createCredentialsForWSUser(username, password);
ApplicationBinding applicationBinding = new ApplicationBinding(
request.getBindingGuid().toString(), request.getApplicationGuid().toString(), request.getServiceInstanceGuid().toString());
swiftTransformInstance.getApplicationBindings().add(applicationBinding);
swiftTransformRepository.save(swiftTransformInstance);
Map<String, String> credentials = new HashMap<>();
credentials.put(URL_PROPERTY, swiftTransformInstance.getInstanceAddress() + "/PalmyraWSSwiftOrderTransformerWSService?wsdl");
credentials.put(USERNAME_PROPERTY, username);
credentials.put(PASSWORD_PROPERTY, password);
return new BindResponse(credentials);
}
@Unbind
public void unbind(UnbindRequest request) {
LOGGER.info("Removing binding with id {}, targeting service instance {}", request.getBindingGuid(), request.getServiceInstanceGuid());
ApplicationBinding applicationBinding = applicationBindingRepository.findOne(request.getBindingGuid().toString());
if (applicationBinding == null) {
throw new MissingResourceException();
}
SwiftTransformInstance swiftTransformInstance = swiftTransformRepository.findByApplicationBindings(applicationBinding);
if (swiftTransformInstance == null) {
throw new MissingResourceException();
}
swiftTransformInstance.getApplicationBindings().remove(applicationBinding);
swiftTransformRepository.save(swiftTransformInstance);
}
Once our broker app is pushed, we can create a new service broker in CF by using the url where it’s been deployed, in our case swift-transform-service.10.244.0.34.xip.io. You also need a specify a user and password, which will be used by the Cloud Controller when it calls the broker api (catalog, provision…).
About security
To play with service brokers, you must have sufficient permissions on the plaform. For example, don’t try it on Pivotal Web Services, it will not work 
Specifically, the user must be in the cloud_controller.admin group. See the CF documentation for more information.
The next steps are to enable access to your service plans (they are private by default), create a service based on one available plan, and bind it to your application.
Don’t forget to push / restage your app.
To validate the entire chain works, we can ask our transform-order-sample app to transform a demo message. The demo message is a xml file representing a payment order. When using the transform endpoint, it converts xml to swift by using the swift-transformation-pro service, and outputs the result.
About multi tenancy
If the legacy app is not multi tenant aware, which is quite likely, you need to be careful with what you do.
If you just define one service, and bind multiple applications to it, all of them will use the same instance of your legacy app. This might cause problems, for example if your legacy app has some configuration you don’t want to share across all applications.
The opposite way to do it is to have one legacy app dedicated to one application. With the user provided service approach, that means creating multiple services with cf cups, each time specifying a url to a different legacy app instance. With the managed service approach, you can achieve that by adjusting the provision and bind methods of your broker. For example, your provision method might get an available legacy app instance from a pool, and use that one for the requesting application.
Another option, kind of in the middle, is to share a legacy app instance inside a group defined by some criteria. For example, assuming your legacy app provide country specific tax calculation services, it might make sense to have applications related to one country talk to the same legacy app.
Conclusions
Cloud Foundry offers strong and flexible support for defining services which can then be consumed by applications. As we illustrated in this article, these services do not necessarily have to run inside Cloud Foundry. The model is compatible with public, private and hybrid clouds, and is therefore quite interesting for ISV willing to offer their services in a modern way.
There are still many things to investigate, such as how to handle the billing, in a private or public environment. For example, Pivotal Web Services relies on AppDirect to manage marketplace services. The granularity of the services to expose is also quite sensible; this model might not be optimal for fine grained business services.