Hacker News Reader

Comment by snupples | Hacker News Reader

You don't need to "buy into" an idea to realize that there are advantages and disadvantages to a given approach.

Take one example: The single server idea is going to suffer outages. You could at the very least have two monoliths either load balanced or in some kind of failover setup.

But, what distributing some of the components into so-called microservices would give you is a graceful failure scenario where even if all the instances of a specific component fail, the rest of the application still works. Maybe only one function stops working temporarily but most work continues on.

This doesn't mean everything must be microservice koolaid all the time all the way, but I'm sure you can conceive of that being an advantage under certain use cases that would be worth other possible trade-offs.

View on HN

I have done extensive work with monoliths, and extensive work with microservices. I quite literally have never seen microservices be a benefit in the way you are describing, and if anything microservices can make the problem of robustness more difficult, because in many workflows there are one (or many) services that are critical. If they're down, everything is down, and if anything distributing these dependencies across different systems can make it more difficult to determine where the critical points of failure are.

As you point out, there is nothing inherent in a monolith that makes it less robust. I currently am building a monolith that is deployed on auto-scaling servers on a cloud provider, so if one server dies it just spins up other instances.

I have also done extensive work on both (I'm much older than the word microservices) and have found advantages to both approaches depending on requirements.

I've also found that most so-called monoliths still often end up breaking apart components anyway. I've only seen true monoliths as described above in the mom and pop type IT shops where there's only a couple support staff and they don't have the resources or experience to properly break things out into separate resilient components. And yes supportability is definitely a valid part of that design call.

Again that was just one example of a potential advantage to it while admitting there are trade offs. Others here have given better examples such as at larger orgs where multiple independent teams get involved with a single app.

This is what I do, I just develop monolithic stateless API's in Docker containers and run them as serverless Cloud Run apps or as Kubernetes pods, if one of them fails it's no big deal.

For particular usecases that fall out of the wheelhouse of my preferred language, I'll typically use single OpenFaaS functions + endpoints for these things (think doing ML with Python, or really heavy computation with Go/Rust).

This combination of containerized Mostly-Monolith with single-purpose endpoints for particular usecases works really well and is very productive. If something is much easier in another language (due to tooling/ecosystem) for example, then I can just build that method or sub-system out in whatever language it's fastest in with this architecture.

> But, what distributing some of the components into so-called microservices would give you is a graceful failure scenario where even if all the instances of a specific component fail, the rest of the application still works. Maybe only one function stops working temporarily but most work continues on.

The important thing to note here is that microservices give you one way to build a graceful failure scenario. You don't get it for free. Often that 500 will propagate all the way back! So you have all the same failure modes + network failure modes!

You could also build a monolith that could handle component level failures, for that matter. Tooling doesn't seem to be as common, though.

I don't disagree with you at all. There are certainly different ways of thoughtfully building things.

The point being you don't need to be a paying subscriber to microservices(tm) to recognize there can be positives to the approach, which you describe in your last paragraph

A monolith that can handle component level failures is very close to the same idea infrastructure-wise minus a lot of baggage implied by the buzzword microservices.

"A monolith that can handle component level failures" - being able to handle component level failures I think is more related to business logic design rather than being a monolith/microservice implementation. If your business process depends on some login microservice and that one is down it does not matter that the other parts are functional.

So just to play to your hypothetical. If there were two login methods, and they were separate microservices, if only one failed and the other remained up, that would be the graceful failure scenario.

I'm not telling you that you must to do this. Others may have requirements that go beyond yours.

Reply on news.ycombinator.com