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

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.

Hi all, I've a question about the database schemas, hope it's the right place.

What raised at his time the needs to have schemas for our databases? Basically, how can be defined a database schema and how we can make "speak" each other different schemas in our database?

"Bonus" question: In a microservices architecture application, should each microservice have his own schema and should communicate with other schemas without speaking to other microservices? What could be a good approach if from the microservice A I want to retrieve information from a schema referred by the microservice B (example, Address microservice speaking with the User microservice).

Thanks for your help and sorry for any mistake.