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

101–110 of 195 posts

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

#101

Post by konschubert »

karlmdavis wrote: post #85
konschubert wrote: post #84

It’s hard to enforce api contracts between components of a monolith. And when performance tanks, it’s hard to pin the root cause to a component. Both of these could probably be fixed by tooling. Could be z as fun research project or maybe a company.

You and I must work in very different contexts, as these questions are so obvious that they first seemed like satire to me. You enforce API contracts in a monolith (or any codebase, really) via an at-least-modest amount of typing and a compiler. You diagnose performance issues via any number of tools, prominently including metrics and profilers. My context for this is a lot of years working with backend languages lik…

Sure… and then the type of the return object if of API is

‘CustomerORMModel’… and now the api consumer can build n+1 query problems across components.

You need a few more restrictions than that. But I agree it’s doable.

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

#102

Post by btown »

aniforprez wrote: post #80
cncivubyv wrote: post #74

Earlier quoted context omitted.

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

The key word here is DX. If a team is exposed to how the DX of their owned service or library enables others in the company to build things that bring smiles to customers' faces, they'll be able to better design for their downstream teams' experiences, finding the right balance of keeping API churn low while building for future flexibility. This is true whether the API boundary is over a network or over a function call.

That said, microservices have the added problem that if you don't get the culture and boundaries set just right from the beginning, it's harder to change. They're good for small domains where boundaries are defined, and many even-early-stage startups have some of those, but it's unlikely that the primary interface for customers is included in that.

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

#103

Post by Too »

ldjkfkdsjnv wrote: post #15

I used to complain about overly complex software, until I realized the problems themselves were very complex. There was/is no way around complexity, and pushing for early simplicity causes more problems than it solves. People need to accept that encoding 1,000 if else statements (software engineering) will be complex no matter how you spin it. Just design the software upfront for what you will need, like a profession…

You have the terms essential vs accidental complexity for that.

Accidental complexity is something you should work hard to avoid. Trying to avoid essential complexity however is a fools errand and if you try, it will result in a deck of cards that only work under perfect conditions.

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

#104

Post by djur »

dzikimarian wrote: post #96
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.

Correct question is: why does it take a few teams to deliver feature? This defeats point of entire exercise. Usually answer is, that division was done by technical role and not business function of the subsystem.

In most cases there's going to be substantial overlap between the functionality required for various business functions, and even in differentiated systems the ideal technical domains may not map cleanly to business domains. It's very easy for this to result in multiple teams having half-assed, semi-compatible implementations of the same functionality.

Some places try to address this by creating dedicated "core" or "platform" teams, but there's numerous pitfalls this way as well. Platform teams and product teams necessarily have to justify their budgets in different ways. They have different stakeholders and internal sponsors. This can result in political struggles over headcount. "Brain drain" scenarios where product teams are perennially starved as their strongest ICs are moved to platform. "Slush fund" scenarios where platform teams are regularly "temporarily" reassigned to support feature development. I've seen them both.

The longer you can have your entire engineering team share responsibility for the entire product the better. I am convinced of this. Unless you can truly, completely decouple systems -- making them separate products with dedicated teams -- you run a high risk of having a codebase that is more complex that people still need to understand in its entirety to work effectively. The worst of both worlds.

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

#105

Post by dzikimarian »

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 bigger team containing people with various seniority, it's often best to give them rigid set of rules, because they'll misinterpret or ignore something more complex.

And that's why black and white approach often works - it's far from ideal, but at least possible to actually execute in many of the teams.

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

#106

Post by Too »

LarsDu88 wrote: post #55

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

If you follow the authors advice you would be tricked into believing monoliths like Photoshop, Excel or any AAA-game could only have been written by a single team only. That couldn’t be further from the truth. There are like 100 other ways to create interface boundaries than carving out microservices.

Microservices is a deployment strategy, not a tool you use to reinforce Conway law, a law that you actually want to defuse more often than follow, to not get your product stuck into your old org chart.

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

#107

Post by randomdata »

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 economy (think a single business).

In other words, it's a team separation technique. 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.

How those teams design their software is ultimately irrelevant. The key aspect is keeping active communication between teams to a minimum, using published documentation and API contracts as the mode of communication between teams, just as we do on the macro scale. Getting another team on the phone should be as hard as getting Google on the phone – i.e. basically impossible, but also basically unnecessary.

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 overcome that. Of course, it serves no purpose in a small company where an economy can't reasonably grow anyway.

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

#108

Post by the_gipsy »

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…

The interface will evolve, and in fact that is the hard part of software development.

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

#109

Post by kitd »

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…

SCA did this back in the J2EE/SOAP days. An SCA interface was just the interface but the boundary itself could be implemented either as an in-process plain Java call, a cross-EJB call, or a SOAP call, so that in theory one could be swapped out for the other. In practice IME, it never was but maybe I just never came across the right use cases.

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

#110

Post by mewpmewp2 »

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…

With no or minimal communication how is it possible to build anything new? In real world if you need to build something new and it requires 10 different companies to do that, it would be virtually impossible.
Post reply on HN