0

Can micro-service interact with downstream service through localhost origin, since my all service is running in same server is that is correct approach ? I found that interacting a downstream service with domain name takes much time when compared to localhost. i was curious to know whether we can do like this ?

ankithvicky
  • 25
  • 9

3 Answers3

3

You're right, you can communicate with other services running in the same host with localhost. It's completely fine and when thinking about network round trips, it's beneficial.

But,

  1. what if you want to scale the services?
  2. What if you want to move any of the services to a different host?

While considering at least these scenarios, binding to a specific host is not worth. And this is applicable if you are using the IP of the host.

*I found that interacting a downstream service with domain name takes much time when compared to localhost.*.

I see what you're saying.

Microservices architecture is not a silver bullet for software development design and always come with tradeoffs

And about your deployment strategy Multiple Service Instances per Host pattern.

  1. How you are going to handle if your services have different resource requirements?
  2. say what if one of your services is utilizing all the host resource?
  3. What if you need to scale out one independent service?
  4. How you are going to ensure the availabilities of your services?
  5. ..
  6. ..

So there are so many questions you must consider before going with a pattern in microservices. It all depends on your requirements.

Sam
  • 4,046
  • 8
  • 31
  • 47
0

If your services are on the same server you should using a message broker or mechanism like grcp to talk between your services so doesn't matter if your orgin is. If you are using HTTP to communicate between your micro services then it totally not gain any advantages of micro services architecture and your architecture is flawed.

Jeyenth
  • 472
  • 4
  • 10
  • I appreciate your answer. But I wonder how an HTTP communication is against advantages of microservices. And how the origin/service address doesn't;t matter for a GRPC call? – Sam Dec 21 '20 at 21:55
  • Sam, I just realized that my answer was so vague, lazy and typed from my mobile. By http communication I mean the fully qualified url eg., my.api.com/service which would actually take a full round trip when you service is available on the same machine. Origin address doesn't matter when the communication happens on a pub/sub message broker in a vague sense. :P I think your answer is very elaborate and appropriate to the question. Thanks for your feedback! – Jeyenth Dec 22 '20 at 15:09
0

Microservice is a concept, it does not force you to where you deploy your application and how they might call each other. You may deploy your microservices on different virtual machines that are hosted on the same physical server. The whole point is you need to have a reason for everything that you decide to do with your architecture. The first question is why you have split your application into different microservices? for only carrying the word of microservice on your architecture or having better control on the business logic, scalability, and maintainability of the project? These are important things you need to take care of them when you are designing an application. draw the big picture of your product, how it's going to be used. which service/component is mostly being used by the customers, does keeping it with other microservices on the same server makes performance issues or not? what if any issue happens to the server and whole applications would be unreachable.

Soroosh Khodami
  • 1,185
  • 9
  • 17