Building new tech solutions is intellectually fun and gets people promoted. Migrations and support are hard and can be way more valuable in the long term, but are rarely recognized or rewarded at some big co's.
I've heard this phenomenon called promotion-oriented architecture.
It sounds like it's working really well to expose an organizational failure. As soon as you have "A owns service, B asks A to build feature, A won't" that has nothing to do with SOA and it's instead about how you prioritize work. Whoever owns the business priorities will have to make the call on what happens here.
I’m not saying SOA inherently makes it worse. I’m saying SOA still comes with its own costs.
> It sounds like it's working really well to expose an organizational failure.
Exactly. But there’s a belief that having individual services leads to efficiencies because everyone is decoupled and works across established contracts.
The reality of the game is far more complex. While it is an organizational problem, at scale the organizational issue is also hard to resolve because of competing goals and priorities.
But to analyze SOA, we have to consider this reality. Looking at SOA as a silver bullet in a vacuum is near sighted - that’s all I’m trying to say.
> Whoever owns the business priorities will have to make the call on what happens here.
In large, distributed organizations, there often isn’t a single person, or the common owner is much higher in the org tree that people don’t want to go to them. We can call that a management failure, but that’s not the point. In reality, this inefficiency burns out engineers and leads to a lot of churn. And this is a ground reality in at least two of the companies whose products you most likely use every day.
Yeah that's actually exactly my point.
> And this is a ground reality in at least two of the companies whose products you most likely use every day.
Yeah, those companies suck organizationally.
These companies are viewed as exemplars of operating at scale. If they're failing at this, there's a deeper problem that requires a second look. Saying these companies "suck organizationally" isn't productive or helpful.
My main point was SOA comes with its own set of issues when you implement it at large scale. You're talking around me instead of listening to what I'm trying to communicate. I'll stop engaging with you since it's not productive.
I mean we can just talk openly about the companies - like are we talking Google? Because I don't know anyone who thinks Google is organizationally functional.
Your post is basically a description of the aftermath of this situation. Which is accurate. But the solution isn't in the description of the aftermath.
We don't know what the service does, why team B doesn't want to address team A's needs, can team A use something else and so on.
Things need to be owned by specific teams, because otherwise the codebase turns into a mess of ad-hoc patches concocted with little to no domain insight on the service being edited.
Service B: We built a distributed storage system. You can append to files, and you can read at a given position from finalized files, and that's it.
Product A: We'd rather have an ACID database.
Service B: lol, fuck off.
Product A: reads some distributed systems papers, improves their design OK, we now realize that these primitive operations are sufficient.
My philosophy here is informed by regular attendance for years at the gmail SRE design review, where typically some guy from Search would come around and say something dumb like "send us every message for universal indexing" and gmail leadership would say "LOL no. fuck off." Then a few months later they'd come back with something better like "compute for us these privacy-protecting index fingerprints for universal search" at which point you can start to say yes. I don't see the value in immediately capitulating to what other service owners claim to need, especially when your first allegiance has to be to your own userbase.
Team B had other priorities, didn’t want Team A touching their code, didn’t want to think about who would support the changes, didn’t want to perform the code review when a developer from Team A sent in the pull request. Team B also didn’t want to implement the features themselves.
Now imagine this occurs at scale, and you literally have entire organizations whose developers work in services owned by other teams, who cannot deliver on time because of these issues out of their control, and they’d just quit and work somewhere else.
As far as I know, that company still hasn’t found a way to solve this problem.
One solution may have been to rearchitect the services and use some kind of federated model to decouple each teams needs - so they can share what they need and have physical/logical separation in the areas where they diverge.
But directors and management are under the gun to deliver things. Investments in rearchitecting? GTFO.