I don’t mean to be snarky but how is that an “unexpected consequence”? Were the pros and cons just never considered when deciding to use micro services? Additional networks calls are one of the most obvious things to go on the cons list!
This is one of the reasons I dislike working in teams that lack 'old people'. Young devs still have a lot of mistakes to make that old devs have already made or seen. The young ones seem to see them as slow and difficult, but they also create stability and control.
In a start-up, having a team of young people will allow you to move fast, pivot and deliver. What you usually end up with though, is a tower built from spaghetti that's serving actual users. I see this again and again and then people get surprised that the software doesn't scale.
My experience of being the old guy in the team (older also than the manager) was that the young whippersnappers[0] drive new tech adoption regardless of the views of the old fart; the manager waves it through to keep the young-un's happy, and the old fart doesn't find out until it's a fait accompli.
My experience was also that the young manager was very suspicious of the old fart. I've never had any problem working for managers younger than me; but some young managers don't know what to make of a team member that knows more than they do.
[0] No insult intended; almost everything I learned after the first 10 years, I learned from people younger than me.
I'm so conflicted over becoming an older engineer (having recently moved back from a leadership role). On one hand, I have a wealth of knowledge and can see around corners that the youngsters have no chance of doing. OTOH, it is absolutely exhausting explaining in excruciating detail why I am right time-after-time as new mids join who just want to experiment. That and I am absolutely petrified of my alacrity fading with time.
I hear ya. If you feel you've lost your perspicacity, fear not; it's always in the last place you look.
But... yeah. A colleague (25+ years) has to deal with this more than I do, but have hit it some over the years, and it happens more the older I get.
Often he or I may be 'right' but only because of existing constraints in a system. Someone with a different view may even be 'correct' in a nuts-and-bolts technical sense. Yes, A is 8% faster than B. But... we have an existing system in B that meets our current needs, and team who know B, have written it, and maintained it for a couple years. Switching tech stacks to something no one knows for an 8% network speed boost is not remotely helpful.
You are right, looking back I also ask why it was not considered more indepth before. I was not involved in the decision making process as I recently joined, and to be honest I would have maybe not thought about it either (but will certainly in the future). I think the main reason this became such a big problem is because we underestimated the number of calls that would be made between the services. Service A was initally supposed to call Service B only as a last resort, so the 10 ms or so were fine, but in the end, the answers that Service B gave turned out to be very useful in our process so more and more calls were made and now they are strongly connected, but still separated services, which is ... not ideal.
Could this be solved by consolidating service A and service B into one unit while maintaining the overall architecture? I know it's just an example but the whole point of microservices is to have the flexibility to rearchitect pieces without having to rewrite the entire project, so potentially poor initial choices can be reworked over time.
Just wait until you decide you need some kind of distributed transaction support across multiple microservices… You should aim to spend a considerable amount of time in the design and discovery phases.
