Hacker News Reader

Comment by candiddevmike | Hacker News Reader

Does it though? If you're triaging an issue, in a microservice environment, errors become limitless red herrings. Reproducibility becomes an enormous undertaking, especially when you can't (quickly) recreate the entire stack ("won't fit on my laptop").

A monolith can be quite scalable and portable.

View on HN

Not only can a monolithic code base be scaleable but you can make it into microservices by adjusting it's startup parameters:

    monolith --start-batch-jobs
    monolith --start-claim-processor
    monolith --start-graphql

And they would be interconnected probably via some clustering protocol with libraries that hide the complexity and runs a bus available in a litany of languages.

Need scale?

k8s replica count on the above pods.

Hmm, wouldn't it make more sense to keep batch jobs outside the monolith? Everything else makes sense to stay in a single binary.

The point of it is to be able to run it simply for developers developering things. If I run in prod with 12 different splits of code, that's fine. If I want to run this locally to develop new features, I would love to put in a breakpoint to see my puppeteer job run to do some screen scraping without having to have 15 VSCode windows open. (Which is what I sometimes have to do at my current company because we're a team of 6 doing microservices with 12 apps (more planned yay).

My experience is that monoliths tend to decay over time unless some serious discipline is enforced. It's possible to reference across boundaries, so that happens sooner or later.

By going down a microservice route, those boundaries are ruthlessly enforce because it's the only way. That trade off may or may not be worth it.

Not doing microservice does not mean doing monolith.

There is an in-between that you can aim for.

But you don't have to recreate the entire stack, that's the whole point.

Reply on news.ycombinator.com