Email or username:

Password:

Forgot your password?
Robert Roskam

Microservices are not inherently more organized than monoliths.

I’m continually amused that people think if you force network calls that organization will naturally appear.

2 comments
Bill Caputo

@raiderrobert

microservice architectures give the illusion of legibility in multi team organizations—this is highly prized by those in more central roles as it gives them more influence over local (ie intra-team) decisions.

Traditionally, the monolith (complete with cutsie/nerdy code name) left extra-contextual parties feeling in the dark about team level activities—microservices provided such folks with intra-team leverage (tho little if any improved understanding) all for the “tiny” cost of additional complexity and coordination at the maker level. This manifests in the both the design and delivery speed of the teams.

IOW the issues have never been in the technical tradeoffs (cf Unix way) but in how this mechanism shifts technical decision making from local/team authority (where the most contextual knowledge lives) to extra-team interests. Microservices enables this due to this increase in perceived legibility.

Of course, we as an industry continue to argue about general technical superiority semantics on this topic because we still believe in technical silver bullets, and ignore the socio-political context of the organization and how it shapes technical decisions. Hopefully we’ll solve this myopia in another generation or two!

@raiderrobert

microservice architectures give the illusion of legibility in multi team organizations—this is highly prized by those in more central roles as it gives them more influence over local (ie intra-team) decisions.

Traditionally, the monolith (complete with cutsie/nerdy code name) left extra-contextual parties feeling in the dark about team level activities—microservices provided such folks with intra-team leverage (tho little if any improved understanding) all for the “tiny” cost of additional...

Matthew Martin

@raiderrobert The organizational improvement comes from forcing one chunk of code to not take a dependency on every internal of another.

If you have 10 developers and 20 files in one repo, over time, the developers will attempt to make imports & distribute code so that that all 20 files depend on all 20 files & nothing can be changed without risking breaking all functions in all 20 files.

I'm skeptical of monorepos because they make it easier to modify 20 microservices and treat them all as 1

Go Up