openwhisk under the hood -- london oct 16 2016

62
OpenWhisk Under the Hood Stephen Fink

Upload: stephen-fink

Post on 16-Apr-2017

351 views

Category:

Technology


0 download

TRANSCRIPT

OpenWhiskUnder the Hood

Stephen Fink

What is OpenWhisk?

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?

an open Beta offering in IBM’s Bluemix cloud

What is OpenWhisk? an open-source project on github

What is OpenWhisk? a high-level serverless programming model

Trigger

Rule

Action

Package

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

Why ?

Why ?

controller

invoker

Deploying and managing traditional microservices1

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

Why ?

Portable description of arbitrary binary user actions (Dockerfile)

Docker file

3

% wsk action invoke hello

in 8 easy steps

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

controller

Step 2. Handle the request

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

invoker

Step7. Get to Work!

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

median ~45 ms latency end-to-end (unloaded system, hello world)

Implementing feeds

Trigger

Action

Action

Action

custom feed example

push, fork, comment, ..

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)

anybody can create a Package with a feed

/whisk.system/github /mynamespace/github

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

More Meta-Programming

Building an OpenWhisk debugger in OpenWhisk

T A B Csequence

R

cloud

T A B Csequence

R

cloud

debug> break on B … debug> inspect ..

developer laptop

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

Implementing a breakpoint

ld push store add jmp sub ld push

debug: push … ret

T A B CR

% (wskdb) attach b

T A B CR

% (wskdb) attach b

create jump action Bj% wsk action create Bj ..

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

T A BjRj

cloud

debugging broker

(wskdb)

T2 Bc CRc

developer laptop

T A BjRj

cloud

debugging broker

(wskdb)

T2 Bc CRc

developer laptop

T A BjRj

cloud

debugging broker

(wskdb)

T2 Bc CRc

developer laptop

T A BjRj

cloud

debugging broker

(wskdb)

T2 Bc CRc

developer laptop

T A BjRj

cloud

debugging broker

(wskdb)

T2 Bc CRc

developer laptop

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

Future directions

What’s coming next?

What are you going to do next?

What are you going to do next?

Backup

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