Very interesting take from @forrestbrazeal on the new #Lambda Provisioned Concurrency. I have a few quick thoughts on this as well... trek10.com/blog/provision…
Yes, "pay-per-use" is very attractive, but I'm okay with AWS's "pay-for-value" model in #serverless environments. I don't expect the cloud to dedicate resources to me for free. I may get the benefit of warm invocations, but that's an internal optimization, not a guarantee.
Steady workloads benefit from "provisioned" capacity, not just from a pricing standpoint, but for performance as well. The "why-not-do-this-high-volume-workload-on-EC2" argument is "sometimes" valid. Provisioned Concurrency w/ Lambda is a step towards negating that logic.
And along that line of thinking, my high-volume workloads (combined with the new HTTP API), gives me a low cost, #serverless endpoint with extremely low latency on both the network and compute layers. Provisioning concurrency might seem like right-sizing, but that's...
...a small price to pay for 1) a lower cost compared to on-demand, 2) no servers to manage or patch, and 3) the ability to handle the occasional spikes without worrying about autoscaling or time-based pre-provisioning.
And lastly, you don't want Provisioned Concurrency to change the stateless nature of your functions. Using global data from warm invocations is very useful, but you should build your functions to assume that data might NOT be there and needs to be rehydrated when necessary...
If you really need stateful compute (which you most likely don't), then maybe take a look at "serverless" containers on something like Fargate. 🤷♂️
Provisioned Concurrency is something I asked for 18 months ago (jeremydaly.com/solving-cold-s…), so while it may not be as "#serverless" as some would like, it bridges a gap that many weren't willing to leap across.
