Hacker News Reader

Comment by Cthulhu_ | Hacker News Reader

This is why I'm mainly focusing on the application side of things; container technology is 'just' the runtime. I'm making sure my stuff is sane, that it runs on anything. Others can worry about containerization / the runtime.

But I'm getting the feeling that a lot of people worry a lot about the runtime. They break up their applications into microservices not to solve a problem, but because they believe it's the best thing to do because $reason. But you shouldn't do that until you're actually running into an issue and have exhausted the other, simpler options.

I mean I wouldn't mind having or experiencing an actual scaling problem directly, but so far I've never seen it. I've seen a LOT more organizational and technical problems stemming from intentionally building a microservices architecture though.

But building just the one codebase is dull.

View on HN

The three most common $reasons I see are: 1) They believe it will help them attract engineering talent, assuming many want to work in a micro services architecture. 2) They believe it will impress investors that they use micro services or be be a red flag to tell investors that their architecture is a monolith. 3) They believe their company will be HUGE one day and that it is therefore wise to prepare for scale now.

But as you can see in the comments in this thread. The coolness of micro services seems to be slowly fading. Feels a bit like the state of noSQL in 2014.

For most applications this is correct. Especially those that a homogeneous like a CRUD productivity app, etc.

But when you are building systems it becomes slightly more complicated. Especially those that require that the data science team write their code in Python / PyTorch and the application team write their code in Typescript.

$reason = Make the microservices independent of each other, so you can rewrite and replace them without much trouble when they're getting old.

This is just modularisation though. You can modularise without microservices. Microservices solve a scaling problem, not a design flexibility problem.

Micro services often solve _an organizational scaling_ problem, and are less frequently deployed for _performance scaling_.

a monorepo also solves that same organisational scaling problem, but without introducing the artificial problem of basic function calls having to traverse the network, and having to keep tons of different services online and talking to each other.

Since servers are ephemeral, any function call of note will need to traverse the network in some way anyway.

that's true, but there's traversing 2 links for a simple client<->server<->database setup, or traversing dozens or even hundreds of links for a microservice architecture, adding tons of fragility for no unique benefit.

Well, there are legitimate benefits, it's just that few organizations are poised to understand/utilize them.

Yeah, but it turns out people can’t actually write software right (or won’t) and this sort of network boundary is the only way to force them to write modular code, without the monolith collapsing into a tangled mess.

It’s really annoying.

yes one of the biggest problems in software development is that most developers are bad at their jobs.

the solution, however, would be to hire a small number of really good developers and have code reviews run through them - hopefully teaching the more average developers how to code better in the process.

It’s so simple. You just need to devise the world’s first 100% predictive interview process

I wish it were easy. The most important things to do are usually pretty hard, or they'd be done already.

The flip side to that is that you end up with a dozen services built with different technologies/languages and you spend all your time upgrading them or replacing them instead of building new features.

At least one of them will be guaranteed to be built with some technology/language (probably Scala or Elixir) that one of your engineers (who's since left) was interested in for a few weeks.

Reply on news.ycombinator.com