Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Serverless meetup - OpenWhisk overview and architecture


Published on

Presentation at Serverless meetup Bangalore, 22July 2017

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Serverless meetup - OpenWhisk overview and architecture

  1. 1. Overview and Architecture Apache OpenWhisk - Serverless, open source cloud platform – Sandeep Paliwal
  2. 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. 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. 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. 5. OpenWhisk – System Overview
  6. 6. OpenWhisk - Architecture overview
  7. 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. 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. 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. 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. 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. 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. 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. 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. 15. Try it Out!!  IBM Bluemix -  Git repo -
  16. 16. Keep in touch  My email –    LinkedIn   Adobe is Hiring!!
  17. 17. References   really-work-3cb127b05f71  interconnect-2017
  18. 18. Thank You