Status of Serverless Computing and Function as a Service(FaaS) in Industry and Research

WHITEPAPER 

First

_​

_​

International

_​

_​

Workshop

_​

_​

on

_​

_​

Serverless 

Computing

_​

_​

(WoSC)

_​

_​

2017 

Report

_​

_​

from

_​

_​

workshop

_​

_​

and

_​

panel

_​

_​

_​

on

_​

_​

the

_​

_​

Status

_​

_​

of 

Serverless

_​

_​

Computing

_​

_​

and

_​

_​

Function-as-a-Service 

(FaaS)

_​

_​

in

_​

_​

Industry

_​

_​

and

_​

_​

Research

 

 

Geoffrey

_​

_​

C.

_​

_​

Fox

_​

_​

(Indiana

_​

_​

University) 

Vatche

_​

_​

Ishakian

_​

_​

(Bentley

_​

_​

University) 

Vinod

​

​

Muthusamy

​

​

(IBM) 

Aleksander

​

​

Slominski

​

​

(IBM) 

  This​​whitepaper​​summarizes​​issues​​raised​​during​​the​​​​First​​International​​Workshop​​on  Serverless​​Computing​​(WoSC)​​2017​​​[1]​​​held​​June​​5th​​2017​​and​​especially​in​ ​​​​the​​panel​​​[2–5]  and​​associated​​discussion​​that​​concluded​​the​​workshop.​​We​​also​​include​​comments​​from  the_​​keynote_​​​[6]_​​​and_​submitted_{​ ​​}papers_​​​[7–10]_​._​​A_​​glossary_​​at_​​the_​​end_​​(section_​​8)_​​defines_​​many  technical​​terms​​used​​in​​this​​report. 

Panel​​participants​:​​​​Geoffrey​​C.​​Fox​​(Indiana​​University),​​Rodric​​Rabbah​​(IBM),​​Garrett  McGrath​​(University​​of​​Notre​​Dame),​​Edward​​Oakes​​(University​​of​​Wisconsin-Madison),  Ryan​​Chard​​(Argonne​​National​Laboratory),​ ​​and​​Ali​​Kanso​​(IBM) 

​

1

_​

 Introduction 

Panel​​participants​​were​​asked​​to​​provide​​a​​short​​presentation​​for​one​ ​​of​​suggested​​topics  

● Argue_​​that_​​serverless_​​computing_​​is_​​nothing_​new_{​ ​​}and_​​point_​out_{​ ​​}the_​​relevant_​​literature 

and​​past​​achievements 

● Take​​the​​position​​that​​serverless​computing​ ​​is​​fundamentally​​different​​and​​requires  revisiting​​common​​assumptions. 

● Discuss_​​challenging_​​real-world_​​problems_​that_{​ ​​}could_​​be_​​research_​​issues.  ● Outline​​the​​definition​​and​scope​ ​​of​​serverless​​computing​​platforms. 

● Propose​​a​​benchmark​to​ ​​compare​​serverless​​platforms. 

● Suggest​​a​​timeline​​for​​evolution​of​ ​​technology​​and​​adoption​​for​​area  The​​panel​​and​​workshop​​​presentations​​are​​linked​​from​​the​​workshop​​website​.  

In​​this​​whitepaper​​we​​will​​only​​summarize​​and​​emphasize​​the​themes​ ​​that​​were​​raised  during​​panel​​and​​workshop​​-​​the​​detailed​notes​ ​​are​​available​​as​​​a​​separate​​document​.  We​​believe​​that​​serverless​​computing​​​[11]​​​is​​not​​only​​an​exciting​ ​​platform​​for​​researchers  to​​explore​​but​​also​​for​​academia​​to​use.​ ​​There​​are​​upcoming​​changes​​in​​leading​​cloud  analytics​​platforms​​to​​become​​more​​serverless​(for​ ​​example​​Spark​[12]​​ ​)​​and​​some  experiments​​to​​use​​serverless​​directly​​as​runtime​ ​​for​​analytics​(for​ ​​example​​​[13]​).   

​

2

_​

 Basic

_​

_​

Definition

_​

_​

of

_​

_​

Serverless

_​

_​

and

_​

_​

FaaS 

Serverless_​​evolved_​​over_​​time_​​as_​​shown_​​in_​​Fig.  1.​​The​​beginning​​of​​usage​​of​​the​​term 

Engine​​​[16–18]​.​​The​​latest​​serverless  solutions​​are​​really​​server-hidden​​and  built​​to​​host​​functions​​and​​hide​​that​​the  functions​​runs​​on​servers​ ​​or​​how​​scaling  is​​done.​​The​​functions​may​ ​​be​​part​​of​​a  service​​(for​​example​​Azure​​Data​​Lake  Analytics​​​​or​​Google​​Cloud​​Datalab)​​or  offered​​as​​an​​independent​​service​​called  Function-as-a-Service​​or​​FaaS.​​Note​​that  unlike​​SaaS​​or​PaaS​ ​​that​​are​​always 

running,​​but​​scale​​on-demand,​​serverless​​workloads​​run​​on-demand,​​and​​consequently,  scale​​on-demand.​​Summarizing​​this,​​we​​see​​that​the​ ​​same​​term​​serverless​​is​​being​​used​​to  describe​​related​​but​​different​​concepts. 

From​​the​​IBM​​tutorial​at​ ​​workshop​​​[19,20]​,​​we​​find​​their​​definition​​of​​FaaS​​and​​Serverless​​as 

● 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 

details​​of​​this​​evolution​​are​​given​​in​​Figs.​3​ ​​and​​4.​​Hiding​the​ ​​server​​infrastructure​​as​​in  Serverless​​is​​coming​​to​​attention​​just​​as​​public​​clouds​​​​offer​​an​​increasingly​​rich​​variety​​of  instances​​with​​compute,​​memory,​​accelerator,​and​ ​​I/O​​choices​​that​​offer​​amazing 

functionality​​but​​at​​increasing​​complexity.  Fig.​​5​​summarizes​​some​​of​​areas 

where​​today​​serverless​​may​​excel  or​​have​​limitations.​​However  discussion​​at​​the​​meeting 

suggested​​that​​this​​characterization  could​​change.​​For​​example​​today  FaaS,​​Event​​driven​​computing,  stateless,​​and​​short​​running​​are​​all  associated​​with​​serverless.​​However  we​​can​​expect​​these​​important  ideas​​to​​evolve​​independently​​and 

