Introduction to Apache OpenWhisk
What is OpenWhisk?
Apache OpenWhisk is an open-source serverless platform donated by IBM in 2016. More specifically, OpenWhisk is a Function-as-a-Service Platform that executes a snippet of codes which is a function. Functions can be executed in response to external events such as HTTP requests, Github merge events, sensor data from IoT devices, etc.
Functions in OpenWhisk are called Actions which can be of any languages such as Node.JS, Python, Java, Go, and even any executable binaries. Actions can be chained, then the execution result of a former action is passed as an input of a latter. As shared above, actions can be executed in response to external events, and event sources can be set up with Feed. When event sources are set up, corresponding Triggers are also created. Triggers are in charge of receiving events from the external event sources and invoke associated actions with Rules. One trigger can be associated with multiple actions with multiple rules each, it works like a fan-out in this case. Actions can be shared among users and a Package is a unit of sharable codes. It can contain actions and feeds but not triggers and rules.
How does it work?
All functionalities of OpenWhisk work based on REST API. So when an action is invoked, a RESTful invocation request arrives at the Nginx layer.
- Nginx is in charge of load-balancing among controllers and SSL termination.
- Controller is a web server that provides REST API based on Akka-HTTP. It authenticates and authorizes clients with data in CouchDB.
- CouchDB stores many data like user identification, action codes, throttling limits, execution results, etc.
- The accepted request is delivered to Invokers which is in charge of code execution via Kafka, one of the most popular messaging platforms.
- Invoker creates a Docker container to execute the given request, invokes it inside of the container, responds to a controller with an execution result, and finally stores it to CouchDB.
Execution Types
As you can see in the above section, action codes run on a container, and container creation is initiated when a new request arrives for the given action. This is called ColdStart. It includes container creation, code initialization, and code execution. So it is the slowest type of execution. Once an action is executed on a container, the container is already initialized with codes and can be reused for the next request. This is the WarmStart. Since the container is already created and code initialization is also already done, this is the fastest execution type. It depends on action codes and runtimes but a warm start is generally 100 ~ 300 times faster than a cold start in terms of latency. So it is critical to maximize warm starts and minimize cold starts to optimize the performance. Another interesting starting type is PrewarmStart. Container creation takes the most of the cold start. So we can prepare some containers in advance to reduce the latency. So containers without any codes are waiting for requests and codes are initialized when a new request arrives. In this way, we can reduce latency to around 16% of the cold start with the prewarm start.
What kinds of runtimes can I use?
Currently, OpenWhisk officially supports the following runtimes.
- Node.JS
- Java
- Python
- Docker
- PHP
- Go
- Swift
- Dotnet
- Ruby
- Rust
- Ballerina
- Custom Docker action.
One thing to note is OpenWhisk allows us to execute a custom Docker action that is created with a custom Docker image. It means you can use whatever you want as your runtime.
As I shared earlier, invokers communicate with containers and there are some protocols between invokers and containers. So as long as you conform to the protocols, you can use “literally” any language that you want including a shell script, any executable binaries, etc. And more importantly, you can even customize the execution flow and environment. You can choose any OS, install any dependent libraries, and even customize the execution itself. One of my colleagues could insert some custom logic before and after of code execution with his own Docker image.
In short, you can write functions in any language that you are familiar with.
Auto-scaling and Resource Optimization
In a serverless world, your codes only occupy resources when they are being executed. If your action is not invoked, no resource is being utilized. That’s the reason why you only pay as you go when you use serverless platforms like AWS Lambda. Also, the only thing you have to do is writing a function.
It implies two things. First, underlying computing resources can be shared in the time axis which is distinctive from traditional cloud computing. Second, you don’t need to take care of any concern about infrastructure but just focus on business logic. And these are the two major directions that cloud computing has evolved in, 1. share more resources, 2. save time for developers.
Basically, whenever a new request comes, OpenWhisk creates a new container(or uses an existing one) and invokes it. It means the number of containers is increased based on the number of incoming requests. So you as an action developer don’t need to concern about scaling. The system automatically scales according to your requests. And it is one of the most attractive features of serverless considering the complication and cumbersome activities to set up the auto-scaling with traditional cloud computing. (Surely, you as an OpenWhisk operator must take care of scaling, but it is not users’ business.)
You can be liberated from concerns about infrastructures, scaling, resource optimization, and just focus on your business logic with serverless. And Apache OpenWhisk would be the perfect starting point to get into the serverless world.
Why don’t you visit the OpenWhisk Github and look around at what you can do with fascinating emerging technology?
Stay tuned! We will look into how to deploy OpenWhisk in multiple ways in the next story!
