We quickly realized that our users weren’t fans of this. It’s roughly equivalent to Amazon charging a higher hourly rate for every additional instance booted up, which is a disincentive to users looking to use hundreds of cores of processing power. Some users cleverly created multiple accounts, each with the cheapest 10 compute unit parallelism limit, and used them in concert to run their computation with a very high parallelism limit.

We weren’t fans either. We had users choose their parallelism limit so we could provision enough servers ahead of time to respond quickly to their computational demands. That was good in theory, but it meant that we had to maintain a large pool of servers even when our users weren’t running functions. Wasted compute cycles meant that we had to raise all of our prices, even for users who didn’t need immediate response times.

New Model
Our solution was to drop the idea of a parallelism limit altogether.

Now, our vanilla service doesn’t guarantee when functions will begin processing. In the background, we’re adding our users’ functions to a fair-queuing scheduler. We estimate the amount of workload in the queue, and automatically scale our cluster as we see fit. Most functions don’t wait very long; you can see empirical data on our product page. If you’re looking for a cheap and effective batch-processing solution, this is it.

Real time compute units now serve a clear purpose. These are compute units that we reserve just for you. When you make a cloud.call(), your function will run immediately if you have any real time compute units available (not allocated to another one of your functions). If your real time compute units are fully utilized, then your function will wait until a real time compute unit becomes available, or if room exists in our fair-queuing system. This is the ideal solution for those who need real time response requirements, or simply want to accelerate their processing time. We charge a minimal amount ($0.015 per compute unit hour) to reserve real time units in hourly increments. This minimal cost exists to protect ourselves in case you don’t run any functions, since we’re reserving space on Amazon instances for you.

I hope this sheds light on why our pricing model has been in flux. Our team is genuinely happy with this latest pricing model, because it accurately structures the value we provide our customers. If you have any questions, thoughts, or concerns, we’d love to hear what you have to say in the comments.