The document discusses the migration of a legacy non-cloud web application to a multi-tenant cloud service using Docker containers, highlighting a history of development and the evolution of technology over seven years. Key challenges include ensuring scalability, security, and cost-effectiveness while maintaining legacy functionalities, with solutions implemented in IBM Bluemix. Lessons learned emphasize the significance of good monitoring, DevOps practices, and the potential future integration of even lighter-weight systems and processes.

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. BACKUP

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