not​​be​​tied​​closely​​together.​​For​​example,​​event​​driven​​FaaS​could​ ​​support​​long​​running  jobs​​and/or​​be​​offered​​on​​explicit​​IaaS.​​Contrastly​​serverless​​ideas​(hiding​ ​​the​​details​​of  server​​deployment)​​could​​be​​used​​on​many​ ​​different​​cloud​computing​ ​​scenarios.​​In​​the  keynote,​​Barga​​described​​Amazon​​Lambda​​which​​is​​their​​event​​driven​​computing​​model  underlying​​their​​serverless​​offering.​​The​Lambda​ ​​homepage​​​[21]​​​describes​​serverless​​FaaS  well: 

“AWS_​​Lambda_​​lets_​​you_​​run_​​code_​​without_​​provisioning_​​or_​​managing_​​servers._​​You_​​pay_​​only_​​for_​​the  compute_​​time_​​you_​​consume_​​-_​​there_​​is_​​no_​charge_{​ ​​}when_​​your_​​code_​is_{​ ​​}not_​​running._​​With_​​Lambda,  you​​can​​run​​code​​for​​virtually​​any​​type​of​ ​​application​​or​​backend​service​ ​​-​​all​​with​​zero 

administration.​​Just​​upload​​your​​code​​and​​Lambda​takes​ ​​care​​of​​everything​​required​​to​​run​​and  scale_​​your_​​code_​​with_​​high_​​availability._​​You_​​can_​​set_​​up_​​your_​​code_​​to_​​automatically_​​trigger_​​from  other_​​AWS_​​services_​​or_​​call_​​it_​directly_{​ ​​}from_​​any_​web_{​ ​​}or_​​mobile_​​app.” 

5)​​--​​identified​​as​​joining​​serverless​​as​​two​​separate​​drivers​of​ ​​next​​generation​​cloud  computing.  

​

3

_​

 Comments

_​

_​

on

_​

_​

Serverless

_​

_​

and

_​

_​

FaaS

_​

_​

Technologies:

_​

_​

The 

State

_​

_​

of

_​

_​

Serverless

_​

_​

Computing 

​

3.1

_​

 The

_​

_​

definition

_​

_​

compared

_​

_​

to

_​

_​

current

_​

_​

practice

_​

_​

in 

serviceless

​

​

and

​

​

FaaS

One​​issue​​that​​was​​raised​​often​was​ ​​the​​definition​of​ ​​serverless​​and​​Function-as-a-Service  (FaaS)​​already​​brought​​up​​in​​section​​2.​​The​​serverless​​manifesto​​poses​​this​​well​​​[22]​.​​During 

his​​workshop​​keynote​[6]​​ ​,​​Roger​​Barga  defined​​serverless​​as​the​ ​​next​​stage​​of  in​​an​​evolution​​of​​cloud​​computing  from​​Grid​​to​IaaS​ ​​Cloud​​to​​PaaS/SaaS  to​​serverless​​FaaS,​​where​​developers  can​​build​​services​​without​​worrying  about​​servers;​​both​​event​​driven​​and  stateless​​did​​not​seem​ ​​essential​​--​​just  common​​features.​​He​​used​​the 

larger​​jobs​​on​​a​​cloud​​infrastructure.​​Still​​this​​feature​​including​its​ ​​important​​lower​​cost,  could​​evolve​​to​​just​​one​​of​​several​​serverless​​offerings.​​We​can​ ​​discuss​​the​​relation  between​​Apache​​Storm​​(Heron​​or​​Amazon​​Kinesis)​​compared​​to​​Apache​​OpenWhisk​​(or  Amazon​​Lambda).​​How​​does​​the​​dataflow​​model​in​ ​​Storm​​(or​​Spark​​and​​Flink)​​relate​​to 

FaaS?​​Eventually​​FaaS​​could​​be​​an​​implementation.​​​We​ ​​can​​also​​compare​​SaaS​​with​​FaaS;​​is  the_​​latter_​​an_​​advanced_​​subset_​​of_​​former?_​And_{​ ​​}in_​​general_​​what_​​are_​​the_​​intersections_​​and  overlaps​​between​​traditional​​serverless​​(where​​servers​literally​ ​​are​​not​used​ ​​instead​​code​​is  running​​peer-to-peer​​to​​provide​​services​​such​​as​​storage,​​messaging,​​etc.)​​and​​event-driven  computing​​(see​​Fig.​​7)?​And​ ​​is​​FaaS​​limited​​to​​event-driven​​computing​​?​​​​​Note​ ​​Figs.​​6​​and​​7  are_​​inconsistent_​​in_​​detail_​​with_​​the_​​nested_​​classifications_​of_{​ ​​}Fig._​​6_​​being_​relaxed_{​ ​​}in_​​Fig._​​7;_​​this  just​​reflects​​the​​typical​confusion​ ​​in​​an​​emerging​​field. 

The​​​​Cloud​​Native​​Computing​​Foundation​​CNCF​​Serverless​​Working​​Group​​is​​exploring​​the  intersection​​of​​cloud​​native​​and​​serverless​​technology​​and​​their​​web​resource​ ​​​[23]​​​has​​a  substantial​​accumulation​​of​​useful​information​ ​​on​​serverless​​and​​FaaS. 

The_​​increasing_​​importance_​​of_​​Serverless_​​computing_​is_{​ ​​}illustrated_​​by_​the_{​ ​​}appearance_​​of_​​the  term​​“Serverless​​PaaS”​​which​​is​​"on​​the​​rise"​​​​in​​the​​2017​​Hype​​Technologies​​Report​​​[24]  from​​Gartner. 

​

3.2

​

 What

​

​

is

​

​

new

​

​

about

​

​

Serverless? 

Rodric​​Rabbah​​brought​​forward​​the​​recent​​example​​of​​the​​FCC​website​ ​​that​​collapsed​​when  it​​was​​unable​​to​​handle​​comments​​about​​net​​neutrality.​​That​is​ ​​good​​example​​where 

serverless​​could​​be​​making​​an​​immediate​​real​difference​ ​​-​​if​​the​​FCC​​used​​a​​serverless  platform_​​that_​​would_​​have_​​a_​​better_​​chance_​​to_​​handle_​​the_​​scale_​​of_​​traffic_​​generated._​​Trying_​​to  decide​​how​​many​​servers​​to​​deploy​​and​​then​​maintain​​their​​scaling​​is​​hard​​job​​and​​unless  substantial​​expertise​​is​​available​​in-house​​it​​is​​easy​​to​​make​mistakes.​ ​​This​​example​​brings  up​​the​​support​​of​​elasticity​​and​cloud-bursting​ ​​to​​reach​larger​ ​​capacity​​sites;​​scheduling  technology_​​needs_​​to_​​be_​​improved_​​to_​​support_​​this. 

