Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

fernandovillalba.substack.com

Post reply on HN
Print view View original

91–100 of 195 posts

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

#91

Post by 3cats-in-a-coat »

jiggawatts wrote: post #65
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. T…

I'm working on a language that's like it. But my esoteric stuff aside, the closest production system we have like that is Erlang (and Elixir, if it's your thing).

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

#92

Post by DarkNova6 »

hooby wrote: post #76

Reading the responses/comments in here, a question arises... Are things really that black and white as people here paint them - with monoliths unavoidably and necessarily becoming a tangled mess of spaghetti, and micro-services being the singular, only way to achieve clean separation, autonomy and partition? With microservices inevitably being an organizational nightmare that leads to problems in inter-team coordinat…

A lot of factors come together whenever the term Microservie or Monolith arises:

- Monolith has implicitly replaced the word "Legacy" system

- Microservices were (/are still) the cool thing to do in a conference driven industry. They were championed by big tech because they desire granular and flexible deployment systems (whereas in smaller products your code just needs to run and everything else is just overhead). Having multiple instances of a MS can fix some performance issues as well.

- People rarely talk about failing with their new (microservice) projects.

- Microservices can be a technical solutions for human problems. Large teams benefit from distributed deployments due to organizational reasons. They also force you to think more about modelling your responsibilities, which might be add odds with your company culture.

To me, Microservices are not an architecture pattern but a deployment strategy. Obviously, you want high cohesion and modules, which you might or might not get with Microservices. It comes down to understanding your problem domain.

If you have a modular monolith, you can still deploy it separately at a later point if the need arises. Even having a shared database is not a problem if your modules are only using the respective tables they own (this can be enforced with permissions).

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

#93

Post by 3cats-in-a-coat »

alexalx666 wrote: post #39
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…

The tradeoffs are great if you are mindful

Tradeoffs of?

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

#94

Post by onion2k »

jpk wrote: post #51
roenxi wrote: post #44

Earlier quoted context omitted.

> I'd love to be able to separate myself and my team from others by an agreed-upon interface. Don't doubt it, but that is what the grandparent was going to - you don't want to be held accountable for the success of the overall product, you want a defined contract that you maintain and the value-add of that is someone else's problem. The dysfunction of a business is made up of individuals doing what makes the most sen…

Isn't this precisely what leadership is for? If you've implemented an architecture that mirrors your org chart, then the interfaces aren't just in software, they exist between managers as well. System-level success depends on the managers and the directors above them to steer the boat in a way that places accountability on the teams and components of the architecture necessary to ship a feature, or whatever.

Isn't this precisely what leadership is for?

If your devs are just implementing whatever system design is coming from your tech leads, and having no opportunity to have an input or their own, you'll find you have very unhappy devs who don't hang around very long. That churn will make it impossible to build a decent system.

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

#95

Post by Zanfa »

ldjkfkdsjnv wrote: post #15

I used to complain about overly complex software, until I realized the problems themselves were very complex. There was/is no way around complexity, and pushing for early simplicity causes more problems than it solves. People need to accept that encoding 1,000 if else statements (software engineering) will be complex no matter how you spin it. Just design the software upfront for what you will need, like a profession…

> Just design the software upfront for what you will need, like a professional.

This is impossible for anything more complex than the simplest of toy examples. Never have I seen a production system where all behaviors and use cases are known, well-defined and correctly documented ahead of (or even after the) implementation in enough detail. That’s just not how people operate.

It’s the equivalent of saying everybody should just come together and talk it out to achieve world peace.

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

#96

Post by dzikimarian »

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.

Correct question is: why does it take a few teams to deliver feature? This defeats point of entire exercise.

Usually answer is, that division was done by technical role and not business function of the subsystem.

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

#97

Post by hw »

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…

Great that it works for you and your particular project.

Without knowing the details if your project and team, I’d take a monolith any day over 400 microrepos and the 70+ backend microservices. Our customers don’t care if it’s microservices or monoliths as long as it works and meets SLAs, so the question really is do I want to upgrade ruby or rails 400 times and deploy 100 services or just do it once in my monolith and deploy once?

Need to upgrade a gem that’s used in 100 of those repos to address a CVE - no thanks. Worse, 10 of those repos were owned by someone who left the company a year ago and since there were no PRs, no one knows how to work in the repo or understand what it does.

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

#98

Post by pluto_modadic »

edandersen wrote: post #88

Lots of architects / tech leads read this instead as: "design the software to fit the maximum team cognitive load that you desire ”. They actually over-complicate software builds in order to justify headcount later. "Oh whoops yes we now need a whole full time Ops team, don't worry I know just the guys".

Kubernetes: because we have cloud engineers and they're not busy, right?

it's not like they could be doing more important things if they weren't chasing fires....

wait why is my head count soaring...

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

#99

Post by stevedonovan »

jiggawatts wrote: post #65
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. T…

Yes, same feeling I had, but with dual mode; can be compiled as a 'standalone' service over HTTP/REST (or whatever) and _also_ compiled as a classic module with a strictly defined interface.

One cool thing about standalone services which needs to be factored in is that they can be spun up and debugged very easily. But for deployment, we pay for all the network latency/marshaling overhead, and coordination complexity.

So, best of both worlds? As for polyglot, there does have to be a shared platform (C ABI, JVM, etc). (Go doesn't play so nicely with other languages due to goroutine stack allocation.)

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

#100

Post by Too »

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…

> Each part is independently built and tested.

> We don't have our tests running in CI.

> It takes about an hour to deploy everything.

Eh? 400 components without any integration testing?? Who glues the sum of the parts together into a whole? This can’t be a single application. Sounds more like many completely independent applications to me.

Post reply on HN