3 ms·

I keep hearing monoliths are returning, without any indication of what has improved to make big single apps more manageable? All the same problems are there, s

by gedy 2y ago

I keep hearing monoliths are returning, without any indication of what has improved to make big single apps more manageable? All the same problems are there, so seems like this is just fashion trends tbh. Yes if you have some small saas app don't go crazy with tiny interdependent services prematurely. But if/as you grow in team size, functionality, get out of here with your "majestic monoliths".

Bjartr 2y ago
It's just the pendulum swinging back the other way. Nothing has changed, we just have a generation of engineers that grew up buying into the microservices as panacea narrative who are more mature and are teaching the next generation not to make the mistakes they did without the awareness that that's what the generation before them was trying to do for them. Both approaches are valid, there is no silver bullet. Critical thinking will always be necessary to choose the right approach, though perhaps an ai will be the one doing that for the next next generation.
jiggawatts 2y ago
Package management has become a turnkey solution even in large enterprises. I know Microsoft is just a myth and doesn't exist, but Azure DevOps has a built-in artefact repository that plugs directly into Visual Studio with MFA+SSO authentication for secure private access. It Just Works, making it much easier to deploy a monolith where the versioning and rollback of individual components can be independently managed in a sane way. Similarly, as long as deployment pipelines are fully automated and run fast enough, it doesn't really matter when different teams deploy their module changes. Just increment or decrement a version number in some package.json type file and press play on the pipeline! This works well enough up to the scale of a few hundred engineers. Microservices start to make a lot of sense past a thousand developers, especially when individual services start to require the equivalent capacity of a large number of servers.
- SOLAR_FIELDS 2y ago
  According to the former CTO of GitHub, the need for an org to use monorepo vs microservices is dependent on the scaling size: https://news.ycombinator.com/item?id=33601658 https://news.ycombinator.com/item?id=33601658 According to him, startups work better in monorepos. Microservices work better for medium to large size organizations. Monorepos again for Google size mega orgs. In the end, its a dumb debate. Because it’s a tooling problem, not a code organization problem. It doesn’t matter which you pick, your success or failure in the organization pattern is entirely dependent on how much you invest in tooling and whether that is microservices tooling or monorepo tooling matters not. Anytime you see someone complaining about one or the other and you ask them why, the answer always can be resolved with better tooling.
  - jiggawatts 2y ago
    The dependency on scaling size is precisely my point. There's fuzzy boundaries where one or another approach starts making sense. If you don't know where those boundaries are, if you don't know what business requirements are going into these decisions, then keep things as simple as possible until you do. In other words, don't try to build an airport before you've understood what an aeroplane even is! Quite recently I saw a completed(!) web application project split up into microservices because the enterprise architect insisted that this was the only acceptable approach, and a monolith was "wrong" somehow. A staggering amount of time, money, and effort was expended to basically make a functioning application worse in every possible way. Nobody could understand it, and the EA couldn't explain other than just waving his hands about and making vague, unspecific noises.
    - SOLAR_FIELDS 2y ago
      My point here is that ultimately it doesn’t really matter. You can make either work at scale (Spotify for microservices, Google for monorepo). So don’t even bother thinking about it too much, just make a decision and start investing in tooling. Which I think is your same statement here. Ultimately I’m going to ask whoever proposed micro services vs monorepo is: how are you going to qualify shared changes? How are you going to publish artifacts? How are you going to document things and make them reusable? There are ways to do so in both approaches. If someone isn’t answering those questions and weighing them against the effort required to implement only the tooling changes without the application code changes, they’re missing the point and are at risk of just wasting everyone’s time remaking the same mistakes that their predecessors made (not investing in tooling) that prompted the discussion about moving from one to the other in the first place.

by gedy 2y ago

Bjartr 2y ago

It's just the pendulum swinging back the other way. Nothing has changed, we just have a generation of engineers that grew up buying into the microservices as panacea narrative who are more mature and are teaching the next generation not to make the mistakes they did without the awareness that that's what the generation before them was trying to do for them. Both approaches are valid, there is no silver bullet. Critical thinking will always be necessary to choose the right approach, though perhaps an ai will be the one doing that for the next next generation.

jiggawatts 2y ago

Package management has become a turnkey solution even in large enterprises. I know Microsoft is just a myth and doesn't exist, but Azure DevOps has a built-in artefact repository that plugs directly into Visual Studio with MFA+SSO authentication for secure private access. It Just Works, making it much easier to deploy a monolith where the versioning and rollback of individual components can be independently managed in a sane way. Similarly, as long as deployment pipelines are fully automated and run fast enough, it doesn't really matter when different teams deploy their module changes. Just increment or decrement a version number in some package.json type file and press play on the pipeline! This works well enough up to the scale of a few hundred engineers. Microservices start to make a lot of sense past a thousand developers, especially when individual services start to require the equivalent capacity of a large number of servers.

SOLAR_FIELDS 2y ago
According to the former CTO of GitHub, the need for an org to use monorepo vs microservices is dependent on the scaling size: https://news.ycombinator.com/item?id=33601658 https://news.ycombinator.com/item?id=33601658 According to him, startups work better in monorepos. Microservices work better for medium to large size organizations. Monorepos again for Google size mega orgs. In the end, its a dumb debate. Because it’s a tooling problem, not a code organization problem. It doesn’t matter which you pick, your success or failure in the organization pattern is entirely dependent on how much you invest in tooling and whether that is microservices tooling or monorepo tooling matters not. Anytime you see someone complaining about one or the other and you ask them why, the answer always can be resolved with better tooling.
- jiggawatts 2y ago
  The dependency on scaling size is precisely my point. There's fuzzy boundaries where one or another approach starts making sense. If you don't know where those boundaries are, if you don't know what business requirements are going into these decisions, then keep things as simple as possible until you do. In other words, don't try to build an airport before you've understood what an aeroplane even is! Quite recently I saw a completed(!) web application project split up into microservices because the enterprise architect insisted that this was the only acceptable approach, and a monolith was "wrong" somehow. A staggering amount of time, money, and effort was expended to basically make a functioning application worse in every possible way. Nobody could understand it, and the EA couldn't explain other than just waving his hands about and making vague, unspecific noises.
  - SOLAR_FIELDS 2y ago
    My point here is that ultimately it doesn’t really matter. You can make either work at scale (Spotify for microservices, Google for monorepo). So don’t even bother thinking about it too much, just make a decision and start investing in tooling. Which I think is your same statement here. Ultimately I’m going to ask whoever proposed micro services vs monorepo is: how are you going to qualify shared changes? How are you going to publish artifacts? How are you going to document things and make them reusable? There are ways to do so in both approaches. If someone isn’t answering those questions and weighing them against the effort required to implement only the tooling changes without the application code changes, they’re missing the point and are at risk of just wasting everyone’s time remaking the same mistakes that their predecessors made (not investing in tooling) that prompted the discussion about moving from one to the other in the first place.