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

Don't start with microservices – monoliths are your friend

arnoldgalovics.com

Post reply on HN
Print view View original

291–300 of 468 posts

Re: Don't start with microservices – monoliths are your friend

#291

Post by geekbird »

salt-thrower wrote: post #289
overgard wrote: post #284

IMO, the big advantage of microservices over monoliths (if they're done right) is reducing iteration times. It's just a lot quicker to build/run/etc. I think monoliths are a fine starting point but once your iteration times get slow, that's when it's time to break it up.

It's a big tradeoff for maintenance complexity and cognitive load though, and people often don't realize how big that tradeoff is. Chasing bugs and maintaining the spiderweb of network connections between all your services can quickly become a nightmare. A distributed ball of mud instead of a monolithic ball of mud, but a ball of mud nonetheless. Personally I lean towards building a monolith first, then breaking out…

"But I've worked on teams that advocated for microservices needlessly, and it was 100% cargo cult behavior: "Netflix does it, so we should too."

I've seen this too, and in fact I got laid off because I pushed back against this silliness for what should have been a simple lift and shift.

Re: Don't start with microservices – monoliths are your friend

#292

Post by sbysb »

rco8786 wrote: post #257
ozim wrote: post #229

Earlier quoted context omitted.

Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…

> Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Yes! Thank you. The "modular monolith" is just "decent separation of concerns in your code" and should be there from the start.

I would actually disagree - to me you can have "decent separation of concerns in your code" but still have only built the app to support a single entry point. "Modular monolith" to me is a system that is built with the view of being able to support multiple entry points, which is a bit more complex than just "separating concerns"

Re: Don't start with microservices – monoliths are your friend

#293

Post by Retric »

jameshart wrote: post #288
ozim wrote: post #229

Earlier quoted context omitted.

Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…

The interesting thing about microservices is not that it lets you split up your code on module boundaries. Obviously you can (and should!) do that inside any codebase. The thing about microservices is that it breaks up your data and deployment on module boundaries. Monoliths are monoliths not because they lack separation of concerns in code (something which lacks that is not a ‘monolith’, it is what’s called a ‘big b…

Monoliths don’t actually look like that at scale. For example you can easily have multiple different data stores for different reasons, including multiple different kinds of databases. Here’s this tiny little internal relational database used internally, and there’s the giant tape library that’s archiving all this scientific data we actually care about. Here’s the hard real time system, and over there’s the billing data etc etc.

The value of a monolith is it looks like a single thing from outside that does something comprehensible, internally it still needs to actually work.

Re: Don't start with microservices – monoliths are your friend

#294

Post by geoffjentry »

asimpletune wrote: post #46

Your code base should reflect the organization of people working on it. Virtually all technical merits are outweighed by that.

This is Conway's Law.

It is why the Reverse Conway is preached. Define your desired architecture, and fit your organization to fit it. At that point your code base will reflect the organization of people working on it, and the output will reflect the desired architecture.

Re: Don't start with microservices – monoliths are your friend

#295

Post by dralley »

sokoloff wrote: post #261
ravenstine wrote: post #238

Earlier quoted context omitted.

> monolith was always supposed to be MODULAR from the start Well, that certainly is sensible, but I wasn't aware that someone had to invent the monolith and define how far it should go. Alas, my impression is that the term "monolith" doesn't really refer to a pattern or format someone is deliberately aiming for in most cases, but instead refers to one big execution of a lot of code that is doing far more than it shou…

> or is reasonable for one repository to manage The amount of code one repository can reasonably manage is quite large. (Linux, Google, Microsoft, Facebook, and others...) https://en.wikipedia.org/wiki/Monorepo

Also: any of the BSDs.

Re: Don't start with microservices – monoliths are your friend

#296

Post by SquishyPanda23 »

KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

It's usually not obvious where to put the seams ahead of time so you can cut them when you need to split into microservices.

Plus keeping the API boundaries clean costs time and resources, and it's tempting to violate them just to launch this one feature. This extra discipline doesn't have any payoff in the short term, and it has unknown payoff in the long term because you're not sure you drew the boundaries ahead of time anyway.

So I think in practice what happens is you create a monolith and just eat the cost of untangling it when the team gets too big or whatever.

Re: Don't start with microservices – monoliths are your friend

#298

Post by mattgreenrocks »

KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

To be fair, modular monoliths weren't talked about much before microservices. I'm thinking about the heyday of Rails, where there were bitter debates over whether you should even move critical business logic out of Rails. I got the impression that most devs didn't even care. (That was sort of the point where I saw that I was a bit of an odd duck as far as developers go if I cared about this stuff, and pivoted my career.) I really enjoy contexts where I can make modular monoliths, however. I'm thinking of mobile/desktop apps here, mostly.

Software design is something of a lost art currently. This is partially due to the current zeitgeist believing that anything that automated tools cannot create/enforce can't be that important in the first place. Of course, there's a whole swath of concerns that cannot be addressed with static or dynamic analysis, or even different languages.

Microservices is a response to the fact that a monolith without any real design moves quickly but can easily converge on spaghetti due to the fact that everything is within reach. It enables teams to create an island of code that talks to other islands only via narrowly defined channels. Additionally, they support larger dev teams naturally due to their isolationist take, and reinforce the belief that "more developers = always better" in the process. In other words, they mesh perfectly with the business context that a lot of software is being built in.

Factor in the fact that $COOL_COMPANY uses them, and you have a winner.

Re: Don't start with microservices – monoliths are your friend

#299

Post by stepbeek »

ozim wrote: post #229
KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…

I explicitly claim to use a "citadel" archicture [0] when talking about breaking off services for very similar reasons. Having a single microservice split out from a monolith is a totally valid application of microservices, but I've had better results in conversation when I market it properly.

I've found this to go so far as to have "monolith" understood to mean "single instance of a system with state held in memory".

[0] https://m.signalvnoise.com/the-majestic-monolith-can-become-...

Re: Don't start with microservices – monoliths are your friend

#300

Post by AtNightWeCode »

trunnell wrote: post #268

Former Netflix engineer and manager here. My advice: Start a greenfield project using what you know (unless your main goal is learning) keeping things as simple as possible. Microservices is more often an organization hack than a scaling hack. Refactor to separate microservices when either: 1) the team is growing and needs to split into multiple teams, or 2) high traffic forces you to scale horizontally. #1 is more l…

What was the root cause of the dependency horror that Netflix created, now immortalized with all the scary data flow GIFs?
Post reply on HN