OpenWhisk is an open source serverless cloud platform that runs user-provided code in response to events or direct invocations. It was started by IBM and supports multiple programming languages and invocation models. The OpenWhisk architecture uses Nginx as an API gateway, a Scala controller to handle requests, Consul for service discovery, Kafka for messaging, Docker containers to run code, and CouchDB for persistent storage. This allows user code to be quickly deployed and executed in response to events in a scalable and reliable manner.

1. Overview and Architecture
Apache OpenWhisk
- Serverless, open source cloud platform
– Sandeep Paliwal

2. About Me
 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

3. 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
 Blocking
 Non-Blocking
 Periodic
 Multi Language support
 Javascript, Java, Python, Swift3, Any Language( Docker)

4. OpenWhisk - Introduction
 Support for programming constructs like
 Chaining/Sequencing
 Parameter Binding
 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.

5. OpenWhisk – System Overview

6. OpenWhisk - Architecture overview

7. Tracking Request – API Gateway
 Ngnix – the entry point
 Used for SSL termination
 Forwarding HTTP request calls to appropriate components
 Can also be used for
 Collecting Metrics
 Rate Limiting
 Request Throttling

8. 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
 Authentication
 Authorization
 Delegate to next component based on request

9. Tracking request – Authentication and
Authorization
 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

10. Tracking request – Fetching the user code
(Action)
 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.

11. Tracking request – who wants to run the
code (Consul)
 Consul
 Service discovery
 Health checks
 Controller gets a list of healthy Invokers from Consul which can execute code of
given type.
 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

12. Tracking request – you are in a queue
(Kafka)
 Kafka
 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.

13. Tracking request – Finally lets just run the
code (Invoker)
 Invoker
 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

14. Tracking request – Storing the results
(CouchDB)
 Invoker again uses CouchDB to store action result and the logs code execution
produced.
 These are stored against the ActivationId which was generated initially.
 User can use the ActivationId now to check result /logs as required using REST
APIs/CLI

15. Try it Out!!
 IBM Bluemix - https://console.bluemix.net/openwhisk/
 Git repo - https://github.com/apache/incubator-openwhisk

16. Keep in touch
 My email –
 spaliwal@adobe.com
 sandy801@gmail.com
 LinkedIn
 https://www.linkedin.com/in/sandeep-paliwal-7879a147/
 Adobe is Hiring!!

17. References
 https://github.com/apache/incubator-openwhisk
 https://medium.com/openwhisk/uncovering-the-magic-how-serverless-platforms-
really-work-3cb127b05f71
 https://www.slideshare.net/OpenWhisk/ibm-bluemix-openwhisk-overview-
interconnect-2017

18. Thank You