Dynamic LoadBalancer Server List

[#1]

[Background: using Apigee on-prem fronting a bunch of microservices]

Apigee provides the API to dynamically add named TargetServer objects and that's great. However, when it comes to the TargetEndpoint configuration for loadbalancing, it seems I have to provide a static list of named servers, and that seems not so great.

I'm operating in a microservice environment, and I want my services to register themselves with something like Consul or Eureka. Then I would like to pump that data into Apigee for dynamic loadbalancing between instances but I can't seem to do that with a static list of named targets. To get around this, I have positioned a load balancer between Apigee and the services to perform the task, but it would be great to not have to.

Am I missing something in Apigee that would allow me to do this (some magic variable I can set, pulling the list of servers from the key/value map, etc)? Or am I trying to fit a square peg in a round hole here and I should stick with the load balancer between Apigee and the services?

[#2]

Hi @Jonathan Baney , Correct your understanding is right .

We can only configure the Targetservers in the load balancer group as of now .

Even if you want to change the ips at runtime I believe you need a redeploy of the apiproxies (This was the case in old release not sure about the latest 15.04)

One thing I can think of in your scenario is to have hostnames in the target servers and have that resolve(on MP) to what ever ips you want ? probably you may want to quickly test it out ? (if redeploy is needed)

[#3]

Okay looks like redeploy is not required https://community.apigee.com/questions/2665/target-server-configuration-changes.html#answer-2667 .

As @mukundha@apigee.com mentioned you can update the target servers dynamically if that is what you are looking at or see the other option I mentioned above .

[gnanasekaran]

One potential option is you could use Management API to update the TargetEndpoint dynamically,

For eg, you could do access the TargetEndpoint using

GET https://api.enterprise.apigee.com/v1/o/{orgname}/apis/{apiname}/revisions/{revision}/targets/{target...

So, get the response in JSON, update the response [add/delete/modify target servers] and then update it by posting it to,

PUT https://api.enterprise.apigee.com/v1/o/{orgname}/apis/{apiname}/revisions/{revision}/targets/{target...

{...updated target endpoint ..}

This will update the TargetEndpoint - no undeploy/deploy necessary

So, you could potentially have a provisioning script like this, and when you onboard your microservice or when it becomes available - it would self register using this provisioning script,

Thanks,

Mukundha

[#5]

Very clever Mukundha

I think the call should be made from Microservice to Apigee, or inclusive better creating a service in Apigee that interacts with Management API, keeping the admin level credentials secure and out of the control of the caller, limiting the access only to modify target servers of few services.

Doing this you can simulate Eureka or Consul (very limited simulation btw) and have Service Discovery using Self Registration pattern.

So, each Microservice instance when is up and working could self register in Apigree creating a new Target Server, or updating the one already created in the initial registration. (you can create a library to manage all these interactions and just import it in your microservice project)

This opens your solution to a lot of stuffs, for example you can add a shutdown/maintenance endpoint to your Microservice solution that calls Apigee asking to update the target server as "disable". Doing this you can do maintenance over the instance without impacting clients and also without touching Apigee each time..... many more things came to my mind 🙂