Microservices are a tax your startup probably can't afford • Hacker News Board

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

#151

Post by roguecoder » Thu, May 08, 2025, 5:18 PM UTC

bitcurious wrote: post #111

I'll go against the grain and say that microservices have advantages for small dev teams embedded in non-tech orgs. 1. You get to minimize devops/security/admin work. Really a consequences of using serverless tooling, but you land on a something like a microservices architecture if you do. 2. You get can break out work temporally. This is the big one - when you're a small team supporting multiple products, you often…

Watch out for bit rot, though: it is very easy for a startup to come back to one of those microservices six months later and discover the dependencies are borked and it no longer even builds.

Each repo you create is one more set of Dependabot alerts you need to keep on top of.

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

#152

Post by motorest » Thu, May 08, 2025, 5:19 PM UTC

roguecoder wrote: post #77

elevatedastalt wrote: post #52

Earlier quoted context omitted.

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.

If it is possible for that other team to merge a broken build, you are doing it wrong. If you are concerned about someone else breaking your thing, good! You were going to eventually break it yourself. Write whatever testing gives you confidence that someone else's changes won't break your code, and, bonus, now you can make changes without breaking your code.

> If it is possible for that other team to merge a broken build, you are doing it wrong.

This assertion is unrealistic and fails to address the problem. The fact that builds can and do break is a very mundane fact of life. There are whole job classes dedicated to mitigate the problems caused by broken builds, and here you are accusing others of doing things wrong. You cannot hide this away by trying to shame software developers for doing things that software developers do.

> Write whatever testing gives you confidence that someone else's changes won't break your code, and, bonus, now you can make changes without breaking your code.

That observation is so naive that casts doubt on whether you have any professional experience developing software. There are a myriad of ways any commit can break something that goes well beyond whether it compiles or not. Why do you think that companies, including FANGs, still hire small armies of QAs to manually verify if things still work once deployed? Is everyone around you doing things wrong, and you're the only beacon of hope? Unreal.

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

#153

Post by roguecoder » Thu, May 08, 2025, 5:19 PM UTC

codr7 wrote: post #143

bob1029 wrote: post #82

Monolith really is the best path and I question if you couldn't make it work in ~100% of cases if you genuinely tried to. One should consider if they can dive even deeper into the monolithic rabbit hole. For example, do you really need an external hosted SQL provider, or could you embed SQLite? From a latency & physics perspective, monolith wins every time. Making a call across the network might as well take an etern…

Containerization unfortunately pretty much killed embedded DBs; it's a shame, because you can squeeze a lot of performance out of not having to access the DB over a network.

Containerization is another thing that is wildly overused by startups that don't yet have the problems it solves.

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

#154

Post by jghn » Thu, May 08, 2025, 5:20 PM UTC

dimal wrote: post #114

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…

I saw one startup with about fifty engineers, and dozens of services. They had all of the problems that the post describes. Getting anything done was nearly impossible until you were in the system for at least six months and knew how to work around all the issues. Here’s the kicker: They only had a few hundred MAUs. Not hundreds of thousands. Hundreds of users. So all this complexity was for nothing. They burned thro…

> They only had a few hundred MAUs

Way too many companies believe they're really just temporarily embarrassed BigTech.

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

#155

Post by elktown » Thu, May 08, 2025, 5:21 PM UTC

pixl97 wrote: post #144

elktown wrote: post #133

Earlier quoted context omitted.

> but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either. Why can the game industry etc somehow manage this fine, but the only place where it's actually possible to adapt this kind of artificial separation over the network, it's somehow impossible not do it beyond an even lower number of devs than for a large game? Suggests confirmation bias to me. The main p…

How many of those game developers are actually art and asset developers? How many times have AAA releases been total crap? How many times have games been delayed by months or years? How many times have games left off features like local LAN play, and instead implemented a 'microservice' as a service for online play? How many times have the console manufactures said "Yea, actually you have the option of running a clie…

Talk about an axe to grind. Are you really implying that AAA releases being bad might be due to not having microservices as a method?

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

#156

Post by [deleted] » Thu, May 08, 2025, 5:23 PM UTC

elktown wrote: post #133

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…

> but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either. Why can the game industry etc somehow manage this fine, but the only place where it's actually possible to adapt this kind of artificial separation over the network, it's somehow impossible not do it beyond an even lower number of devs than for a large game? Suggests confirmation bias to me. The main p…

