Baking those potatoes with microservices and vendors
There's this notion of hot or cold potato routing that I picked up while learning about how the Internet backbones work. Let's say you have two large backbone providers and they interconnect in multiple places. Then, there's someone who opens a connection from one side of the country to the other that involves both networks. What happens next? Magic.
It has to do with how long the packets travel on the source network before being handed off to the destination network. Maybe you're on Comcast on the west coast, and you're talking to a Level3-connected host on the east coast. Both Comcast and Level3 have significant networks spanning the country, and they have peering in multiple places.
In a purely "hot potato" world, your packet leaves your network, goes into Comcast, and at the first opportunity to go into Level3 (probably rather close to you, like in the same region), it does, and Level3 takes it the rest of the way - all the way across the country. Then, conversely, the response switches from Level3 to Comcast as soon as it can, and rides all the way back on Comcast.
What about "cold potato" world? That's where the packet leaves your network, rides Comcast all the way to the east coast, then finds its way into Level3 and is soon at the destination. The response rides Level3 all the way west, hops over to Comcast, and then comes to you shortly thereafter.
Why one and not the other? It's probably multiple things: engineering design issues, capacity issues, and honestly, economic and even political issues between the companies. Imagine if one side always hands off early (hot) and the other side always takes things as far as possible (cold). That would put both sides of the long-distance transit stuff on a single network, and that might raise concerns of fairness.
This, then, is why sometimes I refer to things as "hot potato" situations, even if they aren't necessarily about Internet backbone routing problems. It can also apply to people, or projects, or teams, or even entire companies. It can turn into their default method of operation, unfortunately.
When handed a task, does the person always try to do all of it no matter how far it needs to go (cold potato), or do they always try to get rid of it right away (hot potato), or are they somewhere in-between? That's what I'm talking about.
The "always hot potato" crowd are the ones that tend to bother me. It seems like they are always looking for some way to get the problem out of their hands. In the tech support world, they are the ones who would ask some stupid question of the customer and set the ticket to "require feedback" instead of trying to answer it themselves with five minutes of sniffing around. It let them look like they did some work even if they had no idea what was going on. Do this long enough and they'll run out of day before they run out of tickets to do. Their time is spent waiting for responses and not ever really doing anything.
You can see this with services, too. If you have a user who talks to your service A, and then your service A talks to service B run by some other team, the hot potato response to any user question is to say "well, maybe B is having an outage". Then they usually put the request on hold, and kick off a request of their own to B to see what's up, and do nothing while waiting to hear back. Meanwhile, the user is screwed.
So here's the thing: the smaller your service is, the more likely it will talk to someone else to do something. That gives you a lot more transitions between groups of people: call 'em edges, borders, or interfaces, but it's basically an opportunity to hot-potato something across it to someone or something else.
This means if you have lots of tiny services, you now have tons of edges. If every edge represents an opportunity to eschew responsibility and push it onto someone else, it might be a wonderful place for someone who's only good at routing requests around and not actually DOING anything.
Now, of course, in a microservices world inside a company, you're all supposedly working for the same cause, with a common boss somewhere up the line. In theory, you might be able to use that to get leverage. But, in practice, there are fiefdoms and evil directors, and lines that will not be crossed by anyone. Good luck.
So what do you suppose happens when those edges go cross-company? That's like the mother of all gaps in terms of responsibility. Nobody on your side of it has any idea what's really going on at vendor Q with service X. If there's any way to blame them, the hot potato folks are going to be all over that shit. What do you expect? It's like pouring sugar water everywhere: you're going to get all kinds of weird creepy crawly things showing up to get their piece of the action.
I guess I shouldn't be surprised this stuff is so popular, then.
Do you have to be a weenie who gives up on your users when you have microservices and/or vendors? Absolutely not. Is it very easy to, though? It sure can be. Ultimately, it's a matter of discipline and rigor on the part of the people who are doing the job. If they care a lot, it won't happen.
If they don't, well, hoo boy, look out below.