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

71–80 of 195 posts

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

#71

Post by Nextgrid »

wavemode wrote: post #59
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.

This viewpoint doesn't translate to reality in my experience. Monolith or not, engineers care about working product if they are incentivized to care about working product (and if they aren't, they don't). Code is code. Cognitive load is cognitive load. Doesn't matter how you organize it. Unless your company is still very small and simple, there's no single team that is going to be able to understand how the entire sy…

> engineers care about working product if they are incentivized to care about working product

Places that set up the correct incentives are usually very rare. Maybe hedge funds or some finance places which give you a decent chunk of the profits your code makes but that's about it.

Every other place pays you the same "meh" salary and the quickest way up is to job-hop frequently, in which case resume-driven-development takes priority over "working product". That's how you get cargo-cult over-engineering, everything else be damned since you will be gone by the time the consequences emerge anyway.

(also you have "startups" where over-engineering is usually a desired feature as it gives them a justification to grift more VC money to keep their unsustainable business afloat further).

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

#72

Post by Nextgrid »

ddejohn wrote: post #30
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.

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 for the foreseeable future.

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

#73

Post by jayd16 »

pdonis wrote: post #48
jayd16 wrote: post #43

Earlier quoted context omitted.

If you need flexibility for unknowns, design for that. Specialize as the requirements become more clear.

That assumes that you know the unknowns and how to design for the flexibility you will need. That won't always be the case. Sometimes you just have to accept the fact that you don't know enough up front to make a good design, so your initial efforts need to be focused at gaining the information you need, for example by prototyping to get user feedback knowing that you will probably throw some prototypes away, not mak…

We agree. I just phrased it as design and plan for project flexibility, not design a bunch of knobs strictly for every case you happen to know about at some snapshot in time.

I say design and not just plan because you'll want to mock out or prototype something to show and that does take design work to keep your iteration cadence high.

In my mind flexible means easy to iterate on but maybe that is not clear.

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

#74

Post by cncivubyv »

wavemode wrote: post #59
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.

This viewpoint doesn't translate to reality in my experience. Monolith or not, engineers care about working product if they are incentivized to care about working product (and if they aren't, they don't). Code is code. Cognitive load is cognitive load. Doesn't matter how you organize it. Unless your company is still very small and simple, there's no single team that is going to be able to understand how the entire sy…

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

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

#75

Post by outsomnia »

hmeh wrote: post #69
the_gipsy wrote: post #67

Earlier quoted context omitted.

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

This whole business has had few conceptual ideas that stand apart from fashion and stood the tests of time. A lot of people look down on C now for various reasons, but it's still extremely useful and going strong 50+ years later. Even though I'm older than C itself in the last year or two using it intensively, I found new insights in how to arrange things and what to avoid to make things more robust and maintainable.

It's not likely that hundreds of "microrepos" on github and even rails are The Last Word that people will eventually converge on and be using into the 2100s. It sounds like each repo is its own standalone thing with its own deps. There are advantages and disadvantages to maintaining this kind of thing, some of the disadvantages will only become clear as the deps evolve and mutate. Although you may feel you are in a local optimum with this architecture in 2023, ahead of the game, energized by your belief in it, you probably are not finished evolving your understanding even on the scale of one or five years.

One way or another almost everything in this business is ephemeral, disposable and will be disposed of in favour of something else.

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

#76

Post by hooby »

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 coordination, while monoliths automatically ensure that everyone always is perfectly the same page?

Because by my personal experience, you totally can code a monolith in a strictly modular fashion, with clean interface-based API boundaries between the separate parts. And if you put those "modules" into separate packages, the dependencies between them end up being managed and documented as well. Just like you totally can setup microservices and surrounding procedures in a way that actually increases the feeling of product ownership in the teams, and reduces the hassle of inter-team coordination - especially in larger companies.

Obviously there are ways to do monoliths right, and spectacularly wrong. And there are ways to do microservices right and wrong...

I see so many arguments here, that do compare one method done wrong with the other method done right - and then imply that this is a strong reason for choosing that second method.

I don't get it?

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

#77

Post by kaashif »

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.

> If you've implemented an architecture that mirrors your org chart

In my experience this is almost invariably what happens. I would replace the if with a when.

Wow, you're telling me our three teams want to write three separate services? No way.

And the teams in New York want to use one technology while the teams in San Francisco want to use something else? Say it ain't so!

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

#78

Post by nullandvoid »

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…

To borrow some monolith examples from Monolith to Microservices (https://www.goodreads.com/en/book/show/44144499 - fantastic read)

"Single Process" - Can be module based (Shopify), where multiple module's interact, but must be combined for deployment still, these module's can even extend to the DB's. Can still have multiple instances for performance

"Distributed Monolith" - This is one to fear the most, we have multiple services, yet there is still shared DB's meaning we have to deploy things together.

Both are monoliths but one is less susceptible to ball of mud. It's a sliding scale, with trade offs for each (and many variations still in between those listed).

I think it's a lack of common terminology surrounding monolith / micro-service that creates this binary illusion.

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

#80

Post by aniforprez »

cncivubyv wrote: post #74
wavemode wrote: post #59

Earlier quoted context omitted.

This viewpoint doesn't translate to reality in my experience. Monolith or not, engineers care about working product if they are incentivized to care about working product (and if they aren't, they don't). Code is code. Cognitive load is cognitive load. Doesn't matter how you organize it. Unless your company is still very small and simple, there's no single team that is going to be able to understand how the entire sy…

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 pies in the sky. As with most things, it comes down to good planning
Post reply on HN