[HN Gopher] Service-Oriented vs. Monolith: Organizational Perspe...
___________________________________________________________________
Service-Oriented vs. Monolith: Organizational Perspective
Author : gtoprak
Score : 63 points
Date : 2021-05-09 14:21 UTC (8 hours ago)
(HTM) web link (p99th.substack.com)
(TXT) w3m dump (p99th.substack.com)
| tracer4201 wrote:
| 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.
| [deleted]
| bestcoder69 wrote:
| away teams at amazon?
| slver wrote:
| > 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.
| stadium wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mohbk wrote:
| 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
| kissgyorgy wrote:
| 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.
| staticassertion wrote:
| 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.
| ignoramous wrote:
| 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/tBpsj
|
| Also: https://www.goodreads.com/en/book/show/53138083-working-
| back...
| wdb wrote:
| Two-pizza teams? How big are there pizzas in the US?!?
| TranquilMarmot wrote:
| 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 wrote:
| Not coincidentally we're centering around a similar number
| of cores per processor.
| Lazare wrote:
| 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!
| k__ wrote:
| 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.
| U1F984 wrote:
| Seems to be regional then; a large pizza in my area is 32
| cm.
| dragonwriter wrote:
| > 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.)
| infogulch wrote:
| 12"/14"/16" ~> 30/35/41 cm. Also note that area is
| proportional to the square of the diameter.
| leetrout wrote:
| Area of a circle is Pizza
|
| Given a radius of z:
|
| Pi*z*z=a
| jbverschoor wrote:
| Gold
| hawk_ wrote:
| brilliant! source? or did you just make it up?
| leetrout wrote:
| No -- I think I read it on here some while back. So
| simple and easy to remember; I love it and love repeating
| it!
| dbish wrote:
| 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.
| sokoloff wrote:
| 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".
| dbish wrote:
| 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"
| BiteCode_dev wrote:
| TIL I'm almost a team by myself.
| thatspartan wrote:
| 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 wrote:
| 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 wrote:
| 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.
| cygned wrote:
| > 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.
| BerislavLopac wrote:
| 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.
| gtoprak wrote:
| > 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 wrote:
| 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 wrote:
| It's as bad as REST.
| [deleted]
| ajsharp wrote:
| 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 wrote:
| >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.
___________________________________________________________________
(page generated 2021-05-09 23:01 UTC)