Cloud  Computing  &  Advanced  Web  Technologies  Carlos  Núñez  Cas-llo  Fabio  López  Pires  Cris-an  Cabanellas  

1  

Cloud  Compu)ng  

ELASTICITY   2  

Elasticity  in  Cloud  Computing  •  ODCA,  Compute  Infrastructure-­‐as-­‐a-­‐Service  [9]  ”[.  .  .  ]  defines  elas-city   as   the   configurability   and   expandability   of   the  solu-on  [.   .   .   ]  Centrally,   it   is  the  ability  to  scale  up  and  scale  down  capacity  based  on  subscriber  workload.”  

•  NIST   Defini)on   of   Cloud   Compu)ng   [8]   ”Rapid   elas-city:  Capabili-es   can   be   elas-cally   provisioned   and   released,   in  some   cases   automa-cally,   to   scale   rapidly   outward   and  inward   commensurate   with   demand.   To   the   consumer,   the    capabili-es   available   for   provisioning   oNen   appear   to   be  unlimited   and   can   be   appropriated   in   any   quan-ty   at  any-me.”  

Elas-city

 in  Cloud

 Com

pu-n

g:  W

hat  It  Is,  and

 What  It  Is  N

ot  

3  

Elasticity  in  Cloud  Computing  •  IBM,   Thoughts   on   Cloud,   Edwin   Schouten,   2012   [11]  ”Elas-city   is   basically   a   ’rename’   of   scalability   [.   .   .   ]”   and  ”removes   any   manual   labor   needed   to   increase   or   reduce  capacity.”  

•  Rich  Wolski,  CTO,  Eucalyptus,  2011  [12]   ”Elas-city  measures  the   ability   of   the   cloud   to   map   a   single   user   request   to  different  resources.”  

•  Reuven  Cohen,   2009   [2]   Elas-city   is   ”the   quan-fiable   ability  to  manage,  measure,  predict  and  adapt  responsiveness  of  an  applica-on   based   on   real   -me   demands   placed   on   an  infrastructure   using   a   combina-on   of   local   and   remote  compu-ng  resources.”   4  

Elas-city

 in  Cloud

 Com

pu-n

g:  W

hat  It  Is,  and

 What  It  Is  N

ot  

Elasticity  in  Cloud  Computing  •  “Exis&ng  defini&ons  of  elas&city  fail  to  capture  the  core  aspects  of  this  term  in  a  clear  and  unambiguous  manner  and  are  even  contradictory  in  some  parts”.  

•  Why?  

5  

Elas-city

 in  Cloud

 Com

pu-n

g:  W

hat  It  Is,  and

 What  It  Is  N

ot  

Elasticity  in  Cloud  Computing  •  Scalability  •  Hardware  •  Virtualiza-on  •  SoNware  Layers  

•  Evalua)ng  Elas)city  •  Autonomic  Scaling:  What  adapta-on  process  is  used  for  autonomic  scaling?  

•  Elas&city  Dimensions:  What  is  the  set  of  resource  types  scaled  as  part  of  the  adapta-on  process?  

•  Resource  Scaling  Units:  For  each  resource  type,  in  what  unit  is  the  amount  of  allocated  resources  varied?  

•  Scalability  Bounds:  For  each  resource  type,  what  is  the  upper  bound  on  the  amount  of  resources  that  can  be  allocated?   6  

Elas-city

 in  Cloud

 Com

pu-n

g:  W

hat  It  Is,  and

 What  It  Is  N

ot  

Elasticity:  Proposed  DeBinition  “Elas&city  is  the  degree  to  which  a  system  is  able   to   adapt   to   workload   changes   by  provisioning  and  deprovisioning  resources  in  an   autonomic   manner,   such   that   at   each  point   in  &me  the  available  resources  match  the  current  demand  as  closely  as  possible”  

7  

Elas-city

 in  Cloud

 Com

pu-n

g:  W

hat  It  Is,  and

 What  It  Is  N

ot  

Elasticity:  Core  Aspects  •  Dimensions:    •  CPU  •  RAM  •  …  

•  Core  Aspects  •  Speed  •  Precision  

•  Scalability  and  Efficiency  

8  

Elas-city

 in  Cloud

 Com

pu-n

g:  W

hat  It  Is,  and

 What  It  Is  N

