Re: Feedback: A slightly different perspective on route services
James Bayer
we explored the ux of app to service binding in detail, but it is
problematic.
apps will soon support multiple routes on different ports.
e.g. imagine an app with 3 ports:
web traffic goes to container port 8080 on web.example.com
admin traffic goes to container port 8888 on admin.example.com
jmx goes to 9000 on jmx.example.com
which of the 3 routes should the route service bound to the app be
associated with?
a route can be mapped to multiple apps, what happens when some apps mapped
to a route have a route service bound and others don't?
shannon can probably explain more of the problem areas that we discussed, i
need to get to bed :)
toggle quoted message
Show quoted text
problematic.
apps will soon support multiple routes on different ports.
e.g. imagine an app with 3 ports:
web traffic goes to container port 8080 on web.example.com
admin traffic goes to container port 8888 on admin.example.com
jmx goes to 9000 on jmx.example.com
which of the 3 routes should the route service bound to the app be
associated with?
a route can be mapped to multiple apps, what happens when some apps mapped
to a route have a route service bound and others don't?
shannon can probably explain more of the problem areas that we discussed, i
need to get to bed :)
On Thu, Jun 25, 2015 at 11:55 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:
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
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
Thank you,
James Bayer