Feedback: A slightly different perspective on route services
Mike Youngstrom <youngm@...>
This thread [0] on Route services has got me thinking. I'd like to propose
a slightly different perspective on the route services concept. A typical service today, lets call them "App Services" at its most base function exists to apply some functionality to an application. Typically that functionality comes in the form of credentials supplied to an application. But not always. For example, a Log Drain App Service applies log drain functionality to an app. My organization has other services that apply other functionality to an app not necessarily in the form of credentials. So, with that perspective what should a "Route Service" be? I think at its basest form a Route Service should simply be a way to applying functionality to a Route. (note I said nothing about proxies). Just like a log drain app service is a type of App Service. I think a Proxy Route Service could be viewed as a type of Route Service. Why is this distinction important? I think it keeps the vision of a route service more simple, pure, and less implementation specific. I think with this perspective route services become much simpler and more powerful. You support binding one or more route services to a route just like today you can bind one or more app services to an app. However, if the service identifies itself as a Proxy Route Service (just like a service can identify itself as a log drain service) then the Cloud Controller simply fails the bind because today we only allow one proxy route services to be bound to a route at a time. The UX becomes simply: cf bind/unbind-route-service We leave the problem of ordering multiple Proxy Route Services as a future problem. Of which I think user provided ordering is only one possible solution. I believe other more natural and simple solutions will present themselves over time. Thoughts? Mike [0] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-June/000535.html
|
|