What​​is​​also​​making​​serverless​​attractive​​is​a​ ​​cloud​​offering​​of​​an​​ecosystem​​of​​supporting  middleware​​and​​artificial​​intelligence​​services​that​ ​​integrate​​seamlessly​​with​​the​​serverless  platform​​to​​enable​​natural​​language​processing,​ ​​image​​recognition,​​manage​​state,​​record  and​​monitor​​logs,​​send​​alerts,​​trigger​​events,​​​​or​​perform​​authentication​​and​​authorization.  The_​​use_​​of_​​such_​​services_​​not_​​only_​present_{​ ​​}another_​​revenue_​​stream_​​for_​​the_​​cloud_​​provider,  but​​also​​enables​​application​​dependency​​on​​the​​provider’s​​ecosystem​​and​​vendor​​lock-in.  Serverless​​builds​​upon​​technologies​​that​​have​​been​​subject​​of​​previous​​research​​in 

different​​computing​​domains,​​what​​is​​particularly​new​ ​​about​​serverless?​Is​ ​​Serverless​​be​​all  and​​end​​all​​of​​new​​technologies?​What​ ​​is​​the​real​ ​​cost​​of​​Serverless? 

3.3

​

 Is

​

​

Serverless

​

​

Necessarily

​

​

Stateless? 

The​​stateless​​or​​stateful​​aspect​​of​​serverless​​produced​​much​​discussion.​​Storing​​state  external​​to​​a​​“stateless”​​FaaS​​could​enable​ ​​many​​important​applications​ ​​and​​allow​​big  datasets​​to​​trigger​​multiple​​microservice-based​​FaaS​invocations.​ ​​Here​​we​can​ ​​look​​at​​AWS  Step_​​Functions_​​which_​​can_​​orchestrate_​​a_​workflow_{​ ​​}of_​​multiple_​microservices_{​ ​​}while_​​RDD_​​in  Spark​​can​​store​​state​​in​​an​​external​​entity​​that​​can​​easily​​be​​accessed​​by​​using​​an 

in-memory​​database.​​Note​​the​​manifesto​​​[22]​​​SLE​​assertion​​that​​in​​serverless:​​“permanent  Storage​​Lives​​Elsewhere”. 

​

3.4

​

 Provider

​

​

Side

​

​

view

​

​

of

​

​

Serverless 

This​​was​​discussed​​in​​McGrath’s​​panel​​presentation​​​[5]​​​with​​serverless​​computing​​allowing  providers​​to​​understand​​customer​​applications​​and​​to​​deliver​​value​​based​​on​​this 

information.​​Applications​​declare​​behavior​​such​​as​the​ ​​triggering​​events​and​ ​​one​​can​​also  predict​​behavior​​--​​perhaps​​with​​machine​learning​ ​​from​​logs.​The​ ​​serverless​​fine​​grained  programming​​model​​gives​​the​​provider​more​ ​​flexibility​​to​​schedule/optimize.​​There​​is  perhaps​​a​​relation​to​ ​​JIT​​compilers​​here. 

There​​are​​mutual​​economic​​pressures​​as​Cloud​ ​​providers​​need​to​ ​​cost-compete​​by​​running  datacenters​​more​​efficiently​​(utilization,​​energy-efficiency)​​while​​Cloud​​customers​​seek​​to  reduce​​cost​​by​​minimizing​​resource​​waste.​​Both​​can​​be​​satisfied​by​ ​​better​​matching​​of  application​​needs​​to​​allocated​​services.​​Serverless​computing​ ​​is​​a​large​ ​​step​​forward​​but  we’re​​not​​there​​yet​​as​​we​​ask​​for​​“Never​​pay​​for​​idle,​​or​​for​​wait”​​​[25]​​​as​​time​​spent​​waiting  on​​network​​(function​​executions​​or​​otherwise)​is​ ​​wasted​​by​both​ ​​provider​​and​​customer.  Here​​the​​billing​​model​​of​​serverless​​is​​questioned.​The​ ​​simple​​view​​is​that​ ​​one​​only​​pays​​for  what​​one​​uses​​but​​network​​delay​can​ ​​lead​​to​billing​ ​​for​​unused​​time. 

​

We​​discussed​​the​​compatibility​​of​​serverless​​with​​long​​running​​compute​​tasks​​with 

different​​aspects​​of​​this​​being​​illuminated​​by​the​ ​​panelists.​​Long​​running​​jobs​​are​​of​​course  well​​known​​in​​High​​Performance​​Computing​​(HPC)​​with​​sophisticated​​scheduling​​based​​on  user​​time​​estimates:​​serverless​​workloads​​today​​are​​very​​short​​lived​but​ ​​maybe​​in​​the  future​​will​​be​​longer​​as​​in​​HPC.​​The​provider​ ​​will​​need​​to​provide​ ​​a​​service​​level​​agreement  (SLA)​​and​​long​​running​​tasks​​give​​the​​provider​​less​​flexibility​in​ ​​scheduling​​and​​more  difficulty​​in​​cost-effective​​SLA’s.​​Of​​course,​​serverless​​gives​​the​​illusion​​of​​unlimited  resources​​and​​one​​“just”​​needs​​to​​realize​this.​ ​​One​​possibility​​is​​to​​handoff​​long​​running  jobs​​to​​a​​different​​container​​service.​​Alternatively,​​AWS​​Step​​Functions​let​ ​​you​​manage​​long  running​​flows​​by​​combining​​multiple​​(small)​​FaaS​​invocations. 

This​​question​​forces​​one​​to​​address​​the​​different​​facets​​of​​Serverless​​independently:  hidden_​​(from_​​user)_​​IaaS,_​​event-based,_​edge_{​ ​​}workflows,_​​streaming_​​data,_​​dataflow,_​​micro  (time,​​size)​​services.​​If​​long​​running​jobs​ ​​are​​allowed,​you​ ​​will​​presumably​​need 

checkpointing. 

​

3.6

_​

 Standards 