[deleted]

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

#157

Post by zsoltkacsandi » Thu, May 08, 2025, 5:24 PM UTC

no_wizard wrote: post #38

zsoltkacsandi wrote: post #24

Earlier quoted context omitted.

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…

>Most “benefits” assumed from separation can be achieved with clear interfaces and modular monoliths, without the cognitive and operational tax microservices impose. Perhaps yes. Every situation should be evaluated on merits. This came across that there is also an assumption that we didn't try other solutions first - we absolutely did. Microservice is the best solution to solving the problems we needed solved in this…

> Every situation should be evaluated on merits. This came across that there is also an assumption that we didn't try other solutions first - we absolutely did.

I completely agree. But this a little bit contradicts with your original comment that caught my eye:

> In my experience, a good rule of thumb[0] is if there are actual benefits from being a standalone service.

A rule of thumb is, by nature, a generalization — it simplifies decision making through heuristics. Benefits on the other hand always subjective, they can be interpreted in a given context.

And based on my experience, there will always be some benefits that can be used to justify factoring something out into a separate service. The challenge is that it's often easy to overemphasize those benefits, even when they don't outweigh the downsides. Your example with the auth service and the added friction is, in my view, a good illustration of a justification that might sound reasonable but can lead to unnecessary complexity. (Just to be clear, my intent here isn't to judge your decisions - I understand these trade-offs are often nuanced - and that's why again there is no good rule of thumb for this)

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

#158

Post by roguecoder » Thu, May 08, 2025, 5:25 PM UTC

codr7 wrote: post #149

hereonout2 wrote: post #106

Earlier quoted context omitted.

Are unit tests a shiny fad? Second time I've seen it mentioned in this thread. Is there some other type of testing I should be doing, or have I been doing it all wrong for the last two decades?

Integration testing? Less mocking, more bang for the buck.

I am so mad that the mockists stole the word "unit test" for their thing. The original definition of a unit test was writing "integration" tests for each of the sub-components of a system.

(Mockist tests are fine for people who really want them, as long as you delete them before checking in the code.)

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

#159

Post by sergiotapia » Thu, May 08, 2025, 5:26 PM UTC

gavmor wrote: post #99

sergiotapia wrote: post #64

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.

Ha! I always feel more than a little embarrassed when it happens, but I can't sit idly by while TDD is slandered, especially from so seemingly oblique an angle! While I agree with you regarding microservices (eg language abstractions provide 80% of the encapsulation SOA provides for 20% of the overhead) and I readily acknowledge that 100% test coverage is a quixotic fantasy, I really can't imagine writing reliable so…

i didn't say i don't write tests. i trashed tdd, the practice of tdd is dogma, impractical and unrealistic.

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

#160

Post by addisonj » Thu, May 08, 2025, 5:26 PM UTC

I hope this is more common knowledge these days... but this is good framing and makes really clear the costs.

What this article doesn't cover... and where a good chunk of my career has been, is when companies are driven to break out into services, which might be due to scale, team size, or becoming a multi-product company. Whatever the reason, it can kill velocity during the transition. In my experience, if this is being done to support becoming multi-product, this loss in velocity comes at the worst time and can sink even very component teams.

As an industry, the gap between what makes sense for startups and what makes sense for scale can be a huge chasm. To be clear, I don't think it means you should invest in micro-services on the off-chance you need to hit scale (which I think is where many convince themselves of) nor does it mean that you should always head to microservices even when you hit those forcing functions (scaling monoliths is possible!)

That said, modularity, flexibility, and easy evolution are super important as companies grow and I do really think the next generation of tools and platforms will be benefit to better suiting themselves to evolution and flexibility than they do today. One idea I have thought for some time is platforms that "feel" like a monolith, but are 1) more concrete in building firmer interfaces between subsystems and 2) have flexibility in how calls happen between these interfaces (imagine being able to run a subsystem embedded or transparently to move calls over an RPC interface). Certainly that is "possible" with well structured code in platforms today... but it isn't always natural.

I am not sure the answer, but I really hope the next 10 years of my career has less massive chasms crossed via huge multi-year painful efforts and more cautious, careful evolution enabled by well considered tool and platforms.