Hacker News Reader

Comment by spand | Hacker News Reader

Seems the solution would be to improve the thing rather than reimplement it as microservices.

I think there are some things we can legitimately improve quite a lot under the current structure, and it seems there are other things that make certain improvements just untenable.

Upgrading a major version of an ORM for instance. It seems there are certain key improvements that boil down to "the only way this can be improved would result in a big-bang release affecting the entire of the system and take a dedicated team quite a long time to do". It's just not palatable for anyone.

For the parts we carve out as microservices we are essentially able to erase that technical debt. That comes at the cost of increased ops complexity. We're not ready or capable of having 50 microservices from an ops perspective, but we are capable of handling more on the order of ~5.

Every additional microservice adds complexity to the system, due to having to factor in many failure situations not present if everything is instead in one process.

There are other options in your case, like isolating any dependencies in a module with a well defined API instead of having it all in a separate (micro-)service.

Or split out an individual domain, particularly one you’re having pain with, into its own “micro”service.

I think this is going to be the approach we wind up taking.

In reality there are maybe 1 ~ 3 hotpots in the domain that reveice many more transactions than the rest.

Reply on news.ycombinator.com