►
Description
How to Clean Up Your DevOps Dumping Ground - Melissa Sussmann, Puppet
As the automation surface area grows to accommodate hundreds of interconnected APIs on the cloud, developers are using their own, home-grown “digital duct tape” to manage a growing “DevOps dumping ground”. For a lot of organizations, home-grown glue logic is inconsistent, not repeatable, and expensive to maintain hundreds of event-based workflows and thousands of combinations. We believe that the answer lies in automation workflows. In particular, workflows-as-code that can be triggered by events. We want to replace engineers’ home-grown digital duct tape with reusable, event-driven workflows.
In an effort to deal with ad-hoc deployments and devops infrastructure CI/CD management, many devs try to create their own one-off automation tools or integration hubs, usually per team or per project.
Examples include:
Using Lambda and writing functions for EC2 management tasks
Running scheduled jobs for EBS cleanup
Repurposing a CI/CD tool like Jenkins for incident response workflows
But this “dumping ground” current approach is Inefficient, expensive, and risky.
Inefficient because work is done as one-offs that last forever, no reusability or repeatability
Expensive because spending time building tools and integrations aren’t directly delivering customer value
Risky because sidestepping governance to get stuff done can lead to exposure and failures
This presentation from Melissa Sussmann at Puppet gives viewers a peek into the beta version of Relay, a product for managing containerized apps. This presentation goes over what the team has learned in the process of working on Relay, the underpinnings of the product, and demonstrates a few example workflows to help you save time and money.
A
Hello
cd
summit
folks,
my
name
is
melissa,
seussman,
I'm
from
puppet,
and
I'm
here
to
help
you
take
control
of
your
devops
dumping
ground.
So
over
the
past
five
years,
we've
been
seeing
a
shift
in
the
center
of
gravity
for
where
and
how
automation
happens
in
our
next
slide.
We're
going
to
see
a
really
fun
graph
about
this
cloud.
Adoption
has
shifted
to
the
center
of
gravity,
for
has
shifted
the
center
of
gravity
for
automation.
A
So
over
the
past
five
years
again,
we've
been
seeing
this
the
driver,
for
it
is
often
expressed
as
the
catch-all
phrase
of
moving
to
the
cloud,
but
cloud
is
often
more
of
a
catalyst
for
change
and
the
mechanism
for
it.
Overall
we've
learned
that
we
need
a
higher
level
of
abstraction
above
os
management.
A
What
puppet
brings
to
the
devops
world
for
os
management?
We
are
hoping
that
a
new
product
can
bring
to
the
api
management
via
workflows
as
code
in
the
data
center.
You
see,
obviously
a
model
and
task
driven
automation,
type
of
platform,
where
you
also
see
things
like
os
and
hardware
and
apps
and
you're,
using
the
hypervisor
layer
and
you're
spinning
up
vms
in
this
world.
You
know
configuration
management
is
king
and
puppet.
A
A
The
second
lesson
that
we
learned
is
that
events
are
everywhere,
so
even
a
subset
of
the
landscape,
that's
in
use
in
a
single
organization
can
be
pretty
complicated
and
increasingly
the
tools.
Basically,
they
talk
to
each
other
through
apis,
as
mentioned
in
the
first
slide,
generating
and
consuming
events.
So
the
emerging
practice
of
git
ops
is
a
great
example
of
this.
A
new
container
version
shows
up
in
a
registry
a
tool
like
argo
or
we
works.
Flux
gets
a
notification
that
it's
there.
A
The
tool
then
generates
a
pull
request
against
a
repo
containing
production
configuration
and
if
the
ci
tests
hooked
into
the
repo
pass
it'll
get
merged
and
deployed
automatically,
so
that's
great
at
a
certain
level
and
has
a
ton
of
benefits,
but
it's
also
insanely
complicated
as
I
as
mentioned.
Previously,
events
are
everywhere,
and
here
you
kind
of
see
just
where
they
can
all
come
from,
and
interoperability
here
can
get
really
complex
and
that's
just
one
example
of
an
event-based
workflow.
A
A
A
So
this
is
what
we're
calling
lovingly
the
devops
dumping
ground.
This
dumping
ground
approach
is
inefficient,
expensive
and
risky.
It's
inefficient
because
work
is
done
as
one
offs
that
don't
necessarily
last
forever.
They
have
no
reusability,
they
have
no
repeatability
it's
expensive
because
spending
time
building
tools
and
integrations
isn't
directly
delivering
customer
value
and,
of
course,
it's
risky
because
sidestepping
governance
to
get
stuff
done
can
lead
to
exposure
and
failures.
A
So
all
these
conversations
and
iterations
brought
us
to
the
idea:
that's
behind
relay
relay
listens
to
the
signals
in
your
existing
devops
tools,
infrastructure
and
then
triggers
workflows
to
orchestrate
actions
on
downstream
services.
So
this
adds
again
some
additional
layer
of
interoperability
and
it
adds
you
know
it
takes
away
some
of
the
risk.
A
For
example,
there
could
be
a
killer
process
for
provisioning
new.
You
know,
let's
say
new
lbs,
but
the
point
to
where
it
ends.
Someone
tends
to
have
to
pick
it
up
manually
and
carry
it
forward
to
say
close
the
ticket
that
started
the
request,
so
we
think
there's
some
value
in
being
able
to
link
together
those
incoming
actions
with
some
intelligent
decision
making
that
can
respond
automatically.
A
This
is
where
you
actually
see
more
of
that.
Let's
say
an
example
would
be
to
create
a
ticket,
and
then
you
could
do
a
bolt
run.
You
could
stop
some.
It
looks
like
eps
instances
or
do
some
ebs
cleanup.
Rather,
you
could
then
stop
aws
instances
notify
slack
update
your
focus
on
some
issue
that
might
be
happening
in
your
team.
A
So
basically,
this
is
the
code
that
underpins
the
graph
visualization
from
the
previous
slide.
It's
a
pretty
straightforward,
yaml
dialect,
because
that's
the
most
common
language
that
devs
seem
to
be
using
these
days.
It's
the
hip
new
lingo
yaml
has
basically
some
special
top
level
keys
for
parameters
to
be
filled
in
or
left
to
default.
If
unspecified
like
on
lines
4
through.
A
It
really
speeds
up
the
development
process
as
a
whole
and,
of
course,
we're
using
tekton
pipelines
to
help
us
basically
build
and
traverse
a
graph
of
steps
that
make
up
the
workflows
for
relay.
So
a
really
exciting
thing
about
tecton.
Many
of
you
are
already
familiar
with
it.
They're
really
important,
obviously,
to
the
continuous
delivery
foundation
it
uses
like
kubernetes
native
ci,
cd,
it's
powerful,
it's
an
open
source,
workflow
engine
and
it
basically
organizes
things
into
tasks
and
pipelines.
A
Different
tasks
into
a
workflow
and
basically
techton
is
tekton
pipelines
are
what
basically
help
us
build
and
traverse
a
graph
of
the
steps
that
make
up
the
workflows
for
relay
so
relay
uses
that
each
step
is
basically
a
container
execution
and
that
can
be
an
off-the-shelf
container
to
run
scripts
or
talk
to
remote
apis
or
one
that's
built
with
the
relay
tooling
layer
to
access
and
modify
the
state.
That's
passed
around
through
the
workflow's
life
cycle
to
go
into
this
a
little
bit
more.
A
So
once
a
workflow
kicks
off,
the
steps
are
run
in
order,
and
this
is
where
tekton
comes
in
and
we'll
we'll
talk
about
that
in
a
minute.
The
steps
themselves
are
responsible
for
doing
the
work
and
in
the
workflow,
and
they
basically
contact
external
service
apis
and
process
the
data,
so
the
main,
basically,
the
downstream
services
here
are
where
that
workflow
execution
happens.
A
A
A
A
Just
loading
the
whole
slide,
so
we
basically
have
three
types
triggers
help
set
up:
containers
on
gke
to
respond
to
incoming
events,
which
can
extract
values
from
the
incoming
events
to
fill
out.
The
workflow
parameters
relay
then
uses
tekton
pipelines,
as
mentioned
previously,
to
build
and
traverse
a
graph
of
actions
and
queries
that
make
up
the
workflow
itself.
A
A
We've
also
got
support
for
query
steps
which
can
be
used
for
things
like
manual
approval
or
pause
workflow
execution.
Until
some
external
callback
happens.
This
workflow
visualization
shows
a
few
of
these
actions
through
the
web.
App
the
ec2
reaper
workflow
is
based
on
an
internal
puppet
tool
that
our
sre
team
uses
to
traverse
the
ec2
accounts
for
instances
that
aren't
tagged
with
cost
center
properly
and
then
terminates
the
rogue
ones.
A
A
Many
of
the
examples
we've
been
working
with
use
the
upstream
containers
like
vanilla,
ubuntu
or
terraform,
and,
if
you're
building
something
that
you
want
to
be
part
of
the
ecosystem,
we're
always
trying
to
build
a
really
great
authoring
experience
for
steps.
Recently,
we
changed
our
authoring
experience
and
it
makes
it
really
easy
to
just
get
started.
A
One
of
the
really
great
benefits
of
basically
using
this
is
that
we
have
low
friction
interoperability.
So
again,
this
goes
back
to
the
point.
If
you
have
existing
containers
that
you
want
to
use
in
relay
workflows,
you
can
just
drop
them
right
in
alongside
purpose-built
integrations
you
could
you
should
visit
github.com
relay
dash
integrations
if
you
want
to
take
a
look
at
the
list
of
different
integrations
that
we
have
in
a
minute.
A
So
I
have
now
logged
into
my
account.
I
didn't
want
to
share
the
credentials
with
anyone
or
necessarily
the
process
of
it
with
anyone
publicly,
but
you
get
to
see
what
my
account
looks
like
you
get
to
see
some
of
the
like
most
commonly
run
workflows
and
we
can
just
start
running
a
test
and
you
can
see
how
easy
it
is
to
start
one.
A
A
Already
you
can
see
that
there's
sort
of
a
hello
world
example
design.
That's
in
here
and
here
we
we
have
some
explanation
of
what
you
might
want
to
use
for
like
parameters,
and
we
also
point
to
a
library
of
pre-configured
web
hook.
Red
hook
triggers
that's
available
for
common
integrations
over
here.
A
A
A
A
A
If
you
wanted
to
also
reach
out
to
me
with
any
additional
questions,
my
email
is
there.
Mine
is
super
long.
Canis
is
the
product
manager
and
his
is
super
short
and
so
is
eric,
because
he's
been
a
puppet
such
a
long
time
and
he
does
such
an
amazing
job.
Eric
is
the
technical
product
manager
and
feel
free
to
reach
out
to
any
of
us,
with
any
questions
that
you
might
have
about
relay.