3 ms·
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 eff
by xfitm3 8y ago
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.
- guywithabike 8y ago(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.
- eikenberry 8y ago> 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.
- xfitm3 8y agoIn my example of DB and backend: How could they be decoupled?
- eikenberry 8y agoAs 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.
- analogj 8y agoread only replicas, sharding, clustering, caching