Running Serverless Applications on Rancher

One of the more novel concepts in systems design lately has been the notion of serverless architectures. It is no doubt a bit of hyperbole as there are certainly servers involved, but it does mean we get to think about servers differently.

The potential upside of serverless

Imagine a simple web based application that handles requests from HTTP clients. Instead of having some number of program runtimes waiting for a request to arrive, then invoking a function to handle them, what if we could start the runtime on-demand for each function as a needed and throw it away afterwards? We wouldn’t need to worry about the number of servers running that can accept connections, or deal with complex configuration management systems to build new instances of your application when you scale. Additionally, we’d reduce the chances of common issues with state management such as memory leaks, segmentation faults, etc. Perhaps most importantly, this on-demand approach to function calls would allow us to scale every function to match the number of requests and process them in parallel. Every “customer” would get a dedicated process to handle their request, and the number of processes would only be limited by the compute capacity at your disposal. When coupled with a large cloud provider whose available, on-demand compute sufficiently exceeds your usage, serverless has the potential to remove a lot of the complexity around scaling your application.

...and the potential downside

Granted, there is still the challenge of the increased latency associated with constructing a process for every request. Serverless will never be as fast as having a process and memory allocated in advance; however, the question here is not whether it’s faster, but whether it’s fast enough. Theoretically, we’d accept latency of serverless because the benefits we’d get in return. However, this trade-off needs to be carefully evaluated for the situation at hand.

Implementing serverless with Rancher and open source tools

Docker gives us a lot of tools to implement this concept of serverless, and gave an excellent demo of it at a recent Dockercon. Rancher only accentuates these capabilities. Because our platform handles managing your container infrastructure, you can add and remove compute capacity just by manipulating an API. The ability to define this part of your stack through software supports users achieving full application automation. The next layer up in the stack is where a framework for writing code for a serverless system is useful. You could certainly write your own, or extend some middleware to handle this, but there are many open source projects that provide tooling to make this experience easier. One of those projects isIron.io’s Iron Functions. I did a quick POC of it on Rancher and found it was easy to work with. The setup can be quickly launched in Rancher by using the compose files here. To use these files, copy and paste the docker-compose.yml and rancher-compose.yml files in the repo into the “Add Stack” section of the Rancher UI. Or from the Rancher CLI, simply run “rancher up” (be sure to set the following environment vars: RANCHER_URL, RANCHER_ACCESS_KEY, RANCHER_SECRET_KEY). When the stack launches, you should be able to see it in the Rancher UI. Additionally you can find the URL for the Iron Functions API endpoint and UI by clicking the \“i\” icon next to the first item in the stack (\“api-lb\“). Running serverless stack after deploying Finding the URL for your IronFunctions endpoints Once you have the stack running, follow the “Write a Function” instructions on Iron.io’s Github repo here. This will take some getting used to, as it requires you to think a little differently about how to write your application. There won’t be any shared state for your functions to reference, and things like libraries can be difficult or expensive to leverage. For my example, I chose a simple golang function from Iron.io:

package main

import (
 "encoding/json"
 "fmt"
 "os"
 )

type Person struct {
 Name string
 }

func main() {
 p := &Person{Name: "World"}
 json.NewDecoder(os.Stdin).Decode(p)
 fmt.Printf("Hello %v!", p.Name)
 }

The next step is to deploy the function to the instance of Iron Functions we’ve setup in Rancher. To make this easier to try out, I wrote a script that does all the steps for you. Just follow the README on this repo. Once you’ve deployed the function, you should be able to see it in the UI, and try it out: IronFunctions Dashboard The results of your function being executed From within Rancher, you can scale the number of workers to meet the needs of your demand. Rancher will take care of placing them on a host and connecting them to a load balancer. Per the best practices guide, you can simply scale based on the \“wait_time\” metric, making the scaling actions relatively simple. I found this to be a very informative taste of what it could be like to build applications in this way, and I hope you did as well. If you have any ideas or feedback regarding this, don’t hesitate to reach out on the forums or send pull requests on GitHub. As always, you can talk to us on Twitter @Rancher_Labs.