It's not microservice or monolith; it's cognitive load
fernandovillalba.substack.com
It's not microservice or monolith; it's cognitive load
1–10 of 195 posts
Re: It's not microservice or monolith; it's cognitive load
#2How do you get to third on hn with 8 points and 0 comments in 2 hours?
Re: It's not microservice or monolith; it's cognitive load
#3How do you get to third on hn with 8 points and 0 comments in 2 hours?
Now second
Re: It's not microservice or monolith; it's cognitive load
#4How do you get to third on hn with 8 points and 0 comments in 2 hours?
By being the new post with the most points and comments in 2 hours.
If another post would was more recent and had more points it would be higher.
These posts get a temporary boost but if the points stay the same while being at the top, it'll disappear pretty soon.
Re: It's not microservice or monolith; it's cognitive load
#5Cognitive load is one good dimension to think about here. I like that it is a human concern. There are probably multiple.
What I think is challenging is figuring out what the teams should be - this can be more complex than it appears. Do you have an "auth team" for example? How do you ensure the people in that team are happy that their CV is going to be "done auth for 2 years" when they next do their job.
For small companies you might have micro teams, where there are 0.1 members on that team - I.e. it is at the point of part of someone's role. But treating it like it's own team (it get's own repo(s)) might make sense.
Re: It's not microservice or monolith; it's cognitive load
#6How do you get to third on hn with 8 points and 0 comments in 2 hours?
By being the new post with the most points and comments in 2 hours. If another post would was more recent and had more points it would be higher. These posts get a temporary boost but if the points stay the same while being at the top, it'll disappear pretty soon.
I suspect #points is the main factor. And the algorithm wants to surface fresh stuff, otherwise we'd still all be talking about Sam Altman. Glad we aren't :-) (nothing against Sam...)
Re: It's not microservice or monolith; it's cognitive load
#7We can’t measure cognitive load though. Or if we can, no one knows a way to apply that to software projects.
Re: It's not microservice or monolith; it's cognitive load
#8I think a revisit of Conway's paper[1] might be appropriate. Between that, and the recent talk by Kevlin Henney about architecture[2], you'll be in far better shape to make such decisions.
Re: It's not microservice or monolith; it's cognitive load
#9We can’t measure cognitive load though. Or if we can, no one knows a way to apply that to software projects.
You can't and shouldn't try to. We can however qualitatively try to see where the wind is blowing.
Re: It's not microservice or monolith; it's cognitive load
#10The 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-write optimized), typically stack allocated. Remote IO is also pass-by-copy. But in-between those two levels, we have this intermediate pointer/handle hell of mutable shared state that the C family of languages promote, both procedural and OOP variety.
The original OOP definition is closer to the Actor model which has by-copy messages, but the actual OOP languages we use, like C++, Java, C# all derive philosophically from the way C handles entities on the heap, as this big shared local space you have immediate access to, and can pass around pointers to.
And that's where all our problems come from. This concept doesn't scale. Neither in terms of larger codebases. Nor in terms of distributing an application. It doesn't also scale cognitively, which the article mentions, but doesn't quite address in this context.