Serverless computing (often called Functions-as-a-Service, or FaaS) is one of the hottest emerging technologies today. The OpenWhisk project, currently in incubation at Apache, is an open-source implementation of FaaS that lets you create functions that are invoked in response to events. Our own Brendan McAdams gave a presentation and demo that explained the basics of serverless, how the OpenWhisk project works, and how to run OpenWhisk in OpenShift.
Brendan outlined the three properties of a serverless / FaaS platform:
- It responds to events by invoking functions
- Functions are loaded and executed on demand
- Functions can be chained together with triggered events from outside the FaaS platform itself.
Before we go on, a terminology note. "Functions as a Service" and "Serverless" are normally used interchangeably. Lately, however, people are also using the word "serverless" to mean "anything that doesn't require you to fire up and manage a VM1." To be clear, what we're talking about here is FaaS.
It's useful to quote the official definition of OpenWhisk from the project's website:
...[A] serverless, open source cloud platform that executes functions in response to events at any scale.
The event-driven nature of OpenWhisk is powerful, but its ability to scale makes certain applications economically feasible for the first time. Without a FaaS platform, you'd have to provision the necessary resources to handle whatever loads the world might throw at your application. With FaaS, you don't provision anything. You simply tell the system, "Here are some things that might happen, and here's the code you should run when they do." The architecture of your app is defined declaratively, and the FaaS provider has to deliver the resources to handle the events.
Another part of the power of FaaS is that the events can come from anywhere, including sources outside the FaaS platform. For example, a change to a database might generate an event. OpenWhisk allows you to create your own events as well. Red Hat is working on an AMQP event provider, and others have built code that generates events from things like git commits or posts to a Slack channel. Finally, because all functions in OpenWhisk have a REST API, they can also be invoked directly by another piece of code or from the wsk command-line tool. Brendan's demos used the command line extensively.
A trigger is a class of events, such as all of the changes that are made to a database. Once a trigger is defined, you can create rules to determine which function(s) should be invoked when an event occurs. In OpenWhisk terminology, a function is called an action. All of the terminology is explained in a discussion of the high-level programming model on the project's website. For simplicity's sake, we'll continue to call a function a function.
The universal data format in the world of OpenWhisk is JSON and the most commonly supported languages are Java, Node.js, and Python. For those three languages you'll use the GSON library, native JSON, and Python dictionaries respectively. As you would expect, support for other languages is actively being developed, including Swift and PHP.
It's important to remember is that your functions are stateless. They are given some data generated by an event, and then they process that data and return the results. If you call the function again, it has no knowledge of what happened before. If many copies of the same function are running at the same time, they have no knowledge of each other.
If you're familiar with Unix pipes, you'll grasp the significance of sequences right away. You can create a new function by composing a sequence of functions that should be invoked in response to an event. The output of the first function becomes the input to the second, the output of the second becomes the input to the third, and so on. In Brendan's example, the first function took a name ({"name": "Brandon McAdams"}) and returned a reversed version of that name ({"name": "McAdams, Brandon"}). That JSON was then passed to a Hello World function that returned a greeting with the reversed name returned by the first function ({"greeting": "Hello, McAdams, Brandon"}). Keep in mind that each function in a sequence needs to understand the JSON from the previous one. If you added a third function to the example sequence, it would need to look for a parameter named greeting.
The entire programming model is very flexible. In response to an event, the system can a single function, a sequence of functions, or multiple functions.
As you'd expect from the title of the session, Brandon discussed how to run OpenWhisk inside OpenShift. We have a GitHub repo that contains the templates and Docker images you need to deploy OpenWhisk to your OpenShift project. Follow the instructions and you should be up and running with your very own FaaS platform.
Learning how to build useful applications with a set of serverless functions is a crucial skill for any modern developer. Take a look at our GitHub repo and get started today!
1 To cite a specific example from the world of containers, imagine a Kubernetes environment in which one of the nodes is in fact a cloud that provisions and deprovisions VMs automatically to host pods in the cluster. You can argue the words "serverless computing" describe that scenario because you're not working with the VMs, but that's not what we're talking about. We're firmly and fundamentally focused on functions here.
Last updated: September 3, 2019