Hacker News new | past | comments | ask | show | jobs | submit login

> e.g. performance, if one aspect of your application is hit 10-100x as hard

I'm not sure this one is a good argument for microservices. Having 100 copies of a microservice isn't any easier than having 110 copies of a monolith.

Any kind of competent code division is done because the divided interface is simpler than what you'll get without the division. So, go with the sibling here, and divide your code only if you have a very enticing interface that will be good to isolate and reuse. Doing high-level architecture decision because of operational details is almost guaranteed to lead you into disaster. You can do a few of them ever, so if you do it, it's better be one of your main differentials.




It's cheaper when you reduce resource requirements.

If you're loading a bunch of code in memory you don't end up using, you're wasting memory. Depending on how modular your code is, you may end up loading other external dependencies that don't get used (like initializing database connections). Likewise, for containers, you can usually make the container image smaller reducing data transfer, reducing Docker pull time, reducing host IOPs to unpack the image.

A lot of those problems can be optimized around, but sometimes it's quite a bit of work if you're already on a platform or framework that makes assumptions

If you're not deploying or scaling often and you have other mitigations like lazy loading to reduce memory, there may be no advantage.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: