Service-oriented architecture is one reason why Amazon dove head-first into things that would lead them to create AWS.
Couple SOA with "two-pizza teams" (a team isn't any more larger than could be fed with two pizzas) and "single-threaded owners" (complete authority and autonomy to build or buy anything that meets business needs, even if it is duplicates efforts of another team), you've got yourself an org structure similar to that of Amazon's.
As someone who has been at amazon for a bit and has been a single threaded owner (STO) for a few different things, autonomy and authority part is largely overstated in many orgs. In reality, most groups still have cross-functional overhead to get folks to agree to anything in many of the orgs I've seen and you have slightly more weight on the matter but still are expected to get this cross-functional agreement in many cases since functional leaders still exist. I no longer believe the phrase STO when it's used unless this leader clearly has the cross-functional team members reporting to them as well or the authority to move quickly without having to talk to their senior management.
I always assumed STO was as much about “this person has only one job [rather than 50% on each of topics A and B]” as it was “this person can decide whatever they think is best for topic A”.
That's the single threaded part, but it is also meant to be the proper "owner" in order to move quickly, but the bigger organizations get, the less that part ever actually happens and instead you get decision by committee which is inherently slow and usually sub-optimal since all decisions are negotiations. This is also where my favorite jeff b. quote comes into play (though it is sadly ignored more and more nowadays): "even well meaning gatekeepers slow innovation"
Ah; thanks, that makes a ton of sense. We've struggled with both "halves" of that phrase at different times, but recently we've done better on the O and are still weak on the ST part, so I was overly-focused on the most acute painpoint for us.
Let's say each pizza is eight slices, and each person eats two slices. So, a team should only ever be around eight people. Personally, as a former manager, I've found the sweet spot to be 6 people for software.
It varies, but a large pizza will generally be 14", 16" or 18". All three sizes seem to be commonly used, although 18" is generally more associated with New York or New York style pizzas; 14" is generally more associated with the big national chains.
Diameter of 14" = 35.6cm = an area of 993 cm^2.
Diameter of 16" = 40.6cm = an area of 1.3k cm^2.
Diameter of 18" = 45.7cm = an area of 1.6k cm^2.
And down thread someone from Germany says large pizzas there are 26cm, which would be an area of 531 cm^2. That's less than a third the size of an 18" pizza!
> Micro services and SOA are actually different things, despite sharing similarities.
Fair point. Looking back, I think I should've made it clearer, what I was trying to convey there was for the sake of this article I was using them as similar paradigms of design. However, as you've pointed out they are not the same thing.
Microservices are (a form of) SOA; but SOA does not necessarily mean microservices.
The term "microservices" is not as much bad as misunderstood (which, in a way, means that it is bad): it is commonly believed that it implies each service to be "micro" in the size of the codebase. In fact the "micro" refers to the responsibilities/functionalities a service is supposed to provide. Of course, that is more difficult to measure, as the service boundaries are often not obvious.
100%. One of the most important elements of executing SOA successfully is where you draw service boundaries. Microservices (as the name implies) encourages you to make your services very small, which often/usually has the effect of drawing very poor service boundaries. Finding the right service boundaries has everything to do with domain design and nothing to do with size.
>Micro services and SOA are actually different things, despite sharing similarities.
What would you say the differences are? In my mind, its mostly SOA with the idea that there's no lower bounds on service size. I do agree that people mistake that meaning microservices have an upper bound in size.
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..
TLDR: Micro services offer a REPL like experience for application architecture.
The way I see it, micro-services are the architectural analogues of functional programming. They let me build pieces of an application similar to a function, including tests and debugging in isolation without the fear of unintentionally messing up data somewhere.
This similarity to functions even extends to how micro services are used, calling their API's with keyword arguments e.g get post name id json etc
If you don’t mock out an RPC call in a microservice it has the same implications as not mocking out a database query in a monolith. I’d argue microservices actually encourage testing in isolation which can increase risks when you do ship (assuming you don’t have e2e or integration tests, which can also be more complicated with microservices).
I’m not arguing either way is right or wrong, but I disagree that microservices inherently makes things easier to test. Isolated tests actually implies you tested the lego bricks but not the overall assembly, which would potentially imply higher risk.
It’s also possible to write microservices that are architected in a way contrary to FP, such as having services that mutate their data stores, so I’m not sure id compare microservices to functional programming either.
You compare services to functions, which they are, only with the added complexity of dealing with distributed nature of it. I’m not obviating the benefits, but I disagree microservices are the automatic win you imply.
I would instead attribute the benefits you mention to having good abstraction, whether that’s functions or classes or services, abstractions allow you to isolate mock and reason in isolation.
For instance, the article mentions microservices are supposedly better so a change to your service doesn’t cause spooky action at a distance. I’m not buying this. In a poorly done microservices architecture emitting events can indeed cause spooky action at a distance, especially if you invested heavily into isolated testing only. It is easier for a monolithic architecture to shift boundaries, and in a microservices architecture it is possible (and in my experience common) that changes will need to be made across boundaries
You make fair points in that micro services are not a silver bullet, the functional wins I perceive aren't automatic and I intentionally build a service in that way to get the functional benefits.
So yes there is a caveat, if a service doesn't return the same output for the same input then some benefits of the approach are lost. I would like to add an additional benefit for teams of programmers, in that each team gets the ability to build out a service using whichever technology they find suitable i.e language, frameworks etc. Something I personally find difficult to do with a monolith.
Couple SOA with "two-pizza teams" (a team isn't any more larger than could be fed with two pizzas) and "single-threaded owners" (complete authority and autonomy to build or buy anything that meets business needs, even if it is duplicates efforts of another team), you've got yourself an org structure similar to that of Amazon's.
Refs: https://archive.is/lWPof | https://archive.is/tBpsj
Also: https://www.goodreads.com/en/book/show/53138083-working-back...