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

251–260 of 468 posts

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

#251

Post by why-el »

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…

I call these macro-services. They work nicely, but only if you want long enough, in my experience.

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

#252

Post by falcor84 »

jhgb wrote: post #244
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. Isn't "non-modular monolith" just spaghetti code? The way I understand it, "modular monolith" is just "an executable using libraries". Or is it supposed to mean something different?

The way I see it, spaghetti code is actually a very wide spectrum, with amorphic goto-based code on one end, and otherwise well structured code, but with too much reliance on global singletons on the other (much more palatable) end. While by definition spaghetti code is not modular, modularity entails more. I would define modularity as an explicit architectural decision to encapsulate some parts of the codebase such that the interfaces between them change an order of magnitude less frequently than what's within the modules.

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

#253

Post by jayd16 »

gwbas1c wrote: post #108
bspammer wrote: post #93

Earlier quoted context omitted.

> no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “d…

That's a fallicy. You've optimized for one use case, but you've made everything else more complicated as a consequence. Deploying a single monolith is faster than deploying 10 microservices, especially if you find yourself in the model where your microservices share code, you've ended up with a distributed monolith instead of microservices.

I don't know, is it really harder to deploy 10 services? Isn't it all automated? The organization overhead is lower because you can leave most of the app untouched and only deploy what you need to.

You could screw it up and make it harder for yourself but its not guaranteed either way.

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

#254

Post by __jem »

rtpg wrote: post #222
deniska wrote: post #26

Unless you have a strong technical or organizational reason to use microservices, using microservices is just more work to achieve the same results. Organizational reason would be multiple people/teams who don't want or can't talk much to each other, so they develop pieces of a larger system as relatively independent projects, with clear API and responsibility boundaries. Frontend/backend style web development is an…

one strong operational reason I have seen recently is resource management. The monolith where most API endpoints are instant and use constant memory, but some use much more memory and can be slower... is tough.Like if you just give a bunch of memory to each process now you're overprovisioning and if you try to be strict you run into quality of service issues. If you split out homogenous API endpoints into various gro…

At the same time, you have to be at a pretty huge scale before resource over-provisioning really hurts the bottom line. You can buy a lot of compute for the price of a single engineer's salary, and it usually takes more than one engineer to support a microservice architecture. Most applications hit problems scaling the database vertically long before they exhaust resources at the application level.

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

#256

Post by Mavvie »

p2t2p wrote: post #74

Last five years I'm looking at how my colleagues are struggling to dismantle a king of monoliths to services to enable various teams to move at faster pace and scale different parts independently. Those people couldn't be more wrong. Monoliths are not your friend. Deployment times will be longer, requirements for hosts where you deploy it will be bigger, you will end up with _huge_ instances to rent because some part…

Good points, but I want to point out some caveats to a few of them. I overall disagree with your conclusion of "Once you have business running, you need to dismantle it ASAP". I think it's a case-by-case thing, and you're ignoring the significant complexity costs of a microservices approach.

> Deployment times will be longer

Not necessarily. I'd say that when you have multiple changes across boundaries that need to go out together, monolith deployments can actually be faster as you only need to do a rolling update of 1 container instead of N. But if by "deployment time" you mean the time between deploys, I agree. But also...so what? As long as your deployment times are good enough, it doesn't really need to be faster.

> requirements for hosts where you deploy it will be bigger

True

> you will end up with _huge_ instances

Not necessarily. Depends on the tech stack, framework, etc. I've seen .NET (and even Rails) monoliths that are huge and only use hundreds of MB/a GB or two of RAM. But I've also seen Java monoliths using 12GB+ to handle small amounts of traffic, so YMMV.

> You'll have to scale more than you really need to because some parts of your monolith are more scalable than another

A problem often easily fixed with throwing a bit of $$$ at the problem, depending on your scale and per-request profitability.

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

#257

Post by rco8786 »

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…

> 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.

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

#258

Post by PaulHoule »

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…

What I think nobody talks about is: (1) the legitimate reason for breaking up services into multiple address spaces, and (2) that using different versions of the runtime, different build systems, and different tools for logging, ORM, etc. in different microservices is slavery, not freedom.

(1) is that some parts of a system have radically different performance requirements than other parts of the system. For instance 98% of a web backend might be perfectly fine written in Ruby or PHP but 2% of it really wants everything in RAM with packed data structures and is better off done in Java, Go or Rust.

(2) The run of the mill engineering manager seems to get absolutely ecstatic when they find microservices means they can run JDK 7 in one VM, run JDK 8 in another VM, run JDK 13 in another VM. Even more so when they realize they are 'free' to use a different build system in different areas of the code, when they are 'free' to use Log4J in one place, use Slf4J someplace etc, use Guava 13 here, Guava 17 there, etc.

The rank and file person who has to actually do the work is going to be driven batty by all the important-but-not-fashionable things being different each and every time they do some 'simple' task such as compiling the software and deploying it.

If you standardize all of the little things across a set of microservices you probably get better development velocity than with a monolith because developers can build (e.g. "make", "mvn install") smaller services more quickly.

If on the other hand the devs need to learn a new way to do everything for each microservice, they are going to pay back everything they gained and then some with having to figure out different practices used in different areas.

(Throw docker into the mix, where you might need to wrangle 2G of files to deploy 2k worth of changes in development 100 times to fix a ticket you can really wreck your productivity, yet people really account for "where does the time go" when they are building and rebuilding their software over and over and over and over again.)

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

#259

Post by Tarucho »

Microservices are just a way to implement a distributed system.

The problem seems to be that quite a number of teams don't have any formation about system design (mono/distributed/mixed).

Most teams go for microservices because of hype and because they see an spagheti monolith and believe the problem is the monolith and not the rotten badly modularized code.

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

#260

Post by thrower123 »

I tend to build monoliths, because I've got a sub-two-pizza team to work with. If I could throw dozens of people at the problem, and moreover, needed to invent things to keep that many people busy, then I think microservices would be more interesting.
Post reply on HN