The_​​question_​​of_​​standards_​​was_​​discussed_​​with_​​the_​​clear_​​goal_​of_{​ ​​}supporting_​​easy_​​movement  of​​business​​logic​​between​​different​​serverless​​platforms​​and​​prevent​​vendor​​lock-in.​​There  are​​currently​​no​​directly​​applicable​​standards​​although​​it​​is​​early​​days​​to​​set​​standards​​for​​a  capability​​that​​is​​still​​being​​defined.​​Further​​we​know​ ​​that​​AWS​​is​the​ ​​market​​leader​​of​​the  field​​and​​may​​not​​have​​a​​clear​​motivation​​to​​develop​​standards​​other​​than​​the​​de​​facto  standard​​--​​their​​technology.​​It​​was​​noted​that​ ​​a​​rationale​​for​​open​​sourcing​​OpenWhisk​​is  to​​build​​a​​community​​from​​which​​standards​can​ ​​be​​developed.​​Further​​CNCF​​has​​a​​very  relevant​​working​​group​​[15].​​Again​​at​​this​early​ ​​stage,​​many​​smaller​​players​​can​​still​​upset  the​​market​​leader. 

​

3.7

​

 Programming

​

​

models 

We​​discussed​​possible​​programming​models​ ​​(reactive​​programming,​​logic​​programming,  functional,​​etc.)​​that​​could​​be​​appropriate​​to​​address​​FaaS​​including​the​ ​​problem​​of​​moving  compute​​around.​​Of​​course​​as​​with​​standards,​​we​​are​​right​​at​​the​​beginning​​and​​we​​can  expect_​​a_​​lot_​​of_​​opportunities_​​for_​​innovation_​​in_​​programming_​​languages_​​and_​​runtime.  Although​​event-based​​programming​​is​​not​​totally​​new,​the​ ​​use​​in​​the​​datacenter​​is​​a​​new  context,​​while​​IoT​​devices​​need​​to​​worry​about​ ​​energy​​usage.​​The​​intersection​​of​​FaaS​​and  traditional​​Big​​Data​​programming​​environments​​such​​as​​Spark,​​Flink,​​Hadoop,​​Storm​​and  Heron_​​is_​​discussed_​​in_​​​[26,27]_​. 

​

3.8

​

 Are

​

​

there

​

​

any

​

​

cons

​

​

to

​

​

Serverless

​

​

and

​

​

FaaS? 

There​​was​​a​​lengthy​​discussion​​of​​the​​possible​​negatives​​and​difficulties​ ​​with​​FaaS​​and  serverless.​​At​​the​​highest​​level​​there​​was​​concern​​that​​users​(industry)​ ​​were​​chasing​​the  latest​​fad​​(in​​this​​case​​serverless)​​without​​consideration​​of​​the​soundness​ ​​of​​the​​approach.  For​​example,​​there​​are​​still​​significant​​challenges​in​ ​​using​​OpenStack​​and​​Docker​​at​​scale.​​In  latter​​case,​​OpenWhisk​​uses​​Docker​​at​an​ ​​unprecedented​​scale​and​ ​​has​​uncovered​​many  concurrency​​bugs. 

Concerns​​were​​expressed​​about​​maintaining​the​ ​​(attractive)​​pricing​​model​​for​​Serverless.  This​​is​​important​​for​​keeping​​cost​down​ ​​for​​intermittent​streaming​ ​​applications.​​Note​​that  as​​one​​uses​​Serverless​​for​​more​​complex​​applications,​​the​​provider​will​ ​​get​​additional​​funds  from​​the​​incidental​​activities​​such​​as​​traditional​​storage​​(save​​state),​​a​​supporting 

serverless​​promotes​​separation​​of​​concerns​​between​​the​​application​​logic​​and​​the​​runtime.  Today​​the​​runtime​​is​​typically​​in​​the​cloud,​ ​​but​​it​​could​​be​​in-house​​as​​well. 

The_​​panel_​​discussed_​​using_​​Platform_​​as_​​a_​Service_{​ ​​}PaaS_​​instead_​​of_​​FaaS._​​PaaS_​​is_​​compatible  with​​scaling​​up​​the​​servers​​as​​needed​​to​meet​ ​​demand.​​For​​PaaS,​the​ ​​scaling​​is​​reactive​​and  not​​deterministic​​as​​for​​FaaS.​​Further,​​you​still​ ​​need​​to​​manage​​the​​workflow​​and​​minimum  number​​of​​instances​​for​​PaaS. 

A​​comparison​​was​​made​​with​​networking​with​ ​​an​​analogy​drawn​ ​​between​​FaaS​​and 

network​​packet​​switching​​with​​both​​multiplexing​​demand.​​QoS​​is​​difficult​in​ ​​both​​FaaS​​and  network​​packet​​switching​​with​latter​ ​​compared​​to​​circuit​​switching. 

 

​

3.9

_​

 Current

_​

_​

Serverless

_​

_​

Systems 

The_​​workshop_​​was_​​not_​​aimed_​​at_​​a_​​comprehensive_​​survey_​​of_​​existing_​​serverless 

technologies​​but​​it​​certainly​​did​​cover​​the​​current​​technology​​to​some​ ​​extent.​​Notably​​the  IBM​​Tutorial​​​[20]​​​gave​​a​​thorough​​discussion​​of​​what​​is​now​ ​​Apache​​OpenWhisk.​​The  keynote​​from​​Amazon​​​[6]​​​naturally​​covered​AWS​ ​​technologies;​​important​as​ ​​they​​are​​the  current_​​commercial_​​leader._​​As_​​well_​​as_​AWS_{​ ​​}Lambda_​​and_​Kinesis,_{​ ​​}Barga_​​covered_​​Greengrass  for​​IoT​​and​​X-Ray​​for​​debugging. 

The​​Notre​​Dame​​paper​​​[9]​​​described​​their​​new​​serverless​​system​built​ ​​around​​Docker​​on  Azure​​with​​Windows.​​They​​also​​compared​this​ ​​with​​Google,​AWS.​ ​​OpenWhisk,​​and​​Azure  serverless​​systems.​​The​​performance​​results​​seemed​​quite​​erratic​​in​​this​early​ ​​stage​​of​​the  field.​​This​​paper​​defines​​a​​benchmark​​and​​here​​we​​certainly​​need​​community 

development. 

The​​Wisconsin​​paper​​​[10]​​​was​​mainly​based​ ​​on​​the​Pipsqueak​ ​​python​​packaging​​application  but​​the​​open​​source​​OpenLambda​​technology​​was​​the​​environment​​used. 

​

4

_​

 Use

_​

_​

Cases

_​

_​

for

_​

_​

Serverless

_​

_​

and

_​

_​

FaaS 

