7 ms·

It looks like monoliths are officially back in fashion.

by m_a_g 3y ago

weego 3y ago
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.
- NoMoreNicksLeft 3y ago
  "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.
  - letsdothisagain 3y ago
    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.
malikNF 3y ago
The older I get, the more I understand my seniors.
- javcasas 3y ago
  Welcome to seniorhood. Also get out of my lawn.
jcadam 3y ago
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.
tacker2000 3y ago
I dont think they were ever “out of fashion”, it’s just that the people pushing microservices were extremely vocal about it.
rwoerz 3y ago
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.
mjr00 3y ago
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.
- dopidopHN 3y ago
  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.
- winrid 3y ago
  Have a folder/subproject per team?
  - mjr00 3y ago
    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 https://en.wikipedia.org/wiki/Dependency_hell
    - winrid 3y ago
      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.
JustSomeNobody 3y ago
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.
javcasas 3y ago
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.

It looks like monoliths are officially back in fashion.

by m_a_g 3y ago

It looks like monoliths are officially back in fashion.

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.

NoMoreNicksLeft 3y ago
"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.
- letsdothisagain 3y ago
  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.

malikNF 3y ago

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

javcasas 3y ago
Welcome to seniorhood. Also get out of my lawn.

jcadam 3y ago

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.

tacker2000 3y ago

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

rwoerz 3y ago

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.

mjr00 3y ago

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.

dopidopHN 3y ago
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.
winrid 3y ago
Have a folder/subproject per team?
- mjr00 3y ago
  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 https://en.wikipedia.org/wiki/Dependency_hell
  - winrid 3y ago
    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.

JustSomeNobody 3y ago

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.

javcasas 3y ago

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.