9 ms·

Service-Oriented vs. Monolith: Organizational Perspective

68 points by gtoprak 5y ago

tracer4201 5y ago
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.
- bestcoder69 5y ago
  away teams at amazon?
- staticassertion 5y ago
  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.
  - tracer4201 5y ago
    > How does SOA make this worse? 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.
    - staticassertion 5y ago
      > We can call that a management failure, but that’s not the point. 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.
      - tracer4201 5y ago
        >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.
        5y ago
- stadium 5y ago
  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.
- jeffbee 5y ago
  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.
  - murukesh_s 5y ago
    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.
    - jeffbee 5y ago
      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.
      - murukesh_s 5y ago
- mohbk 5y ago
  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
- deleted 5y ago
  [deleted]
- slver 5y ago
  > 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.
- kissgyorgy 5y ago
  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.
cygned 5y ago
> So far in the article, I’ve been using service-oriented and microservices as interchangeable terms. They are the same thing, I believe Micro services and SOA are actually different things, despite sharing similarities. > however microservices term does lead some to believe each service to be micro in size Yeah, the name is actually a bad one.
- gtoprak 5y ago
  > 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.
- slver 5y ago
  Saying they're different, but not saying how (according to you) is honestly not very useful. Especially when no one defines these terms the same way, so it's not like I can go and find and compare definitions.
  - IshKebab 5y ago
    It's as bad as REST.
    - deleted 5y ago
      [deleted]
- ajsharp 5y ago
  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.
- jayd16 5y ago
ignoramous 5y ago
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. Refs: https://archive.is/lWPof https://archive.is/lWPof | https://archive.is/tBpsj https://archive.is/tBpsj Also: https://www.goodreads.com/en/book/show/53138083-working-backwards https://www.goodreads.com/en/book/show/53138083-working-back...
- wdb 5y ago
  Two-pizza teams? How big are there pizzas in the US?!?
  - TranquilMarmot 5y ago
    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.
    - slver 5y ago
      Not coincidentally we're centering around a similar number of cores per processor.
  - k__ 5y ago
    I once read somewhere that a two pizza team is 5-10 people. So, I assume the pizzas in the US are pretty large. Our "large" pizzas here in Germany have a diameter of 26cm. I usually eat one of those on my own.
    - dragonwriter 5y ago
      > Our "large" pizzas here in Germany have a diameter of 26cm. IME, That’s about a typical US small pizza (10”; large is typically 14” though I've seen places that use 12”/14”/16” S/M/L.)
thatspartan 5y ago
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
- joshribakoff 5y ago
  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
  - thatspartan 5y ago
    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.

68 points by gtoprak 5y ago

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.

bestcoder69 5y ago
away teams at amazon?
staticassertion 5y ago
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.
- tracer4201 5y ago
  > How does SOA make this worse? 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.
  - staticassertion 5y ago
    > We can call that a management failure, but that’s not the point. 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.
    - tracer4201 5y ago
      >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.
      - 5y ago
stadium 5y ago
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.
jeffbee 5y ago
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.
- murukesh_s 5y ago
  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.
  - jeffbee 5y ago
    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.
    - murukesh_s 5y ago
mohbk 5y ago
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
deleted 5y ago
[deleted]
slver 5y ago
> 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.
kissgyorgy 5y ago
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.

cygned 5y ago

> So far in the article, I’ve been using service-oriented and microservices as interchangeable terms. They are the same thing, I believe Micro services and SOA are actually different things, despite sharing similarities. > however microservices term does lead some to believe each service to be micro in size Yeah, the name is actually a bad one.

gtoprak 5y ago
> 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.
slver 5y ago
Saying they're different, but not saying how (according to you) is honestly not very useful. Especially when no one defines these terms the same way, so it's not like I can go and find and compare definitions.
- IshKebab 5y ago
  It's as bad as REST.
  - deleted 5y ago
    [deleted]
ajsharp 5y ago
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.
jayd16 5y ago

ignoramous 5y ago

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. Refs: https://archive.is/lWPof https://archive.is/lWPof | https://archive.is/tBpsj https://archive.is/tBpsj Also: https://www.goodreads.com/en/book/show/53138083-working-backwards https://www.goodreads.com/en/book/show/53138083-working-back...

wdb 5y ago
Two-pizza teams? How big are there pizzas in the US?!?
- TranquilMarmot 5y ago
  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.
  - slver 5y ago
    Not coincidentally we're centering around a similar number of cores per processor.
- k__ 5y ago
  I once read somewhere that a two pizza team is 5-10 people. So, I assume the pizzas in the US are pretty large. Our "large" pizzas here in Germany have a diameter of 26cm. I usually eat one of those on my own.
  - dragonwriter 5y ago
    > Our "large" pizzas here in Germany have a diameter of 26cm. IME, That’s about a typical US small pizza (10”; large is typically 14” though I've seen places that use 12”/14”/16” S/M/L.)

thatspartan 5y ago

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

joshribakoff 5y ago
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
- thatspartan 5y ago
  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.