I agree with a lot though I think they overegg the possibilities for data performance at the as-a-Function level.
Some more specific reactions:
> Put precisely, there are three critical distinctions between serverless and serverful computing ... 3. Paying in proportion to resources used instead of for resources allocated.
I've taken to calling this "buying capacity vs buying consumption". You need to think about which you need (they touch on this in the fallacies section).
An ambulance is idle almost constantly. When I was a kid they were built on F150s and vapourised ten litres every time you glanced at them. But when I need one I don't care about the idleness and resource costs, I want to come to my aid ASAP. What I don't want is the paramedics converging from random locations on electric scooters rented on-the-fly.
> In acritical departure, [AWS Lambda] charged the customer for the time their code was actually executing, not for the resources reserved to execute their program. This distinction ensured the cloud provider had “skin in the game” on autoscaling, and consequently provided incentives to ensure efficient resource allocation.
I'd say yes and no. Yes, it provides an incentive to the platform provider. But there is a much, much bigger incentive to achieve platform lockin through data services. Keeping the function alive after the first invocation is a subsidy. I would bet folding money that Amazon are tracking this cost and weighing it against their market strategy.
> By allowing users to bring their own libraries, serverless computing can support a much broader range of applications thanPaaS services which are tied closely to particular use cases.
I'm not sure if the authors are familiar with buildpacks, despite citing Heroku. They don't mention buildpacks anywhere.
Disclosure: I work for Pivotal, we do a bunch of stuff in this area, including Buildpacks and Knative. But nothing is forward looking, personal opinion, consult your dr etc etc
I agree with a lot though I think they overegg the possibilities for data performance at the as-a-Function level.
Some more specific reactions:
> Put precisely, there are three critical distinctions between serverless and serverful computing ... 3. Paying in proportion to resources used instead of for resources allocated.
I've taken to calling this "buying capacity vs buying consumption". You need to think about which you need (they touch on this in the fallacies section).
An ambulance is idle almost constantly. When I was a kid they were built on F150s and vapourised ten litres every time you glanced at them. But when I need one I don't care about the idleness and resource costs, I want to come to my aid ASAP. What I don't want is the paramedics converging from random locations on electric scooters rented on-the-fly.
> In acritical departure, [AWS Lambda] charged the customer for the time their code was actually executing, not for the resources reserved to execute their program. This distinction ensured the cloud provider had “skin in the game” on autoscaling, and consequently provided incentives to ensure efficient resource allocation.
I'd say yes and no. Yes, it provides an incentive to the platform provider. But there is a much, much bigger incentive to achieve platform lockin through data services. Keeping the function alive after the first invocation is a subsidy. I would bet folding money that Amazon are tracking this cost and weighing it against their market strategy.
> By allowing users to bring their own libraries, serverless computing can support a much broader range of applications thanPaaS services which are tied closely to particular use cases.
I'm not sure if the authors are familiar with buildpacks, despite citing Heroku. They don't mention buildpacks anywhere.
Disclosure: I work for Pivotal, we do a bunch of stuff in this area, including Buildpacks and Knative. But nothing is forward looking, personal opinion, consult your dr etc etc