We’d like to share a feature developed by the OSS Routing team at Cloud Foundry called Context Path Routing that should simplify creation and management of multiple microservices. Although this was introduced late last year, we have just completed CLI support for it; so this is a good time to review it. More importantly, this should save time for most of you by streamlining your development and reducing the complexity associated with many applications.
Most Cloud Foundry developers know that if you push your app to Cloud Foundry and want to have data traffic reach that app and do something meaningful, you need to create and map a route to your app. The way you create a route is by adding a hostname to the domain. Here is an example:
cf create-route myspace example.com –hostname myapp
This will create a route myapp.example.com which you would then map to your app. Let’s say you named your app as “my-app” as follows:
cf map-route my-app example.com –hostname myapp
This will map route myapp.example.com to your application named my-app. Now your application is reachable to your clients at myapp.example.com. So, if your clients hit http://myapp.example.com/home or http://myapp.example.com/somewhereelse, both of these requests will be routed by Gorouter to your app `my-app`.
This works perfectly fine if all the paths under the domain myapp.example.com can be served by one single app. However, in this era of microservices, it is possible – even likely – to have to create an application consisting of multiple microservices that has same top domain myapp.example.com but serve just a few context paths in the URL. And all of these microservices together serve all the supported paths under the domain myapp.example.com. So how do you solve this issue in the CloudFoundry platform?
This is the problem that Context Path Routing addresses. In short, context path routing is routing based not only on domain names (host header) but also the path specified in the URL. Gorouter now can route requests to different apps based on path as well. So this will enable your microservices architecture to use the same top level domain (myapp.example.com) and have different apps providing support for different paths in the URL. Now that you can achieve context path based routing, you can independently scale up or down those portions of your app that are in high/low demand or are experiencing high/low traffic.
Here is an example of how to create and map route that has paths:
To create route with path:
cf create-route myspace example.com –hostname myapp –path foo
This will create a route myapp.example.com/foo and then you would map it to your app as follows:
cf map-route my-app example.com –hostname myapp –path foo
This will map your app my-app to myapp.example.com/foo.
Similarly you can create another route with same top level domain but different path and map it to different app:
cf create-route myspace example.com –hostname myapp –path bar
cf map-route my-another-app example.com –hostname myapp –path bar
Now requests to myapp.example.com/foo will be routed to app my-app while requests to myapp.example.com/bar will be routed to app my-another-app.
We hope this feature will help you realize your microservices architecture more quickly and effectively with CloudFoundry. As always, we love feedback – please share your experiences in the comments!