Podcast / Top Stories

Red Hat’s Approach to ‘Functions as a Service’

18 Jun 2018 1:50pm, by

Michael Hausenblas, Red Hat developer advocate for OpenShift, still prefers the term “Functions as a Service.” In the push to expand the serverless capabilities of Kubernetes, he told us at KubeCon in May that one of the key desires for enterprises is to be able to host Amazon Lambda-like functionality internally as well as in public clouds. He expects as more users adopt serverless functions, that developers will increasingly become comfortable with function accessibility via APIs.

Hausenblas then detailed some of the changes this shift would bring to developers and their tools. “On the upside, I see a lot of positive developments so that it’s pretty easy to actually write something. You can write it any language, as long as it’s in Node.js. From a developer point of view, I don’t think this is a big problem. It’s more on the operational side. So if you actually think about who is going to be on call when you’re operating that at scale, since you don’t necessarily have any administrators around any more,” said Hausenblas.

He added that some teams put their developers on call in order to replace the administrators made obsolete by the use of serverless systems. Others are still trying to figure out what functions mean at scale: how are hundreds of functions managed together? “We need to see more large scale deployments. If you have a monolith, breaking it down to 200 or 300 functions, and breaking it down like that. I would expect, like anything else, people would initially do some home-grown stuff, and then have shell scripts or Terraform to do that kind of orchestration. At some point in time there will probably be a Cloud Native Computing Foundation project that will emerge as the standard for function orchestration,” said Hausenblas.

The complexity for many enterprises might be rising as serverless frameworks become more common and proliferate. Hausenblas said, “It’s a bit like PaaS, in that they are opinionated. It’s great on the one hand in terms of productivity, but to me, it’s always this trade-off between convenience and productivity, and on the other hand lockdown. You might not have the full control over what you want to do. You have certain limits in there, and they might be reasonable… If you want to have that control, well you end up deploying your own framework on top. … At the end of the day, an organization needs to find where in that spectrum do you see yourself,” said Hausenblas.

For Red Hat, the serverless solution comes from the Apache Foundation in the form of OpenWhisk. “We originally had a project called Fabric8. When IBM donated OpenWhisk to the Apache Foundation, our engineering muscles, nowadays, are essentially behind OpenWhisk from the product perspective. We’re making that run great on OpenShift,” said Hausenblas.

In this Edition:

1:06: What is serverless anyway?
4:40: How many people are using AWS Lambda for Serverless?
6:00: How will developer toolchains be affected by these new environments?
13:19: How would you preserve functions? Do you have to preserve state?
15:02: How do you distinguish between all of the serverless tools?
20:05: What’s the Red Hat take on serverless?

Red Hat sponsored this podcast. The Cloud Native Computing Foundation is a sponsor of The New Stack.

A digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.