openwhisk under the hood -- london oct 16 2016
TRANSCRIPT
a cloud-native platform for
short-running, stateless computation and
event-driven applications which
scales up and down instantly and automatically and
charges for actual usage at a millisecond granularity
event handlersevents
What is Serverless?
What is OpenWhisk? a high-level serverless programming model
Trigger
Rule
Action
Package
language support to encapsulate, share, extend code
first-class event-driven programming
constructs
first-class functions compose via sequences
docker containers as
actions
all constructs first-class — powerful extensible
language
What is OpenWhisk under the hood?
http://fordmustanglover.blogspot.com/
• Basic Runtime
• Meta-programming
github.com openwhisk/openwhisk
coreruntime
CLIpackagessecurityfeatures
persistent store
loggingmonitoring billing
authentication
Edge VMEdge
VM
Edge VM
Edge VMEdge
VM
Master VM
controllerEdge VMEdge
VM
Slave VM
invoker
• microservices deployed in docker containers • open-source system middleware • NoSQL (CouchDB) persistence
action containeraction
containeraction containeraction
containeraction containeraction
containeraction containeraction container
Slave VM
Why ?
Lightweight isolated execution environment for arbitrary user code
action containeraction container
action containeraction container
action container
action containeraction container
action container
2
Step 1. Entering the system
Edge VMEdge
VM
Edge VM
Edge VMEdge
VM
Master VM
controller
Why
POST /api/v1/namespaces/myNamespace/actions/myAction
? • SSL termination • Load Balancing • Blue/Green continuous delivery
Master VM
kafka SDK
couchDBSDK
sprayDSL
loadbalancer
consulSDK
data modelsauthcaching
Why scala ?
Step 2. Handle the request
• original prototype node.js: abandoned and rewrote • static typing
• makes refactoring much easier • whole classes of bugs went away
• nice concurrency features (actors/futures) • kafka libraries more stable on JVM
actors
controller
Step 3. Authentication + Authorization
scala
kafka SDK
couchDB SDK
spray DSL
load balancer
consul SDK
data models
authcaching
external auth
• Cloudant: hosted CouchDB • plug-in structure for custom
authentication module
actors
controller
Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l
Step 4. Get the action
scala
kafka SDK
couchDB SDK
spray DSL
load balancer
consul SDK
data models
authcaching
• check resource limits • actions stored as documents in CouchDB
• binaries as objects (attachments)
actors
controller
Step 5. Looking for a home
scala
kafka SDK
couchDB SDK
spray DSL
load balancer
consul SDK
data models
authcaching
controller
Load balancer: find a slave to execute Slave health, load stored in consul
• Sequentially consistent KV store • Replication, Fault Tolerance • Health Check / Monitoring utilities
Why ?
actors
Step 6. Get in line!
scala
kafka SDK
couchDB SDK
spray DSL
load balancer
consul SDK
data models
authcaching
invoker
Why ? • High throughput fault-tolerant queues • Point-to-point messages via topics
• explicit load balancing
Post request to execute to queue in
actors
Master VM
Master VM Slave VM
controller
Slave VM
Step 7. Get to work!
scala
kafka SDK
couchDB SDK
docker utilities
container pool
consul SDK
data models
caching
invoker
bound to user action
• each user action gets it own container (isolation) • containers may be reused • container pool allocates and garbage collects containers
stem cell
actors
User action containers
invoker
containerpool
cold start stem cell container
docker run
HTTP POST /init
HTTP POST /run
warm container
Step 8. Store the results.
scala
kafka SDK
couchDB SDK
docker utilities
container pool
consul SDK
data models
caching
invoker
action container
HTTPResponse
logs on filesystem
actors
using OpenWhisk feeds
wsk package bind /whisk.system/github myGit --param username myGitUser --param repository myGitRepo --param accessToken aaaaa1111a1a1a1a1a111111aaaaaa1111aa1a1a
1 Bind a Package with your credentials (parameters)
using OpenWhisk feeds
wsk package bind /whisk.system/github myGit --param username myGitUser --param repository myGitRepo --param accessToken aaaaa1111a1a1a1a1a111111aaaaaa1111aa1a1a
wsk trigger create myGitTrigger --feed myGit/webhook --param events push
1 Bind a Package with your credentials (parameters)
2 Create a Trigger (instantiate a stream of events)
using OpenWhisk feeds
wsk package bind /whisk.system/github myGit --param username myGitUser --param repository myGitRepo --param accessToken aaaaa1111a1a1a1a1a111111aaaaaa1111aa1a1a
wsk trigger create myGitTrigger --feed myGit/webhook --param events push
wsk rule create R myGitTrigger myAction
1 Bind a Package with your credentials (parameters)
2 Create a Trigger (instantiate a stream of events)
3 Create a Rule (hook trigger to an action)
logical architecture of a github feed service
REST API
Create feed POST /feeds
Read feed GET /feeds/{id}
Update Feed PUT /feeds/{id}
Delete feed DELETE /feeds/{id}
wsk trigger create
what’s the easiest way to implement a service?
REST API
Create feed POST /feeds
Read feed GET /feeds/{id}
Update Feed PUT /feeds/{id}
Delete feed DELETE /feeds/{id}
what’s the easiest way to implement a service?
REST API
Create feed POST /feeds
Read feed GET /feeds/{id}
Update Feed PUT /feeds/{id}
Delete feed DELETE /feeds/{id}
logical architecture of a github feed service
serverless feed action
main(params) { … params.lifecycle == Create Read Update Delete }
wsk trigger create
feed action: an OpenWhisk action which manages a feed
wsk trigger create myGitTrigger --feed myGit/webhook --param events push
-> wsk action invoke myGit/webhook --param events push —-param lifecyleEvent ‘CREATE’ —-param triggerName myNamespace/myGitTrigger —-param auth myAuthKey …
wsk package create myGitPackage
wsk action create myGitPackage/myFeedAction action.js
wsk package update myGitPackage --shared
Create your own package and share it
/yourNamespace/myGitPackage
T A B Csequence
R
cloud
debug> break on B … debug> inspect ..
developer laptop
But how ? • Serverless runtime is stateless, short-running • debugging tools (Chrome, lldb, ..) are local
T A B CR
% (wskdb) attach b
create jump action Bj
Bccreate continue action
% wsk action create Bj ..
% wsk action create Bc ..
T A B CR
% (wskdb) attach b
T A BjRj
create jump action Bj
Bccreate continue action
create jump rule
% wsk action create Bj ..
% wsk action create Bc ..
% wsk rule create Rj A Bj
T A B CR
% (wskdb) attach b
T A BjRj
T2 Bc CRc
create jump action Bj
Bccreate continue action
create continue rule
create jump rule
% wsk action create Bj ..
% wsk action create Bc ..
% wsk rule create Rj A Bj
% wsk rule create Rc Bc C
T A B CR
% (wskdb) attach b
T A BjRj
T2 Bc CRc
create jump action Bj
Bccreate continue action
create continue rule
create jump rule
start up local debug broker
% wsk action create Bj ..
% wsk action create Bc ..
% wsk rule create Rj A Bj
% wsk rule create Rc Rc C
All the debugger components are unprivileged user code
debugging broker
(wskdb)
T A BjRj
T2 Bc CRc
Bj Bc
Uses OpenWhisk introspection to examine and rewrite the user code using actions, triggers, rules.
https://github.com/openwhisk/openwhisk-debugger
Edge VMEdge
VMEdge VM
Edge VMEdge
VMMaster VM
Edge VMEdge
VMSlave VM
REST client
CLI
UI
core runtime
foundation: virtual machines (IaaS, vagrant, …)
Why virtual machines? • direct access to host OS for some container functions • OS support for security, networking, resource control • infrastructure, stability, tools