ot  

Elasticity:  Matching  Function  

9  

Elas-city

 in  Cloud

 Com

pu-n

g:  W

hat  It  Is,  and

 What  It  Is  N

ot  

Elasticity:  Metrics  

10  

Elas-city

 in  Cloud

 Com

pu-n

g:  W

hat  It  Is,  and

 What  It  Is  N

ot  

Elasticity:  Benchmarking  

11  

Elas-city

 in  Cloud

 Com

pu-n

g:  W

hat  It  Is,  and

 What  It  Is  N

ot  

Exercise      

12  

•  Analyze  when:  •  Peak  =    150  &&  noon  =  100  •  Peak  =    100  &&  noon  =  100  •  Peak  =  900    &&  noon  =  100  

•  Do  the  math,  explain  and  write  down  your  conclusions  

Cloud  Development  Methodology  

•  Methodology  for  building  soXware-­‐as-­‐a-­‐service  apps.  •  Declara-ve  (Automa-on)  •  Maximum  Portability  •  Deployment  on  Modern  Cloud  Plahorms  •  Minimize  Divergence  (Environments)  •  SCALE  UP  

13  

hip://12factor.net/  

Cloud  Development  Methodology  •  I.  Codebase:  One  codebase  tracked  in  revision  control,  many  deploys  

•  II.  Dependencies:  Explicitly  declare  and  isolate  dependencies  

•  III.  Config:  Store  config  in  the  environment  

•  IV.  Backing  Services:  Treat  backing  services  as  aiached  resources  

•  V.  Build,  release,  run:  Strictly  separate  build  and  run  stages  

•  VI.  Processes:  Execute  the  app  as  one  or  more  stateless  processes  

 

14  

hip://12factor.net/  

Cloud  Development  Methodology  •  VII.  Port  binding:  Export  services  via  port  binding  

•  VIII.  Concurrency:  Scale  out  via  the  process  model  •  IX.  Disposability:  Maximize  robustness  with  fast  startup  and  graceful  shutdown  

•  X.  Dev/prod  parity:  Keep  development,  staging,  and  produc-on  as  similar  as  possible  

•  XI.  Logs:  Treat  logs  as  event  streams  

•  XII.  Admin  processes:  Run  admin/management  tasks  as  one-­‐off  processes   15  

hip://12factor.net/  

Cloud  Compu)ng  

Platform  as  a  Service  (PaaS)   16  

Platform  as  a  Service  •  The  capability  provided  to  the  consumer  is  to  deploy  onto  the  cloud   infrastructure   consumer-­‐created   or   acquired  applica-ons   created   using   programming   languages,   libraries,  services,  and  tools  supported  by  the  provider.  

•  The   consumer   does   not   manage   or   control   the   underlying  cloud   infrastructure   including   network,   servers,   opera-ng  systems,   or   storage,   but   has   control   over   the   deployed  applica-ons   and   possibly   configura-on   senngs   for   the  applica-on-­‐hos-ng  environment.  

17  

The  NIST  De

fini-on

 of  C

loud

 Com

pu-n

g.  SP  800-­‐145  

PaaS:  Google  App  Engine  

18  

The  NIST  De

fini-on

 of  C

loud

 Com

pu-n

g.  SP  800-­‐145  

PaaS:  Google  App  Engine  •  Designing  for  Scale  

•  A  single  en-ty  group  in  the  Datastore  should  not  be  updated  too  rapidly  

•  Avoid  high  write  rates  to  Datastore  keys  that  are  lexicographically  close  

•  Do  not  set  a  daily  budget  that  could  be  exceeded  •  Ensure  that  you  will  not  hit  quota  limits  on  API  calls  •  Shard  task  queues  if  high  throughput  is  needed  •  Use  the  default  performance  senngs  unless  you  have  tested  the  impact  of  changes  

•  Use  traffic  splinng  when  switching  to  a  new  default  version  •  Avoid  Memcache  hot  keys  •  Test  third-­‐party  dependencies  •  Implement  backoff  on  retry  

19  

hips://develop

ers.google.com

/app

engine

/ar-cles/scalability  

PaaS:  Google  App  Engine  •  Best  prac)ces  for  wri)ng  scalable  applica)ons  

