Live data from Hacker News

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

fernandovillalba.substack.com

151–160 of 195 posts

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

#151
Most system can have a single server today and it will basically always be more simple than N smaller ones. Everything is just faster if you just skip the TCP layer. Less configuration, less attack surfaces, less possible problems and issues. The CI/CD and backup is a lot easier as well.

It is as another author wrote: It is a people problem. We programmers like the "do one thing" mantra so we tend to want to add it everywhere - even in places were the cost may outweigh the benefits.

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

#152
post #22

Earlier quoted context omitted.

The entire purpose of microservices is to comply with Conway.

This is wrong. That's not how Conway's Law works. It’s also not how software design works. But please, by all means, continue to spread disinformation and keep us in the dark ages.

A cynical take is not "disinformation". Let's not dilute that word.

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

#153
post #141

Earlier quoted context omitted.

Usually, when you put quotes around something, it's considered proper to actually be quoting someone instead of trying your best to make them sound like a clown. But, why don't I go ahead and give you a real quote. Of our 400+ repos, 100 or so of them are deploy projects. The only time they need to change in batch is if one of our boilerplate scripts changes. This is infrequent, but when it does happen, we have a "pr…

Someone got to say it so I will. Most of your comments comes across like you've gone off the rails and started replacing competency, not to mention humility, with narcissism. Being so cocksure and backing it up with statements that you need to be as brilliant as you to "understand" is such a laughingly large red flag that I'm not surprised people interpret it as satire. I really hope your colleagues are onboard with…

> Someone got to say it so I will. Most of your comments comes across like you've gone of the rails and started replacing competency, not to mention humility, with narcissism. Being so cocksure and backing it up with statements that you need to be as brilliant as you to "understand" is such a laughingly large red flag that I'm not surprised people interpret it as satire.

Where did I say that, exactly? I’ve said nothing about intellect. I’ve mentioned tacit knowledge multiple times, because I have enough experience to recognize how ludicrous a lot of this sounds. It sounded that way to me at first until I experienced it and saw the pieces fit together. That’s how tacit knowledge works, especially when it is counter to average knowledge. It’s the same reason American industry smashed Japanese cars in demonstration instead of listening to them when they said large batches were bad (I’m simplifying here somewhat)

And which part, specifically sounds incompetent? I’m happy to discuss that.

By the way, it's decidedly difficult to challenge a common belief, dare I say, orthodoxy, without sounding insane, confident, or even cocky. Could I be better at it? Of course, and I work at it, but I also am not here to make friends. I'm here to provide a perspective that I believe is sorely lacking from the development community and is drowned out by the orthodoxy, its acolytes, and its beneficiaries.

> I really hope your colleagues are onboard with this and that this isn't your own dogmatic crusade dragging them along.

Given their tenure on the team and their other options, it’s a pretty safe bet. It’s not my crusade, btw, it’s our teams goal to manage a relatively complex project with a relatively small team.

Also, someone has to say it, so I will. You have now dropped this conversation, which was about the work, into ad hominem and straw man attacks. That’s one of the worst part about this industry: people’s inability to debate and discuss without attacking people or glorifying celebrities.

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

#154
post #153

Earlier quoted context omitted.

Someone got to say it so I will. Most of your comments comes across like you've gone off the rails and started replacing competency, not to mention humility, with narcissism. Being so cocksure and backing it up with statements that you need to be as brilliant as you to "understand" is such a laughingly large red flag that I'm not surprised people interpret it as satire. I really hope your colleagues are onboard with…

> Someone got to say it so I will. Most of your comments comes across like you've gone of the rails and started replacing competency, not to mention humility, with narcissism. Being so cocksure and backing it up with statements that you need to be as brilliant as you to "understand" is such a laughingly large red flag that I'm not surprised people interpret it as satire. Where did I say that, exactly? I’ve said nothi…

> into ad hominem and straw man attacks. That’s one of the worst part about this industry: people’s inability to debate and discuss

Let's see here:

> You have experienced what happens when web developers cosplay as software architects.

> That is, you experienced an average team doing average work misguided by average bad advice. It says absolutely nothing about software design. It only speaks to the fat part of the bell curve doing what it always does.

> because, unlike them, I have significant material experience in both camps.

> It’s hard to imagine worse advice.

> But please, by all means, continue to spread disinformation and keep us in the dark ages.

> Just read the author’s bio. This is a person that appears to have zero software design experience writing an article telling you to ignore software design and just respect your team configuration. I call this Conway’s Confusion.

