> This gets compounded when applications start fighting for resources on the same machine and you get unanticipated interactions. One strategy for dealing with

> This gets compounded when applications start fighting for resources on the same machine and you get unanticipated interactions. One strategy for dealing with this is to use something like k8s to run the various components in different pods. That way you can size each pod such that there are always enough resources set aside for that component, and if it starts getting too big for its britches, you know about it before the whole thing comes crashing down (because they're the britches for just that component). Seems innocent enough, but bearing in mind that internet traffic is bursty, you end up with a situation where your pods are 90% empty 90% of the time because they're all sized for the worst case scenario. The compute you're paying for goes unused most of the time but AWS will still be billing you for 100% it. It's a sort of cancer of the request/response world that we live in. I think we need to go back to the 90's and make a different choice about the web. pub/sub maybe. The cases where we can't tolerate a few minutes of latency are quite small--provided that the data appears out-of-date during that time instead of the app being unusable, which is how we're handling it now.