Skip to content

README.md

Latest commit

 

History

History
81 lines (60 loc) · 3.12 KB

README.md

File metadata and controls

81 lines (60 loc) · 3.12 KB

OpenLambda Worker

Deployment

See how to build the code, deploy a worker, and write/run lambdas here.

Usage

Design

The following shows the major components of an OpenLambda worker:

The worker consists of three layers (from the bottom up): sandbox, lambda, and event.

1. Sandbox

A sandboxing system (containers, VMs, etc) is necessary to isolate lambda functions from each other in any serverless platform. This is a pluggable layer in OpenLambda -- different implementations can be defined in github.com/open-lambda/open-lambda/ol/worker/server.

Very early on, OpenLambda used Docker containers for isolation. Now, the main implementation is SOCK (serverless-optimized containers) -- the first version of this is described in Oakes et al..

2. Lambda

The invocation of a lambda function occurs in a container, but it's possible to have a lambda function with zero containers (or many containers). The lambda layer is in the github.com/open-lambda/open-lambda/ol/worker/lambda package.

The two most important subsystems in this layer are the lambda function and lambda instance. A lambda instance is like a robust virtual container and is backed by either 0 or 1 sandboxes. A lambda instance provisions a sandbox as needed and restarts it upon failure. When there are no incoming requests, the lambda instance is responsible for pausing the backing container (if any).

The lambda function takes incoming requests and forwards them to lambda instances. A lambda function decides how many lambda instances there should be based on number of queued requests and the average invocation time. The number of instances can be viewed as how many containers the lambda function "wants" -- it might get fewer (if memory is limited, it may not be possible to back every instance with a container).

3. Event

Major cloud offerings (like AWS lambda) offer a variety of lambda triggers, such as HTTP requests, queue messages, cron, DB/S3 triggers, etc.

OpenLambda currently supports three types of triggers: HTTP requests, Kafka messages, and cron schedules. The event code is in the github.com/open-lambda/open-lambda/ol/worker/event package.

HTTP triggers: Requests to http(s)://WORKER_ADDR:PORT/run/LAMBDA_NAME invoke lambdas directly.

Kafka triggers: Lambdas can be configured to consume from Kafka topics. The worker runs Kafka consumers that poll for messages and invoke the corresponding lambda function automatically. See kafka-triggers.md for details.

Cron triggers: Lambdas can be invoked on a schedule using cron expressions. The boss component runs a cron scheduler that automatically invokes lambdas at the configured times.