Eureka service discovery

[Kirk James]

Hi all, I'm approaching to the study of Spring Eureka Server relatively to a microservices architecture.

Basically, as far I understood, the main purpose of Eureka is to discover each registered microservice's address that meanwhile pings the Eureka server to notify it that is available.

So, I was reading some articles about it, trying to understand why we need a service discovery in our architecture, and I faced some doubts about the service scaling process:

Nowadays, on a cloud platform, it is obvious that all the servers or containers use dynamic IPs for autoscaling. And the interesting thing is that in microservice architecture, the key principle is that your service can autoscaled as per load, so cloud platforms are ideal for microservices. (...)
We can not predict the IP addresses of the container/server beforehand, so putting dependent services IP addresses in the config file is not a solution. We need a more sophisticated technique to identify the service, and Eureka server steps in here.

Can someone explain me these last two sentences about the autoscaling process and its relationship with a cloud platform?

Thanks.

[Rob Spoor]

Consider you have a microservice that you use. There is one instance deployed, and you talk to that directly. After a while, your demand increases and a single instance just can't cut it, so you add a second instance. However, now you must change your application to support both instances, or put a load balancer (Apache, Nginx, etc) in front of it. You can do that, but once you need a third instance you need to go through this process again. (If you use a load balancer, you must update its configuration).

With service discovery, each instance registers itself. Your application is a client of the discovery service. When it needs to access the microservice, it asks the discovery server for an instance to talk to. You don't need to configure all the separate instances, only the discovery service. If a new instance is added, it registers itself again, and the discovery service will automatically make it available for you.

[Kirk James]

Rob Spoor wrote:Consider you have a microservice that you use. There is one instance deployed, and you talk to that directly. After a while, your demand increases and a single instance just can't cut it, so you add a second instance. However, now you must change your application to support both instances, or put a load balancer (Apache, Nginx, etc) in front of it. You can do that, but once you need a third instance you need to go through this process again. (If you use a load balancer, you must update its configuration).

With service discovery, each instance registers itself. Your application is a client of the discovery service. When it needs to access the microservice, it asks the discovery server for an instance to talk to. You don't need to configure all the separate instances, only the discovery service. If a new instance is added, it registers itself again, and the discovery service will automatically make it available for you.

Thank you for your reply.

Going in deeper, what's the role covered by a load balancer and Zuul proxy server in this kind of workflow/structure  (that basically is the kind of architecture i'm trying to understand more)?

[Rob Spoor]

I don't know the Zuul proxy server, but with a discovery service you don't need a load balancer, the discovery service can take care of that. A load balancer is often used instead of a discovery service, but it usually requires manual adding and removing of available nodes.