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

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

#191

Post by randomdata » Sun, Dec 31, 2023, 5:48 PM UTC

lelanthran wrote: post #178

randomdata wrote: post #107

Earlier quoted context omitted.

Perhaps it is easier to understand when you remember that service is not a technical term? People provide service. In the macro economy, service comes from other companies. If you integrate an LLM into your application, you may use the services of OpenAI. If you integrate payment processing into your application, you may use the services of Stripe. Microservices are just like services, except offered within a micro e…

> You let teams within a business organize as if they were separate businesses and let them offer services to each other as if they were operating different businesses. > This is done in large organizations to ensure that developers aren't forever bogged down in meetings. If you have 10,000 developers all trying to work on the same project the communication overhead will kill you. Microservices is a way to try to ove…

I'm not sure a team is defined by individuals who may come and go. Look at professional sports teams that have been around for a long time. None of the people involved in the team today are the same people who were there in the beginning. The people don't define the team.

I expect you will find that service, product, and team all mean approximately the same thing in this context.

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

#192

Post by hmeh » Sun, Dec 31, 2023, 9:12 PM UTC

guhcampos wrote: post #184

hmeh wrote: post #52

Earlier quoted context omitted.

If you don't disagree, then I assume you have a strong understanding of structural design. I assume that you recognize that Conway's law is more of a curse, and a warning than it is something to embrace. I assume that you recognize that the only possible way to "embrace conway's law" and simultaneously recognize structural design would be to constantly be firing or otherwise disbanding entire teams as components get…

No, not at all. I see why you think of it as a curse, I don't enjoy it as a resulta, but it's an observation of a pervasive pattern, not a design decision. It emerges from the way humans communicate and organize themselves. You can either fight it agressivelly and try to minimize it, or you can "embrqce" it and try to adapt. I could force it into a disability analogy: if you become suddenly deaf, you can agressivelly…

The difference, though, is that microservices was more about the focus on the micro. That was, small things. Not per-team things. It was about trying to break things down into the smallest possible piece (while simultaneously ignoring software design IMO). A single team could end up with 5 microservices. A single microservice may not need to be touched after it's deployed. It's true that this can facilitate multiple teams, and you say this when people emphasized the technology soup approach to microservices: finally, you can combine Go, Rust, Java, Ruby, TypeScript, and even COBOL!

By the way, the entire premise that you should organize your software based on the way teams are organized is the flawed thing. Natural designs emerge when designing software. If you must have multiple teams, it may make sense to distribute some of those partitions that emerge across those teams. Or it may not. What absolutely does not make sense is creating partitions to account for your multiple teams. That's design-by-making-stuff-up and it's as doomed to failure as the REST-based-microservices fad.

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

#193

Post by jrs235 » Tue, Jan 02, 2024, 8:16 PM UTC

rezonant wrote: post #176

jrs235 wrote: post #172

Earlier quoted context omitted.

I don't read cockiness or narcissism in his posts. Having just started reading Clean Architecture by Robert C. Martin two days ago (and hoping to complete it tonight, then planning on re-reading it again), it seems to me that hmeh has learned and PRACTICED what is discussed in that book. I wish I were in their shoes!

There are parts of CC that are still quite controversial, even amongst folks who agree generally with what Uncle Bob is saying.

Clean Code (What I assume you are referring to with 'CC') is 10 years older than Clean Architecture. I haven't read Clean Code, I just picked up Clean Architecture, but I venture to guess some of his thoughts have changed since then. I also assume that Clean Architecture deals with higher level issues than Clean Code. I may have to pickup Clean Code to see what he said in that.

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

#194

Post by jrs235 » Tue, Jan 02, 2024, 8:19 PM UTC

elktown wrote: post #179

jrs235 wrote: post #172

Earlier quoted context omitted.

I don't read cockiness or narcissism in his posts. Having just started reading Clean Architecture by Robert C. Martin two days ago (and hoping to complete it tonight, then planning on re-reading it again), it seems to me that hmeh has learned and PRACTICED what is discussed in that book. I wish I were in their shoes!

Let's just say that that sphere of the software dev community isn't exactly universally seen as competent work, more like the orthodoxy of ~15 years ago that's now increasingly, and in my opinion rightfully, being put into question for its bad complexity and performance trade-offs when applied beyond textbooks and conference talks. And this is being diplomatic compared to others. I'm certainly not saying there isn't…

I see a difference between "Clean Code" and code design patterns and "Clean Architecture". It seems to me that most think I'm speaking of Uncles Clean Code book/ideas when I'm thinking about his Clean Architecture book/ideas.

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

#195

Post by bruce343434 » Thu, Jan 04, 2024, 10:28 PM UTC

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…

From your description I thought you might just want a bunch of singletons calling each others methods ("passing messages"), and to get the "by-copy" you could serialize and deserialize everything, or write proper copy constructors. Do I understand correctly?