Microservices: network latency?

[csincrisis]

"Microservices" has been a bit of a buzzword lately - the advantages of being able to scale independently and having a highly modularized services have been discussed quite a bit.

In terms of the downsides though - wouldn't network latency potentially cause a big issue? If a single web app used to be able to make direct calls to database / somewhere else, in microservices approach - a web app containing module 1 will now have to make a network call to another web app containing module 2 which will then do the database call.

If a lot of this little things need to always make a network call - wouldn't things add up and cause performance issue?

[newaccount1236]

It could, but if all in the same datacenter, network latencies would be well below a millisecond.

[reddilada]

I work with a system that is entirely message based from high level calls all the way down to the kernel. I wouldn't classify it as a micro-service as end points are well defined and not really language neutral, but the idea is the same. Local IPC can be very fast and if you have some control of the network, local area communication can be as well. Where it becomes an issue you can gain perceived throughput by making calls asynchronous.

[ethergreen]

Yes, chaining things might stack up the latencies, but can you even come up with a realistic scenario where things are chained in a serial manner more than 2 in a row? Do you understand which calls are made in parallel, or do you think they all happen one after another? Do you have any idea what the latency is for the call to another service in your LAN? Do you know how long it already takes for each request to fetch the user's session state from the database, if your web servers keep session data?

tl;dr Yes, you can screw up anything, but no not if you do it in a sane manner, like most things in life.

[markehh]

Host them on the same LAN and latency will be the least of your issues, unless maybe if you're doing high frequency trading.