►
From YouTube: Webinar: Leveraging Kubernetes to Build a Flexible Self-Service Product Demo Environment
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Kubernetes is dominating the container orchestration market, and companies everywhere are adopting it to power their containerized workloads. It is a very versatile platform and can do much more than orchestrate your containerized services and applications. At Sumo Logic, we have been using Kubernetes to power our product demo environment used by our Sales Engineers. It has allowed us to create a reliable, comprehensive self-service environment to demo our product. In this talk, we will walk thru the needs of our demo environment, why we choose Kubernetes and dive into what we built as well as what we have learned along the way.
In this webinar, we'll cover:
- Understanding the use case and needs of a product demo
- Understanding our old solution and why we needed a new solution
- Why Kubernetes + Kubernetes 101
- What we built for our SE teams, deep dive into the components of the environment
- End To End Demo of creating the demo environment, to using it to demo the Sumo Logic platform.
A
Alright
looks
like
the
numbers
are
stabilizing:
let's
go
ahead
and
get
started
things
we
wanted
to
join
in
today's
the
MCF
webinar
leveraging
kubernetes
to
build
a
flexible
self-service
product,
demo,
environments,
I'm,
Kaitlin,
Varner
marketing
manager
at
CNCs
and
I'd
like
to
thank
everyone
who
is
joining
us
today.
I'd
also
like
to
extend
a
welcome
to
our
presenter
today,
Frank,
we
know
technical
product
manager
at
sumo
logic,
so
just
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
speak
as
an
attendee.
A
So
there
is
a
Q&A
box
at
the
bottom
of
your
screen.
If
you
have
any
questions
throughout
the
webinar,
please
feel
free
to
drop
them
in
there
and
then
we'll
get
to
as
many
as
we
can.
At
the
end,
the
session
is
also
being
recorded
and
we'll
send
that
out
afterwards,
along
with
the
slides
as
well.
So
with
that
I'll
hand
it
over
to
Frank
to
kick
off
today's
presentation.
B
Thanks
very
much
Katelyn,
hey
everybody
nice
to
meet
you
today,
I
want
to
talk
to
you
about
how
we've
been
using
kubernetes
here
at
the
Summa
logic.
We've
got
a
couple
of
different
use
cases,
but
I
want
to
talk
to
you
about
one
that
it's
a
bit
different.
It's
one
that
I
haven't
really
heard
from
it's
an
internal
use
case
we're
using
kubernetes
to
power
our
product
demo
environment.
So
before
I,
dive
in
I
want
to
give
you
a
little
bit
of
an
introduction
to
who
we
are.
B
A
B
Your
modern
application
stack,
we've
got
over
2,000
customers
and
55
thousand
users
spread
across
six
different
AWS
regions.
We
analyzed
about
a
hundred
petabytes
of
data
in
a
single
day
like
every
company,
though
we
need
the
ability
to
provide
our
potential
customers
with
a
demo
of
our
platform
to
show
how
the
product
works
and
what
we
can
help
users
with.
It
should
be
no
surprise
that
you
know
product
demos,
their
critical
path
in
the
customer
lifecycle,
they're,
how
you
introduce
your
potential
customers
to
your
product.
B
They
tend
to
go
a
bit
deeper
than
your
marketing
material
or
your
documentation
to
give
customers
a
real
glimpse
into
the
power
of
your
product,
they're,
really
designed
to
help
educate
customers
on
exactly
what
makes
your
product
stand
out
from
the
rest.
But
many
products
can
just
be
complex.
Soumya
logic
is
really
no
different.
We
have
a
complex
product
ourselves
and
you
have
countless
number
of
use
cases
and
features
that
you
support.
B
You
needed
it
to
navigate
through
all
these
complexities
to
really
show
customers
exactly
what
your
products
intended
to
do
and
to
really
help
you
navigate
that
complex
journey.
It's
really
good
to
have
a
driver
who
can
help
you
and
help
the
customer
walk
through
the
product
demonstrate
the
true
power
of
it
and
really
what
they
can
benefit
from
it
and
at
SEMA
logic.
Our
sales
engineers
are
those
drivers
they
demoed
the
product
to
potential
customers
all
day.
B
B
Ses
really
need
a
dependable
environment
in
order
to
be
able
to
successfully
deliver
their
demos,
and
so
you
know
a
few
key
criteria
for
for
any
kind
of
really
successful.
Demo
is
that
a
demo
needs
to
be
reliable,
as
you
need
to
know
that,
when
they're
getting
on
that
call,
their
demo
is
stable,
that
it's
ready
to
go
and
it's
going
to
work
exactly
like.
They
expect
it
to
they
even
confidence.
B
They
can
go
through
the
demo
with
it
without
any
interruption
and
as
they
can,
your
prospect
may
get
worried
or
have
some
doubts
about
their
products.
The
demo
definitely
needs
to
be
comprehensive.
It
needs
to
showcase
all
areas
of
your
product
with
a
clear
end
and
a
clear
beginning
making
sure
that
journey
is
easy
to
follow
and
to
understand.
It
also
needs
to
be
relatable
to
a
story
that
you're
telling,
but,
more
importantly,
to
the
story
that
your
prospects
are
they're
interested.
B
B
The
ability
to
adapt
to
these
different
situations
is
really
critical,
and
so
I
want
to
talk
a
little
bit
of
how
we
used
to
deliver
our
demos
here
at
Summa
logic,
so
we
developed
an
internal
tool
called
log
jam
that
enabled
us
to
create
streams
of
machine
data
in
any
format.
We
wanted
me
streams
to
be
sent
to
Sumo
to
simulate
machine
data
from
really
any
application
or
any
stack.
We
could
model,
though
application
format
such
as
nginx
or
my
sequel.
B
We
can
also
model
you
know
common
services
like
any
one
of
the
AWS
services,
such
as
cloud
trail
or
s3
audit.
We
could
also
model
time
series
data,
so
CPU
memory
metrics.
We
can
model
custom
application
metrics
as
well,
and
then
really
we
could
Montiel
about
you
know
emulate
anything
we
wanted.
After
all,
we
could
model
any
kind
of
common
applications
that
do
a
specific
things,
tell
a
different
story,
and
so
previously
we
would
put
multiple
streams
together
to
tell
a
story.
We
could
simulate
real-world
scenario
from
streams,
these
machine
data
using
block
gems.
B
We
had
a
bunch
of
different
demos
that
maybe
some
told
a
security
story
or
some
operational
story,
and
all
these
demos
were
different
demos
that
the
SES
would
give
to
our
customers,
and
so
it
was
great.
It
was
really
helpful.
They
definitely
got
the
job
done.
It
was
definitely
something
that
could
we
could
demo
the
power
of
the
platform
to
customers.
It
was
definitely
meet
some
met,
some
of
those
key
criteria,
but
it
wasn't
exactly
what
we
really
wanted.
We
wanted
to
go
faster.
We
needed
to
have
more.
B
We
wanted
that
next
level
up,
so
we
really
started
to
think
about
what
we
could
do,
but
before
we
did,
we
needed
to
look
at
well
what
was
missing,
what
were
some
of
the
key
criteria,
so
we
started
having
our
conversations
with
our
SES
to
get
a
sense
of
how
they
were
demoing.
What
were
the
strings?
What
were
the
weaknesses,
and
it
really
boiled
down
to
a
few
key
points.
The
first
thing
was
there
was
zero
isolation
between
the
Dow's,
everyone
demoed,
the
same
exact
environment.
B
So
there
was
no
way
for
an
SE
to
say,
make
some
minor
tweaks
or
changes
that
would
really
resonate
with
his
prospect,
but
the
person
that
he's
talking
to
maybe
more
so
than
another
se
he
was
giving
that
same
demo.
Onion
is
going
back
to
this.
It
wasn't
customizable
right
so
they're.
Actually,
even
if
they
had
you
know
independent
streams,
there
was
no
easy
way
for
SES
to
customize
these
log
jams.
They
were
all
pre-built.
They
were
running
somewhere,
they
didn't
have
access
to.
B
It
was
an
environment,
they
could
really
touch,
they
just
saw
the
it
product
really,
and
the
other
thing
is
that
it
wasn't
really
real
I
mean
sure
we
could
model
these
streams
to
tell
an
interesting
story,
but
we
couldn't
make
it
tangible.
We
couldn't
go
back
to
some
real,
live
application
and
show
ya.
This
application
is
actually
broken,
so
we
started
thinking
about
what
we
could
do
and
what
we
wanted
kind
of
the
next
generation
demo
platform
to
look
like
you.
B
Those
pain
points
we
had
identified
by
TMS
DS.
We
identified
basically
three
areas
that
we
wanted
to
address.
The
first
thing
was
tangible:
it
came
up
over
and
over
again
we
wanted
something
that
was
real.
We
wanted
an
application
that
we
can
actually
go
to
and
use
Summa
logic
to
monitor
it.
We
monitor
its
life
cycle,
we
can
show
its
health,
we
can
show
its
state,
we
can
show
exactly
how
it's
doing
and
what's
going
on.
B
B
They
wanted
to
each
se,
wanted
to
be
able
to
enhance
or
add
things
they
wanted
to
do
if
they
wanted
to
tell
a
different
story
if
they
wanted
to
slightly
tweak
a
story
that
made
sense
for
their
particular
customer
that
they
happen
to
be
speaking
with,
it
was
important
for
them
to
do
that.
So
we
knew
that
the
demo
had
to
be
customizable,
but
the
last
thing
is
we:
we
still
had
it
with
all
these
new
enhancements.
We
still
have
to
preserve
reliability.
B
Sometimes,
as
these
are
back
to
back
on
demos
all
day
long,
they
need
to
know
that
off
the
next
call
they
go
to
off.
One
call
to
go
to
the
next
call:
everything
is
going
to
run.
Everything
is
going
to
work
exactly
like
they
expected
and
exactly
like
they
wanted
to.
So
we
started
thinking
about.
Well,
how
can
we
get
there?
What
can
we
do?
You
know
seem
illogical
itself
is
built
on
a
series
of
distributed
micro
services
running
in
AWS.
That's
been
our
architecture,
since
we
were
since
we
were
born.
B
We
knew
that
we
wanted
to
do
something
with
micro
services.
Here,
we've
learned
a
lot
from
it.
We
knew
we
wanted
to
take
a
lot
of
those
strengths
and
incorporate
that
back
in
into
something
that
we
could
build
into
our
product
demo,
environment.
We
also
knew
we
wanted
to
get
into
docker
and
containers.
It
was
something
that
we
weren't,
using
with
our
with
our
current
platform.
B
And
from
docker,
but
with
all
these
things,
we
knew
there
was
going
to
be
some
overhead
and
we
didn't
really
want
to
have
that
overhead
with
want
to
have
to
be
pushing
this
car
uphill
constantly.
Maintaining
this
environment,
there's
no
real,
dedicated
team
here,
managing
the
demo
environment.
Today,
it's
actually
managed
by
some
of
the
SES
themselves,
so
it
needed
to
be
something
they
could
easily
manage.
B
After
all,
they're
their
sole
responsibility
is
to
get
on
the
phone
with
prospects
and
help
them
and
get
them
introduced
to
the
product
and
guide
them
along
their
journey,
as
they
start
to
discover
the
product.
So
it
was
really
important.
They
still
have
the
opportunity
to
do
that.
We
knew
that
we
were
going
to
need
some
level
of
orchestration.
B
We
needed
some
level
of
orchestration
to
help
us
maintain
all
of
these
micro
services
running
the
containers,
help
us
maintain
the
environment
and
provide
some
automation
on
lower
level
things
that
could
free
up
time
with
the
SES
and
we
started
looking
and
kubernetes
is
coming
up
a
lot
at
this
time.
This
was
probably
almost
three
years
ago
and
obviously
kubernetes
is
coming
up
a
lot.
B
You
know
I
think
everybody
here
knows
what
kubernetes
is:
it's
a
very
portable
extensible,
open
source
platform
for
manner
of
managing
your
containerized
work,
clothes
and
services,
and
it's
got
a
lot
of
great
abstractions
and
services.
That
kind
of
help
facilitate
these
things
and
we
took
a
lot
of
advantage
of
those
two
to
build
our
environment,
so
we
decided
to
go
with
kubernetes.
B
It
was
hot
at
the
time
it
offered
a
lot
of
great
features,
but
there
was
really
some
key
points
that
we
liked
that
we
wanted
to
exploit
and
to
really
use
number
one
was
the
automation
like
I
said
earlier.
If
a
small
team,
that's
you
know
it's
a
team
of
SES,
but
they
don't
have
a
team.
Managing
this
environment
needs
to
be
pretty
self
service.
Ses
can
be
able
to
go,
create
their
own
demos,
make
code
changes
pushes
out
to
their
environment
all
independently.
To
maintain
that
we
wanted
easy
scheduling.
B
Obviously
you
know
we
need
that's
part
of
the.
You
know:
basics
of
an
Orchestrator.
We
don't
want
to
deal
with
the
scheduling
logic.
We
want
that
to
kind
of
be
hand
before
us,
scalability
we're
growing
and,
as
we
were
growing,
we
needed
to
be
able
to
scale
our
demo
environment
out
as
new
SES,
our
on-boarded
they're,
going
to
need
their
own
environment
they're,
going
to
need
their
own
playground
that
they
can
go,
build
and
play
and
tweak
and
make
changes
and
the
dogfooding.
B
B
What
kind
of
changes
could
we
make
that
we
could
apply,
and
this
was
this-
was
an
exercise
well
different
use
case
and
not
necessarily
powered
with
Summa
logic
platform,
it's
very
informative
than
the
less,
and
we
were
going
to
learn
a
lot
along
the
way,
and
it
was
knowledge
that
we
could
correlate
back
to
engineering
and
share
amongst
them
as
we
learn
and
as
we
go.
So
we
took
this
as
an
opportunity
to
kind
of
learn
a
bit
more
about
humanities,
to
what
we
could
do.
B
I'll
spend
a
little
bit
of
time.
Talking
about
so
you
know
some
of
the
constructs
of
kubernetes
at
the
high
level
in
case
there's
folks
who
don't
know,
but
you
know
the
core
of
kubernetes
is
the
communities
control
plane
is
the
brains
of
the
operation,
it's
kind
of
like
the
engine
in
the
car
that
makes
the
car
go
and
it
consists
of
multiple
parts.
But
you
know
some
of
the
parts
of
the
API
server,
the
scheduler
of
the
controller
manager
at
CD.
Each
of
these
components
serve
as
the
control
plan.
B
They
work
together
to
provide
the
orchestration
layer
that
makes
the
cube
Randy.
That's
what
it
is
I
like
to
think
of
compute
like
if
you're
going
with
the
car
analogy
like
it's
like
the
tires
of
the
car,
and
they
make
up
they're
made
up
of
a
couple
of
things
like
your
nose.
Your
nose
of
the
tires
in
the
car
tube
lid
is
an
agent
that
runs
in
every
node
to
proxies
and
other
agents
are
on
some
nodes
and
you've
got
the
container
runtime.
Obviously,
whatever
your
container
runtime
is
our
case.
B
We
use
docker,
but
kubernetes
supports
many
other
container
runtimes
today
and
then
you've
got
your
building
blocks
for
your
for
your
applications
for
the
things
you're
going
to
build,
and
these
are
the
things
that
we
really
wanted
to
take
advantage
of.
Then
we
were
going
to
build
our
demo
environment
with
you
know,
paas
of
the
lowest
level
of
compute
within
kubernetes.
They
are
a
set
of
containers
that
are
co-located
in
Co
schedules.
B
Deployments
can
be
declared
updates
to
your
configuration.
Daemon
sets
are
really
useful
for
agents
things
that
you
want
to
run
on.
Every
node
in
the
cluster
services
handle
have
pods
communicate
with
each
other
and
namespaces,
giving
you
a
logical
grouping
of
how
you
can
group
resources
together.
It's
not
bad
necessarily
backed
by
the
physical
clutter
cluster.
It's
more
of
a
virtual
cluster,
so
I
want
to
start
with
the
end
here.
So
we
took
all
of
these
bits
and
pieces,
we
put
them
all
together
and
we
build
a
product
we're
going
to
start
at
the
end.
B
This
is
travel
logic.
This
is
this
some
screenshots
from
the
application.
It's
a
fairly
simple
UI.
It
models
an
e-commerce
booking
site,
but
it's
fully
interactive
users.
Can
you
can
go
in
and
you
can
book
a
flight
and
you
can
go
through
it
process
and
checkout.
You
can
go
for
the
whole
flow
and
it's
all
running
in
kubernetes-
and
this
is
all
running
in
AWS
as
well
and
now
what
I
want
to
do
is
I
kind
of
want
to
break
this
down
a
bit.
I
want
to
talk
about
each
individual
component.
B
How
we
did
it
and
kind
of
we
did
and
then
at
the
end,
we're
going
to
go
through
a
live
demo,
so
starting
kind
of
with
the
high-level
architecture
namespace.
The
way
we
use
namespaces
is
that
that's
how
we
isolate
the
environments
for
each
se,
so
every
SC's
demo
runs
in
its
own
namespace
and
within
that
namespace
there
will
be
a
series
of
different
services
that
make
travel
logic.
B
What
it
is,
we've
put
together
a
lot
of
open
source
technologies
which
are
so
layer,
but
you
know
you
have
some
common
things,
such
as
you
need
a
persistence
layer,
a
caching
layer,
some
custom
services
like
check
out
service,
so
that
you
know
you
can
simulate
users
checking
out
through
the
website
a
product
service
to
serve
up
what
slides
or
hotels
or
car
rentals
we're
going
to
serve
up.
There's
an
administrative
UI
which
allows
SES
to
kind
of
fine-tune
some
things
within
the
demo
or
make
some
tweaks
from
a
UI
perspective.
B
Obviously
there's
a
UI
service,
and
then
we
need
to
simulate
like
traffic
against
the
site.
This
is
going
to
be
a
real
live
application
in
the
end,
we're
using
Summa
logic
to
monitor
that
we're
getting
all
of
that
machine
data.
We
need
a
way
to
kind
of
simulate
that
traffic
and
rather
than
having
log
jam,
which
we
used
to
use.
We
wanted
to
make
this
real.
These
services
were
obviously
real.
If
you
took
action
against
those
services,
like
you
know,
made
some
rest
calls
to
the
product
service.
You
know
there
was
a
log
line
generated.
B
There
was
a
metric
generated,
and
so
we
use
a
task
automation
framework
to
help
us
simulate
load
across
the
servers
and
that
produces
real
live
log
data,
that's
coming
into
the
system
and
then
beyond
that
I
mean
if
that
covers
off
on
the
some
of
the
components
at
a
high
level
that
make
up
travel
logic.
You
know
itself,
but
beyond
that
there
were
a
lot
of
things
we
still
had
to
do
that
work
done
great.
We
had
our
winter
application,
but
how
do
we?
How
do
we?
How
do
we
deploy
it?
B
How
do
we
maintain
it?
We
built
a
you,
know,
a
proper,
build
and
deploy
process,
and
it
covers
end
to
end
from
check-in
to
deployment
to
give
us
ease
that
customization.
If
they
want
to
go
in
and
customize
things
they
can
go
in,
make
a
good
commit,
it
can
go,
build
their
image
and
it
can
push
to
their
environment,
and
on
top
of
that,
we
also
found
that
we
had
to
build
and
monitoring.
B
So
we
were,
we
were
kind
of
customer
zero
when
we
developed
our
own
monitoring
solution
for
how
similar
logic
integrates
with
kubernetes,
how
we
pull
the
machine
data
from
your
from
the
orchestration
layer
from
your
custom
applications
that
are
running
in
there.
We
use
this
exercise
to
build
that
integration,
and
it
was
a
really
good
exercise
for
us
to
do.
It
gave
us
some
hands-on
experience
and
we
were
able
to
really
quickly
learn
what
we
could
do
and
what
were
the
best
ways
to
get.
B
Some
of
this
data
out
of
Cheaper,
Nettie's
and
you'll,
see
logged
in
here
logged
in
is
still
very
much
alive
in
our
demo,
but
we've
kind
of
changed
its
purpose.
It
has
a
much
different
purpose,
which
we'll
talk
about
a
little
bit,
so
I
want
to
break
down
some
of
that
travel
logic
layer
a
little
bit
more.
You
know.
All
of
these
things
I
talked
about
everything's
running
is
a
namespace.
We
have
a
bunch
of
deployments
and
we're
just
basically
stitching
together
a
lot
of
open
source
technologies
to
leverage
things
so.
B
We've
got,
for
example,
our
persistence
and
caching
layer
which
we're
just
using
my
sequel
in
Redis
for
on
the
custom
services
so
like
the
products
that
serve
up
the
cars
and
the
hotel,
the
flights
or
checking
out
things
like
that.
We're
breezing
flies
freezing
the
flash
framework
for
that.
It
was
very
easy
for
us
to
build
some
simple
cred,
api's
and
various
AP
is
against.
You
know
creating
these
products
than
going
through
an
active
checking
out
and
going
through.
B
The
flow
I
talked
earlier
about,
there's
a
there's,
an
administrative
interface
where
users
can
go
customize
things,
so
we
have
abused,
also
use
flasks
and
our
setting
service
to
kind
of
fine-tune
the
demo.
You
can
do
things
like
control
the
load,
control,
the
frequency
of
errors,
control,
the
distribution
of
events,
that
kind
of
change
the
flow
of
things
you
can
even
go
in
and
change
like
some
of
the
logos
or
some
of
the
branding
like.
If
you
don't
want
to
serve
up,
you
know,
hotels,
you
could
serve
up
something
else.
You
can
date
there.
B
B
B
There's
an
automated
process.
That's
picking
up
the
commits
going
through
it
pushing
the
changes
out.
So
it
depends
depends
on
what
they're
trying
to
do.
If
a
user
needs
to
spin
up
a
new
demo
like
a
new
se,
started
part
of
his
onboarding,
he
gets
access
to
Jenkins
and
you
get
the
document
that
explains
how
to
go,
deploy
his
demo
and
you
get
his
own
environment
up
and
then
from
there
they
can
go
to
get
enhance
it,
and
then
the
monitoring
components
are
really
critical.
B
I
talked
about
how
we
use
this
opportunity
to
develop
our
own
monitoring
solution
for
kubernetes
and
what
we
ended
up
doing.
Is
we
built
a
fluent
deep
plugin?
We
use
fluid
D
to
aggregate
all
the
logs
from
kubernetes
across
the
control
plane
across
all
of
the
nodes.
Enrich
them
with
metadata
and
ship
them
over
to
Summa
via
an
HTTP
source
is
what
we
call
it.
Basically,
a
secure,
URL
that
transmits
all
the
data
over
to
CMO
and
from
the
metrics.
B
We
also
have
an
integration
there
with
pulling
in
all
the
metrics
from
each
of
the
individual
instrumented
components
as
they
come
in,
which
include
see
advisor
and
API
server.
All
the
control
plane
components
cubelet.
So
we
can
capture
all
of
these
metrics
and
bring
all
of
this
data
into
sumo
as
well,
and
then,
of
course,
we've
got
our
infrastructure
side
again.
This
is
all
running
in
AWS
we
are
using.
B
We
used
cops
to
create
our
kubernetes
cluster
and
that's
running
in
a
in
our
udana
in
a
region
in
AWS
and
we're
taking
advantage
of
a
bunch
of
other
services.
Your
and
we
kind
of
tie
them
into
our
demo.
But
like
things
like
the
pc
flow
logs
or
cloud
trail
logs,
you
know
because
this
is
a
real
application.
There's
other
services
in
AWS
be
on
ec2
that
we're
using
and
we're
kind
of
connecting
the
whole
dots
here
that
this
is
a
kubernetes
cluster.
B
It's
running
in
a
cloud
environment,
we're
showcasing
how
we
can
bring
in
all
the
different
data
and
all
the
telemetry
from
these
different
services.
I
talked
earlier
about
logged
in
and
it
turns
out
it
is
still
a
very
critical
part
of
our
demo
product.
So
one
of
the
things
we
have
is
we
have
what
we
call
applications
and
applications
are
basically
pre-built.
Contents
they're
usually
built
around
some
kind
of
technology,
so,
for
example,
any
one
of
the
AWS
services
or
patchy
logs
or
my
sequel
logs,
and
these
are
pre-built,
basically
searches
and
dashboards.
B
So
visualizations,
taking
this
raw
log
data,
identifying
key
things
to
keep
an
eye
on
and
to
look
at
and
visualize
that
data,
and
so
because
log
jam
could
simulate
any
stream
of
data.
We
still
heavily
use
this
and
we
use
this
to
basically
enable
us
to
demo
anything
in
our
App
Catalog.
We
don't
have
to
go,
set
up
an
s3
bucket
or
defined
cloud
trail
or
go
set
up
some.
You
know
physical
hardware
like
with
firewalls
or
anything.
We
can
model
what
those
logs
look
like,
because
they're
a
known
format.
B
We
know
what
the
format
looks
like
and
we
can
use
that
data
inside
a
few
varieties
in
our
full
demo
environment
to
have
this
kind
of
single
platform
demo
everything
that
you
can
do
the
sumo
so
now
I
want
to
switch
over
to
a
live
demo
and
we'll
hope
the
demo
gods
have
been
good
today.
Let
me
go
ahead
and
come
over
here.
B
Just
want
to
show
you
kind
of
what's
running
here,
so
you
can
see
there's
a
series
of
different
pods
here.
I
talked
about,
we
have
my
sequel
for
a
back-end.
Nginx
is
serving
you
I
we've
got
some
custom
services
like
a
checkout
service
or
our
product
service
settings
and
tasks
are
being
handled.
So
again
those
tasks
are
triggering
all
the
load
and
simulating
all
that
load
across
the
system,
and
so
now,
let's
go
to
the
final
product
here.
B
A
B
To
do
is
well
now
I'm
going
to
break
the
demo.
We've
got
multiple
different
demos
of
this
can
service
so
I'm
going
to
give
you
an
operational
demo,
so
I'm
going
to
push
a
hotkey
notice
on
the
bottom.
There
you
got
a
little
okay
pop.
It's
kind
of
a
visual
clue
to
the
SE
that
something's
happening.
I'll
continue
to
go
through
will
purchase
this.
B
B
What's
that,
what
happens
up
happening
is
that
a
new
Jenkins
job
gets
deployed
and
the
Jenkins
job
is
going
to
spin
up
some
additional
checkout,
sir
checkout
pods,
and
so
as
as
the
transactions
were
going
through,
we
have
one
checkout
pod
behind
the
service
and
as
I
hit
the
service.
All
the
traffic
goes
to
that
pod.
We
scale
out
and
we
deploy
a
new
version
of
code
and
as
we
deploy
a
new
version
of
code,
that
code
is
going
to
have
some
inherent
bugs
in
it
that
make
it
not
work.
B
You
log
back
into
Jenkins.
Apparently
there
we
go,
looks
like
it's
triggered.
So
this
is
the
Jenkins
job.
We
can
go
go
to
the
console
output.
We
can
see
that
it
was
tied
to
cluster.
So
in
this
targeting
my
demo
environment
and
what
we're
going
to
do
is
we're
going
to
push
some
new
code,
we're
pushing
dev
code
out
we're
going
to
deploy
two
additional
pods
to
that
system.
B
B
You
can
travel
logic,
dot,
end
zone
all
right
so
now,
I
want
to
jump
to
the
Summa
logic
view
and
all
of
these
dashboards
here
they're
in
live
modes,
so
that
the
data
is
being
streamed
in
real
time.
All
this
data
is
coming
in
and
this
is
the
representation
of
what
we're
taking
from
that
data.
So
we're
breaking
down
the
travel
logic,
business
overview.
We've
got,
you
can
see
our
flights,
we
can
see
our
tells
cars.
We
can
see
that
everything
is
healthy.
B
We
can
see
where
we're
getting
traffic
from
again
we're
simulating
that
traffic
using
a
task
execution
framework
called
celery.
But
all
these
things
are
transactions
that
are
flowing
in.
We
can
monitor
for
any
kind
of
outlier
behavior
of
what's
happening
if
there's
any
spikes
or
there's
sudden
drops
and
traffic
data.
This
is
another
view
of
the
operational
demo.
This
is
more
high-level
to
show
you
things,
but
this
kind
of
shows
how
we
are
pulling
in
some
of
this
real
AWS
data.
So
we've
got
our
eld
logs.
B
We've
got
our
EPC
Network
flow
logs
and
we
were
obviously
breaking
down
our
different
services
as
well,
bringing
all
that
data
in
as
well,
and
then
we
can
even
go
so
far
as
to
break
down
service
level
information
right.
So
in
this
case
we
can
see
metrics
and
logs
here
simulated
together,
we've
got
our
custom
metrics.
We
generate
metrics
in
this
application.
Every
time,
there's
a
booking
when
a
success
for
what
fails,
we're
monitoring
the
CPU
of
each
one
of
the
positive
running
in
there
and
we've
got
our
gateway
latency.
We
can
monitor.
B
We
can
see
if
there's
any
errors
by
node.
We
can
also
see,
if
there's
any
error,
particular
trends
in
the
last
seven
days.
So
we
can
see
that
all
the
time
for
the
last
seven
days
there
have
been
no
errors
in
the
system.
So
that's
good!
That
makes
sense.
That's
what
we
want
to
see.
Let
me
go
back
to
Jenkins
if
it
has
gone
up,
yeah,
okay,
so
it
is
in
progress.
B
Jenkins
is
running
a
little
slow
still
so
I'm
going
to
let
that
finish
up
for
us
I
can't
so
a
little
bit
about
you
know
how
we're
collecting
this
data
I
talked
about
how
we
build
a
fluent
deep
plugin.
So
everything
is
coming
in.
We
are
running
fluent
D
in
this
cluster
as
well.
So
if
I
do,
let's
just
do
get
all
pods
shorthand
to
this.
B
We've
got
a
lot
of
pausing
in
this
cluster.
Every
SC
has
their
own
environment.
We've
got
some
simple:
we've
got
some
simple
environments
that
we
break,
that
are
scheduled
interval
and
some
entities
have
their
own
environment
like
myself
and
there's
several
others
that
we
can
break
on
demand
as
we
need
to,
but
we
run
fluent
D
on
every
node
in
the
cluster
and
fluidy
is
sending
in
the
logs
to
us
and
bringing
in
the
DES
logs
with
all
the
image
data,
and
it
runs
in
every
node
in
the
cluster.
B
So
we're
able
to
get
a
comprehensive
view
of
the
orchestration
layer
and
of
the
control
plane
layer
as
well.
Oh
good
things
are
starting
to
happen.
So
the
again
these
dashboards
are
in
live
mode.
So,
if
I
go
back
and
I
run
this
command
again,
you
can
see
here
that
we
started
up
some
new
checkout
pods
right
here.
Here
are
two
new
checkout
pods
that
are
running
this
one
is
running
for
five
hours.
B
These
are
the
two
that
are
inherently
broken,
but
again
they
all
they're
all
sitting
behind
the
checkout
service,
and
so,
if
we
go
back
to
our
applicator
some
of
our
reviews,
we
can
see
that
okay,
we're
starting
to
get
some
more
failures.
We
go
back
to
our
business
overview,
we're
starting
to
see
some
red
panels
light
up
here,
we're
starting
to
see
some
delay
in
our
application
status.
B
We
can
even
go
to
our
operational
overview,
we're
getting
higher
number
of
Galle,
be
errors
or
check
out
services,
reporting
issues,
and
if
I
check
out
services
reporting
issues,
then
we
have
programs
but
wait.
We
just
demo
this
we
just
went
through
and
things
work
fine.
Well
again,
it's
all
sitting
behind
a
service
that
some
of
those
pauses
are
broken.
So
if
I
go
back
in
here
now,
what
we
should
see
as
a
failure-
and
it
says-
error-
processing
payment.
So
what
just
worked
is
now
inherently
broken.
B
B
A
B
Ready
yet,
but
we
actually
go
look
at
the
pods.
We
should
see
those
running
yeah,
so
there's
free.
No,
if
you
remember
I
deployed
it,
I,
just
added
it
to
my
name.
These
pods
are
running,
so
the
demo
is
still
coming
up.
It's
still
being
spun
up
and
once
that's
done
and
everything
goes
to
initializes
all
the
setup
and
tasks
jobs
complete
we'll
have
a
new
travel
on
a
demo
environment
that
a
user
could
go
in
and
kind
of
troubleshoot
all
right.
So
let's
switch
back
to
slides
now.
B
Cool,
so
I
want
to
go
back
to
the
beginning
of
the
presentation
where
I
talked
about
our
goals
and
did
we
meet
our
goals?
Well,
we
have
an
application,
it's
definitely
tangible,
it's
something
that
we
can
take
customers
through
or
show
them
a
quick
demo
of
the
application
and
all
the
data
that
comes
into
SEMA
logic
is
straight
from
that
application.
It's
being
streamed
in
to
Summa
logic,
so
it's
definitely
tangible
and
we
can
break
it
and
we
can,
as
we
saw,
we
can
actually
see
that
break
happening
soon.
B
We
saw
that
spike
and
failed
bookings.
We
saw
those
errors
increase,
we
saw
panels
start
to
change
and
that's
because
we've
deployed
inherently
broken
code
to
the
cluster
and
real
transactions
are
happening,
and
now
those
real
transactions
are
periodically
hitting
one
of
those
two
of
those
three
broken
pods.
It
is
customizable
in
the
sense
that
SES
can
have
access
to
the
github
repo.
They
can
go,
make
changes
and
they
can
push
those
changes
to
their
environment.
Their
environment
is
isolated
from
every
other
Essie's
environment.
They
have
full
control
over
that.
So
I
want
to
go.
B
Make
some
changes
to
the
story?
Maybe
I
don't
want
to
use
the
travel
site,
but
I
want
to
use
some
other
e-commerce
site
or
build
something
else.
They
have
full
control
to
do
that
and
over
time,
as
I
see
have
done
this,
we
kind
of
prepackaged
that
stuff
up
and
made
it
even
easier
for
them
to
deploy
and
they
can
easily.
You
know,
deploy
different
demos.
We've
got
this.
B
This
demo
I
gave
you
is
just
one
example
of
a
demo,
but
we've
got
other
demos
that
target
different
operational
use
cases
or
securities
cases
and
they've
been
customized
and
suitable
to
your
needs.
So
we
definitely
met
that
goal
and
for
reliability.
For
the
most
part,
we
have
had
very
you
know
very
limited
problems
with
with
travel
logic
me
it's
like
I
said
we
don't
have
a
team
sitting
there
monitoring
it.
We
put
really
good
things
in
place
like
horizontal,
horizontal
Pato
scaling
when
we
need
to
vertical
node
scaling.
B
If
we
need
to
scale
out
the
notes
we
have
are
not
vertical.
No
sorry,
horizontal,
node
scaling,
we
put
into
place
a
lot
of
automation
to
ensure
that
things
can
recover.
We
make
heavy
use
of
like
lightness,
probes
and
health
checks
so
that
we're
constantly
monitor
its
monitoring.
The
system
and
kubernetes
takes
action
against
it
as
it
needs
and
can
help
recover
the
system
and
cover
off
in
a
lot
of
use
cases,
and
it's
been
a
very
reliable
environment
for
our
SES
to
go
to
into
demo
the
platform
to
your
customers.
B
So
in
the
end
we
met
all
these
goals.
We
felt
like
we've,
met
all
these
goals
and
you
know
we
learned
a
lot
from
this
experience
and
we
started
looking
at
other
use
cases,
and
you
know
one
of
the
use
cases
we
had
was
within
our
customer
success
team.
So
at
Summa
logic,
a
customer
success
can
be
very
different
at
different
companies.
Sometimes
it's
more
aligned
to
the
sales
side
where
they
might
be
like
on
an
Account
Manager
level,
and
sometimes
they
might
be
more
technical
and
itsumo.
That's
the
case.
B
Our
customer
success
teams
are
are
more
technical,
post
sales
arm
that
are
very
proactive
in
assisting
customers
going
beyond
a
little
bit
of
sometimes
beyond
the
PS.
Does
we're
here
to
be
proactive
arms
to
help
customers.
We
monitor
their
usage,
we
monitor
what's
going
on
and
how
we
can
help
them
and
at
zuma
logic
we
have
a
lot
of
decentralized
data
and
tooling
we
did.
We
have
you
know
a
CRM
data
from
one
system,
invoicing
data
from
another
system,
then
you
know
our
Zendesk
and
our
various
other.
B
B
These
you
know
custom
applications
into
kubernetes
and
into
also
you
know,
bringing
in
various
feeds
using
cron
jobs
and
taking
advantage
of
some
other
constructs
that
we
could
to
bring
all
this
data
centralized
into
sumo
and
what
it
really
helped
the
CS
teams
do
was
to
provide
this
kind
of
single
pane
view
for
everything
related
to
a
customer
to
help
them
monitor
customers
to
help
them
see.
How
is
this
customer
doing?
Are
they
experience
any
slow
queries?
What's
their
adoption
like?
Are
they
logging
in
or
they
today,
taking
advantage
of
the
system?
B
Is
there
anything
that
they
any
feature
they're
not
using?
That
might
be
relevant,
given
some
of
the
some
of
the
things
that
they're
trying
to
do,
and
obviously
I
talked
about
internal
dogfooding,
a
next-generation
thing
that
we
wanted
to
do
you
know
this
is
this
kind
of
this
is
kind
of
an
older
version,
but
this
is
a
you
know.
A
map
of
all
the
different
services
that
make
zoom
of
today
and
one
of
the
things
that
we're
looking
at
is
we're
looking
at
moving
our
services
to
kubernetes
and
we're
looking
a
lot
of
eks.
B
We
like
the
automation
that
eks
gives
us
we'd,
like
the
fact
that
it's
everything's
contributed
back
to
upstream.
We've
done
a
good
job
with
it,
and
so
we're
going
to
be
looking
at
migrating
every
slowly
migrating
our
services
over
to
eks
and
kind
of
making
that
next
level
change
to
our
architecture,
I'm,
getting
it
lined
up
that
way.
So,
if
I
take
anything
from
this
presentation,
the
way
I
was
watching
I
guess
what
I
wanted
to
remind
is
this
kubernetes
is
very
versatile.
We
saw
three
different
use
cases.
B
We
really
focused
on
one
right,
our
product
demo,
environment
and
the
goal
there
was
to
build
a
fully
self-service,
flexible
demo
environment
for
our
SES,
to
really
use
the
power
of
Summa
logic
and
to
showcase
the
power
of
the
platform
and
because
of
our
existing
tooling,
and
what
we
learn
from
long
gen.
We
made
a
lot
of
decisions
along
the
way
to
really
enhance
our
environment,
to
make
it
a
little
bit
more
flexible
to
make
it
more
tangible
and
to
make
it
an
even
more
reliable
than
what
we
had.
B
That
was
our
sales
engineering
org,
but
we
also
found
use
cases
internally
for
a
customer
success
organization,
and
we
that
enabled
a
lot
of
things
to
where
it
actually
wasn't
just
customer
success
who
was
using
it.
But
it
was
other
teams
started
using
the
centralized
environments
as
well.
Engineering
and
product
engineering
could
look
at
the
health
of
the
service
across
everything.
Product
could
look
at
feature
usage
and
compare
that
back
with
customer
information.
Sales
could
monitor
the
health
of
their
accounts.
B
They
could
make
sure
that
their
customers
are
using
the
system
that
they're
happy
with
the
system
and
then
area.
Of
course,
our
engineering
use
case
of
where
we're
actually
going
to
start
migrating
our
services
into
kubernetes
and
making
sure
that
we're
taking
advantage
of
that
next
generation
architecture
and
keeping
our
architecture
on
point,
and
that's
that's
it
for
my
presentation
today,
I
wanted
to
say
thank
you
thanks
for
joining
today
and
I
hope.
You
I
hope
you
consider
other
use
cases
for
your
environments
and
for
different
things.
You
can
do
with
kubernetes.
A
Awesome
thanks
Frank
for
great
presentations,
so
we
have
some
time
for
questions
now.
Just
as
a
reminder,
if
you
have
a
question
that
you'd
like
us
answered,
please
drop
it
in
the
Q&A
tab
at
the
bottom
of
your
screen
and
we'll
get
to
as
many
as
we
can
all
right.
The
questions
coming
in
so
if
the
in
the
general
is
the
workload
being
deployed
as
a
deployment
object
or
via
a
replica
set.
B
We
do
this
kind
of
proactively
in
some
cases
like,
for
example,
when
an
se
is
off
boarded,
but
we
also
basically
make
it
so
that
an
SE
can
only
have
one
primary
demo.
That's
allowed
to
run
all
the
time
and
others
have
a
time
limit
and
we
basically
have
a
process
that
runs
inside
of
kubernetes.
Looking
for
things
that
expired
and
doing
that
cleanup.
One
of
the
things
that
we
want
to
do
kind
of
next-generation
to
is
that
we
don't
do
a
good
job
of
today
is
kind
of
down
scaling
on
the
weekends.
B
You
know,
because
our
SES
aren't
giving
demos
on
their
weekends
typically,
so
that's
something
that
we're
going
to
be
looking
at
incorporating
now.
We've
got
some
ideas
on
how
to
would
do
that,
based
on
what
we've
learned
from
the
other
cost
maintenance,
but
that's
definitely
something
we
have
some
of
them,
but
I
think
we
could
still
do
a
better
job.
B
Let
me
go
back
so
I
kind
of
touched
on
that
briefly,
when
our
live
demo
was
having
some
slight
pain.
So
it's
quite
it's
basically
a
job
in
Jenkins
for
them
to
go.
Do
this,
so
they
can
go
to
manage
travel
logic
and
basically
they
can
just
go
in
here
and
the
name
space
translates
to
their
name.
So
if
we
have
a
new
SC
Bob
who
joins,
he
would
enter
his
name
here.
Push
build
and
that's
going
to
translate
to
a
demo
earlier.
B
A
B
There
are
you
know
from
our
own
experience
with
using
them
on
a
single
repo
to
power.
This
all.
There
are
a
lot
more
hoops
and
hurdles
that
you
have
to
jump
through,
and
it
really
boils
down
more
to
what
Jenkins
does,
because
everything's
powered
in
Jenkins.
So
we've
had
to
develop
a
lot
of
like
custom
scripts
to
handle
various
things.
I
wouldn't
say
it's
as
flexible
there.
It
has
its
quirks
and
its
issues
there
we
thought
about
separating
it
out.
We
haven't
made
a
decision
either
way.
B
We
would
need
to
make
some
tweaks
and
some
changes
to
some
things,
just
a
pretty
some
things
up
a
little
bit,
arguably,
but
but
that's
something:
we're
not
against
I
think
that
we
could
certainly
look
at
doing
that
and
that's
something
we
can
definitely
take
back
to
the
team
and
talk
about
internally.
We've
talked
about
it
before,
but
I
think
we
should
maybe
take
a
harder
look
at
that
I
think,
particularly
if
you
can
run
into
your
own
environment
and
you
can
do
the
same
demo
with
Soumya
logic.
A
B
B
B
Have
a
single
cluster
right
now
for
the
production
environment
and
some
of
the
essays
who
want
to
build
more
things
and
kind
of
like
play
with
things
or
we're
going
to
you
know
play
with
upgrades
or
changing
a
technology.
We
have
a
dev
environment
that
we
use
for
that,
but
that's
a
limited
subset
and
that's
a
much
smaller
cluster,
the
production
environment
for
auto
scaling.
The
thing
to
remember
is
that
we're
not
it's
a
different
use
case.
It's
it's
not.
You
know
we're
not
like
having
a
huge
spike
in
traffic
like
regularly.
B
B
But
if
we
onboard
a
bunch
of
new
SES
like
we
might
have
to
go,
you
know
to
tweak
that
ourselves
that
there's
an
onboarding
process,
and
so
we
know
when
a
new
SC
comes
on,
we
can
kind
of
look
to
see
where
the
health
is
we
have,
and
in
that
same
environment,
that
I
demoed.
We've
got
some
monitoring
setup
internally
to
like
monitor
the
health
of
kubernetes,
making
sure
there's
no
issues.
If
there
are
issues
we
can
take
advantage
of
that.
B
If
Jenkins
is
running
inside
of
Huber
Nettie's,
so
we
are
running
Jenkins
within
kubernetes
kind
of
a
chicken
before
the
egg
thing
I
get
it
it's
work
for
our
purposes.
The
age
of
the
the
slaves
basically
come
online,
a
run.
What
we're
thinking
about
doing,
though,
is
running
Jenkins
on
an
ec2,
a
separate,
dedicated
ec2
instance
running
the
Jenkins
master
there,
and
just
opening
up
the
service
that
can
convey
that
so
that
we
can
deploy
the
pods
to
the
API
server.
We
there's
a
there's,
a
great
Jenkins
plugin,
so
we
use
it.
B
I
actually
don't
know
the
name.
It
was
just
like
the
Jenkins
kubernetes
plugin.
To
be
honest,
I,
don't
know,
there's
that
many
of
them
and
that's
what
we
take
advantage
of
so
does
it
does
everything
there
and
then
we
just
use
the
Jenkins
hound
chart
out
of
box
having
Jenkins
inside
of
kubernetes
has
some
flexibility,
but
you
sometimes
get
into
these
like
chicken
before
the
egg
problems
which
can
be
fun
to
deal
with.
That's
why
we're
thinking
about
moving
the
master
out
to
is
like
a
separate
ec2
instance.