Service oriented architecture isn’t a silver bullet though. In at least one of the big tech companies I worked at, team A would need to make changes or add features to some service owned by team B.
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.
The investment in rearchitecting also happens when it's a big enough problem that team A builds their own solution to team B's service. Then team B either loses a big internal customer and their service slowly dies out as engineers flee to greener pastures. Or both teams support different ways to solve the same problem and the big picture problem becomes even more complex.
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.
How does SOA make this worse? The alternative is I guess that no one owns things, so team A could have touched the code, and then no one wanted to maintain it so it would have accrued as debt?
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.
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.
> These companies are viewed as exemplars of operating at scale.
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.
> In at least one of the big tech companies I worked at, team A would need to make changes or add features to some service owned by team B.
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.
I think service-changing requests should be passed to a higher level in the chain, to the architects or whatever, changing service contracts can end up changing the domain. I'd assume the architects would have a high level view where they can instruct teams whether to prioritize the requested change, delay it or just veto it completely
Microservices will not solve the fundamental problem that developers don't know how to implement things / can't ship features fast / can't work together / can't communicate properly. These are "people problems" which you can't always solve with technology.
Sounds healthy to me. I've definitely seen it work. Saying "no" to people who want changes in Service B can be the right thing for the future health of the entire company. E.g.
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.
in large companies most of the times its not as simple as that, lets say Service A uses data exposed by Service B. Now Service A wants to add few more data to Service B's response, however Service B is not interested in adding that as it's not in their priority list. Now Service A is stuck waiting for Service B to provide that. It happens at scale as well. That's one reason enterprise analysts spend hours on phone. As their system is dependent on multiple other systems from other departments. Navigating that at scale is tough.
There’s nothing technical about that, though. If there’s some data that a product needs which can only be produced by another team with an interface that does not yet exist, the alignment has to be at the executive level. Either the product with the need gets engineering resources from the other service, or it doesn’t launch.
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.
of course yes in product companies or tech companies that can happen. in large banks for e.g. its more difficult, as different departments are run pretty much like different companies. you can eventually align things either at peer level or from executive level but would take lot of time. its not a problem of SOA per se, but overall friction/inertia inherent in large orgs..
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.