1

I have heard this term many times, and it makes sense in theory. That app is doing many things and it'd be easier to manage, scale, test and improve them if they are not completely connected to each other and work like functions instead. This way you could have option to even easily replace components of app with different languages easily as long as output remains consistent.

However i dont get this idea practically, how is it constructed. Impression i get is that all microservices talk to each other using JSON/Auth/API and share database.

Is it true? it makes sense too, but what about performance hit. It's certainly faster to send data from one controller to another in same app then have it go to another server and be refetched form database.

What about streaming. Is streaming possible between api calls instead of fetching from database?

won't authentication step between microservices further slow it down? is authentication between servers/microservices even needed.

do microservices running on same server need to talk to each other using api, even though they are on same machine..

Where can i learn more about this.

3

A few assumptions:

  • Microservices can communicate between themselves
  • Implementations of each microservice are not relevant to the external world (this is even easier when abstracted into a container)

Imagine a client/server interaction, the client/server might communicate with a JSON API. Or a message broker. The specific implementation does not matter, the important part is that:

  • Both use the same protocol for communication
  • From the client's perspective, how the server is implemented doesn't matter
  • From the server's perspective, how the client is implemented doesn't matter

There will always be a basic level of coupling between even microservices. The communications tool has to in some sense be coupled. Services will also be coupled, to a lesser extent, but practically speaking will have varying levels of coupling.

You could have a client written in Java or C++ or assembly, as long as that language implemented the communications protocol. Same for the server.

This effectively decouples the implementation of either, except utilizing the same communications API. This is a huge benefit. Your server/client can run on the same machine. Or different machines. Maybe you want two servers and one client. Or one server with tons of clients. Because it's all separate you can do this.

To do this the microservices have to be able to communicate through some API/message system. Even if they are running on the same machine.

Also, as a note, proper versioning of your microservices is important. If you have a minor release on the server you should not break a client (and vice versa). There will always be some level of inherent coupling between any client/server interactions as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.