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

161–170 of 272 posts

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

#161

Post by danielscrubs »

jghn wrote: post #154
dimal wrote: post #114

Earlier quoted context omitted.

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.

Bad software dev. degrees that focus on fancy architecture that brings nothing to the table except overhead.

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

#162

Post by bunderbunder »

roguecoder wrote: post #94
bunderbunder wrote: post #71

Earlier quoted context omitted.

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.

People misunderstanding Conway's Law is a big part of the problem for sure. The law says nothing about team boundaries: it talks about communication pathways. The paranoid socialist in me thinks big companies like team-sized microservices because it lets them prevent workers from talking to each other without completely ruling out producing running software. When companies instead encourage forums for communication a…

If team boundaries aren't a major influence on your communication pathways, what on earth do you even mean by "team"?

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

#163

Post by bcrosby95 »

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…

Note that the game's industry uses the term 'developer' differently. If a game has X developers, the vast majority of those people are not programmers. Engines also do a lot to empower non-programmers to implement logic in video games, taking lots of the workload off of programmers.

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

#164

Post by roguecoder »

motorest wrote: post #152
roguecoder wrote: post #77

Earlier quoted context omitted.

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…

I haven't seen a broken build in at least nine years, not since I left the company with a merge process built out of bash scripts that took three hours and required manual hand-holding.

I am genuinely curious what situations you are seeing where builds are making it through CI and then don't compile.

It isn't always worth investing in quality, but when it is it is entirely possible to write essentially bug-free software. I've gone seven months without a bug in production and the one we saw we had a signed letter from product saying "I am okay if this feature breaks, because I think writing the tests that can verify this integration was going to take too long."

FAANG companies aren't prioritizing writing software well: they are prioritizing managing 50,000 engineers. Which is a much harder problem, but the management solutions that work for that preclude the techniques that let us write bug-free software.

One of the great things about startups is that it is trivial to manage five engineers, so there is no reason we have to write software badly.

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

#167

Post by dec0dedab0de »

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 generally agree, but there are some decent use cases for one team to have multiple services micro or otherwise:

1. when the requirements are better served by a different language/location/environment/platform.. or by deploying a 3rd party app.

2. some of the services need to quickly scale up and down, and you have enough traffic for it to be worth it.

3. if you have a tight SLA for parts of the app but not all of it.

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

#168

Post by roguecoder »

tuckerman wrote: post #90
roguecoder wrote: post #77

Earlier quoted context omitted.

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.

Even if it builds successfully, I've never worked anywhere where automated tests prevented 100% of problems and I doubt I ever will. For most systems of sufficient complexity you are testing in prod, even if you did a lot of testing before prod as well.

That's even more true for microservices, though, since I have yet to see a microservice architecture that automatically runs end to end tests before deploying.

The post I was replying to said "your build will still break": that's what I was taking issue with. In this day and age there is no reason our trunk build should ever be broken.

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

#169

Post by Capricorn2481 »

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…

> How many times have AAA releases been total crap?

> How many times have games been delayed by months or years?

What are we arguing here? Because I can think of many microservice apps that are crap as well, and have no velocity in development.

> How many times have games left off features like local LAN play, and instead implemented a 'microservice' as a service for online play?

This is entirely irrelevant. We're talking about the trade-offs of separating networked services that could otherwise be one unit. You're saying "why do games have servers then" which is a befuddling question with an obvious answer.

That's like saying my web server is a Microservice because it's not run in my clients browser. It makes no sense.

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

#170

Post by dec0dedab0de »

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

Don't know why you're downvoted, but this is the way.

Even if you're using micro services, it's usually best to have them in the same repo organized into different directories.

No matter how many people you have, you really should minimize working on the same files concurrently. This is trivial with most languages

Post reply on HN