Feedback: A slightly different perspective on route services


Mike Youngstrom
 

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


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 :)

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


Mike Youngstrom
 

Let me clarify. I'm still 100% on board with binding a service to a
route. What I'm proposing with my different perspective is to decouple the
idea of a Route service being a proxy and think of a service bound to a
route as a generic way to apply enhanced functionality to a route (not
necessarily through a proxy) and make applying a proxy to a route a
standard extension to a route service similar in concept to how a service
meant to be bound to an app can be enhanced to provide a log drain.

Does that make sense?

Mike

On Fri, Jun 26, 2015 at 1:36 AM, James Bayer <jbayer(a)pivotal.io> wrote:

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 :)


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

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


James Bayer
 

i think i understand what you mean now. shannon has thought through those
concepts and relationships and the options for how to express them. i'll
let him comment on his current thinking. i got hung up on this example not
being complete and assumed you mean binding to an app:

cf bind/unbind-route-service

more explicitly, i believe you're advocating for an experience like:

cf bind-route-service ROUTE SERVICE_INSTANCE
cf unbind-route-service ROUTE SERVICE_INSTANCE

where ROUTE today is typically expressed with the compound "DOMAIN -n
HOSTNAME" rather a named alias.

On Fri, Jun 26, 2015 at 7:23 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Let me clarify. I'm still 100% on board with binding a service to a
route. What I'm proposing with my different perspective is to decouple the
idea of a Route service being a proxy and think of a service bound to a
route as a generic way to apply enhanced functionality to a route (not
necessarily through a proxy) and make applying a proxy to a route a
standard extension to a route service similar in concept to how a service
meant to be bound to an app can be enhanced to provide a log drain.

Does that make sense?

Mike

On Fri, Jun 26, 2015 at 1:36 AM, James Bayer <jbayer(a)pivotal.io> wrote:

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 :)


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

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer


Dieu Cao <dcao@...>
 

Hi Mike,

I think I understand your use case.
Currently route services are specced out such that they must, at minimum,
function like a proxy.
I think you're proposing that a route service could be a service that is
not a proxy.
I think what would be needed is a way to specify things, like https only
for example, as a route service, such that a router, like the gorouter, or
tcp router, could interpret that attribute on the route and apply that
behavior.
That sound right?

-Dieu

On Sat, Jun 27, 2015 at 2:05 PM, James Bayer <jbayer(a)pivotal.io> wrote:

i think i understand what you mean now. shannon has thought through those
concepts and relationships and the options for how to express them. i'll
let him comment on his current thinking. i got hung up on this example not
being complete and assumed you mean binding to an app:

cf bind/unbind-route-service

more explicitly, i believe you're advocating for an experience like:

cf bind-route-service ROUTE SERVICE_INSTANCE
cf unbind-route-service ROUTE SERVICE_INSTANCE

where ROUTE today is typically expressed with the compound "DOMAIN -n
HOSTNAME" rather a named alias.

On Fri, Jun 26, 2015 at 7:23 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Let me clarify. I'm still 100% on board with binding a service to a
route. What I'm proposing with my different perspective is to decouple the
idea of a Route service being a proxy and think of a service bound to a
route as a generic way to apply enhanced functionality to a route (not
necessarily through a proxy) and make applying a proxy to a route a
standard extension to a route service similar in concept to how a service
meant to be bound to an app can be enhanced to provide a log drain.

Does that make sense?

Mike

On Fri, Jun 26, 2015 at 1:36 AM, James Bayer <jbayer(a)pivotal.io> wrote:

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 :)


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

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Mike Youngstrom
 

Yes, though in your "https only" example the route service broker would be
the one to interpret how to implement the attribute or service bound to the
route and choose to either provide a proxy or configure other outside
resources accordingly. An "https only" service broker might choose to
implement its functionality with a proxy that looks for the X-Forwarded_For
header. In this case CF knows how to handle that proxy url returned just
like CF knows how to handle a syslog drain url returned by something like a
splunk service broker.

Re-configuring the frontend load balancer might be the way some other
service broker might choose to implement binding to a route.

I think a proxy is only one way someone might choose to implement a route
service. So, lets look at a proxy route service as simply one type of
route service. Making services bound to routes more flexible.

Mike

On Mon, Jun 29, 2015 at 4:02 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Mike,

I think I understand your use case.
Currently route services are specced out such that they must, at minimum,
function like a proxy.
I think you're proposing that a route service could be a service that is
not a proxy.
I think what would be needed is a way to specify things, like https only
for example, as a route service, such that a router, like the gorouter, or
tcp router, could interpret that attribute on the route and apply that
behavior.
That sound right?

-Dieu


On Sat, Jun 27, 2015 at 2:05 PM, James Bayer <jbayer(a)pivotal.io> wrote:

i think i understand what you mean now. shannon has thought through those
concepts and relationships and the options for how to express them. i'll
let him comment on his current thinking. i got hung up on this example not
being complete and assumed you mean binding to an app:

cf bind/unbind-route-service

more explicitly, i believe you're advocating for an experience like:

cf bind-route-service ROUTE SERVICE_INSTANCE
cf unbind-route-service ROUTE SERVICE_INSTANCE

where ROUTE today is typically expressed with the compound "DOMAIN -n
HOSTNAME" rather a named alias.

On Fri, Jun 26, 2015 at 7:23 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Let me clarify. I'm still 100% on board with binding a service to a
route. What I'm proposing with my different perspective is to decouple the
idea of a Route service being a proxy and think of a service bound to a
route as a generic way to apply enhanced functionality to a route (not
necessarily through a proxy) and make applying a proxy to a route a
standard extension to a route service similar in concept to how a service
meant to be bound to an app can be enhanced to provide a log drain.

Does that make sense?

Mike

On Fri, Jun 26, 2015 at 1:36 AM, James Bayer <jbayer(a)pivotal.io> wrote:

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 :)


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

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev