Hacker News Reader

I think that splitting things can be a good idea once in a while. The important part is that you only make a new service because some job fits being its own service.

The microservice syndrome begin once you start splitting services simply because you arbitrarily declare them too large.

View on HN

But you can make a "new service" in code in the same binary communicating through memory. You can then separate it to a separate binary, when the network and serialisation overhead worth it. 80% of the time it will never come.

Microservices are not only "function calls over TCP" though. There are other concerns such as database per service vs a single shared database. There are also security implications that you don't have with a monolity. Designing it that way from the beginning could easily be as complicated as making them separate services.

I wouldn't call that microservices.

> because some job fits being its own service

Determining this at all takes skill. Determining it that far ahead of time requires so much skill and foresight that suggesting that people try is bad advice.

Reply on news.ycombinator.com