Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices are a tax your startup probably can't afford

nexo.sh

Post reply on HN
Print view View original

61–70 of 272 posts

Re: Microservices are a tax your startup probably can't afford

#61

Post by mjr00 »

monero-xmr wrote: post #51
eloisant wrote: post #42

Earlier quoted context omitted.

1 team supporting multiple services is not great, but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either. That's why I don't like the term "microservice", as it suggests each service should be very small. I don't think it's the case. You can have a distributed system of multiple services of a decent size. I know "services of a decent size" isn't as catchy as…

We solve the problem of 50 devs working in a single monolith with folder and file structure, separation of concerns, basic stuff like this

Folder and file structure and separation of concerns doesn't change the fact that if you have one deployable artifact, it's all sharing the same runtime when deployed. Which means the underlying versions of Java/Go/Python/etc, or core shared libraries, all need to be updated at the same time. All the code is far more coupled than it first seems.

Re: Microservices are a tax your startup probably can't afford

#62

Post by bcrosby95 »

eloisant wrote: post #42
abirch wrote: post #30

Earlier quoted context omitted.

Microservices are GREAT when 1 team owns each service. I haven't seen a good use case when you have 1 team supporting multiple microservices.

1 team supporting multiple services is not great, but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either. That's why I don't like the term "microservice", as it suggests each service should be very small. I don't think it's the case. You can have a distributed system of multiple services of a decent size. I know "services of a decent size" isn't as catchy as…

I call them nanoservices.

Re: Microservices are a tax your startup probably can't afford

#63

Post by BoardsOfCanada »

jihadjihad wrote: post #4

Microservices [0] > grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too > seem very confusing to grug 0: https://grugbrain.dev/#grug-on-microservices

Because the network call turns the rule into a law.

Re: Microservices are a tax your startup probably can't afford

#64

Post by sergiotapia »

microservices are a gigantic waste of time. like TDD.

it takes skill and taste to use only enough of each. unfortunately a lot of VC $$$ has been spent by cloud companies and a whole generation or two of devs are permasoiled by the micro$ervice bug.

don't do it gents. monolith, until you literally cannot go further, then potentially, maybe, reluctantly, spin out a separate service to relieve some pressure.

Re: Microservices are a tax your startup probably can't afford

#65

Post by roguecoder »

monero-xmr wrote: post #51
eloisant wrote: post #42

Earlier quoted context omitted.

1 team supporting multiple services is not great, but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either. That's why I don't like the term "microservice", as it suggests each service should be very small. I don't think it's the case. You can have a distributed system of multiple services of a decent size. I know "services of a decent size" isn't as catchy as…

We solve the problem of 50 devs working in a single monolith with folder and file structure, separation of concerns, basic stuff like this

Part of the problem is that many current programmers came up through functional programming or framework-based development. Microservices are often the first time they encountered modular programming or encapsulation, and so they equate "literally any architecture" with "microservices".

I've worked on monoliths with 400+ developers that were great, but it takes skills that people who have only ever worked in orgs that mandate microservice just don't have.

Re: Microservices are a tax your startup probably can't afford

#66

Post by bluefirebrand »

fallingknife wrote: post #33
asim wrote: post #2

> Microservices only pay off when you have real scaling bottlenecks, large teams, or independently evolving domains. Before that? You’re paying the price without getting the benefit: duplicated infra, fragile local setups, and slow iteration. For example, Segment eventually reversed their microservice split for this exact reason — too much cost, not enough value. Basically this. Microservices are a design pattern for…

There are plenty of tech reasons for microservices. e.g. scaling high traffic services separately and separating low priority functionality from critical paths. I would agree that this is usually not a smart thing to do in a small org, but I have seen times where splitting out a high load path into a microservice has been very much worth it at a startup.

> scaling high traffic services separately

This is a great optimization once you have high traffic services

Building this way before you have any traffic at all is a great way to build the wrong abstractions because your assumptions about where your load will be might be wrong

Re: Microservices are a tax your startup probably can't afford

#67

Post by duxup »

I can't imagine a small team following ALL the rules of microservices benefiting much at all. It makes no sense.

For large orgs where each service has a dedicated team it starts to make sense... but then it becomes clear that microservices are an organizational solution.

Re: Microservices are a tax your startup probably can't afford

#68

Post by ellisv »

mindcrash wrote: post #9

I know about a org with ~2-3 devs who decided microservices would be cool. I warned not to go that way because they would surely face delivery and other issues which they wouldn't have when building the solution based on a architecture archetype which could be a better fit for the team and solution, which I evidently decided should be a modular monolith. (the codebase at that point was already a monolith, in fact, bu…

> 2 years later the rebuild of the old codebase was done. > > 3 years later and they are still fighting delivery and other issues they would never have had if they didn't ignore me and just went for the "lame" monolith.

Sounds to me like every startup.

Re: Microservices are a tax your startup probably can't afford

#69

Post by zbobet2012 »

zsoltkacsandi wrote: post #24
no_wizard wrote: post #3

They have their place. In my experience, a good rule of thumb[0] is if there are actual benefits from being a standalone service. For example, we have a authentication microservice at work. It makes sense that it lives outside of the main application, because its used in a multiple different contexts and the service boundary allows for it to be more responsive to changes, upgrades and security fixes than having it be…

Most “benefits” assumed from separation can be achieved with clear interfaces and modular monoliths, without the cognitive and operational tax microservices impose. > It also adds enough intentional friction that we don't accidentally put logic where it doesn't belong as part of the user authentication process. Preventing misplaced logic is a matter of good code structure, well defined software development processes…

The largest benefit of microservices has always been lifecycle management, and "clear interfaces" in "modular monoliths" does not in fact solve that. If you update the logging library in a monolith, everyone takes that updates even if it breaks half the teams.

That's a "large" organization problem. But large is actually, not that big (about 5-10 scrum teams before this is a very large problem).

It also means on critical systems separating high risk and low risk changes are not possible.

Like all engineering decisions, this is a set of tradeoffs.

Post reply on HN