It's not microservice or monolith; it's cognitive load • Hacker News Board

Re: It's not microservice or monolith; it's cognitive load

#61

Post by 8n4vidtmkvmk » Fri, Dec 29, 2023, 5:14 AM UTC

irjustin wrote: post #38

ddejohn wrote: post #30

Earlier quoted context omitted.

This strikes me as overly cynical. My current job is working with around 20 other engineers on an extremely bloated and coupled monolith. I'd love to be able to separate myself and my team from others by an agreed-upon interface. Yes, "agreed-upon" is certainly doing some heavy lifting there, but I don't think it's realistic to expect that > cross team meetings and project management every time you want to ship a fea…

> This strikes me as overly cynical. > My current job is working with around 20 other engineers on an extremely bloated and coupled monolith. I'd love to be able to separate myself and my team from others by an agreed-upon interface. > Yes, "agreed-upon" is certainly doing some heavy lifting there, but I don't think it's realistic to expect that This is overly cynical to you likely because you haven't experienced mai…

Standing up a service across the globe is non-trivial even with world class tools. You still run into issues like services not being properly co located with other services they need to call so you end up paying for inter continental hops. And cold connections because the new service doesn't have much traffic yet. And maybe DB leaders are only in North America so Asia has terrible perf.

Re: It's not microservice or monolith; it's cognitive load

#62

Post by Spivak » Fri, Dec 29, 2023, 5:33 AM UTC

gedy wrote: post #47

nateburke wrote: post #26

The moment you adopt service based teams with service based managers, say goodbye to engineers caring about working product. Say hello to cross team meetings and project management every time you want to ship a feature. It's pure vanity for a startup to think they will become the next AWS by adopting hard service-based contracts between teams.

The moment you adopt feature teams with feature managers, say goodbye to engineers caring about working infrastructure. Say hello to cross team meetings and project management every time you want to deal with anything platform related. I appreciate you qualified as for startups, but worked with plenty of former startups/scaleups that were bogging down rapidly due to infra or scaling issues. Since they were feature fa…

This doesn't ring true for me at all and I've dealt with the dreaded omni-rails stack (or worse the dreaded tomcat springboot stack). Monoliths are far far easier to scale because you have one throat to choke and performance patches / elimination of n+1's spread across the whole app. Also in a monolith unit tests have the power of integration tests in a microservice world. I can actually be sure the boundaries between components behave as I expect and fail loudly if they change in a manner that breaks me. And the last thing in the world I ever want to do for scaling purposes is stick a network call/serialization step between two pieces of my own app because that's a bottleneck waiting to happen.

It feels like a lot of people reach for microservices when they should be reaching for sharding and/or moving to reads to replicas (which you can finally do in Rails thank god).

Re: It's not microservice or monolith; it's cognitive load

#63

Post by chatmasta » Fri, Dec 29, 2023, 5:34 AM UTC

LarsDu88 wrote: post #55

Lets step back a second. If the rationale behind adopting microservices for everything is PURE orgitecture rather than software architecture, then that's not really a rationale at all. Instead of having one instance, you now have dozens of little service fiefdoms plus all the added network I/O overhead associated with that. The principled approach is really to simply not do that, for the basic latency costs. I mean,…

Maybe WoW didn't run on Microservices, but you can bet the project was divided into a bunch of different fiefdoms. Just they were separated at the interface level rather than the network level. Same concept though.

Ultimately if you've got different teams working simultaneously, they should be working on non-conflicting features. Microservice is just one architecture that develops within this constraint. You'll never get anywhere if everyone is working on the same interfaces with no separation of concerns. So where should the separation emerge, if not along the same lines as the existing IRL separation? Conway's law is not a coincidence; it's an inevitability...

Re: It's not microservice or monolith; it's cognitive load

#64

Post by jauntywundrkind » Fri, Dec 29, 2023, 5:34 AM UTC

I feel like we are going to spend many years coping with Team Topologies, a book which idolizes a seeming infinite and vast independence of teams from each other in the name of 'spending things up' or some such.

I love, respect, & cherish the ideas here. But the sound-bite ideas of the book vastly overweigh the practical complexities of development.

Yeah, giving each team authority to do their thing is desperately necessary today; there's too much organizational confusion & unclear decision making processes. Teams need autonomy. Yes. But the book really seems to have so little to say about how to play together. It doesn't talk hardly at all about how to find concordance & to make decisions across teams. What are good common techs to adopt? Microservices as I'm everyone can pick whatever (Haskell for this, pho for that, & 12 varieties of node) is one organizational end, monolith is another end. The confusion and angst Team Topologies let's dwell and build is infinite, because it's pretense is that there are many parallel streams of development and that inter-team work is a negative.

The books is so good and so important. Because so many orgs are fucked and doing things terribly. Cognitive load is massively over managed and it's impossible to do anything to escape the tar pit the shitty ancient overly established pretentious shitbag elders have dictated. But the result of what Team Topologies says is such an opposite and shitty fucked, where cognitive loads expand exponentially because every team is independent & fucking off into their own space, with only vague constraining behavior or nebulous "platform" teams that "support" or maybe dictate to these platforms teams.

Never have I seen a book I both respect so highly & think so terrible & awful.

Re: It's not microservice or monolith; it's cognitive load

#65

Post by jiggawatts » Fri, Dec 29, 2023, 5:35 AM UTC

3cats-in-a-coat wrote: post #10

The sad thing about these "monolith vs microservice" debates is that to this day we have programming languages which favor shared mutable state, so a program written like this is an absolute hell (or a very leaky abstraction) to distribute. And it doesn't have to be like this. Think about it. When your variable is a simple value, like a number or a string or a struct, we treat it as pass-by-copy (even if copy-on-writ…

