External Service Registration/Discovery

[fm-tibco]

Current behavior:

Expected behavior:

Add a standard way to register trigger as a service in an external registry and also to look one up in an activity for example.

Add support for a pluggable external service registration/discovery implementation.

What is the motivation / use case for changing the behavior?

Additional information you deem important (e.g. I need this tomorrow):

[fm-tibco]

By external service registration/discovery, I mean service registration using for example kubernetes, consul, etcd, or docker. With something like this, you can for example, look up a REST micro-service using a name instead of an exact host and port

[skothari-tibco]

I think we can use functions. Thoughts @fm-tibco @mellistibco @vijaynalawade

[vijaynalawade]

@skothari-tibco : Though nice idea, using mapper functions will limit this capability. e.g. what if I want to dynamically enable/disable this capability? Given there are many services that offer such capability (Consul, Eureka, etcd, Zookeeper etc), keeping abstraction is very important for productivity. I should be able to switch to different service without making any change in my application.