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

51–60 of 272 posts

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

#51

Post by monero-xmr »

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…

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

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

#52

Post by elevatedastalt »

singron wrote: post #12
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…

> You'll have a monolith, it might break out into frontend, backend and a separate service for async background jobs And when you break these out, you don't actually have to split your code at all. You can deploy your normal monolith with a flag telling it what role to play. The background worker can still run a webserver since it's useful for healthchecks and metrics and the loadbalancer will decide what "roles" get…

If you are building the same binary for all microservices you lose the dependency-reduction benefit microservices provide, since your build will still break because of some completely unrelated team's code.

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

#53

Post by DarkNova6 »

roguecoder wrote: post #49

You only need microservices for massive scale or to enable micromanagement of teams, but that doesn't mean you have to give up on clear module boundaries. You can get the architectural benefits of microservices by using message-passing-style Object-Oriented programming. It requires the discipline not to reach directly into the database, but assuming you just Don't Do That a well-encapsulated "object" is a microservic…

Or you have a good understanding of your logical boundaries and enforce them with ArchUnit.

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

#54

Post by siliconc0w »

The biggest wins for microservices aren't really technical, they're organizational. They force you to break a problem down and allow each team to own a piece of it, including end to end delivery. This allows specialization of labor which is a key driver of productivity - including an ability to experiment and innovate. Every change is incremental by default, and well-documented external APIs are the only way to talk to other domains- no shared databases, filesystems, or internal APIs. It's not free and definitely takes some discipline and tooling to enforce shared standards (every service should have metrics, logging, tracing, discovery, testing, CI/CD, etc) but you'd need to build that muscle with a monolith as well.

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

#56

Post by roguecoder »

abirch wrote: post #30
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…

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.

I mean, "GREAT" until you need to do any kind of refactoring, or the company grows, or shrinks, or reorgs, or you have a feature that needs to change more than one service.

The "one team per microservice" makes code-enclosure style code ownership possible, but it is the least efficient way I have ever seen software written.

I've long wanted to hack an IDE so people are only allowed to change the Java objects they created, and then put six Java programmers in a room and make them write an application, yelling back and forth across the room. "CAN YOU ADD A VERSION OF THAT METHOD THAT ACCEPTS THIS NEW CLASS?" "SURE THING! TRY THAT?"

People discount the costs of microservices because they makes management's job easier, especially when companies have adopted global promotion processes. But unless they are solving a real technical constriant, they are a shitty way to work as an engineer.

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

#57

Post by sitkack »

monero-xmr wrote: post #34

My friend briefly worked at a company where every API was a lambda. Each lambda had a git repo. Lambdas would often call into other lambdas. In order to make a feature, it might involve touching 10+ lambdas. They had over 200 lambdas after a year. Total nightmare

I think the major issue that I see, and I could be wrong is that if you want to change some underlying functionality between you and a dependent function to do that you would need to change all the intermediate functions only so that you could call that dependent function and layers deep.

I have played around with architectures like this, but I allowed the caller to patch in a dependent function in the call with those function overlay overrides were passed from function to function.

Apologies, used sst

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

#58

Post by didip »

Micro services show their benefits in a large organization.

It’s a tool to solve people issues. They can remove bureaucratic hurdles and allow devs to somewhat be autonomous again.

In a small startup, you really don’t gain much from them. Unless if the domain really necessitates them, eg. the company uses Elixir but all of the AI toolings are written in Python/Go.

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

#59

Post by __MatrixMan__ »

abirch wrote: post #30
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…

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.

As long as that team built those microservices to solve whatever problem they're responsible for solving I think it's better to let the problem domain dictate how many you need. Better to have seams that make sense in terms of the surrounding code than to have them in arbitrary places based on the org chart.

The trouble comes when some political wind blows and reshuffles the org chart, and now you're responsible for some services that only made sense in the context of a political reality that no longer exists.

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

#60

Post by Espressosaurus »

devin wrote: post #15
candiddevmike wrote: post #6

Earlier quoted context omitted.

Some resume driven developers will choose microservices for startups as a way to LARP a future megacorp job. Startup may fail, but they at least got some distributed system experience. It takes extremely savvy technical leadership to prevent this.

In my experience, it seems the majority of folks know the pitfalls of microservices, and have since like... 2016? Maybe I'm just blessed to have been at places with good engineering, technical leadership, and places that took my advice seriously, but I feel like the majority of folks I've interacted with all have experienced some horror story with microservices that they don't want to repeat.

I feel like it's only in the last 5 years in the tech publicity sphere that I've seen pushback against microservices, only it feels like only the last year or two where I see it to the exclusion of influencers pushing microservices.

Things are different in the embedded space so I don't have personal experience with any of it.

Post reply on HN