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

71–80 of 272 posts

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

#71

Post by bunderbunder »

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

This is really what it comes down to right here. The real challenge is Conway's Law. Both the software architecture and the org chart need to be designed with Conway's Law in mind. If that hasn't happened then deciding between microservices and monolith is ultimately just deciding how you will be punished for your mistake.

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

#72

Post by dkkergoog »

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…

[dead]

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

#73

Post by alaithea »

candiddevmike wrote: post #6
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…

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.

And when it's your technical leadership leveraging buzzword-driven development to rise to the top, you're screwed.

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

#74

Post by xcskier56 »

Microservices make sense from a technical perspective in startups if:

- You need to use a different language than your core application. E.g. we build Rails apps but need to use R for a data pipeline and 100% could not build this in ruby.

- You have 1 service that has vastly different scaling requirements that the rest of your stack. Then splitting that part off into it's own service can help

- You have a portion of your data set that has vastly different security and lifecycle requirements. E.g. you're getting healthcare data from medicare.

Outside of those, and maybe a few other edge cases, I see basically no reason why a small startup should ever choose microservices... you're just setting yourself up for more work for little to no gain.

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

#75

Post by dkarl »

My current take on microservices is that people pay serious attention to modularity and API design in the context of microservices. They work hard to break down the problem properly and design good interfaces between parts of the system.

In monoliths, they generally don't.

There's no logical reason why you couldn't pay as much attention to decomposition and API design between the modules of a monolith. You could have the benefit of good design without all the architectural and operational challenges of microservices. Maybe some people succeed at this. But in practice I've never seen it. I've seen people handle the challenges of microservices successfully, and I've never seen a monolith that wasn't an incoherent mess internally.

This is just my experience, one person's observations offered for what they're worth.

In practice, in the context of microservices, I've seen an entire team work together for two weeks to break down a problem coherently, holding off on starting implementation because they knew the design wasn't good enough and it was worth the time to get it right. I've seen people escalate issues with others' designs because they saw a risk and wanted to address it.

In the context of monoliths, I've never seen someone delay implementation so much as a day because they knew the design was half-baked. I rarely see anyone ask for design feedback or design anything as a team until they've screwed something up so badly that it can't be avoided. People sometimes make major design decisions in a split second while coding. What kind of self-respecting senior developer would spend a week getting input on an internal code API before starting to implement? People sometimes aren't even aware that the code they wrote that morning has implications for code that will be written later.

Theoretically this is okay because refactoring is easy in a monolith. Right? ... It is, right?

I'm basically sold on microservices because I know how to get developers to take design seriously when it's a bunch of services talking to each other via REST or grpc, and I don't know how to get them to take the internal design of a monolith seriously.

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

#76

Post by monero-xmr »

mjr00 wrote: post #61
monero-xmr wrote: post #51

Earlier quoted context omitted.

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.

All of that is so much easier with a single monorepo

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

#77

Post by roguecoder »

elevatedastalt wrote: post #52
singron wrote: post #12

Earlier quoted context omitted.

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

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.

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

#78

Post by echelon »

didip wrote: post #58

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.

If your application has different load or resource requirements, you should build separate services, even in a startup.

You can put most of your crud and domain logic in a monolith, but if you have a GPU workload or something that has very different requirements - that should be its own thing. That pattern shouldn't result in 100 services to maintain, but probably only a few boundaries.

Bias for monolith for everything, but know when you need to carve something out as its own.

At scale, you're 100% correct.

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

#80

Post by parpfish »

I’ve read a lot of pros/cons about micro services over the last decade, but don’t have a clear definition for what qualifies.

My current job insists that they have a “simple monolith” because all the code is in a single repo. But that repo has code to build dozens of python packages and docker containers. Tons of deploy scripts. Different teams/employees are isolated to particular parts of the codebase.

It feels a lot like microservices, but I don’t know what the defining feature of microservices is supposed to be

Post reply on HN