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

81–90 of 195 posts

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

#81

Post by chronid »

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…

My 2c: you can get things right, but most of the time you won't, for many reasons - technical, logistical, cultural or merely political. Sometimes you don't control these reasons.

So you are now left with managing risk. It's trade-offs all the way down.

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

#82

Post by rezonant »

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…

I don't intend this to be mean, but in some parts this reads as satire.

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

#83

Post by solatic »

LASR wrote: post #46

The single-most important lesson I've learned building products as a founding engineer in a successfully exited startup: weighing tradeoffs and deciding which software architecture to use is the wrong place to dedicate mental energy. It's always the product. It comes first. Then the business. If you're lucky you may become a pawn in a larger battle among giants and you'll get acquired before you attempt to make any p…

Sad to see this isn't the top comment. Unless or until you have a built-in source of guaranteed demand - the only thing that matters is product agility in order to find customer demand. Without demand, you have no revenue, investors lose interest, the money runs out, and people stop paying you to work on that system. Then everything gets thrown out. And "demand" is not "we have paying customers" - it's having sufficient revenue, for whatever that means for that particular org.

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

#85

Post by karlmdavis »

konschubert wrote: post #84

It’s hard to enforce api contracts between components of a monolith. And when performance tanks, it’s hard to pin the root cause to a component. Both of these could probably be fixed by tooling. Could be z as fun research project or maybe a company.

You and I must work in very different contexts, as these questions are so obvious that they first seemed like satire to me.

You enforce API contracts in a monolith (or any codebase, really) via an at-least-modest amount of typing and a compiler. You diagnose performance issues via any number of tools, prominently including metrics and profilers.

My context for this is a lot of years working with backend languages like Java, Rust, etc. though the same assurances and tooling are available for most every platform I’m aware of.

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

#86

Post by braza »

chronid wrote: post #81
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…

My 2c: you can get things right, but most of the time you won't, for many reasons - technical, logistical, cultural or merely political. Sometimes you don't control these reasons. So you are now left with managing risk. It's trade-offs all the way down.

> but most of the time you won't, for many reasons

This.

One thing that I noticed working in 3 different continents is that the learning/teaching on technology (CS?) is highly fragmented and it's quite hard to find some "common ground" in practices and methods and mesh all of that in a socio-technological place makes everything harder.

A weak generalization to illustrate the point: A [Continent A] developer will be more resource aware due to their natural lack of, an [Continent B] developer since it has more human capital available (better mentors, big ecosystem, huge amount of finance capital) will have more room for scaling ideas, a [Continent C] developer will have a better understanding of the intricacies due to their formal education and cultural aspects.

Placing all those people underneath a tech project and not having a program to terraform biases and level them to a shared and understandable set of expectations is the root cause of all this debacle.

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

#87

Post by cncivubyv »

aniforprez wrote: post #80
cncivubyv wrote: post #74

Earlier quoted context omitted.

Microservices tends to result in developers thinking their service is the product they're shipping to other developers.

Honestly, in my experience there's nothing wrong with this line of thinking as long as you also consider that the product you're shipping to other devs is in service of a much more important and larger product/service in itself. Thinking of your service as a product keeps you thinking of the use cases, the potential errors and the DX of what you're shipping which is a good thing I say as long as you're not building p…

This results in people optimizing local maximums, ultimately the real product suffers.

The developers also assume their product is relevant when perhaps it no longer is in the wider context of the business.

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

#88

Post by edandersen »

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".

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

#89

Post by 3cats-in-a-coat »

the_gipsy wrote: post #66
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.

It is because that's literally an architectural choice which prevents you from easily moving out a module from your "monolith" to another machine on the network, and causes the bugs.

The language & memory architecture... are an architecture matter.

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

#90

Post by aniforprez »

cncivubyv wrote: post #87
aniforprez wrote: post #80

Earlier quoted context omitted.

Honestly, in my experience there's nothing wrong with this line of thinking as long as you also consider that the product you're shipping to other devs is in service of a much more important and larger product/service in itself. Thinking of your service as a product keeps you thinking of the use cases, the potential errors and the DX of what you're shipping which is a good thing I say as long as you're not building p…

This results in people optimizing local maximums, ultimately the real product suffers. The developers also assume their product is relevant when perhaps it no longer is in the wider context of the business.

Yeah that's why I added my conditionals. Obviously the goal is the broader product/service at large
Post reply on HN