Mad, bad and dangerous – not in a good way. Boffins roast serverless

falco

Serverless might be the future but in its present form serverless is not just embarrassing – and could be viewed as a cynical bid to lock-in customers – it’s damaging.

That’s according to Serverless Computing, One Step Forward Two Steps Back from researchers at the University of California, Berkeley, here.

While serverless offers the potential “to program the cloud” – the step forward – the report states gaps in today’s offerings mean that data processing is being ignored while development of distributed systems, especially in data systems, is being stymied.

UCB based its report on AWS – the first and largest public cloud and first to serverless with Lambda – but its rivals do not get off the hook.

Advertisement

“Offerings from [Microsoft] Azure and [Google] GCP differ in details but not in spirit,” the report states.

It identifies a number of gaps in today’s generation of FaaS, stating they restrict the ability to work efficiently with data or distributed computing resources.

That means serverless is, at best, a simple and powerful way to run “embarrassingly parallel computations or harness proprietary services.”

At worst: “It can be viewed as a cynical effort to lock users into those services and lock out innovation.”

The researchers identified the following deficiencies: functions would shut down after 15 minutes, leading to services that have limited lifespans; the presence of performance bottlenecks as per-function bandwidth shrank proportionately when compute power is scaled up; storage slowed down communications; a lack of APIs or other mechanisms to access specialised hardware.

The academics have offered their take on what’s needed to break through this and achieve a truly programmable serverless environment for the cloud.

Among the ideas: the ability to co-locate code and data, which can be released by “shipping code to data, rather than the current FaaS approach of puling data to code.”

Also, that cloud providers make specialised hardware “cost effective.”

Finally, APIs for service-level objectives with services priced according to up-front SLOs, rather than vendors charging for FaaS function by size – such as RAM or number of cores.

- Advertisement -