•  Minimizing   work:   Minimizing   the   amount   of   work   that   your  applica-on  performs  should  help  to  fine-­‐tune  your  code  and  take  beier  advantage  of  the  resources  allocated  for  your  app.  

•  Paging  through  large  datasets:  One  of  the  typical  web  func-ons  you   may   need   to   do   is   pagina-on,   that   is,   displaying   large  datasets  one  page  at  a  -me.  

•  Avoiding   datastore   conten)on:   Datastore   is   a   powerful  distributed   data   storage   service   built   on   top   of   the   high-­‐performance   database  management   system   known   as   BigTable.  You  must   take   care  when   designing   your   data  models   to   avoid  the  prospect  of  conten-on  as  your  applica-on  grows.  

20  

develope

rs.goo

gle.com/app

engine

/ar-cles/scaling/overview

 

PaaS:  Google  App  Engine  •  Best  prac)ces  for  wri)ng  scalable  applica)ons  

•  Sharding   counters:  When  developing  an  efficient   applica-on  on  Google  App  Engine,   you  need   to  pay   aien-on   to  how  oNen  an  en-ty  is  updated.  While  App  Engine's  datastore  scales  to  support  a   huge   number   of   en--es,   it   is   important   to   note   that   you   can  only  expect  to  update  any  single  en-ty  or  en-ty  group  about  five  -mes  a  second.    

•  Effec)ve  memcache:  Caching  popular  pages,  Saving   transient  or  frequently  updated  data,  Caching  frequently  fetched  en--es  

21  

develope

rs.goo

gle.com/app

engine

/ar-cles/scaling/overview

 

PaaS:  Google  App  Engine  

22  

hips://develop

ers.google.com

/app

engine

/ar-cles/lo

ad_test  

PaaS:  OPENSHIFT  

23  

hips://w

ww.ope

nshiN.com  

PaaS:  OPENSHIFT  

24  

hips://w

ww.ope

nshiN.com  

25  

hips://w

ww.ope

nshiN.com  

PaaS:  OPENSHIFT  

26  

hips://w

ww.ope

nshiN.com  

PaaS:  OPENSHIFT  

27  

hips://w

ww.ope

nshiN.com  

PaaS:  OPENSHIFT  

28  

hips://w

ww.ope

nshiN.com  

PaaS:  OPENSHIFT  

29  

hips://w

ww.ope

nshiN.com  

PaaS:  OPENSHIFT  

ANEKA:  Private  and  Public  Clouds  

30  

Clou

d  Co

mpu

-ng  -­‐  P

rinciples  and

 Paradigms  

PaaS:  Can  We  Go  Open  Source?  •  Cloud  Foundry:  hip://www.cloudfoundry.org/  

•  Deis:  hip://deis.io/  

•  Open  Stack  +  Heat:  hips://wiki.openstack.org/wiki/Heat/  

31  

Reading  •  Building  Scalable  Web  Applica)ons  with  Google  App  Engine  

 hips://sites.google.com/site/io/building-­‐scalable-­‐web-­‐

applica-ons-­‐with-­‐google-­‐app-­‐engine  

32  

Reading  •  Demonstra)on  of  auto  scaling  workers  in  Cloud  Foundry  

hips://github.com/cloudfoundry-­‐samples/cf-­‐autoscaler      

•  Deploying  Cloud  Foundry  hips://github.com/cloudfoundry-­‐community/cf-­‐docs-­‐contrib/

wiki/Deploying-­‐CF  

33  

References  •  N.   R.   Herbst,   S.   Kounev,   R.   Reussner.   Elas-city   in   Cloud  Compu-ng:  What   It   Is,  and  What   It   Is  Not.  10th   Interna-onal  Conference  on  Autonomic  Compu-ng.  USENIX,  2013    

•  P.   Mell,   T.   Grance.   The   NIST   Defini-on   of   Cloud   Compu-ng  (SP-­‐800-­‐145).  Na-onal  Ins-tute  of  Standards  and  Technology,  2011.  

•  R.   Buyya,   J.   Broberg,   A.   M.   Goscinski.   Cloud   Compu-ng:  Principles  and  Paradigms.  Wiley,  2011.  

34  

Thank  You  

Carlos  Núñez  Cas-llo    

More  info  at  the  course  web  site  hips://sites.google.com/site/  

msc2014fpunacloud/  

35