161–166 of 166 posts
Earlier quoted context omitted.
It is a shame that comment is not a blog post!
You will like the Strange Loop 2017 talk about this subject: "Stop Rate Limiting! Capacity Management Done Right" by Jon Moore https://www.youtube.com/watch?v=m64SWl9bfvk Concurrent capacity might not be the best metric.
Earlier quoted context omitted.
Well, P isn't really much of a choice, I don't think you can opt out of acts of god.
You can design to minimize P, though. For instance, if you have all the services running on the same physical box, and make people enter the room to use it instead of over the Internet, "partition" becomes much less likely. (This example is a bit silly.) But you're right, if you take a broad view of P, the choice is really between consistency and availability.
For example, running S3 locally or not.
Earlier quoted context omitted.
Even better, based on queue latency instead of length
The single best metric I've found for scaling things like this is the percent of concurrent capacity that's in use. I wrote about this in a previous HN comment: https://news.ycombinator.com/item?id=41277046 Scaling on things like the length of the queue doesn't work very well at all in practice. A queue length of 100 might be horribly long in some workloads and insignificant in others, so scaling on queue length requ…
Be still my beating heart. I have lived to see this day. Genuinely, we've wanted this for ages and we got half way there with strong consistency.
Might finally be possible to do this on S3: https://pkg.go.dev/github.com/ncruces/go-gcp/gmutex
Earlier quoted context omitted.
yeah. one of the goals was startup time, so It made sense to precreate them. In practice we never ran out of free machines (and if we did, I have a cdk script to make more), and inifnite scaling is a pain in the butt anyways due to having to manage subnets etc. Cost-wise we're only paying for the EBS volumes for the stopped instances which are like 4GB each, so they cost practically nothing, we spend less than a doll…
Warm pools are a supported feature in AWS on auto scaling groups. Works as you're describing (have a pool of instances in stopped state ready to use, only pay for EBS volume if relevant) https://aws.amazon.com/blogs/compute/scaling-your-applicatio...