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

121–130 of 195 posts

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

#121

Post by baby »

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…

I think we’ve been spoiled by move fast break things type of startups, and indeed if you’re in a competitive field you might have to fight for your survival.

But truly successful projects are the ones that are worked on and improved for decades. Long-term work means that you will have to be conscious about being clean, and care about constant refactoring and simplification, and design decision that will prevent paralysis down the line.

There’s a reason twitter did not change for like 10 years and apps like Instagram are able to adopt new trends super quickly. (Unrelated: since the Instagram team is behind Threads, I predict that Threads is going to evolve really really fast and be harsh competition to twitter over time)

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

#122

Post by hardware2win »

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.

I dont think so, at least in C#

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

#123

Post by kiviuq »

randomdata wrote: post #107
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…

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…

HOW DO COMMITTEES INVENT? By MELVIN E. CONWAY

Walkthrough

https://youtu.be/5IUj1EZwpJY?t=688

Paper

https://www.melconway.com/Home/pdf/committees.pdf

Bartosz Milewski's take on the topic of decomposing complexity

Category Theory 1.1: Motivation and Philosophy

https://youtu.be/I8LbkfSSR58?list=PLbgaMIhjbmEnaH_LTkxLI7FMa...

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

#124

Post by hooby »

dzikimarian wrote: post #105
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…

In my opinion it's people problem. Lots of developers are focused on pure technicalities. They will focus on writing code and ignore why it's written. As result of that their choice of architecture will be detached from business function. Also, as thinking about architecture isn't writing code it will be often afterthought based on shallow knowledge and superstitions. Keeping that in mind - when you are talking to bi…

But shouldn't it still be a rational decision?

The imho rational thing to do, would be to compare the pros and cons of each option and find a conclusion that way.

Comparing only the pros of one solution with only the cons of the other, seems a bit... disingenuous and an emotionally-driven line of argument.

And I personally just do not believe that making decisions with such wide-reaching implications as monolith or microservice based on emotional arguments, does lead to useful results?

The only thing that imho can come from this sort of arguing, is the kind of religious divide, evangelism and proselytism that ultimately only hurts both sides of the argument, because it makes people favor dogmatic choices over considering what's actually useful in the current situation?

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

#125

Post by TylerE »

baby wrote: post #116

IMO: write everything in Rust. If a dependency is not in Rust, rewrite in Rust. Carmack has a rant about Meta’s stack for the Quest being in different languages and being a pain. Having worked in heavily-split stacks I don’t want to run into these again.

Never rewrite. Rewrites always fail.

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

#126

Post by twhitmore »

Nextgrid wrote: post #72
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…

> I'd love to be able to separate myself and my team from others by an agreed-upon interface. My experience suggests that speccing out such an interface well is a tremendous amount of work, and if you get it wrong (you most likely will) or if it needs to evolve it will generate lots of work since now it's set in stone and very hard to change so you're likely going to pay "interest" by working around its shortcomings…

Difficulty & cost evolving the interface between microservices can seriously hinder improving the actual product.

I've seen the misguided adoption of microservices affect a couple of companies & products.

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

#127

Post by kybernetikos »

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…

I think you're right to be skeptical that microservices are required in order to stop code becoming spaghetti.

I think of it as all about what kind of boundaries you choose to put in your code and where. https://hivekit.io/blog/mesolithic-architecture/ The blog calls it 'mesolithic' architecture, but I almost wonder if 'gabion' architecture might be better - separate small rocks held together by a metal frame, forming a single architectural piece.

The principles of good architecture do not require you to make your boundaries network or process boundaries, but they do require that you have boundaries and that you're careful when and how you cross them.

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

#128

Post by dzikimarian »

hooby wrote: post #124
dzikimarian wrote: post #105

Earlier quoted context omitted.

In my opinion it's people problem. Lots of developers are focused on pure technicalities. They will focus on writing code and ignore why it's written. As result of that their choice of architecture will be detached from business function. Also, as thinking about architecture isn't writing code it will be often afterthought based on shallow knowledge and superstitions. Keeping that in mind - when you are talking to bi…

But shouldn't it still be a rational decision? The imho rational thing to do, would be to compare the pros and cons of each option and find a conclusion that way. Comparing only the pros of one solution with only the cons of the other, seems a bit... disingenuous and an emotionally-driven line of argument. And I personally just do not believe that making decisions with such wide-reaching implications as monolith or m…

>The only thing that imho can come from this sort of arguing, is the kind of religious divide, evangelism and proselytism that ultimately only hurts both sides of the argument, because it makes people favor dogmatic choices over considering what's actually useful in the current situation?

Of course :-) I'm not advocating for it in anyway. Quite contrary. That's just what I've seen - which sadly is, that tons of developers are not able to rationally discuss architecture and the just default to dogma.

Often someone dropped stone tables years ago and they just follow. If instructions they were given were simple and well understood on mechanical level, usually result is bit better than total chaos. Thus black&white approach.

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

#129

Post by 4hg4ufxhy »

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…

I think most people agree with your post but you are indeed missing the point.

People are discussing anecdotal "average" cases. Not what is possible, but what actually happens.

Of course anything can and does happen, and outliers are interesting, but you shouldn't assume they are equivalent to other cases just because they are possible. The distribution does matter and since it's not easily measurable people discuss anecdotes and opinions.

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

#130

Post by hiAndrewQuinn »

I maintain that the only way to truly fight cognitive load is to outsource more of your design to long-term memory. That is as close to a silver bullet as you will ever get, and it explains way more of the tech landscape than you want to admit.

In the ideal case, there exists a literal piece of mathematics you translate into code and work with from there. The upfront cost is extreme - but, once the math is internalized, the resulting product is sleek and elegant and can be understood rapidly at a bird's eye view by other people who also understand the underlying mathematics.

Weaken this ideal case however appropriate to your business case, but no more than you have to!

Post reply on HN