Something I’ve wanted for a while now is a language / framework that behaves like networked micro services but without the network overheads.

E.g.: the default hosting model might be to have all of the services in a single process with pass-by-copy messages. One could even have multiple instances of a service pinned to CPU cores, with hash-based load balancing so that L2 and L3 caches could be efficiently utilised.

The “next tier” could be a multi-process host with shared memory. E.g.: there could be permanent “queue” and “cache” services coupled to ephemeral Web and API services. That way, each “app” could be independently deployed and restarts wouldn’t blow away terabytes of built up cache / state. One could even have different programming languages!

Last but not least, scale out clusters ought to use RDMA instead of horrifically inefficient JSON-over-HTTPS.

Ideally, the exact same code ought to scale to all three hosting paradigms without a rewrite (but perhaps a recompile).

Some platforms almost-but-not-quite work this way, such as EJB hosts — they can short circuit networking for local calls. However they’re not truly polyglot as they don’t support non-JVM languages. Similarly Service Fabric has some local-host optimisations but they’re special cases. Kubernetes is polyglot but doesn’t use shared memory and has no single-process mode.

Re: It's not microservice or monolith; it's cognitive load

#66

Post by the_gipsy » Fri, Dec 29, 2023, 5:39 AM UTC

3cats-in-a-coat wrote: post #10

The sad thing about these "monolith vs microservice" debates is that to this day we have programming languages which favor shared mutable state, so a program written like this is an absolute hell (or a very leaky abstraction) to distribute. And it doesn't have to be like this. Think about it. When your variable is a simple value, like a number or a string or a struct, we treat it as pass-by-copy (even if copy-on-writ…

They are a constant sources of bugs, but it's not really an architecture matter.

Re: It's not microservice or monolith; it's cognitive load

#67

Post by the_gipsy » Fri, Dec 29, 2023, 5:49 AM UTC

hmeh wrote: post #60

irjustin wrote: post #58

Earlier quoted context omitted.

> So, as a blunt statement - your experience is typical. That is, it's average. Definitely a fair judgement and would agree that this constitutes poor architecting on many many companies' parts including ones that I've been a part of. > Every one of our 100+ components maintained by our dozen person team can be run and tested on its own. Can you elaborate on this? What is the primary benefit of running 100-300 compon…

> Can you elaborate on this? What is the primary benefit of running 100-300 components vs a monolith specifically with a 12 person team? > More directly, what's wrong with a monolith at the dozen person team size? Great question. It's honestly a hard question to answer because the real answer requires tacit knowledge, but I'll try anyway because you asked. I'll link a couple articles of longer form writing that may h…

> we have 400 separate GitHub repositories

Do you think this sounds good?

> We can't accidentally get peanut butter in our mayonaise

Hint: you have 400 different jars of peanut butter with mayonnaise.

Re: It's not microservice or monolith; it's cognitive load

#68

Post by irjustin » Fri, Dec 29, 2023, 5:52 AM UTC

hmeh wrote: post #60

irjustin wrote: post #58

Earlier quoted context omitted.

> So, as a blunt statement - your experience is typical. That is, it's average. Definitely a fair judgement and would agree that this constitutes poor architecting on many many companies' parts including ones that I've been a part of. > Every one of our 100+ components maintained by our dozen person team can be run and tested on its own. Can you elaborate on this? What is the primary benefit of running 100-300 compon…

> Can you elaborate on this? What is the primary benefit of running 100-300 components vs a monolith specifically with a 12 person team? > More directly, what's wrong with a monolith at the dozen person team size? Great question. It's honestly a hard question to answer because the real answer requires tacit knowledge, but I'll try anyway because you asked. I'll link a couple articles of longer form writing that may h…

Thanks for the longer writeup, I appreciate it. It'll take me some time to digest the concepts.

Re: It's not microservice or monolith; it's cognitive load

#69

Post by hmeh » Fri, Dec 29, 2023, 6:03 AM UTC

the_gipsy wrote: post #67

hmeh wrote: post #60

Earlier quoted context omitted.

> Can you elaborate on this? What is the primary benefit of running 100-300 components vs a monolith specifically with a 12 person team? > More directly, what's wrong with a monolith at the dozen person team size? Great question. It's honestly a hard question to answer because the real answer requires tacit knowledge, but I'll try anyway because you asked. I'll link a couple articles of longer form writing that may h…

> we have 400 separate GitHub repositories Do you think this sounds good? > We can't accidentally get peanut butter in our mayonaise Hint: you have 400 different jars of peanut butter with mayonnaise.

How do you know that? Hint: you don’t. You’re not the first to tell us what we do is impossible, and you won’t be the last.

By the way, I know how it sounds. And I know why a person would fear it. And, I know why they’d be incorrect in their assessment, because, unlike them, I have significant material experience in both camps.

Re: It's not microservice or monolith; it's cognitive load

#70

Post by hmeh » Fri, Dec 29, 2023, 6:04 AM UTC

irjustin wrote: post #68

hmeh wrote: post #60

Earlier quoted context omitted.

> Can you elaborate on this? What is the primary benefit of running 100-300 components vs a monolith specifically with a 12 person team? > More directly, what's wrong with a monolith at the dozen person team size? Great question. It's honestly a hard question to answer because the real answer requires tacit knowledge, but I'll try anyway because you asked. I'll link a couple articles of longer form writing that may h…

Thanks for the longer writeup, I appreciate it. It'll take me some time to digest the concepts.

You are welcome. Feel free to reach out at any time with follow up questions. GitHub discussions are probably easiest, but I’ll try to check here too.