Comment by calpaterson | Hacker News Reader

Comment by calpaterson | Hacker News Reader

Parent Full thread

I don't agree that scaling up is an unqualified advantage of microservices. In practice you have to co-ordinate communication between your services. Though some of this communication will be asynchronous publish-subscribe (ie: speed unimportant) some communication will necessarily be synchronous.

If one heavy part of your rails app takes up 90% of the processing time, there is nothing wrong with just getting a bigger machine for the whole app. The bigger CPU/memory/whatever will be spent on the heavy part and the rest will be normal.

For most business, scaling is not a problem - they can just get bigger machines. Having to re-implement transactions across your microservice architecture really is a problem. Very often transactions need to cross microservice boundaries and that really requires a lot of thought

>> that really requires a lot of thought

Yes, sure, but that's the resources spent right. Not the monolithic spaghetti crap you waste time on trying to figure out what went wrong - 99% businesses everyday activity

Spent right? Implementing a protocol to coordinate transactions (if it is possible at all, depending on the various backends you work with) to get what you could have already done in your database?

You can keep transactions in one part of the system and the queries in another. CQRS as one example.

There are other options, like spend the same resources building a monolith that is not spaghetti. And it is certainly possible for the sum of microservices to become spaghetti.

I'd take a stronger line than this. Microservice architectures scale worse than monoliths. Because with a monolith, you can just do this:

http://paulhammant.com/2011/11/29/cookie-cutter-scaling/

Moreover, unless you're doing something intrinsically computationally expensive (video transcoding or whatever), or you've screwed up, your bottleneck will be in the database anyway. Scaling the database looks exactly the same for monoliths and microservices: you can scale up, scale out, or split.

It is slightly different, in that it is already a sharded database compared to what the monolith would have.

If you've built your microservices on top of multiple databases, then you could have built the same features in a monolith on top of multiple databases. What helped scaling is splitting the database, not splitting the application.

Reply on news.ycombinator.com