Serverless meetup - OpenWhisk overview and architecture
Overview and Architecture
- Serverless, open source cloud platform
– Sandeep Paliwal
Overall 10+ years of IT experience
Computer Scientist at Adobe
Part of Adobe I/O team
– platform for developers to integrate, extend, or create apps and experiences based on
Adobe's products and technologies.
Working on Adobe I/O Runtime project
Serverless platform that allows you to quickly deploy custom code to respond to events
OpenWhisk - Introduction
Serverless, open source cloud platform
Runs user code in response to events or direct invocations
Started by IBM
API gateway contributed by Adobe, also Adobe actively contributing to current project and tools around OpenWhisk
Red hat recently announced their support for the project.
Active community of developers
Supports different invocation models
Multi Language support
OpenWhisk - Introduction
Support for programming constructs like
Support for plugging in event producers via Feeds
Allows Rule based invocations
User code is mapped to events (internal or external)
Ex. Incoming emails produces an event which can run user code.
Tracking Request – API Gateway
Ngnix – the entry point
Used for SSL termination
Forwarding HTTP request calls to appropriate components
Can also be used for
Tracking Request - Controller
Scala based implementation of REST APIs (Akka and spray based)
Interface for everything user can do
CRUD requests for user entities in OenWhisk
Invoking on user code (Actions)
Understands the requests and take necessary action
Delegate to next component based on request
Tracking request – Authentication and
Controller gets user details from CouchDB
Verifies sent credentials against ones stored in DB
Checks user privileges
In case of action invocation means action should belong to namespace users owns
Tracking request – Fetching the user code
Controller loads Action code from CouchDB
Code to be executed
Any defaults parameters
Any resource restrictions on memory, timeout etc.
Merges passed parameters with the default ones.
Tracking request – who wants to run the
Controller gets a list of healthy Invokers from Consul which can execute code of
Now that we have our code executor what can possibly go wrong?
A system crash and we lose our invocation
System is heavily loaded and we need to wait
Tracking request – you are in a queue
High throughput, distributed, publish subscribe messaging system.
Controller and Invoker only communicate through Kafka
Controller publishes message to selected Invoker
Kafka takes care of persisting the message
Once Kafka receives the message it sends acknowledgement to Controller (ActivationId)
For non blocking calls Controllers just sends back this ActivationId to caller.
ActivationId is also persisted in CouchDB to get result/logs later for the given invocation.
Tracking request – Finally lets just run the
Implemented in Scala
Also uses Docker
Docker is used to setup a new self-encapsulated environment (container) in which
action can be executed in fast and isolated way.
Each action gets its own container spawned
Action code is injected
Action is executed and result is obtained
Result is sent back to caller in case of blocking request
For Unblocking request, result can be fetched using ActivationId
This completes the full request execution
Tracking request – Storing the results
Invoker again uses CouchDB to store action result and the logs code execution
These are stored against the ActivationId which was generated initially.
User can use the ActivationId now to check result /logs as required using REST
Try it Out!!
IBM Bluemix - https://console.bluemix.net/openwhisk/
Git repo - https://github.com/apache/incubator-openwhisk
Keep in touch
My email –
Adobe is Hiring!!