Hacker News Reader

Comment by m_a_g | Hacker News Reader

It looks like monoliths are officially back in fashion.

When I researched it(around 2017), most microservices sucess stories began with "our monolith couldn't scale beyond our 200 devs, 300000 clients and 150 millions of revenue per year, so we had to do something".

So, how did you manage to go from nothing to 200 devs/300000 clients/150M of revenue? Exactly, with a monolith.

Getting to market so you can get the next found of funding or start making a profit is always in fashion.

Whether you did it perfectly right once you get there is the correct "technical debt" problem to have as a burden.

"We're very worried about tech debt. If we don't get this perfect now, we'll forever be flailing around trying to make it work even as other teams add worse baggage to the wrong pattern you laid down. We'll never have time to go back and fix it."

-- No one ever.

This made me think of Twitter's "fail whale". And then I remembered that mess of spaghetti PHP sold for 44 billion dollars and now I'm rethinking my life.

I dont think they were ever “out of fashion”, it’s just that the people pushing microservices were extremely vocal about it.

Indeed. I never understood how they got synonymous to "big ball of mud". When I think of a monolith, I think of something heavy with a very simple structure like the Washington Monument.

The older I get, the more I understand my seniors.

Welcome to seniorhood. Also get out of my lawn.

I do worry the pendulum will swing too far the other way. Having a separate Lambda function for every web request "because microservices" sucks, but having a single codebase worked on by 200+ engineers also comes with a lot of problems.

Exactly, I do appreciate micro services but not for the technical aspect.

They shine in large cove base where at least a handful of teams are responsible for some services and not other.

So you don’t have to get in there backlog too much.

Have a folder/subproject per team?

This helps, but doesn't fully solve the problem. You still end up using the same runtime so it's not like the teams are fully independent. Classic problem is you have a /Team1 and /Team2 folder (or library that gets imported, doesn't matter). Team1 needs to upgrade to pandas 2. They try, but wait, Team2's code depends on Tensorflow which depends on pandas 1.x. You are now in dependency hell[0] and need to do something unpleasant, whether that's forcibly updating everything in that pandas/TF/etc dependency chain, which can be a long and painful project in large codebases, if it gets done at all. Or doing JAR shading or fork-and-rename to be able to support both pandas==1.x and pandas=2 in the same runtime, which may not even work in pandas' case. Or the most common thing, which is just give up and stick with comically outdated libraries and runtimes for way too long. Hello, Java 6/7.

[0] https://en.wikipedia.org/wiki/Dependency_hell

No suggestion will fully solve all the problems. Are you looking for silver bullets in HN comments? :)

I would rather deal with folder per team in same repo than services spread across multiple repos that still depend on common libraries/utilities/databases, which has happened at most jobs I've had, and it's a mess.

lol

I work on a single codebase with 2000+ engineers

I wish blogger driven development would go out of fashion, but I guess it never will. People need to be engineers. Stop trying to figure out how to solve your problem by copying what others have done to solve theirs.

This. It's hard to manage a dozen services with only 1-2 devs - especially considering you're solving a problem you don't have yet, and by the time you do, you'll have more devs to handle/justify the complexity.

Reply on news.ycombinator.com