Of_​​course_​​the_​​future_​​of_​​Serverless_​​and_​FaaS_{​ ​​}will_​​critically_​​depend_​​the_​​application_​​drivers_​​and  the​​breadth​​of​​user​​cases​​is​​driving​​a​​lot​of​ ​​the​​current​​interest​​in​​the​​field​​​[13]​.​​Amazon  Alexa​​like​​chatbots​​are​​another​​example​​of​​that​​interest​[28]​.​The​ ​​event-based​​model​​is  familiar​​from​​previous​​work​​such​​as​CORBA​ ​​on​​distributed​object​ ​​technology​​with​​RMI  (Remote_​​Method_​​Invocation)_​​or_​​RPC_​(Remote_{​ ​​}Procedure_​​Call)_​​implementing_​​FaaS._​​Rather  old​​examples​​of​​this​​include​​“optimization​​on​demand”​ ​​NEOS​​​[29]​​​and​​the​​DoD​​high​​level  architecture​​HLA​​implementation​​of​​distributed​simulation​ ​​​[30]​.​​NetSolve​​and​​GridSolve  [31]​​​​​represent​​the​​Grid​​community​​approach​​to​​RPC. 

 

One​​can​​also​​argue​​that​​the​​cloud​​provider​​can​​influence​​the​​use​​cases​​for​​Serverless.​​The  more​​self​​awareness​​(through​​monitoring)​​the​​cloud​​has​​(e.g.​​traffic​​patterns,​​resource  utilization,​​data​​transfer​​size/frequency,​​...),​​the​​more​​triggers​​it​​can​offer​ ​​to​​its​​customers  and_​​the_​​more_​​triggers_​​the_​​customer_​​have,_​​the_​​more_​​functions_​​they_​​can_​​write_​​to_​​react_​​to  those​​triggers.​​Serverless​​is​​a​​declarative​​policy-based​​approach​​such​​that​​the​​more  triggers​​we​​have,​​the​richer​ ​​the​​policies​​can​​be. 

​

4.1

​

 What

​

​

are

​

​

established

​

​

use

​

​

cases

​

​

for

​

​

serverless? 

One​​major​​use​​case​​motivation​​as​​stressed​​by​​Barga​​is​​user​​convenience;​​they​​do​​not​​want  to​​worry​​about​​complex​​IaaS.​​A​​more​​specific​​feature​​is​​the​​automatic​​elastic​​scaling​​as​​is  needed​​in​​many​​e-commerce​​applications​​such​​as​​ticket​​sales​​with​surges​ ​​in​​popularity.​​A  broad​​use​​case​​is​​support​​of​​edge​​computing​described​ ​​in​​section​​5​and​ ​​in​​the​​following​​we  discuss​​use-cases​​covered​in​ ​​papers​​and​​presentations. 

Barga’s​​keynote​​​[6]​​​discussed​​6​​classes​​of​​use-cases:​​web​​applications,​​backends​​including  IoT​​(section​​5),​​Big​​Data,​​Chatbots,​​Amazon​Alexa​ ​​and​​IT​​Automation.​​Under​​Big​​Data,​​Barga  mentioned​​PyWren​​with​​600​​concurrent​​functions;​​he​​challenged​​the​​audience​​to​​explore  more​​sophisticated​​MapReduce​​applications.​Image​ ​​thumbnail​​production;​​streaming​​social  media​​data​​analysis​​in​​Kinesis;​​data​​warehouse​​ETL​​transformations;​​e-commerce 

Reuters​​processes​​4,000​​requests​​per​​second​and​ ​​Expedia​​1.2​billion​ ​​requests​​per​​month  on​​Lambda.​​The​​video​​hosting​​company​​Vevo​handles​ ​​spikes​​of​​a​​factor​​80​​using​​serverless  elasticity. 

The​​Wisconsin​​Pipsqueak​​paper​​​[10]​​​describes​an​ ​​interesting​​application​to​ ​​have​​a​​large  number​​of​​Python​​library​​functions​​available​​for​​serverless​​FaaS.​​This​was​ ​​achieved​​with​​a  sleeping​​Python​​interpreter​​and​​the​​package​​stored​in​ ​​memory​​and​​SSD.​​The​​IBM​​paper​​​[7]  goes​​through​​a​​use​​case​​where​​OpenWhisk​is​ ​​used​​to​​process​​results​​of​​Vulnerability​​scans  on​​Docker​​containers​​managed​​by​​Kubernetes.​​The​results​ ​​of​​the​​scan​​posted​​on​​a​​policy  endpoint​​to​​be​​processed​​by​​FaaS.

​

4.2

​

 Can

​

​

serverless

​

​

help

​

​

with

​

​

scientific

​

​

research? 

The​​panel​​considered​​that​​serverless​​and​FaaS​ ​​although​​currently​explored​ ​​in​​business,​​do  have​​major​​importance​​for​​science​​and​engineering​ ​​research.​​For​example​ ​​there​​are​​many  scientific​​Instruments​​gathering​​data​​with​​custom​​Laboratory​​management​​systems​​that  could_​​be_​​unified_​​to_​​advantage_​​with_​​FaaS._​This_{​ ​​}is_​​related_​​to_​​applications_​​discussed_​​in_​​section  5​​and​​has​​been​​extensively​​in​​recent​workshops​ ​​​[32,33]​​​on​​streaming​​data​​for​​science.​​The  latter​​raised​​interesting​​questions​​about​​the​functionality​ ​​of​​systems​like​ ​​Apache​​Storm​​for  science​​experiments;​​these​​typically​​have​​events​​such​​as​​huge​​images​that​ ​​are​​larger​​than  those_​​seen_​​commercially._​​The_​​issues_​​of_​reproducibility,_{​ ​​}scalability,_​​and_​cost_{​ ​​}need_​​to_​​be  explored​​for​​science​​use​​cases. 

​

5

_​

 Edge

_​

_​

Computing:

_​

_​

A

_​

_​

Key

_​

_​

Driver

_​

_​

for

_​

_​

Serverless

_​

_​

and

_​

_​

FaaS 

There_​​is_​​a_​​natural_​​relevance_​​of_​​FaaS_​​and_​​edge_​​computing_​​as_​​latter_​​is_​​inevitably_​​built_​​around  events​​shared​​between​​device​​and​​fog;​​fog​​and​​cloud​​​[26]​.​​In​​fact​​this​​link​​between 