That sets a good friendly tone huh? If you can't take push back, don't be an arse to begin with.

> And which part, specifically sounds incompetent? I’m happy to discuss that.

Your arrogance precludes a fruitful discussion. But I believe that this needs to be called out, if nothing else to nudge other people to also do it when they see it, or to, albeit much less likely, nudge you towards eating some humble pie.

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

#155
post #119
post #79

I totally agree... the real question is how to reduce cognitive load. Try to get a system that can fit in your head, although I have totally failed to achieve this myself. But it is a goal!

Create self-contained frameworks and libraries by extracting code that starts becoming heavy and could be useful by its own. These are the useful abstractions. Constantly seek to specify, document, and simplify the protocols you implement. The clearer the ideas, the cleaner the implementation. Strive to use a single programming language. Organize your code like you would organize a city or a book.

Thanks, good tips!

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

#156
post #69

Earlier quoted context omitted.

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

As someone who has worked in monoliths and microservices, monorepos and github galaxies, I think it would be better if we could converge on a monorepo managed by something like Bazel where you can just create a new build target that lists its dependencies, and can work directly with the dependency graph via its querying mechanism. Using repositories to encapsulate dependencies and build scripts I think is much too heavy of an abstraction and leads to poor discoverability. When I have to deal with that I usually wind up treating it like a monorepo anyways by creating automation to check out all repos and manage syncing them.

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

#157
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 agree with your perspective here.

If you don't get something, perhaps it's that this is a bit of a holy war, and as with all holy wars, each camp tends to argue things from a very black-and-white perspective. As with most things, though, the truth is not so binary.

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

#158
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 often have had the feeling that people tend to try to solve code-organisation issues with microservices. Sure you can code a tangled mess in a monolith, but adding TCP connections and Kubernetes to the problems you have probably won't make things better. Instead, rewriting some code to use whatever applicable design pattern probably will make it better. An analogy that comes to mind is looking for a new house. Most…

> Sure you can code a tangled mess in a monolith, but adding TCP connections and Kubernetes to the problems you have probably won't make things better.

Yes!

I call this "moving the spaghetti". That tangled mess in a monolith can easily be (and often is) replaced with an equally tangled mess in microservices. It's just that the mess will be in the connections between services rather than in the code itself.

I see the same thing in certain OOP camps -- removing the spaghetti code from the actual lines of code into the inheritance hierarchy instead.

It's much like sweeping the floor and leaving the dirt under the carpet. At first glance, it looks cleaner. But if you have to move the carpet, you see the truth.

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

#159
post #138

Earlier quoted context omitted.

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

Do you know what does stand the test of time? Design principles that are based on the immutable laws of physics. There's a reason that I can quote Plato to support the notion of partitioning. There's a reason that the basic principles are used in the design of every single significant thing in the world. There's a reason Linux has as many modules as it has (for them, a single monorepo works, but multiple works too --…

Nobody is denying partitioning is helpful. It’s the implementation details of that partitioning that cause the debate. IMO using repos as a partition boundary is an abuse of git. And IMO invoking Plato to make a point is not helpful. Argumentum ad antiquitatem. This goes for the “30 years” comment as well: it’s entirely conceivable that they’ve been doing things inefficiently for 30 years. More likely that there is such a huge sunk cost that they are heavily invested in justifying it.

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

#160

Lets step back a second. If the rationale behind adopting microservices for everything is PURE orgitecture rather than software architecture, then that's not really a rationale at all. Instead of having one instance, you now have dozens of little service fiefdoms plus all the added network I/O overhead associated with that. The principled approach is really to simply not do that, for the basic latency costs. I mean,…

Maybe WoW didn't run on Microservices, but you can bet the project was divided into a bunch of different fiefdoms. Just they were separated at the interface level rather than the network level. Same concept though. Ultimately if you've got different teams working simultaneously, they should be working on non-conflicting features. Microservice is just one architecture that develops within this constraint. You'll never…

Yeah but "non-conflicting features" can be at the level of an individual task. It doesn't have to be an entire component. The best projects I've worked on were ones where anyone was allowed (and encouraged!) to work on any part. It helps people learn, spread knowledge, prevents boredom, reduces the number of "critical" people.

The worst projects I've worked on (including my current one) had components where people "owned" them. They fight against outside input and treat "their" part as a little kingdom that they rule. It's worse in almost every way.

Obviously there are limits - at some point your project is big enough that you have to have some specialist individuals and teams, but it's wise to avoid that as much as possible.

Post reply on HN