The word “serverless” is a beguiling buzzword if there ever was one because servers are kind of pain. All of those patches for those security holes that are described in a bazillion words in a million emails sitting in your inbox? If you could get rid of a server, you could forget about those patches. All of those ports on the firewalls that you’ve got to remember to keep closed? They won’t be your worry anymore either. The serverless world will set you free. At least that’s what the word seems to promise.
The serverless world looks relaxed and full of time to devote to your one true mission: whatever your suits tell you it should be. But don’t be fooled. You’ll pay for this freedom from worry by sacrificing your freedom to wander or change. The serverless platforms in the Amazon, Microsoft, and Google clouds deliver their magic through a proprietary interface and every time you offload some of your worries into their waiting arms, you become addicted. Absorbed by the Borg. “Owned” is much too strong a word, but you may find it just as hard to escape.
Programmers hate shackles like this and that’s why a number of them are trying to build open source packages that offer some or even most of the features of the cloud-based serverless platforms, but in a pile of code that you can take anywhere. Not only does this make debugging and testing easier, but it lets you take your whole kit and kaboodle to another cloud with better prices, better latency, or better anything. You might even bring it home to that air conditioned closet that you used to call the server room.
To get a handle on this burgeoning world of open source serverless frameworks, I booted up a few machines and wrote some simple logic. It’s still too early to come to any firm conclusions because the projects like to say that they’re “pre-alpha,” but there’s much promise for liberating us from the lock-in.
Here is a look at four major efforts—Fission, Fn, Kubeless, and OpenWhisk. Surely more will be coming along soon.
Fission
An open source serverless solution from Platform9, Fission knits together containers running inside Kubernetes using some standard containers with dynamic loaders. Your functions will be pulled into the appropriate standard container and loaded to answer queries from a web server that’s already inside the container.
The standard environments include the dominant models (Node.js, Python, and Go) as well as some old school solutions like PHP, .Net, Ruby, and even Perl. Of course you can also roll your own with whatever language you like as long as you produce a binary that answers an HTTP request.
Fission is probably most useful for anyone who wants to jump directly to the Kubernetes level with the auto-scaling options the container orchestrator provides. Fission runs inside Kubernetes clusters using the standard tools like Kubectl, Helm, and Tiller.
IDG
A quick five-line example of using Fission’s command line interface to turn a simple function into a running container.
If you can’t rely upon an HTTP call to invoke the functions, Fission can trigger them from either a Crontab or a message from one of two supported queuing tools (Azure Queue Storage or NATS Streaming). There’s also an option to define “workflows” in a YAML file that will run multiple tasks in sequence.
The biggest service provided by Fission is maintaining the set of standard containers that dynamically load your code. They’re essentially pre-configured, saving you the trouble of adding the code necessary to function correctly in the cluster.
Fn Project
Oracle’s entry in the serverless space, Fn, glues together some templates, the standard build routines for the major languages, and some standard Docker containers. Fn is a bit more Java-centric than the others, not too surprising when you consider Oracle owns Java. Fn should work with most combinations of languages and build routines as long as Docker is at the base. Some of the Oracle literature says “One dependency: Docker.”
One of the more interesting features is a set of wrappers that will let you run your AWS Lambda code in Oracle’s local stack instead of yours. The core functions are relatively easy to map over using these wrappers but that’s often only part of the picture. Most people use Lambda as glue code for other Amazon cloud services. These wrappers only help you bring over the Lambda code itself, so you’ll have to figure out some other solution for the heavy lifting done by the AWS APIs. The wrappers are great but their utility depends upon how you’ve designed your architecture and how many of the Amazon services are used by your code.
The interface to Fn, like all of these tools, is all command line. You type fn and then add commands to create new templates, build the resulting code, or eventually deploy it. You write a simple function is a separate file and then fn will bundle it with the right template so it can run in a Docker container somewhere.
Prebuilt templates for Go, Java, Python, Ruby, and Node.js are bundled as Fn Development Kits (FDKs) but you don’t need to concentrate on them. All of them ask you to build a function that takes a string as a parameter and returns a string as the result. It couldn’t be simpler.
IDG
This experimental UI in Fn shows how a number of different functions can be linked together into a workflow.
When you deploy the code, Fn will connect it to an HTTP trigger that bundles all of the parameters and feeds them to your function that’s running in a Docker container. Pretty much everything else is left open to your dreams and designs. Yes, Fn is saving you from all of the deployment headaches, but you’ve still got to write all of that code inside that one function.
You can fiddle a bit with the mechanisms inside Fn. The housekeeping information is stored in a basic database (SQL3) used to keep track of routes and other deployment information but you can use MySQL or Postgres out of the box. There’s also a configurable choice for the message queue that helps the different versions of Fn coordinate. You’ll probably leave these untouched, but the option is there if you want more.
Fn feels very lightweight and simple, no doubt by design. It takes a few standard build tools and some standard Docker templates and links them together so it’s easier to write a bit of code and see it run in one of these Docker containers.
Kubeless
Kubeless comes from Bitnami, one of the companies that helps us extract all of the power of the cloud with several different types of hand-holding products. Like Fission, Kubeless is designed to bring all of the fun of serverless to Kubernetes clusters. The name is kind of a joke because the technology is anything but Kubernetes-free. If anything, it’s all about exploiting the built-in features of Kubernetes to whip up a quick serverless infrastructure.
Kubeless turns your functions into custom resources, something that Kubernetes is designed to create and scale as needed. The developers seem to like Python the most, if only because the examples are largely written in them, but there are also runtimes of Node.js, Ruby, PHP, Go, and .Net. Although Java 1.8 is missing from some parts of the documentation, it’s included in the list of available runtimes according to the version I installed.
The basic functions are a bit more sophisticated than in other frameworks. Each function you write will take two parameters, an object with the event and another object with some metadata or context. This allows slightly more sophisticated and self-aware programming models than the approaches that just pass a string to the function. In the end, you’ve got to return a string that will be returned to whatever HTTP request started everything rolling. (There are some nicer helper functions in some of the stacks, where the Node.js runtime accepts an object and serializes it.)
IDG
Kubeless has a UI that lets you edit your function and then deploy it with a click.
If you don’t want to trigger the functions from an HTTP request, Kubeless can also be configured to respond to Kafka or NAT messages or a scheduled invocation at a particular time. You can also extend this by creating a custom resource source for the events.
The Kubeless approach will be most attractive to anyone who has completely embraced Kubernetes and feels comfortable inside this world of clusters and auto-scaling. Kubeless is mostly a tool for quickly converting some basic code into a Kubernetes cluster that answers the request.
OpenWhisk
OpenWhisk is IBM’s official tool for building Cloud Functions in the IBM Cloud. It’s also an open source project (in incubation status) shepherded by the Apache Software Foundation. OpenWhisk is really a synthesis of several popular Apache projects that are stitched together to take a few lines of your code, wrap them in Docker containers, and invoke their execution through a REST API. The requests are fielded by Nginx, turned into Kafka messages, then passed into the containers. Authentication and management information is stored in a CouchDB. It’s like an Apache Foundation reunion.
The code itself can be written in JavaScript, Java, Python, PHP, Go, and, what do you know, even Swift for those who are taking time off from writing iPhone apps. Of course you can use pretty much anything you can bundle into a Docker container, as long as the function parameters can be accepted by stdin and the results piped out through stdout.
The OpenWhisk developers have essentially built out a bunch of standard frameworks for each of the major languages that will take some text input and spit out some text output using some preconfigured libraries. When you write your short function, OpenWhisk will stick it into this standard container and everything should work—if you’ve followed the instructions and written your function correctly.
There will always be wrinkles. The Java code expects the Google GSON library to be available. The container for your Swift code will run the open source version of Swift, so there may or may not be moments when the code behaves exactly the same as what you’ve experienced in the iOS world. JavaScript will probably be the most popular option for everyone, and your JavaScript code will run inside Node 6 or Node 8, which are well understood and predictable.
Apache Software Foundation
The path of an OpenWhisk request. After the request arrives at the HTTP gateway it travels through Kafka to the right Docker packages.
There was a huge difference, though, between using OpenWhisk in IBM’s nicely curated cloud and running it in my own machine. IBM’s web interface made it simple to write a few lines and see them run successfully. It took me only half an hour to go from nothing to a running interface that stored text in an IBM Cloudant database.
When I tried to do anything similar with the open source distribution, I kept running into roadblock after roadblock like configuring the API host. The documentation is nowhere near as complete as it should be. There are pointers to several different quick start paths, and you’ll be guessing and filling in holes as you go.
It quickly becomes clear that there’s quite a bit of configuration to getting this all running on your own machine. The instructions for packaging up your Swift function are a good example of how a few lines of code take plenty of configuration and scripting to get it running.
Serverless vs. simplicity
All four of these projects fill a fairly narrow niche. The word “serverless” isn’t used as broadly as it could be, and there are many other options that offer much of the same flexibility and freedom from scutwork without wearing the “serverless” buzzword. Databases are often said to be the original serverless option and many of the open source systems like WordPress, Drupal, and Magento are effectively serverless. You extend them by adding snippets of PHP that fit into a big framework. What we used to call plug-ins or modules could just as well be marketed as “serverless.”
In this context, none of these tools are as worry-free as any of that generation of technology. These four serverless platforms are closer to an enhanced manager for Kubernetes or Docker clusters. They’re more like management tools that make it simpler to juggle all of the configuration you need to do to set up and run these clusters. Or like automatic build tools that wrap up your function and get it running on a cluster.
The limits to their role is defined by their architecture. The tool creators aim to offer maximum flexibility. All of them have a long list of supported languages, but then try to sweeten the deal by saying they’ll work with any binary that obeys the formatting rules for input and output. So all they can do is glue the parts together and spit out a container.
It turns out that getting the parts right inside of the container is still a huge part of the challenge. All of the literature says that you can get these tasks or actions running by writing one function. But what a function it can be. And so you’re stuck handling all of the work inside the container. You’ve got to get the libraries and the code inside there right before handing over control. And then you’ve got to handle all of the other parts like the databases and the APIs.