serverless​​and​​edge​​computing​​was​​an​​important​​take-away​​from​​the​​workshop.​​This  edge-cloud​​integration​​can​​be​​implemented​​​[34]​​with​ ​​Apache​​Storm​(AWS​ ​​Kinesis)​​linked​​to  Apache_​​OpenWhisk_​​(AWS_​​Lambda)._​​It_​​was_​​stressed_​​that_​​we_​​are_​not_{​ ​​}proposing_​​to_​​move  computing​​to​​the​​edge​​but​​rather​​to​​integrate​the​ ​​edge​​with​​the​cloud.​ ​​In​​fact​​data​​centers  are​​getting​​larger​​not​​smaller​​and​​we​​are​​not​​moving​​back​​to​​a​​very​​distributed​​core 

computing​​model​​except​​for​​the​​case​​where​​we​​need​​to​​link​​datacenters​​to​​activities​​at​​the  edge._​​Content_​​Delivery_​​Networks,_​​multiplayer_​games,_{​ ​​}smart_​​homes_​​​[35]_​​​and_​​autonomous  vehicles​​are​​current​​important​​examples,​​where​the​ ​​latter​​cases​were​ ​​obviously​​very​​hot  with​​the​​CES​​show​​in​​Las​Vegas​ ​​January​​2017​full​ ​​of​​such​​startups. 

iRobot​​use​​of​​Lambda​​and​​AWS​​Step​​Functions​​for​​Image​recognition​ ​​was​​described​​by  Barga_​​​[6]_​​​as_​​an_​​example_​​of_​​inherently_​​distributed_​​serverless_​​application._​​Barga_​​further  discussed​​AWS​​Greengrass​​​[36]​​​extending​Lambda​ ​​to​​a​​common​​cloud-device​​environment  with​​interesting​​quote​​​“​​Amazon_​​expects_​​that_​​the_​​majority_​​of_​on-premises_{​ ​​}hardware_​​will_​​soon  be_​​IoT_​​devices_​​as_​​enterprises_​​move_​​their_​​servers_​​into_​​the_​​cloud._​​​“​​AWS​​Snowball​​edge​​storage  and_​​compute_​​runs_​​this_​​Lambda@Edge_​​software._​​Google_​​Firebase_​​is_​​a_​​related_​​product.   

6

_​

 Future:

_​

_​

What

_​

_​

are

_​

_​

low

_​

_​

hanging

_​

_​

fruits

_​

_​

for

_​

_​

serverless? 

The​​panelists​​were​​asked​​to​​discuss​​a​timeline​ ​​and​​topics​​for​​the​​evolution​​of​​the  technology_​​and_​​a_​​discussion_​​of_​​its_​​adoption_​​by_​​users._​​The_​suggestions_{​ ​​}varied_​​from_​​wide  ranging​​dreams​​to​detailed​ ​​nuts​​and​​bolts. 

Optimistically​​it​​was​​predicted​​that​​FaaS​​will​​be​​applied​​to​general​ ​​purpose​​computing​​and  it​​will​​grow​​in​​capability​​and​​limitations​​such​​as​​the​​“5​​minute​​kill​limit”​ ​​will​​disappear.​​It​​will  be​​great​​for​​end​​developers​​as​​they​will​ ​​not​​need​​to​​know​​scaling​​and​​distributed 

used​​to​​reach​​exascale​​on​​supercomputers.​Scientific​ ​​notebooks​​need​to​ ​​be​​integrated​​with  FaaS.​​FaaS​​could​​further​​help​​users​​by​​making​​libraries​​easier​​to​​use​​as​​one​​needn’t​​put  library​​routines​​in​​one’s​​code;​​just​​invoke​​them​​as​​FaaS. 

At​​a​​more​​detailed​​level,​​debugging​​was​​identified​​as​​a​​near​​term​​critical​​problem​​where​​we  need​​to​​be​​able​​to​​test​​locally​​and​​then​​deploy​​on​​the​​edge​​and​​the​​cloud.​​​​The​​debugger  itself​​should​​be​​serverless​​and​​support​​live​​breakpoints​​and​​replay.​We​ ​​can​​adopt​​a  test-driven​​development​​with​​unit​​tests. 

Performance_​​is_​​an_​​important_​​issue_​​although_​​not_​​the_​​only_​​one_​​--_​​usability_​​is_​​for_​​example_​​a  key​​feature​​of​serverless.​ ​​More​​generally,​​we​​need​​to​​define​​evaluation​​metrics​​​[9]​. 

Unikernels​​are​​an​​attractive​​technology​​for​serverless.​ ​​There​​are​also​ ​​security​​concerns​​to  be​​addressed;​​does​​one​​need​​more​​than​a​ ​​container​​for​​the​​function​​and​​how​​should  events​​be​​made​​secure? 

The_​​billing_​​issues_​​brought_​​up_​​in_​​section_​​3.4,_​​need_​​to_​​be_​​studied_​​and_​​understood_​​how_​​much  of​​the​​delays​​and​​overheads​​are​​inevitable.​​It​​was​​noted​​that​​in​​AWS​​Step​​Functions,​​one  decouples​​the​​billing​​of​​the​​functions​​from​​the​​coordination​​of​​the​​composition. 

There​​was​​substantial​​discussion​​about​​the​​programming​​model​​and​​runtime.​​For​​runtime,  load​​balancing​​(handling​​communication​​and​​computing)​​and​​scheduling​​were​​identified.  Note​​the​​runtime​​is​​a​​provider​​point​​of​​view​​(allowing​​magic​​behind​​the​​scenes)​​and​​the  programming​​model​​the​​concern​​of​​users.​​Data-locality​​needs​​to​​built​into​ ​​the​​runtime.​​The  programming​​model​​and​​runtime​​need​​to​support​ ​​key​​features​of​ ​​serverless:​​event​​driven,  hidden​​servers​​for​​users,​​fine​​grained​​billing,​​implicit​​distribution,​​low​​latency.​​Analogously  to​​the​​Java​​Virtual​​Machine​​JVM,​​serverless​​could​​become​​a​common​ ​​runtime​​for​​multiple  programming​​models.​​The​​fine​​grain​​nature​of​ ​​FaaS​​allows​more​ ​​optimizations​​than​​those  conventionally​​allowed;​​this​​needs​​research.​The​ ​​runtime​​research​​needs​​to​​understand  what​​SLA’s​​are​​needed​and​ ​​what​​can​​be​​supported. 

environment.​​Serverless​​is​​right​​at​​its​​start;​​just​​as​​Spark​improved​ ​​on​​the​​original 

MapReduce,​​we​​need​​the​​next​​generation​​FaaS​(which​ ​​is​​in​​fact​​compatible​​with​​Spark,​​Flink  and​​Heron!) 

