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.

Building a multi-tenant cloud service from legacy code with Docker containers

A reusable architectural pattern to migrate legacy application to a cloud service. The architecture pattern can be used by other legacy applications that need to migrate to cloud. The architecture was validated by the Beta release of the IBM Bluemix Workflow service and Docker containers were key capability to manage separate workflow engines for each tenant combined with cloud database for persistence layer and a content-based routing.

  • Be the first to comment

Building a multi-tenant cloud service from legacy code with Docker containers

  1. 1. Building  a  mul+-­‐tenant  cloud   service  from  legacy  code  with   Docker  containers     Aleksander Slominski, Vinod Muthusamy, and Rania Khalaf {aslom, vmuthus, rkhalaf} at us.ibm.com IBM T.J. Watson Research Center  
  2. 2. Overview   •  A  bit  of  history  …   •  IBM  Bluemix  Workflow  Service  Beta   •  Legacy  non-­‐cloud  web  applica+on     •  Building  mul+-­‐tenant  cloud  architecture  with   Docker  containers   •  Conclusions  and  future  direc+ons   Slides  at    hGp://www.slideshare.net/aslomibm    
  3. 3. Why  did  we  do  it?   •  We  developed  very  lightweight  REST-­‐centric  workflow   engine  that  was  inspired  by  BPEL   –  Bite:  Workflow  Composi+on  for  the  Web.  Presented  at  the   ICSOC  Conference  2007   •  hGp://www.slideshare.net/raniakhalaf/flow-­‐composi+on-­‐in-­‐ resource-­‐centric-­‐environment     •  It  was  built  in  Java  and  used  servlets  –  just  run  .war  in   servlet  container  and  connect  to  rela+onal  database   for  persistence  (circa  2007)   •  Developed  for  Mashups,  used  Atom/RSS,  script-­‐like   approach  to  data  typing,  extensible  ac+vi+es  can  be   defined  in  Java,  Groovy  or  other  JVM-­‐supported   scrip+ng  language  ex.  <sendEmail  address=‘…’>  
  4. 4. Legacy  (non-­‐cloud)  applica+on   Legacy  App:   Tomcat  or  WebSphere  running   workflow  engine  packaged  as  .war   Uses  pluggable  persistence:     File  system   RDBMS   Browser   App   REST  API  HTML  UI  
  5. 5. What  changed  in  7  years?   •  s/Java/JavaScript/g   •  s/XML/JSON/g   •  s/Mashup/Cloud/g   •  Etc.   •  Expecta+ons:  users  want  to  get  from  idea  to   running  workflow  in  seconds:   – Write  JavaScript  code  in  Web  IDE  like  Orion?  
  6. 6. IBM  Bluemix  Workflow   Take  form  ar+cle  “Create  an  applica+on  with  the  IBM   Workflow  for  Bluemix”:   –  hGp://www.ibm.com/developerworks/cloud/library/cl-­‐ workflow1-­‐trs/     buildSaleObj  =  SCRIPT(weather,  func+on()  {          var  emailbody  =  'You  got  20%  discount!  Please  use  code  '+  coupon  +'  online  or  in  stores.';          if(weather.out.main.temp  >=  290){        emailbody  +=  'It  is  quite  warm  out.  Try  our  new  iced  Mocha-­‐LaGe!';          }  else  emailbody  +=  "Try  our  new  Caffe  Malin”   });   sendmail  =  POST(buildSaleObj,  'hGps://api.sendgrid.com/api/mail.send.json’,        {  //….    'text':  emailbody});  
  7. 7. Changes  needed  in  “legacy”  code   (legacy  =  non-­‐cloud)  for  Beta:       •  How  to  support  mul+ple  tenants  when  majority  runs  only  few  workflows?   –  1%  usage  during  a  24  hour  period  means  the  service  will  only  be  used   for  about  15  minutes  (in  reality  it  was  much  lower  …)   –  But  they  can  invoke  workflow  service  any  +me!   •  Solu+on?  à  Start  JVM,  engine  and  load  state  to  process  request  in   seconds.  And  when  no  workflows  running  stop  JVM  à  savings   •  File-­‐systems  and  cloud  not  a  perfect  match:   –  Storage  needs  to  be  fault-­‐tolerant  and  work  at  cloud  scale   –  Unless  special  effort  is  made  files  are  ephemeral  (ex.  configura+on   files  inside  container  –  how  to  manage  volumes  in  cloud?)   –  If  possible  convert  file  opera+ons  to  use  (NoSQL)  database  or  cloud   storage  (store  your  configura+on  in  key-­‐value  JSON  store  like   Cloudant  or  Apache  CouchDB)  
  8. 8. Making  of  cloud  service   •  “Cloud-­‐scale”:  cloud  services  should  meet  many   expecta+ons:   –  Elas+city,  scalability,  redundancy  etc.   •  Cost:  a  high  density  design  is  desirable  so  that   many  tenants  can  be  supported  with  minimal   resources     –  Must  be  economically  viable   •  Security  –  isola+on  between  tenants  but  also   tenant  management,  metering  and  billing   –  Security  is  not  op+onal  but  required  for  business   $  
  9. 9. Created  (and  scaled  up  or  down)  on  demand   Cloud  service  that  wraps  legacy  app   Container  En   Cloudant   Browser   JazzHub  App   Legacy     App   …   HTML  UI   REST  API   Container  Em   Legacy     App   HTML  UI   REST  API   Container  R   File   server   Seeker  (Neylix  Zuul)  
  10. 10. Suppor+ng  mul+ple  tenants  with   Docker  containers   •  Incoming  requests  arrives  to  always  running   Seeker  component  built  using  Neylix  Zuul     –  Seeker  check  request  for  tenant-­‐ID  (inside  HTTP  URL)   and  checks  if  there  is  already  process  engine  for  that   tenant  running   –  If  no  tenant  process  is  running  then  Seeker  starts  new   Docker  container  and  run  JVM  with  engine   –  Seeker  forwards  the  request  to  tenant  engine  and   wait  for  a  response  to  send  back   •  Containers  enable  that  scenario  –  minimal   overhead  and  quick  startup  of  containerized   processes  
  11. 11. How  does  this  design  address   cloud  requirement?   •  Cloud-­‐scale   –  Docker  containers  started  can  run  in  Container  cloud   (auto-­‐scale  etc.)   •  Mul+-­‐tenancy   –  Containers  running  engine  JVM  will  stop  when  engine   decides  to  exit  à  JVM  process  exits  à  container   stops  (We  found  out  overhead  to  start  to  be  in   seconds)  à  higher  density  à  $   •  Security   –  Only  JavaScript  code  is  executed  and  with  limited  set   of  opera+ons,  addi+onal  work  on  network  isola+on   etc.   $  
  12. 12. Related  work   •  Skyport  uses  containers  to  deploy  and  execute   scien+fic  workflow  tasks  cheaply  in  a  cloud  playorm.     –  Skyport  is  not  designed  to  be  a  mul+-­‐tenant  cloud  service,   and  hence  mul+-­‐tenancy,  density,  cost,  security,  and   isola+on  are  not  cri+cal  requirements     •  Sandstorm.io  -­‐  personal  cloud  that  uses  containers  as  a   natural  fit  for  running  “legacy”  web  applica+ons.     –  Sandstorm  uses  Linux  container  capabili+es  to  wrap  Web   applica+ons,  such  as  Wordpress   –  Needs  to  be  modified  to  store  all  the  state  in  the  /var   directory,  use  RPC  for  networking  and  other  changes  to  fit   into  sandbox.    
  13. 13. Lessons  learnt   •  Scalability  is  hard  –  cloud  ot  Docker  is  not  magic  …   •  Anything  can  fail  any  +me!     –  Several  problems  with  virtual  disk  and  containers  corrupted  …   •  Cloud  maintenance  happens  –  whole  cloud  failing?   –  Cloud  reboot  with  Xen  VMs  …   •  Do  not  underes+mate  +me  needed  to  make  changes!   •  Good  monitoring  is  really  required   –  Distributed  systems  …   •  DevOps  is  really  required  and  made  easier  with  Docker!   –  Containers  work  beGer  when  automated   –  Who  to  blame  when  it  is  not  working  (see  above)?   –  Instead  focus  on  incremental  delivery,  automa+on,  etc.   –  Use  staged  deployments,  canaries,  A/B  tes+ng  etc.    
  14. 14. Conclusions   •  A  reusable  architectural  paGern  to  migrate  legacy   applica+on  to  a  cloud  service   •  The  architecture  paGern  can  be  used  by  other   legacy  applica+ons  that  need  to  migrate  to  cloud     •  The  architecture  was  validated  by  the  Beta   release  of  the  IBM  Bluemix  Workflow  service,   –  Docker  containers  are  key  capability  to  manage   separate  workflow  engines  for  each  tenant  combined   with  cloud  database  for  persistence  layer  and  a   content-­‐based  rou+ng    
  15. 15. Future  steps   •  Take  advantage  of  beGer  environments  to  run   containers  –  future  of  cloud  is  containers?   •  Even  more  lightweight  composi+ons  that  use   new  run+me  systems   –  Cusina  –  use  recipes  like  IFTTT  but  run  them  in   enterprise,  support  sharing  and  collabora+on   •  Easy  to  create  but  not  easy  to  understand  what  is   happening?   –  BPI  –  Business  Process  Insight  project  but  for  any   process  
  16. 16. Future   •  Dinosaurs  à  Birds  à  ???   •  VM  à  Docker  à  ???     •  X  à  Y  à  ???   •  ???  is  a{er  “event  horizon”  of  what  we  can  see   now?  Unexpected  unexpected  …   •  Wikipedia  hGps://en.wikipedia.org/wiki/Dinosaur    
  17. 17. Ques+ons   •  And  last  but  not  least  …   – Are  you  interested  in  similar  topics  and  having  the   both  academia  and  industry?   •  Check  our  IBM  Research  Service  IntegraDon  and   AnalyDcs  Group  page   hGp://researcher.watson.ibm.com/researcher/ view_group.php?id=2972     •  We  have  openings  for  a  full  Dme  researcher,   summer  interns,  and  open  tßo  the  opDon  of   visiDng  scienDsts.  
  18. 18. BACKUP  
  19. 19. Creating Scripts: Login, author, deploy, invoke in minutes 1.  Web-based authoring in Orion in JazzHub 2. Content assist for built-in activities. 3. Call template for service endpoints 4. Convenient buttons to deploy and invoke. Runs in BlueMix BlueMix  

    Be the first to comment

    Login to see the comments

  • ogawatadashi

    Aug. 20, 2015

A reusable architectural pattern to migrate legacy application to a cloud service. The architecture pattern can be used by other legacy applications that need to migrate to cloud. The architecture was validated by the Beta release of the IBM Bluemix Workflow service and Docker containers were key capability to manage separate workflow engines for each tenant combined with cloud database for persistence layer and a content-based routing.

Views

Total views

1,962

On Slideshare

0

From embeds

0

Number of embeds

3

Actions

Downloads

48

Shares

0

Comments

0

Likes

1

×