Private ELB for microservices

[isaa...@gmail.com]

Hi -

I would like to understand if having an AWS ELB deployed inside a private subnet in a VPC accomplishes something similar to having Eureka/Ribbon deployed in a VPC.

In other words, what are the advantages of using a Netflix middleware tier (Ribbon/Netflix) for micro-services which are not directly exposed to the public Internet over a private AWS ELB?

Eureka was open-sourced in 2012. I believe that, back then, AWS still didn't support ELBs sitting in front of private subnets. However, AWS has added support for private ELBs, so it would be good to understand the real benefits of having Ribbon/Eureka instead of just ELB.

Apologies if this question has already been answered before in this Forum. I did a lot of research and couldn't find any satisfactory answer.

Many thanks in advance

Isaac

[Nitesh Kant]

Hi Isaac,

This is a great question. 

Ribbon (client-side load balancing) provides a lot of avenues of doing much more intelligent load-balancing which ELBs do not do. We have developed algorithms like zone-awareness, zone-affinity which helps us in terms of resiliency in the wake of zone outages and other partial network partitions. This provides us enough benefits to not move all our mid-tier services behind ELBs inside VPC.

There are other reasons like,

-- Since, ribbon is integrated with eureka, it also becomes a powerful tool to control instance availability via external administrative tools. eg: for debugging purposes, if you wish to isolate an instance, you can set that instance as Out of service in eureka & ribbon will stop sending traffic to it. This is a pretty useful feature, which otherwise is hard to do with ELBs (you would have to manage the healthcheck of the instance to take it out of service)

-- Introducing an ELB, introduces an extra network hop without adding significant benefits otherwise.

-- In the future, we are looking at using binary protocols between our micro-services and having an ELB in between is again a hindrance (specifically in terms of handling application level back-pressure) without adding significant benefits.

Looking at the above scenarios, it is much more useful to keep the control with our clients in terms of how to balance load between different service instances and having an ELB, reduces that control.

Having said the above, having an ELB in front of micro-services greatly reduces the complexity and if the reasons above do not apply to your deployment, choosing to front all your micro-services with an ELB will be a good idea.

--
You received this message because you are subscribed to the Google Groups "eureka_netflix" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eureka_netfli...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Isaac Pereira Tavares da Silva]

Hi Nitesh, 

Thank you so much for your comprehensive answer. 

So it seems the combination of Ribbon/Eureka offers more resilience/transparency than just using ELB. 

You also mentioned that ELB introduces an extra network hop. However, wouldn't the same happen in case a microservice made a remote call to Eureka in order to find/retry a specific service?

Best,

Isaac

[Nitesh Kant]

>> However, wouldn't the same happen in case a microservice made a remote call to Eureka in order to find/retry a specific service?

Eureka calls are background tasks, they are not made inline with user request processing. 

[Isaac Pereira Tavares da Silva]

Great, that's good to know.

Thanks once again