Both​​serverless​​technologies​​and​​their​​evaluation​​are​​immature.​​We​​need​​to​​develop  benchmarks​​covering​​both​​edge​​computing​​and​​other​​use​​cases.​​This​​workshop​​attempts  to​​address​​another​​need;​​the​development​ ​​of​​a​​serverless​​developer​​community. 

​

7

_​

 Conclusion 

To​​some,​​serverless​​and​​FaaS​​are​the​ ​​next​​generation​of​ ​​computing​​supporting​​centralized  and​​edge​​computing​​with​​a​common​ ​​event-driven​​programming​​model.​​Conversely​​the  drivers​​of​​cloud​​computing​​are​​Edge​​Computing​​and​​Serverless.​​One​​often​​discusses  distributed​​/​​edge​​computing​​versus​​centralized​​approaches​​and​​wonders​​how​​we​​move  back​​and​​forth;​​the​​answer​​is​​clear​​--​​we​​have​​both​intrinsically​ ​​intertwined.​​​​Serverless​​will  build​​the​​long​​dreamed​​infinite​​limitless​​computing​​fabric. 

This​​white​​paper​​aims​​to​​capture​​the​current​ ​​state​​of​​serverless​​and​​FaaS​​and​​hopefully  inspire​​a​​broader​community​ ​​to​​become​​involved.

​

8

_​

 Glossary 

Apache/IBM​​OpenWhisk:​​​Apache​​OpenWhisk​​(Incubating)​​is​​a​​serverless,​​open​​source  cloud​​platform​​that​​executes​​functions​​in​​response​​to​​events​​at​​any​​scale 

http://openwhisk.incubator.apache.org/_​._​​It_​​builds_​​on_​​IBM_​​Bluemix_​​project 

https://developer.ibm.com/openwhisk/​. 

Apache​​Storm​​and​​Heron:​​​Open​​source​​programming​​and​​execution​​on​the​ ​​cloud​​for​​data  streaming.​​Systems​​originally​​developed​​by​​Twitter​​with​​Heron​​improving​​Storm​​with​​same  API.​​​http://storm.apache.org/​​​​​​https://twitter.github.io/heron/  

AWS​​Kinesis:​​​collect,​​process,​​and​​analyze​​real-time,​​streaming​​data​​in​a​ ​​similar​​fashion​​to  Apache​​Storm​​​https://aws.amazon.com/kinesis   

AWS​​Greengrass:​​​Amazon​​Lambda​​supporting​​local​​compute,​​messaging,​​data​​caching,  and​​sync​​capabilities​​on​​a​​device​​at​​the​​edge​​​[36]​​​​​​https://aws.amazon.com/greengrass/   AWS​​Lambda:​​​Event-based​​computing​​FaaS​​from​​Amazon​​​[21] 

AWS​​Step​​Functions:​​​lightweight​​orchestration​​of​​Amazon​​Lambda​​Functions​​as 

AWS​​X-Ray:​​​analyzes​​and​​debugs​distributed​ ​​applications,​​such​​as​​those​​using  microservices​​and​​Amazon​​Lambda​​​​​https://aws.amazon.com/xray/​. 

Azure​​Functions:​​​Implementation​​of​​serverless​​FaaS​​on​​Azure. 

https://docs.microsoft.com/en-us/azure/azure-functions/functions-overview  

Cloud​​Native:​​​applications​​are​​designed​​to​run​ ​​on​​clouds​as​ ​​preferred​​host,​​exploiting  concepts_​​such_​​as_​​containers,_​​microservices,_​​elasticity_​​and_​​serverless_​​​https://www.cncf.io/  [37] 

Content​​Delivery​​Network​​CDN:​​​is​​a​​geographically​​distributed​​network​​of​​proxy​​servers  that​​distribute​​information​​from​​data​​centers​​to​​spatially​​distributed​​users​​with​​high  availability​​and​​high​​performance.​​CDNs​​serve​​a​​large​​fraction​​of​the​ ​​Internet​​content​​toda 

https://en.wikipedia.org/wiki/Content_delivery_network  

Dataflow:​​​describes​​a​​range​​of​​computing​​ideas​​but​​here​​refers​to​ ​​an​​execution​​graph  defined_​​by_​​data_​​flowing_​​between_​​nodes_​​as_​​seen_​​in_​​Apache_​Storm_{​ ​​}Spark_​​and_​​Flink.  Docker:​​​Open​​Source​​container​​technology​​for​​Linux​​and​​Windows​​supporting 

operating-system-level​​virtualization​​​​​https://en.wikipedia.org/wiki/Docker_(software)   Edge_​​Computing:_​​​The_​​processing_​​associated_​​with_​the_{​ ​​}Internet_​​of_​Things_{​ ​​}IoT_​​and_​​including  local​​computing​​resources,​​often​​termed​​Fog​​computing,​​devoted​​to​​give​​local​​low-latency  support​​to​​IoT​​devices.​​​https://en.wikipedia.org/wiki/Fog_computing   

Function​​as​​a​​Service​​FaaS:​​​Event​​based​​functions​​typically​​executed​​on​​serverless  infrastructure​​and​​described​​in​​section​​2​​of​​report 

Funktion:​​​Open​​source​​event​​driven​​lambda​​style​​programming​​model​​on​​top​​of  Kubernetes.​​​https://github.com/funktionio/funktion   

Globus​​Transfer:​​​cloud-controlled​​secure​high-performance​ ​​data​​transfers​​based​​on  advanced​​FTP​​​https://www.globus.org/data-transfer   

Google​​Firebase:​​​A​​mobile​​development​​platform​​linking​​to​​the​​cloud​​and​​exploiting  serverless_​​computing_​​Google_​​Functions_​​to_​​process_​​events._​​​https://firebase.google.com/  Google​​Functions:​​​FaaS​​provided​​on​​Google​​clouds​​​https://cloud.google.com/functions/  GridSolve:​​​implemented​​as​​Netsolve,​​is​an​ ​​RPC​​based​​client/agent/server​​system​​that  allows_​​one_​​to_​​remotely_​​access_​​computing_​​functions_​​as_​​a_​​service_​​​[31]_​. 

High​​Performance​​Computing​HPC​ ​:​​a​​community​​and​​an​​approach​built​ ​​to​​support​​the  largest​​scale​​computational​​science,​especially​ ​​numerical​​simulations.​​Typically​​uses 

