Let's be real. The whole sales pitch for serverless was "you don't think about servers, you just run code." You pay for execution time, not idle capacity. Beautiful.
Now we've got "provisioned concurrency" as a premium feature. You're literally paying for idle capacity to keep a function warm. It's a tax on cold starts, a problem the vendors created and now sell you the solution for.
Where's the line? If you're provisioning concurrency for half your functions, at what point would a couple of good old-fashioned, always-on containers have been cheaper and simpler? You've traded VM management for concurrency management, and the bill isn't always better.
My experience:
* Tried it for a customer-facing API endpoint on Lambda. The cold start was hurting UX.
* The moment we turned on provisioned concurrency, our bill jumped 40%. For that price, we could have run a small autoscaling group of EC2 instances and had more control.
* It's another config to manage, another thing to scale up/down with forecasts. So much for "no ops."
It feels like a bait-and-switch. They lure you in with the promise of pure pay-per-use, then nickel-and-dime you to fix the performance pitfalls inherent in the model. The "serverless" premium is starting to look a lot like the old managed services premium, just with different jargon.
Anyone else running the numbers and finding that the "always on" tax makes the value proposition start to fall apart? Or am I just being cynical (again)?
been there, migrated that