Docker for Serverless Applications

The following diagram illustrates the position of event-driven programming, FaaS, and serverless FaaS, where serverless FaaS is the intersection area between FaaS and serverless:

Figure 1.2: A Venn diagram illustrating the relationship between serverless and FaaS

Serverless is a paradigm shift that enables developers to not worry about server provisioning and operations. Billing would be pay-per-request. Also, many useful services are there on the public cloud for us to choose, connecting them together and use them to solve the business problems to get the job done.

Applications in the serverless architecture typically use third-party services to do other jobs such as authentication, database systems, or file storage. It is not necessary for serverless applications to use these third-party services, but architecting the application this way takes full advantage of the cloud-based serverless platforms. The frontend applications in this kind of architecture are usually a thick, fat, and powerful frontend, such as single-page applications or mobile applications.

The execution engine for this serverless computing shift is a Function as a Service or FaaS platform. A FaaS platform is a computing engine, that allows us to write a simple, self-contained, single-purpose function to process or compute a task. A compute unit of a FaaS platform is a function that is recommended to be stateless. This stateless property makes functions fully manageable and scalable by the platform.

A FaaS platform does not necessarily run on a serverless environment, such as AWS Lambda, but there are many FaaS implementations, such as OpenFaaS, the Fn Project, and OpenWhisk, that allow us to deploy and run FaaS on our own hardware. If a FaaS platform runs in the serverless environment, it would be called serverless FaaS. For example, we have OpenWhisk running locally, so it is our FaaS platform. But when it is running on IBM Cloud as IBM Cloud Functions, it is a serverless FaaS.

Every FaaS platform has been designed to use the event-driven programming model, to be able to connect efficiently to other services on the public cloud. With the asynchronous event model and the stateless property of functions, this environment makes serverless FaaS an ideal model for next-generation computing.

But what are the drawbacks of this approach? They are as follows:

This book discusses the balance between FaaS on our own infrastructure and serverless FaaS. We try to simplify and unify the deployment model of FaaS by choosing three major FaaS platforms that allow us to deploy Docker containers as functions, which we discuss in this book.

With Docker containers as deployment units (functions), Docker as a development tool, and Docker as the orchestration engine and networking layer, we can develop serverless applications and deploy them on our available hardware, on our own private cloud infrastructure, or a hybrid cloud that mixes our hardware together with the public cloud's hardware.

One of the most important points is that it is easy enough to take care of this kind of infrastructure using a small team of developers with Docker skills.

Looking back the previous Figure 1.2. If you're getting the clue after reading this chapter up to here, let's guess a bit that what would be the contents to be discussed in this book. Where should we be in this diagram? The answer is at the end of this chapter.

A description of the architecture from bottom to top is as follows:

Now, we will discuss the actual FaaS layers. We will go from left to right:

We will try the echoit function to hello world with OpenFaaS. First, clone the project from https://github.com/openfaas/faas with one level of depth to just make the clone process quicker:

$ git clone --depth=1 https://github.com/openfaas/faas

Then, change the directory into faas, and simply deploy the OpenFaaS default stack, using the following command:

$ cd faas
$ docker stack deploy -c docker-compose.yml func

Wait until the stack is going up. Then, we do hello world with the curl command:

$ curl -d "hello world." -v http://localhost:8080/function/func_echoit
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST /function/func_echoit HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Length: 12
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 12 out of 12 bytes
< HTTP/1.1 200 OK
< Content-Length: 12
< Content-Type: application/x-www-form-urlencoded
< Date: Fri, 23 Mar 2018 16:37:30 GMT
< X-Call-Id: 866c9294-e243-417c-827c-fe0683c652cd
< X-Duration-Seconds: 0.000886
< X-Start-Time: 1521823050543598099
< 
* Connection #0 to host localhost left intact
hello world.

After playing around it, we could also use docker stack rm to remove all running services:

$ docker stack rm func

Let's quickly move to OpenWhisk. To hello world with OpenWhisk, we also need a docker-compose binary. Please visit https://github.com/docker/compose/releases and follow instructions there to install it.

With OpenWhisk, the whole stack would be a bit longer to get up and running than with OpenFaaS. But the overall command will be simpler as the hello world is already built in.

First, clone the OpenWhisk development tool from its GitHub repository:

$ git clone --depth=1 https://github.com/apache/incubator-openwhisk-devtools devtools

Then change the directory into devtools/docker-compose, and manually do image pulling, using the following commands:

$ cd devtools/docker-compse
$ docker-compose pull
$ docker pull openwhisk/nodejs6action

After that, just call make quick-start to perform the setup:

$ make quick-start

Wait until the OpenWhisk cluster has started. This could take up to 10 minutes.

After that, run the following command, make hello-world, to register and invoke the hello world action:

$ make hello-world
creating the hello.js function ...
invoking the hello-world function ... 
adding the function to whisk ...
ok: created action hello
invoking the function ...
invokation result: { "payload": "Hello, World!" }
{ "payload": "Hello, World!" }
deleting the function ...
ok: deleted action hello

Make sure that you're on a fast internet connection. The slowness associated with OpenWhisk pulling the invoke and controller often causesmake quick-start to fail.

To clean up, just use the make destroy command to terminate the target:

$ make destroy

This is another FaaS project covered by this book. We quickly do hello world by installing the Fn CLI. Then use it to start a local Fn server, create an app, and then create a route that links to a pre-built Go function under the app. After that, we will use the curl command to test the deployed hello world function.

Here's the standard command to install the Fn client:

$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sudo sh

After that, we can use the fn command. Let's start an Fn server. Use --detach to make it run in the background:

$ fn start --detach

Well, if we see a container ID, it is good to go. Next, quickly create an Fn app and call it goapp:

$ fn apps create goapp

Then, we already have a pre-built image called chanwit/fn_ch1:0.0.2 on the Docker Hub. Just use it. We use the fn routes create command to link the new route to the image. The purpose of this step is to actually define a function:

$ fn routes create --image chanwit/fn_ch1:0.0.2 goapp /fn_ch1
/fn_ch1 created with chanwit/fn_ch1:0.0.2

OK, the route is ready. Now, we can use the curl command to just call our hello worldprogram on Fn:

$ curl -v http://localhost:8080/r/goapp/fn_ch1
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /r/goapp/fn_ch1 HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Length: 26
< Content-Type: application/json; charset=utf-8
< Fn_call_id: 01C99YJXCE47WG200000000000
< Xxx-Fxlb-Wait: 383.180124ms
< Date: Fri, 23 Mar 2018 17:30:34 GMT
< 
{"message":"Hello World"}
* Connection #0 to host localhost left intact

OK, it seems all things are working as well as expected for Fn. Let's remove the server after it has finished:

$ docker rm -f fnserver