Hacker News new | ask | show | jobs
by bob1029 406 days ago
Monolith really is the best path and I question if you couldn't make it work in ~100% of cases if you genuinely tried to.

One should consider if they can dive even deeper into the monolithic rabbit hole. For example, do you really need an external hosted SQL provider, or could you embed SQLite?

From a latency & physics perspective, monolith wins every time. Making a call across the network might as well take an eternity by comparison to a local method. Arguments can be made that the latency can be "hidden", but this is generally only true for the more trivial kinds of problems. For many practical businesses, you are typically in a strictly serialized domain which means that you are going to be forced to endure every microsecond of delay. Assuming that a transaction was not in conflict doesn't work at the bank. You need to be sure every time before the caller is allowed to proceed.

The tighter the latency domain, the less you need to think about performance. Things can be so fast by default that you can actually focus on building what the customer is paying for. You stop thinking about the sizes of VMs, who's got the cheapest compute per dollar and other distracting crap.

2 comments

>I question if you couldn't make it work in ~100% of cases if you genuinely tried to.

You could say this about almost any pattern, if you genuinely tried to make microservices work it could work in ~100% of cases, I'm sure of that.

Its this pattern of dismissing or accepting a solution with strong prejudice you don't evaluate the merits is the real problem. Thats the true behavior we need to get away from.

We as an industry may find, that modular monoliths trend toward the top as a result (I hate to speculate too much, every company is different and there are in fact other patterns of development beyond the two mentioned) but that would be a side effect if true. The real win is moving away from such prejudiced behavior

> Its this pattern of dismissing or accepting a solution with strong prejudice you don't evaluate the merits is the real problem.

I spent a solid 3 years of my career attempting to make micro service architecture work in a B2B SaaS ecosystem. I have experience. This is not prejudice.

> modular monoliths

I don't see the meaningful difference between this and microservices.

>I spent a solid 3 years of my career attempting to make micro service architecture work in a B2B SaaS ecosystem. I have experience. This is not prejudice.

Yes, you do have experience, and it may not match others. Thats my point. At previous jobs, I had terrible microservice experiences, they were everything people complained about them to be. Yet, by setting that aside and really diving into evaluation on merits, I came around on the idea because I understand the failures of my previous experience came to misapplication of the concepts, not the concepts themselves.

Thats what we need more of, the kind of evaluation and reflection one should do when making these decisions (or being apart of a group that does) and I don't think we should discount our own experiences, we should strive to separate them from the concepts of appropriate technical decision making, lest we become overly biased for or against something.

>I don't see the meaningful difference between this and microservices.

The most obvious is the independence microservices have. They're truly independent. Sometimes that is exactly what you want

Containerization unfortunately pretty much killed embedded DBs; it's a shame, because you can squeeze a lot of performance out of not having to access the DB over a network.
Containerization is another thing that is wildly overused by startups that don't yet have the problems it solves.