Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Build the Modular Monolith First

fearofoblivion.com

Post reply on HN
Print view View original

61–70 of 90 posts

Re: Build the Modular Monolith First

#61

Post by mberning »

afhammad wrote: post #27
mberning wrote: post #21

I have long running ruby and java apps that I use for this purpose. They have build scripts, test frameworks, etc. When I get an idea for something new I add them to one of these existing projects, but I do it in a way that I can easily excise it in the future.

Curious to hear more. Are these personal projects or serving users? What are some examples of unrelated ideas you’ve tacked on to existing app servers?

It’s mostly enterprise stuff. I have a local rails app and local springboot app that I keep around and am constantly trying stuff out in. If it starts to look like it would be generally useful I will rip it out, put it in it’s own repo, set it up in a jenkins pipeline, and then have the jar/gem published to an internal artifactory instance. Then I can just include the jar or gem in other codebases as needed. Works great and keeps me from doing a bunch of boilerplate for something which may go nowhere.

Re: Build the Modular Monolith First

#62

Post by drittich »

jameshart wrote: post #15

There are more than two architectures. I agree if you don’t have organizational scale, microservices solve problems you don’t have. But there are at least three separate things that are ‘monolithic’ about a classical monolith. 1) the codebase, 2) the database, and 3) the build and release process. And you can certainly modularize your codebase into libraries or independent modules, but retain monolithic builds and re…

I would add 4) documentation to that list. A wiki full of docs is the closest analog I've seen to a monolith ball of mud codebase.

Re: Build the Modular Monolith First

#63

Post by simplotek »

eeperson wrote: post #45
KyeRussell wrote: post #36

Earlier quoted context omitted.

I think a (but not the only) central conceit of a microservices architecture is that most development teams cannot be trusted to maintain proper separation of concerns, and enforcing at a technical level the inability to call Any Old Function is a big part of what you’re buying into.

This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices? In theory the extra work of making an API call would give you smaller bowls of spaghetti. However, once you add some abstraction to making these calls it seems like developers are empowered to make the same mess. Except now it is slower and harder to…

> This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices?

It's far harder to update multiple services to handle requests they should not handle, let alone update a deployment to allow those requests to happen.

Walls make great neighbors, just like multiple services make teams great at complying with an architecture constraint.

Re: Build the Modular Monolith First

#64

Post by dontlaugh »

jameshart wrote: post #30
jrochkind1 wrote: post #12

This is written like it's a novel take bucking the trend, but I feel like most things I have seen on this topic for at least several years now have the same observations and conclusions? If anyone wants to actually speak up for microservices, I feel like that's what needs a defense at this point!

I think anyone who has taken a large monolith through a significant platform version upgrade or change, like .NET 2 to .NET 4, or Python2 to Python3, or Angular to React, would need a very persuasive argument to make them believe that starting a new project with a monolithic design was a good idea.

Having upgraded both kinds of projects to Python 3, the monoliths were far simpler to deal with.

Re: Build the Modular Monolith First

#65

Post by simplotek »

basicallybones wrote: post #39

Microservices vs. monoliths is a false dichotomy in the present day. If you put microservices in a monorepo with a good build tool (like NX), put the common auth/logging/types/dtos/etc. functions in reusable libs, and version/release all the apps together, you get the best of both worlds. At a small scale, you can deploy your whole containerized stack on two big HA instances (monolithic infrastructure, so much easier…

> If you put microservices in a monorepo (...)

What exactly do you gain with this approach, other than pinning versions of all microservices?

Any competent team working on services does not suffer from "versioning hell" because APIs are stable and tracked with integration tests and smoke tests, and you version the API and not the code.

Re: Build the Modular Monolith First

#66

Post by steveBK123 »

mbrodersen wrote: post #51

A colleague of mine is working on one of the worst software systems I have ever seen or heard of. It is a 20+ years old micro-services architecture. More than 50 services all interacting with each other in mysterious time dependent ways. It is almost impossible to debug or reason about. It took him most of a year to figure out how to reliably and automatically build and boot the system from scratch. I have worked on…

I think team size / responsibility is a big part of choosing how much you need to go down the micro service route as well. I've recently launched on a ~2 dev team, and leaning more and more towards monolith the longer we go.

The worst teams I have been on are the ones with multiples (~5x) as many repos & running services as we have developers.

Huge swathes of repos would go without commits, builds or releases for years. Inevitably the next time you had business requirements on that repo, something in CI/CD or environment had changed enough that you had to do a bunch of devops/infra/non-business work to get the plumbing working again to even start the task.

Even in teams where we eventually had nice central utilities & libraries with versioned dependencies, you never had the chance to do enough "catch up" releases to keep all 100 repos on some reasonably recent version of the core libraries. So the cost to activate some new observability function from your central libs was huge because you needed to make small changes on 50+ repos otherwise the observability was pointless since it had low coverage.

Re: Build the Modular Monolith First

#67

Post by thunky »

simplotek wrote: post #63
eeperson wrote: post #45

Earlier quoted context omitted.

This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices? In theory the extra work of making an API call would give you smaller bowls of spaghetti. However, once you add some abstraction to making these calls it seems like developers are empowered to make the same mess. Except now it is slower and harder to…

> This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices? It's far harder to update multiple services to handle requests they should not handle, let alone update a deployment to allow those requests to happen. Walls make great neighbors, just like multiple services make teams great at complying with an arc…

> Walls make great neighbors

I think you're trying to solve a communication problem with a technical solution, which is a recipe for trouble.

If multiple teams working on interdependent components can't communicate well enough to keep from stepping on each other's toes, imposing technical barriers probably isn't going to make things better. Especially once you inevitably realize that you put the walls in the wrong place and functionality has to move across borders, which is now a major pain because you've intentionally made it hard to change.

Re: Build the Modular Monolith First

#68

Post by tiberriver256 »

theptip wrote: post #3

The assertion that monoliths are taboo is a bit odd; “monolith first” has been pragmatic best practice for years: https://martinfowler.com/bliki/MonolithFirst.html .

Majority of people I work with think that there are only two architectures. Monolith and microservices. Microservices is the good architecture. Monolith is the bad architecture.

Such a sad trend :( but seems to be very prevalent

Re: Build the Modular Monolith First

#70

Post by zabhi »

thunky wrote: post #67
simplotek wrote: post #63

Earlier quoted context omitted.

> This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices? It's far harder to update multiple services to handle requests they should not handle, let alone update a deployment to allow those requests to happen. Walls make great neighbors, just like multiple services make teams great at complying with an arc…

> Walls make great neighbors I think you're trying to solve a communication problem with a technical solution, which is a recipe for trouble. If multiple teams working on interdependent components can't communicate well enough to keep from stepping on each other's toes, imposing technical barriers probably isn't going to make things better. Especially once you inevitably realize that you put the walls in the wrong pl…

> If multiple teams working on interdependent components can't communicate well enough to keep from stepping on each other's toes, imposing technical barriers probably isn't going to make things better.

But it actually does, and there is a lot of data to prove it. When you have a big project and a bunch of teams, the first thing you build is boundaries / walls. Then you get to defining interfaces between interdependent services. And this frees them up to get hacking on their modules in parallel - without stepping on each others' toes. Communication would have definitely helped, but it is way easier for smaller teams to own and operate their services and try to get a big organization plough through a big mess.

That said, microservices are just one way to solve a problem, and not always the right way. But there is always a place where you would look at the problem, the organization that is tasked to solve it, and it would fit just right in.

Post reply on HN