Hacker News Reader

Comment by YetAnotherNick | Hacker News Reader

This is hn so obviously your comment has to be the top voted comment. I am really tired of this trend here.

No. microservice vs monolith is not the deciding factor of the developer speed or bugs. It wouldn't even be top 5 factor for good developers. Difference between microservices and monolith technically is just network rpc rather than function call. In itself, it doesn't make much of a difference. If a developer finds themselves stuck because of microservice architecture, they are probably very bad developer in first place

View on HN

Placing a network call in your system also introduces:

- distributed systems problems - think consistency and ACID

- increased refactoring complexity - you now have to change the api three times instead of 1 to deploy the change with 0 downtime

- requirements for more generic CI/CD pipelines - you will develop many microservices, it's important to do it fast

it's not "just" a network rpc, even technically

If it's a network RPC style microservices architecture, you've built a distributed monolith; every service in a proper microservices architecture should be developed, maintained and deployed 100% independently from any other service. If two services are closely tied, they should be merged together.

Yes this causes overhead; every microservice will have a public API of sorts that will need to be documented and communicated, and any other service consuming it will need to eventually be updated to keep up with changes. If this overhead is not something your organization can afford, you should not be doing a microservices architecture.

> it's not "just" a network rpc, even technically

Except is is. Microservice doesn't mean distributed setup. For the first problem, yes service running in multiple pods causes issues, but even monolith could face the same issue. Statefulset based microservices not only exists, but is a pretty common setup. Also I would even call multiple container on the same pod as microservice, which basically solves all of the problem.

There are many ways to solve second problem. Some folks create different API version. I prefer different deployment.

Last is a problem for monolith. I know of big companies where compile time is in order of an hour for monolith, even for small change.

Except it isn't, because a microservice requires an isolated dataset, API abstraction, documentation, versioning, consumer contract, dependency chain, complex release management. It's a radically different design because it forces you to develop the entire system differently to deal with very different abstractions, ways of working, expectations.

A distributed monolith is simpler, but simultaneously more buggy than a centralized monolith.

The fact some people think there's little difference between function calls and RPCs is exactly why microservices is such a dangerous idea.

A few questions if its the same...

- In case of errors, do we get a full backtrace of function calls across service boundaries?

- Is the function call as cheap as passing an argument? What if we're passing 1KB? 1MB? 1GB?

- Can we use a debugger to step in and out of those functions?

- Can we spin up a simple test runner to integration test a few levels of function calls together? Preferably something like Jest that has a watch mode so we can quickly run dozens of tests?

- Can all database modifications run in a single transaction so that we know that either all of them happened or none at all?

> - In case of errors, do we get a full backtrace of function calls across service boundaries?

Unless you don't discard the error, then yes

> - Is the function call as cheap as passing an argument? What if we're passing 1KB? 1MB? 1GB?

No it is not. In general microservice costs are bit higher.

> Can we use a debugger to step in and out of those functions?

You could trace across services but passing the context. Also attaching debugger is possible afaik.

> Can we spin up a simple test runner to integration test a few levels of function calls together?

I use docker compose and it can be done

> - Can all database modifications run in a single transaction so that we know that either all of them happened or none at all?

Yes. I don't see how this is different than function call.

> Yes. I don't see how this is different than function call.

If you need atomicity _across services_ it's very different, hence why everyone resorts to eventual consistency and all the associated extra complexity. If there's a decent way to have true transactions that span multiple services, I've certainly never seen it.

You can get Distributed Transaction Coordinators (e.g. MSDTC on Windows), but it will make everything much slower.

We all appreciate your contribution to micro services. But let us now choose simplicity and move on with our lives. You do you with your zoo of dockerized babel towers

I use monolith 90% of the time. I think you missed my point. I just said that I could be similar level of productive in well thought of microservices division.

The more services you have, the more of a nightmare your development environment takes to set up. Network calls are a lot less reliable than function calls.

It's not "just". The network calls introduces all sorts of added complexity.

Dangerously hidden behind some microservices architectures / frameworks, sometimes, that promise to fix or at least hide all these complexities for you.

Reply on news.ycombinator.com