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.

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