Infrastructure​​as​​a​​Service​​IaaS:​​​​​makes​​servers​​explicit​​for​​users​of​ ​​cloud​​computing​​but  abstracts​​away​​the​​details​​of​infrastructure​ ​​like​​physical​​computing​​resources,​​location,  data_​​partitioning,_​​scaling,_​​security,_​​backup_​​etc. 

Kubeless:​​​​

Kubernetes-native

_​

_​

serverless

_​

_​

framework

_​

_​​

https://github.com/kubeless/kubeless  Kubernetes:_{​​​​​}Open-source_​​platform_​​for_​​automating_​​deployment,_​​scaling,_​​and_​​operations_​​of  application​​containers​​such​​as​Docker​ ​​across​​clusters​​of​​hosts 

https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/​. 

Kubernetes​​Fission:​​​Serverless​​Functions​​as​a​ ​​Service​​for​​Kubernetes​​developed​​by  Platform9 

http://blog.kubernetes.io/2017/01/fission-serverless-functions-as-service-for-kubernetes.html 

Microsoft​​Logic​​Apps:​​​provides​​a​​visual​​interface​​to​​specify​​workflows​​of​​connected  applications​​and​​triggers​​in​​the​​cloud.​​​https://docs.microsoft.com/en-us/azure/logic-apps/   Microservice:​​​​​service-oriented​​architecture​​(SOA)​​style​that​ ​​structures​​an​​application​​as​​a  collection​​of​​loosely​​coupled​​fine-grained​​services​​communicating​​by​​lightweight​​protocols. 

https://en.wikipedia.org/wiki/Microservices  

OpenLambda:_{​​​​​}Open-source_​​serverless_​​computing_​​platform._​​​https://open-lambda.org  Platform​​as​​a​​Service​​PaaS:​​provides​ ​​a​​cloud​​development​​environment​​(middleware)  with​​details​​of​underlying​ ​​resources​​often​​hidden. 

https://en.wikipedia.org/wiki/Cloud_computing  

Pipsqueak:​​​Serverless​​package​​support​​from​​the​​University​​of​​Wisconsin​​-​​Madison​​​[10]  PyWren:​​​Python​​MapReduce​​with​​stateless​maps​ ​​running​​under​​Amazon​​Lambda​​​[13]  Ripple:_​​​Science_​​event_​​based_​​FaaS_​​application_​​for_​​data_​​management_​​​[8] 

Serverless:​​​​​discussed​​in​​this​​whitepaper​​as​​a​​server​​hidden​​cloud​​computing​​execution  model​​where​​provider​​dynamically​​manages​​the​​allocation​​of​​machine​​resources,​​and​​bills  on​​use​​rather​​than​on​ ​​pre-purchased​​units​​of​​capacity. 

https://en.wikipedia.org/wiki/Serverless_computing  

Software​​as​​a​​Service​​SaaS:​​​is​​a​cloud​ ​​computing​​usage​​model​​where​​providers​​install​​and  operate​​application​​software​​in​​the​​cloud,​​which​​is​​accessed​​by​​cloud​​users. 

9

_​

 Acknowledgements 

Geoffrey​​Fox​​acknowledges​​support​​from​the​ ​​Indiana​​University​​Precision​​Health​​Initiative  and​​NSF​​CIF21​​DIBBS​​1443054.​​We​​also​​acknowledge​​the​​contributions​of​ ​​both​​the​​panel  members_​​and_​​participants_​​in_​​the_​​workshop_​which_{​ ​​}were_​​essential_​to_{​ ​​}the_​​ideas_​​described  here. 

​

10

_​

 References 

1.  WoSC.​​First​​International​​Workshop​​on​​Serverless​​Computing​​(WoSC)​​[Internet].​​2017  [cited​​16​​Jul​​2017].​​Available:​​​http://www.serverlesscomputing.org/wosc17/ 

2.  Oakes​​E.​​On​​the​​State​​of​​Serverless​​Computing​​[Internet].​​First​​International​​Workshop  on​​Serverless​​Computing​​(WoSC)​​2017;​​2017​​Jun​​5;​​Atlanta.​​Available: 

http://www.serverlesscomputing.org/wosc17/presentations/oakes-workshop-panel.pdf  3.  Chard​​R.​​FaaS:​​The​​future​​of​​computing​​[Internet].​​First​​International​​Workshop​​on 

Serverless​​Computing​​(WoSC)​​2017;​2017​ ​​Jun​​5;​​Atlanta.​​Available: 

http://www.serverlesscomputing.org/wosc17/presentations/chard-workshop-panel.pdf  4.  Kanso​​A.​​Serverless?​​are​​there​​any​​Cons?​​[Internet].​​First​​International​​Workshop​​on 

Serverless​​Computing​​(WoSC)​​2017;​2017​ ​​Jun​​5;​​Atlanta.​​Available: 

http://www.serverlesscomputing.org/wosc17/presentations/kanso-panel-public.pdf  5.  McGrath​​G.​​Provider-Side​​Serverless​​Opportunities​​[Internet].​​First​​International 

Workshop​​on​​Serverless​​Computing​​(WoSC)​2017;​ ​​2017​​Jun​​5;​​Atlanta.​​Available:  http://www.serverlesscomputing.org/wosc17/presentations/garrett-workshop-panel.p df 

6.  Barga​​RS.​​Serverless​​Computing:​​Redefining​​the​​Cloud​​[Internet].​​First​​International  Workshop​​on​​Serverless​​Computing​​(WoSC)​2017;​ ​​2017​​Jun​​5;​​Atlanta.​​Available:  http://www.serverlesscomputing.org/wosc17/#keynote 

7.  La​​NB,​​Dettori​​P,​​Kanso​​A,​Watanabe​ ​​Y,​​Youssef​A.​ ​​Leveraging​​the​​Serverless  Architecture​​for​​Securing​​Linux​​Containers.​​IBM;​​2017.​​Available: 

http://www.serverlesscomputing.org/wosc17/#p3 

8.  Chard​​R,​​Chard​​K,​​Alt​​J,​​Parkinson​​DY,​​Tuecke​​S,​​Foster​​I.​​RIPPLE:​​Home​​Automation​​for  Research​​Data​​Management.​​Argonne​National​ ​​Laboratory,​​University​​of​​Chicago,  National​​Center​​for​​Supercomputing​​Applications,​​Lawrence​​Berkeley​​National  Laboratory;​​2017.​​Available:​​​http://www.serverlesscomputing.org/wosc17/#p2  9.  McGrath​​G,​​Brenner​​PR.​Serverless​ ​​Computing:​​Design,​​Implementation,​​and