Post on 16-Jul-2015
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
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
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=‘…’>
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
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?
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});
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)
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
$
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)
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
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.
$
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.
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.
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
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
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
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.