►
From YouTube: C* Summit 2013: Cassandra on Cloud Foundry
Description
Speakers: Renat Khasanshyn, Founder and CEO at Altoros and Cornelia Davis, Senior Technologist at Pivotal
Slides: http://www.slideshare.net/planetcassandra/c-summit-2013-cassandra-on-cloud-foundry-by-renat-khasanshyn-and-cornelia-davis
Coupling Cassandra with a Platform as a Service may significantly simplify the process of deploying Cassandra and applications that utilize it, reduce the cost of managing Cassandra within the organization, and to allow infrastructure service providers a simple path to offering database as a service to their customers. Attendees will learn why and when use Cassandra atop of Cloud Foundry, the history of Cassandra service within Cloud Foundry, the State of Cassandra integration with Cloud Foundry, how to create and manage Cassandra nodes on Cloud Foundry and what to expect in the next 6 months.
A
Hi
everyone,
my
name
is
renata
I'm,
adult
or
kerneli
Davis
from
pivotal.
Today
we're
going
to
share
with
you
the
Cassandra
on
top
of
cloud
foundry,
what
kind
of
benefits
it
can
bring
to
to
a
developer
and
what
country
is
about
and
how
you
can
use
it
to
to
make
your
life
easier.
So
I
will
start
with
the
brief
introductions
of
what
our
companies
and
what
the
backgrounds.
A
My
background
is
in
professional
services,
the
company
outdoors,
which
I
started
as
a
one-man
shop
10
years
ago,
and
now
we're
focusing
on
deploying
and
managing
Hadoop,
no
sequel
solutions.
And
very
recently
we
started
called
foundry
practice
that
we
were
putting
together
and
perhaps
Cornelia
could
introduce
pivotal.
B
No
getting
it
oh
there
we
go
now
it's
on
very
briefly:
just
is
anybody
familiar
with
the
pivotal
company?
Okay
I
see
a
couple
of
people
saying
no,
and
if
you
say
yes
so
very
quickly,
you
can
see
from
bottom
to
top.
Here
we
go
from
very
concrete
stuff
cloud,
storage
or
storage,
emcs
world
virtualization
vmware's
world
and
then
there's
a
whole
bunch
of
assets
that
layer
on
top
of
those.
B
Some
of
those
you
might
be
familiar
with,
like
green,
plum,
come
from
the
emc
side
of
the
business
and
Cloud
Foundry
is
one
of
those
things
that
comes
from
the
VMware
side
of
the
business
if
you'll
click
to
the
next
slide.
What
pivotal
company
is
about
is
about
those
those
top
three
layers
that
I
showed
on
the
screen.
It's
a
it's
a
separate
company
owned
by
vmware,
emc
and
General
Electric
General
Electric
has
also
done
a
sizable
investment
in
it.
So
that's
the
pivotal
company.
It.
A
Why
why
why
cloth
on
me?
Why
is
it
here?
Why
we're
talking
about
it?
Well,
to
my
view,
the
main
beneficiaries
of
of
platform
as
a
service
in
general
fre
specifically,
are
the
developers
and
instead
of
waiting,
you
can
just
deploy,
and
the
main
point
of
using.
Why
use
a
cloud
foundry
for
developers
is
to
separate
the
notion
of
developing
an
application
and
deploying
it
and
scaling
it,
and
so
the
cloud
foundry
is
a
is
a
collection
of,
as
I
would
define
it's
a
collection
of
smaller
projects.
A
A
Middleware
abstraction
layer
that
sits
between
the
infrastructure
of
your
choice,
bead
AWS,
the
openstack
cloud
stack
and
by
abstracting
this
this
infrastructure.
From
from
the
developer
console,
we
can
achieve
significant
benefits
that
some
of
them,
I
would
say,
important
to
us
as
an
application
developer
for
servicing
many
companies
is
the
the
the
awarding
the
lockin.
If
we
have
built
and
deployed
an
app
on
AWS
using
cloud
foundry,
shifting
it
to
a
private
cloud
or
to
another
public
cloud
provider
becomes
so
much
easier.
A
B
B
So
the
cloud
foundry
platform,
if
you
think
of
it
as
an
application,
a
cloud
foundry
application
and
you'll
see
why
I
make
that
distinction
in
just
a
moment
is
itself
a
very,
very
complex
application
and
highly
distributed.
So
all
of
these
different
nodes
that
you
see
here,
colored
in
the
in
the
pink,
are
different
components
of
the
system
that
are
likely
running
on
different
machines.
B
They
could
be
running
on
the
same
machine,
but
they
likely
aren't
and
there's
probably
multitudes
of
each
of
those,
and
so
how
you
take
a
distributed
application
like
that
and
have
those
components
communicating
with
one
another
is
actually
one
of
the
things
that
I
like
about
the
way
that
this
slide
is
shown
so
there.
Let
me
just
briefly:
go
over
the
the
primary
functions.
What
we
see
here
on
the
kind
of
on
in
the
middle
on
the
left
is
the
cloud
controller.
So
the
cloud
controller
is
really
the
brains
of
this.
B
This
is
what's
going
to
orchestrate
the
deployment
of
applications.
The
provisioning
of
services
when
a
client
from
the
outside
goes
to
do
something
with
you
know,
deploy
a
new
application
into
cloud.
Foundry
they're,
going
to
do
all
the
communicating
with
it
with
the
Cloud
Controller
you
a
a
is
about
authentication
and
authorization.
So
that's
the
subsystem
that
handles
that
over
here.
B
On
the
right
hand,
side
is
a
health
manager,
so
one
of
the
important
things
about
Cloud
Foundry
is
that
it
includes
components
that
do
recovery
for
you,
so
it
automates
some
of
those
things
that
you
would
have
had
to
do
in
your
infrastructure
when
you
deployed
production
applications,
that's
baked
into
cloud
foundry.
So,
for
example,
the
health
manager
is
going
to
monitor
those
applications
and
when
the
when
an
application
goes
down,
because
maybe
this
server
that
it
was
running
on,
went
down
or
some
there
was
some
other
problem.
Maybe
a
network
problem.
B
The
health
manager
recognizes
that
and
remediate
sital
restart
the
application.
So
that's
the
role
of
the
health
manager,
then
over
here
we
have
something
called
DEA
and
DEA
stands
for
droplet
execution
agent,
and
what
that
really
is
is
these
are
this
area
over?
Here
is
the
container
in
which
your
applications
are
running,
so
all
of
the
applications
are
running
up
with
in
that
container
I'm
not
going
to
talk
about
the
collector
and
the
syslog
aggregator,
there's
in
fact,
I'm
just
realizing
that
there's
another
component.
B
That
I
will
address
in
just
a
moment,
but
before
I
get
to
that,
there's
two
more
components
that
are
not
in
the
hot
pink,
that's
the
router
and
Nats
Nats
is
a
messaging
fabric.
So
you
can
see
that
when
we
see
these
paths
that
go
between
the
different
components,
they're,
either
going
through
Nats
or
they're
going
through
the
router.
So
there
is
either
using
asynchronous
messaging
through
the
Nats
service
bus
or,
if
the,
if
it's
an
HTTP
request,
it's
going
through
the
router.
B
Those
are
components
that
are
included
as
a
part
of
Cloud
Foundry
as
well
the
router
and
gnats
and
finally,
there's
something
that
isn't
depicted
on
this
slide.
And
that
is
this.
The
services,
so
services
are
really
where
are
going
to
be
things
like
your
databases
or
it
might
be
also
something
like
RabbitMQ,
where
you
want
to
use
messaging
outside
of
the
cloud
foundry
infrastructure.
B
As
a
part
of
your
application,
so
in
the
end
I
like
this
slide,
because
it
kind
of
highlights
those
those
various
components
and
does
so
in
a
way
that
shows
you
really
how
distributed
they
are
now,
that's
Cloud
Foundry,
so
Cloud
Foundry
itself
is
the
platform-as-a-service.
So
what
you
do
with
the
platform
is
the
services
that
you
push
applications
you
bind
to
existing
services.
You
are
not.
You
are
not
dealing
with
things
at
the
ayahs
layer,
you're
not
dealing
with
virtual
machines
and
networks
and
and
in
storage
you're
dealing
with
applications
and
services.
B
That's
your
unit
of
currency
in
the
past!
Well,
how
do
you
deploy
the
pa's
itself,
so
we're
not
just
offering
cloud
foundry
com
as
a
path
that
you
can
come
and
use?
One
of
the
things
that
we
are
focusing
on
at
pivotal
is
enabling
you
your
path
strategy,
even
internally,
in
the
enterprise.
If
you
think
about
it,
our
legacy
comes
from
VMware
and
EMC,
both
of
which
are
Enterprise
enterprise
companies.
So
we're
really
focusing
on
that
space
as
well.
B
So
we
want
to
make
it
so
that
you
can
deploy
your
own
internal
paths
and
that's
where
Bosh
comes
in
Bosh
is
an
open
source
tool
chain
that
allows
you
to
deploy
these
highly
complex,
highly
distributed.
Applications
like
this
one
you've
got
lots
of
moving
parts
across
lots
of
different
machines.
How
do
you
coordinate
all
of
that
and
that's
what
Bosch
allows
you
to
do,
and
so
one
of
the
key
things
is
that
basha
offers
you
an
abstraction
layer
over
the
infrastructure
as
a
service.
B
So
Bosh
will
allow
you
to
deploy
cloud
foundry
on
top
of
vSphere
on
top
of
Amazon
Web
Services
on
top
of
OpenStack,
and
it
has
a
component
a
subsystem
within
it
that
allows
you
to
plug
in
other
layers
below
it.
So
there's
a
cloud
provider
interface
that
allows
you
to
plug
in
different
things
instead
of
those
I
as
options
there.
So
it
really
does
give
you
the
option
of
doing
things
internally
externally
and
as
we're
not
mentioned,
it
gives
you
the
opportunity
just
having
the
pa's
layer.
B
This
architecture,
the
Bosch
architecture,
is
similar
to
what
you
saw
in
the
previous
slide
in
that
Bosh
itself
is
a
very
sophisticated
system,
multi-node
system,
where
there's
multiple
components,
you'll
notice,
that
there's
components
that
are
very
analogous
to
what
we
saw
in
the
cloud
foundry
side.
So,
for
example,
there
is
a
director
just
like
there
was
a
cloud
director.
There
is
now
a
boss
director
and
that's
what
we're
seeing
here,
there's
a
message:
bus
again,
that's
used
by
the
different
components
within
Bosch
to
communicate.
B
There's
a
health
monitor
to
make
sure
that
the
things
that
we're
deploying
is
a
part
of
Bosch
remain
up
or
if
they
go
down,
come
back
up
so
just
like
in
Cloud
Foundry.
If
your
application
node
goes
down,
the
health
monitor,
recognizes
it
and
brings
it
back
up
on
the
Bosch
side
of
an
entire
virtual
machine
goes
down.
It
recognizes
that
and
we'll
bring
that
virtual
machine
backup.
So
Bosch
is
really
about
automating,
that
interface
down
to
the
ayahs
layer.
So
it'll
do
exactly
what
I
just
described
a
virtual
machine
goes
down.
B
It
says:
oh
I
can't
find
this
virtual
machine
anymore.
It
waits
a
few
more
seconds,
whatever
that's
all
configurable,
and
then
it
says
oh
I'm,
going
to
assume
that
virtual
machine
went
down
I'm
going
to
spin
up
a
new
one.
Oh
that
virtual
machine
was
in
charge
of
these
droplet
execution
agents.
I'll,
deploy
the
droplet
execution
agent
onto
it
and
spin
up
some
new
applications
on
it.
B
So
that's
exactly
what
the
health
monitor
does
there
and
there's
a
few
other
components
like
worker
components
that
help
you
do
things
like
compile
things
before
you
deploy
them
out
into
the
infrastructure
and
so
on.
All
of
that,
what
we
what's
in
Bosh
is
what
we
call
the
outer
shell
and
then
what's
in
the
inner
shell
is
the
distributed
application,
which
in
this
case
is
cloud
foundry
itself.
So
Cloud
Foundry
is
running
on
a
bunch
of
VMs
Bosh
itself.
The
deployment
mechanism
for
Bosh
runs
on
a
bunch
of
VMs
as
well,
so,
okay.
B
So,
but
we're
not
here
just
to
talk
about
cloud
foundry,
we're
here
to
talk
about
Cassandra.
This
is
the
Cassandra
summit.
After
all,
so
I
want
to
tell
you
a
little
bit
about
some
work
that
we
did
in
exposing
Cassandra
as
a
service
within
cloud
foundry,
so
at
a
very
high
level
and
I'm
not
going
to
spend
my
whole
time
on
slides.
In
fact,
I
want
to
spend
most
of
the
time
in
a
demo
in
a
in
a
screenshot
in
a
screencast
that
I
have,
but
the
way
that
services
work
in
Cloud
Foundry.
B
This
is
kind
of
a
generic
picture,
for
all
services
is
that
we
have
services
that
are
running
on
virtual
machines
that
have
been
deployed
by
Bosh
and
I'll
show
you
that
running
live.
So
we
have,
let's
say
the
Cassandra
nodes
that
are
running
in
Bosh.
Let's
say
we
have
a
two
node
cluster
and
cassandra
is
running
on
those
when
we
deploy
an
application
to
Cloud
Foundry.
B
We
want
to
bind
to
that
Cassandra
deployment
and
we
do
so
via
something
called
a
service
gateway,
and
that's
what
we
see
down
here
on
the
lower
part,
so
requests
are
made
to
the
service
gateway
and
the
service
gateway
communicates
with
the
Cassandra
installation
via
a
layer
called
the
service
node.
And
that's
what
you
see
here
and
you
can
see
that
there's
multiple
instances
of
the
service
node.
B
So
there
would
be
lets
say
if
we
have
this
to
node
Cassandra
cluster,
that
I
talked
about,
we
would
have
an
instance,
one
in
instance
to
and
there's
a
thin
layer.
That's
that's
deployed
along
side
of
the
Cassandra
itself
and
that
deployments
done
via
Bosh
that
essentially
brokers
down
commands
down
into
the
Cassandra
system,
so
that
when
you
want
something
new
from
Cassandra,
you
want
to
provision
something
new,
that
little
layer
of
service
node
makes
those
calls
down
into
Cassandra.
B
But
from
externally
when
you're
pushing
the
app
that's
all
done
via
the
Gateway
and
the
Gateway
communicates
via
the
nodes
via
am
messaging
broker.
Ok,
so
that's
kind
of
a
high
level
architecture
of
services
in
general.
Let
me
now
jump
over
to
the
demonstration
and
let
me
show
you
first
what
we're
going
to
do
in
that
demo
I'm
going
to
show
you
an
initial
deployment
of
a
cloud
foundry
system.
It
includes
a
Cassata
to
node
Cassandra
cluster
I'm,
getting
my
mic
excellent.
Thank
you
good
timing.
B
So
I'm
going
to
start
out
with
a
two
node
Cassandra
cluster,
then
I'm
going
to
show
you
how
easy
it
is
to
push
an
application
to
Cloud
Foundry.
Then,
finally,
I'm
going
to
go
back
and
I'm
going
to
demonstrate
how
you
can
use
Bosh,
remember,
bashas
the
deployment
tool
I'm
going
to
show
you
how
you
can
use
Bosh
to
modify
your
Cassandra
deployment
to
go
from
a
two
node
cluster
to
a
three
node
cluster
and
then
I'll
show
you
how
all
of
that
works.
So
let
me
jump
over
to
that.
B
Highlight
so
the
command
that
was
run
at
the
top
of
this
was
a
command
called.
It's
there's
a
command-line
interface
for
Bosh.
This
is
Boche
BMS,
so
this
is
showing
you
all
the
virtual
machines
that
are
being
used
to
run
Cloud
Foundry,
what's
highlighted
there.
You'll
notice
is
that
there's
two
nodes
that
are
Cassandra
nodes
and
there's
also
that
gateway
that
I
talked
about
so
we'll
let
this
continue
forward.
So
that
shows
you
what
the
current
cloud
foundry
in
setting
looks
like
now.
What
we're
going
to
do
is
we're
going
to
be
a
past
consumer.
B
Now
we're
going
to
come
we're
going
to
do
things
against
that
pass.
The
first
thing
that
we're
going
to
do
is
we're
going
to
target
the
past
and
that's
what's
happening
with
this
target
command.
So
we
set
that's
today
and
that's
to
the
cloud
controller
that
I
talked
about
earlier.
Then
we're
going
to
log
in
and
that's
using
that
you
a
a
component
that
I
showed
you
in
the
screenshot.
B
So
will
log
in
and
hit
a
password,
then
what
we're
going
to
do
is
I'm
going
to
show
you
that
we
want
to
see
what
applications
do
I
currently
have
running
in
the
system
and
what
service
instances
do
I
have
running
well,
I,
don't
have
any
applications
and
you'll
see
in
a
moment
that
I
don't
have
any
service
instances
either.
Now
the
next
thing
I'm
going
to
do
is
show
you
that
there
are,
however,
some
services
available
for
consumption.
B
So
when
I
do
an
info
with
dash
dash
services,
you
can
see
that
there
is
going
to
be
a
Cassandra
service
listed
there.
So
this
is.
This
is
telling
me
that
when
I
push
an
application,
I
can
bind
it
to
a
Cassandra
service,
there's
my
application.
So
I
just
showed
you
that
I
have
a
war
file
there
and
pushing
to
that
pushing
that
to
cloud
boundaries
as
simple
as
doing
a
push
command.
The
push
command
detects
the
war
file,
and
you
have
to
answer
a
handful
of
questions,
the
name
of
the
application.
B
How
many
instances
you
want
running
of
that
application
I
could
have
ten
I.
Could
a
hundred
I
could
have
one
I
answer
a
few
other
questions
about
how
large
I
want
that
system
to
be,
and
at
the
bottom
let
me
move
the
pointer
out
of
the
way
is
the
URL
for
that
application.
I
also
answer
the
question
of
yes:
I
want
to
bind
to
a
Cassandra
service.
You
can
see
that
there
and
no
I
don't
want
to
Biden
to
any
other
services
and
you'll
see
my
fancy
shmancy
application
in
just
a
moment.
B
So
now
you
can
see
that
it's
uploading,
it's
starting
that
application
checking
to
make
sure
it's
okay
and
now
we're
going
to
bring
the
application
up.
So
you
can
see
here
my
wonderful
you
I
coding
skills.
You
can
see
at
the
top
there's
a
little
bit
of
a
status
message
that
shows
you
that
we
are
connecting
to
one
of
those
nodes.
I'll
remind
you
that
the
nodes
of
the
cluster
were
151
and
152.
B
You
can
see
that
on
151,
you
see
at
the
top
of
the
screen
that
we
were
able
to
see
that
now
I'm
going
to
go
over
into
152
and
we'll
do
the
same
thing
will
go
into
that
sample
key
space
and
sample
column,
family
and
we'll
see
that
same
data
record
and
then.
Finally,
the
last
thing
that
I'm
going
to
do
in
this
stage
is
I
am
going
to
jump
over
to
preemptively
to
another
node
and
I'm,
going
to
try
to
connect
to
153.
B
Now
153
should
fail
because
remember
I
told
you
it
was
only
a
two
node
cluster,
so
the
two
node
cluster,
it's
going
to
fail
here
and
sure
enough.
It
does
okay.
So
we've
got
just
a
couple
minutes
left
on
this
video.
That's
pretty
much
of
what
we're
doing
so
now.
I've
come
back
over
to
the
boss,
CLI
machine,
and
I'm
going
to
show
you
very
quickly
that
we're
going
to
edit
a
deployment
manifest.
So
now
we're
dealing
with
bosch
in
the
deployment
manifest.
B
So
I
add
that
to
six
now
I'm
going
to
do
a
quick
search
for
the
section
in
this
deployment
manifest
for
the
Cassandra
configuration
you
can
see
there
that
it
had
two
instances
I'm
going
to
change
that
to
three
and
then
you
can
also
see
the
range
of
IP
addresses
that
are.
You
are
used
to
deploy
this
cluster
151
and
152
we're
going
to
change
that
to
153.
So
now
we're
going
to
have
three
nodes
of
the
cluster.
B
This
is
literally
exactly
what
I
did
to
change
my
deployment
from
a
two
node
cluster
to
a
three
node
cluster.
So
now
I'm
going
to
do
a
Bosch
deploy
which
is
going
to
take
this
new
configuration.
It
summarizes
the
differences
that
I
made
five
to
six
to
23
and
the
range
of
IP
addresses,
and
now
it's
going
to
do
its
work.
Sabash
is
going
through
and
it's
it's
provisioning,
a
new
virtual
machine.
It's
provisioning,
Lee
Cassandra
bits
on
to
that
virtual
machine
and
configuring
those
into
the
cluster.
B
And
now
when
we
go
back,
it's
we're
all
show
you.
The
bosch,
VMs
and
it'll
show
you
that
there's
now
three
nodes
in
the
cluster,
so
you
can
see
Cassandra,
node,
0,
1
and
2,
and
now,
when
I
go
back
to
the
CLI
eel,
you
would
see
and
I'm
going
to
pause
the
video
here,
because
it's
just
going
to
show
you
the
CLI
that
in
fact,
I
went
to
that
CLI
and
that
data
record
was
appearing
in
that
CLI
as
well.
B
So
I
think
what
we
want
to
do
is
go
back
to
our
slides
and
the
four-year
benefit.
The
slides
will
be
available,
of
course,
and
there
couple
of
screens
that
are
showing
you
how
the
staging
process
works.
So
the
app
gets
staged
and
I
talked
through
a
lot
of
this,
but
the
slides
are
there
for
you
to
remember
how
those
happens.
B
So
I
talked
about
the
fact
that
we
communicate
via
gateways
to
nodes
and
we
come
back
apps
get
provision
down
into
the
DEA
and
then
finally,
the
last
picture
that
I
want
to
show
and
then
I'll
let
ranaut
wrap
up
for
us
is
that
this
is
a
picture
that
depicts
what
we
just
did
in
the
demo.
Going
from
a
two
node
cluster
to
a
three
node
cluster
using
bosch,
this
just
highlights
the
different
places
in
the
configuration
where
we
made
changes
and
how
a
templating
mechanism
is
used
for
those
deployments.
B
All
very,
very
briefly
mentioned
in
30
seconds
or
less
that
we
have
this
solution
that
I
just
showed.
You
is
running
in
a
content
management
scenario
that
was
that's
being
built
by
emc.
This
is
the
architecture.
They
have
a
number
of
cloud,
foundry
services
that
are
running.
You
can
see
here
that
they're
running
Cassandra
services,
as
well
as
blob
stores
and
an
XML
database,
and
then
they
have
application
components,
different
layers
of
application
components
running
as
cloud
foundry
apps
in
those
DEA
s,
alright,
so
I'll,
let
you
wrap
things
up
here
and.
A
To
wrap
up,
I
wanted
to
comment
on
the
state
of
the
cloth
laundry
service
in
the
upcoming
version
of
cassandra
to
point
o
the
service
portion
is
the
is
getting
rebuilt,
and
I
guess,
as
soon
as
the
end
of
august,
beginning
of
September's
they'll
be
the
new
version
of
the
service
module
that
hopefully
we
will
bring
the
new
Cassandra
service
on
to
the
cloud
foundry
two
point:
oh
and
I
hope
that
we'll
see
you
next
year
here
the
summit
and
maybe
we'll
talk
about
how?
How
does
it
work
thanks?
C
C
B
Right
exactly,
and
so
this
was
our
very
very
last
slide
and
we
had
a
little
snafu
there,
but
build
packs.
So
there
was
a
stager
component
and-
and
there's
still
is
something
that's
doing-
some
work
around
the
build
packs,
but
something
that's
coming
in
cloud
foundry.
In
fact,
I
think
we're
going
ga
on
that
today.
In
cloud,
foundry
com
will
have
the
new
build
pack
support
modeled
after
Heroku
build
packs,
and
so,
rather
than
staging
being
something
that
was
baked
very
deeply
into
cloud
foundry.
It
comes
via
the
build
pack,
and
so
by
staging.
B
For
those
of
you
who
don't
know
what
staging
is
staging
is
the
mechanism
of
taking
your
application,
the
war
file
that
you
saw
there
and
getting
it
ready
for
deployment
on
the
node.
That's
running
the
droplet
execution
agent
and
it
used
to
be
a
fairly
involved
process
that
only
allowed
you
to
if
you
wanted
to
extend
Cloud
Foundry
with
new
types
of
staging
for
a
new
programming
language
or
a
new
framework,
or
something
like
that,
it
was
fairly
involved
and
now
that's
happening
via
build
packs.
So
exactly
and.