Hacker News Reader

Comment by xfitm3 | Hacker News Reader

I'm surprised I didn't see application performance monitoring mentioned here. A lot of applications are complex and in those cases adding containers is only effective until you reach the next constraint.

Having two resources (such as DB and app) scale in concert can be exceedingly difficult.

View on HN

(Author here) Absolutely! It's amazing how complex things get on the configuration side as you try to get smarter about autoscaling. The big downside of trying to be too clever here is that you wind up with a wildly brittle autoscaling setup that falls over as soon as the underlying assumptions around the relationship between your metrics and your scaling needs change. As in many things engineering, we've found that it's best to keep the configuration as simple as possible and use a solid foundation of reporting / alerting to give you an early heads up that you need to revisit and update your autoscaling strategy.

> Having two resources (such as DB and app) scale in concert can be exceedingly difficult.

This means your resources are too tightly coupled. If they are so tightly coupled that they need to scale together then they are not two resources and you should look into restructuring them into two actual resources or bind them more closely to make a single resource.

In my example of DB and backend: How could they be decoupled?

read only replicas, sharding, clustering, caching

As far as runtime, applications and DBs are already decoupled. You have N application instances mapped to M database instances. Applications can usually scale pretty much with load. Databases vary wildly in how they scale and it depends on the DB type.

Reply on news.ycombinator.com