Route Services in Cloud Foundry
Route Services in Cloud Foundry
I’d like to share an exciting new development in the continuing evolution of Predix with Cloud Foundry. Specifically, the OSS Cloud Foundry Routing team (in conjunction with a few GE engineers) just finished work on some new advances on creating route services with the Cloud Foundry platform. Read on for more info.
Join the DZone community and get the full member experience.Join For Free
See why enterprise app developers love Cloud Foundry. Download the 2018 User Survey for a snapshot of Cloud Foundry users’ deployments and productivity.
I’d like to share an exciting new development in the continuing evolution of Predix with Cloud Foundry. Specifically, the OSS Cloud Foundry Routing team (in conjunction with a few GE engineers) just finished work on some new advances on creating route services with the Cloud Foundry platform. All of the necessary work on the GoRouter side and cloud controller side has been done to enable this new feature (available in CF release v231) that will save significant time and complexity for all developers creating new apps on Predix.
First, some brief background info. Route services are all about trying to address a use case in which users need to intercept all traffic on a specific route in order to achieve some type of functionality. This could include metering, caching, or authentication to name a few instances, but this really includes any resource that you want to intercept and adjust at the routing layer in Cloud Foundry. Clearly, most cloud applications and services will require such functionality, so this is a critical addition to the toolbox for developers creating new apps on Predix and Cloud Foundry. Addressing this functionality at the route level by making sure that each request to a route is intercepted (rather than leaving it to each app to integrate with these services on their own) reduces complexity, increases the options for the developer, and should save significant time in developing the overall app.
Let’s provide a bit more context to showcase what we mean. Say, for example, you have deployed a Cloud Foundry-based application. Like other services, route services will be listed in `cf marketplace`. Service brokers that provide these services are already registered with Cloud Foundry and all a developer should do is create an instance of the service and bind it to a route. This is exactly the same as how you create and bind services to an app. The only difference being instead of binding to an app you bind the service to a route.
In the same way that you have bind services, you can also have unbind services to remove these associations. Route services can be either managed services or user-provided services.
In terms of specific, step-by-step instructions, we’ve provided a link to some excellent content that will enable you to get started immediately.
CLI UX in the above link is not the final one, as it uses some `curl` commands. Here is an idea of what the UX looks like (it is now available as part of cf CLI v6.16.0).
CLI to create instances of managed service remains the same as any other service in Cloud Foundry (cf create-service). However, for user provided services to be used as route services there is an additional parameter added to CLI:
cf create-user-provided-service SERVICE_INSTANCE [-p CREDENTIALS] [-l SYSLOG_DRAIN_URL] [-r ROUTE_SERVICE_URL] e.g. cf create-user-provided-service my-route-service -r https://example.com
CLI to bind service to route:
cf bind-route-service DOMAIN SERVICE_INSTANCE [-n HOST] [-f] e.g. cf bind-route-service 10.244.0.34.xip.io myratelimiter -n spring-music
CLI to unbind service to route:
cf unbind-route-service DOMAIN SERVICE_INSTANCE [-n HOST] [-f] e.g. cf unbind-route-service example.com myratelimiter -n myapp
Route services bound to a route can be seen using cf routes command.
That should be all you need to get started. As always, we’re eager to hear your feedback. Please share your thoughts in the comments.
Opinions expressed by DZone contributors are their own.