►
From YouTube: How CNET (And Friends) Use the CNCF Landscape To Run High Traffic, Dynamic... - Corey McGalliard
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
How CNET (And Friends) Use the CNCF Landscape To Run High Traffic, Dynamic, Scalable, And Cost-Effective Websites. - Corey McGalliard, Red Ventures
Speakers: Corey McGalliard
CNET is no stranger to the world of containers; having been an early adopter of Docker Swarm, we've been using containers for many years! Recently, we migrated our workloads to Kubernetes, and the CNCF ecosystem has been a core component of our tech stack. As we started our application modernization initiative, we quickly realized by utilizing tools like Prometheus, Cert-Manager, External DNS, Traefik Ingress controller, Open Policy Agent, and others, we could give our developers a robust environment. The Kubernetes-based platform is not only for Production but Development Environments as well. The consistency between environments has kept our error rates down and websites up! Let's look at the flexibility the open software platform has given our developers! Let's take a journey from the perspective of a requested change on the front door of the website! First, a Product Manager makes the request, then we can see how a developer makes the change to the codebase and how quickly we can give the product manager a sandboxed environment to validate the requested change. the whole process takes only a few minutes. All of this is possible using open technology and our cloud provider. Let us show you how these tools work together to accomplish this flexibility and scale!
A
Hey
thanks
for
coming
to
my
talk,
I
try
to
go
for
the
longest
title
award,
I
think
this
year,
how
I've
seen
that
in
friends,
use
cncf
landscape
to
run
high
traffic
Dynamic
scalable,
cost-effective
websites
also
just
went
for
all
those
great
bud
buzzwords
right.
My
name
is
Corey
McGalliard
I'm,
an
engineering
manager
for
a
company
called
Red
Ventures,
probably
the
largest
Media
Company.
You've
never
heard
of.
We
haven't
seen
that,
but
also
quite
a
few
other
large
websites.
A
You
can
go
check
out
the
website
later
to
learn
about
us,
but
but
I've
been
with
CNET,
specifically
for
about
three
three
and
a
half
years
now
and
seeing
that's
been
around
for
a
while,
it
started
in
1994..
I
was
originally
a
Ted
network.
Not
a
lot
of
people
actually
realized
that
we
started
with
the
focus
on
TV
and
then
shifted
to
a
web
presence.
A
Afterwards,
we
see
about
45
billion
requests,
monthly
at
Edge
and
10
billion
requests
at
origin
per
second,
which
is
probably
a
metric,
we're
more
comfortable
with
that's
20
000
requests
a
second
and
five
to
ten.
Depending
on
the
metric.
You
look
at
down
to
the
actual
containers
at
origin.
Right
CNET
has
a
rather
long
history
of
acquisition,
so
starting
in
94,
they
started,
gobbling
up
Brands
and
then
was
purchased
by
CBS
Interactive
in
2008,
and
then
when
I
joined,
CBS
Interactive
in
2009,
they
were
being
a
choir,
sorry
2019.
A
A
A
We
started
about
two
and
a
half
three
years
ago,
really
initiating
the
the
the
the
process
of
doing
this
and
the
first
few
things
I
think
everybody
will
like
agree
with
these
things.
They're
really
comfortable
with
we
see
it
is
super
flexible
platform.
Has
all
this
all
these
tools
available
to
it
and
there's
really
high
industry
adoption
for
us.
We
were
really
comfortable
with
containers.
A
We've
been
using
them
for
years,
so
the
step
into
kubernetes
world
was
actually
really
really
smart
and
easy
for
us
to
do
right,
but
then
what
really
kind
of
sold
it
for
us
is
managed
kubernetes
we're
in
Google.
So
we
get
what
I
consider
the
cream
of
the
crop
of
the
kubernetes
world
gives
us
visibility
and
control.
I
kind
of
I'll
share
I'll
share
with
you
in
a
bit
the
difference
between
what
it
was
like
to
live
in
a
Docker
swarm
world
and
manage
kubernetes
world
today.
A
A
But
it
doesn't
add
complexity
to
our
general
workloads,
and
we
can
also
interact
with
the
cncf
ecosystem,
which
is
probably
why
we're
all
here
right
and
additionally,
why
kubernetes
developer
and
customer
experience
our
Engineers
aren't
infrastructure
Engineers.
They
why
they
just
want
to
write
node
code
right
and
be
able
to
submit
containers
to
an
API
and
give
them
a
really
consistent
response.
But
you
also
see
how
flexible
we've
set
it
up
to
be
over.
A
The
last
couple
years,
so
this
is
what
Dr
swarm
looks
like
if
anybody's
never
used
it
from
a
node
perspective,
the
barrier
of
Entry
to
interact
with
swarm
meant
that
an
engineer
would
have
to
SSH
onto
an
onto
a
manager
node
and
run
commands
against
it
right.
So
we
could
get
really
good
information.
We
could
get
the
containers
that
were
running.
A
We
could
get
the
the
images
they
were
running,
how
many,
how
many
containers
were
running
and
stuff
like
that
it
was
visible,
but
for
our
general
day-to-day
Engineers
they're
not
going
to
wanting
to
do
this
moving
to
Google,
we
were
able
to
give
them
a
really
nice
dashboard
free
out
of
the
box
right.
So
we
can
see
the
containers.
This
is
actually
the
front
end
CNET.
By
the
way
we
could
see
the
the
containers
that
are
running
the
front
end.
A
You
can
see
the
resource
utilization
requests,
we're
over
provisioned
pretty
heavily
and
pride,
because
we
want
to
make
sure
that
y'all
get
really
good
experiences
as
you
hit
our
site
and
then
you
can
also
really
easily
get
to
logs
I
can't
see
my
pointer,
but
up
there
and
then
inside
the
containers
themselves.
You
can
see
not
only
the
entire
deployments
logs,
but
the
container
Logs
with
just
a
click
of
a
button
but
Additionally
you
have
the
ability
to
modify
your
deployment
really
easily.
A
We
don't
have
permissions
to
production
by
default.
We
have
to
request
that
right.
So,
even
even
me,
as
a
platform
engineer,
I
have
to
request
those
permissions,
but
what
this
has
allowed
us
to
do
is
to
give
us
a
really
easy
way
for
our
Engineers
to
make
the
same
request
and
then
adjust
scaling
on
scaling.
Events
like
if
we
hit
a
Black,
Friday,
Cyber
Monday.
We
can
prepare
for
that
or
if
all
of
a
sudden,
an
iPhone
gets
announced
and
we're
getting
more
traffic
than
we
anticipated.
A
This
is
The
Next,
Step,
really
kind
of
that's
like
the
way,
the
the
point
behind
why
we
chose
to
go
towards
gke
specifically,
but
this
is
our
cncf
tool
chain
and
a
couple
other
open
source
and
internal
tools
that
I
like
to
talk
about
today
and
we'll
get
into
those
details
in
a
minute.
So
let's
kind
of
put
that
together
right.
A
So
what
happens
is
like
you'll
start
with
a
slack
message
to
say:
hey,
can
you
can
you
take
a
look
at
this
ticket
and
then
we
go
to
the
ticket
and
it
might
not
not
necessarily
be
the
ticket
we
just
want,
but
it's
the
one
we
deserve.
We
validate
that
that's
on
April,
Fool's,
joke
business,
Comic
Sans
right
and
then
we
we
make
a
commit.
We
push
setup
to
get
and
we're
at
Jenkins
shop.
A
A
It
takes
all
of
five
minutes.
What's
nice
about
this,
this
isn't
running
locally.
This
is
running
into
kubernetes
inside
of
Google
cloud
and
then
I
can
give
that
link
to
a
product
manager.
The
product
manager
can
then
can
validate
what
they
requested
us
to
do
and
say
whether
or
not
is
what
they
wanted.
A
So
what
makes
all
this
possible?
The
first
thing
are
the
kubernetes
objects.
We
should
all
be
pretty
familiar
with
those
I'm
going
to
walk
through
them
kind
of
quickly,
just
to
kind
of
share
how
we
kind
of
structure
things
so
we'll
have
a
deployment
that
obviously
spins
up
pods
in
this
situation,
I'm
just
wanting
one
node.js
pod
next
to
an
nginx
pod,
that's
pretty
common
practice
right
and
then
the
next
thing
we're
going
to
have
in
between
those
pods
or
Services.
A
The
oddly
named
node
service
is
a
an
artifact
of
us,
using
Docker,
swarm
and
Docker
composed
and
how
you
name-
services
in
Docker
and
there's
configuration
typically
or
so
sorry,
so
that
that's
why
that's
named
that
way,
and
then
the
Ingress
that
allows
traffic
to
come
inside
the
cluster
and
flow
through
the
surfaces
to
the
Pod
so
kind
of
a
drawing
wise.
This
is
kind
of
how
it
works.
A
This
is
our
typical
kind
of
simplified
Ingress
definition
I'm
going
to
walk
through
all
those
annotations
which
that's
really
the
power
behind
the
cncf
world,
in
my
opinion,
is
how
we
can
quickly
pull
in
different
tools
and
augment
the
native
kubernetes
apis
and
then
also
there's
config
maps
and
secrets.
This
is
showing
a
secret
for
a
TLS
certificate.
A
So
that's
how
kubernetes
does
it
think
does
its
things,
and
these
are
our
internal
open
source
and
cncf
tools
that
we're
going
to
kind
of
walk
through
the
first
one's
helm,
for
us
really
is
obviously
a
package
manager
right,
so
anything
that
can
that
we
run
inside
of
our
clusters
kind
of
gets,
bundled
in
a
chart
and
helps
us
kind
of
move
those
deployments
into
the
cluster
we
like
it
because
of
the
deployment
history.
We
have
jobs
that
allow
us
to
look
at
the
deployment
history
and
roll
back.
A
What
what
I
appreciate
a
lot
about
Helm?
It
doesn't
just
capture
the
container
image
change,
but
it
captures
any
image
anything
that
changes
in
the
the
Manifest
itself.
So
if
I
make
an
Ingress
change
and
I
work,
it
right
and
I
have
to
come
back.
It's
really
easy
to
pull
back
that
config
change
and
then
also
gives
us
some
flexibility
in
the
Manifest
themselves.
How
many
people
are
setting
out
image
tags
today?
A
Right
so,
like
that's,
been
a
pattern
in
the
past
to
where
you
would
set
up
a
deployment
and
you
would
change
the
image
tag
based
on
using
a
said
command.
Helm
has
given
us
the
ability
to
really
easily
pass
values
down
into
our
manifest
and
make
them
really
really
flexible,
and
it
gives
us
the
ability
to
have
the
multiple
environments
based
off
of
one
chart.
A
A
It
was
really
really
flexible
and
easy
for
us
to
use
there,
but
we
brought
it
over
into
kubernetes
because
it
was
familiar
and
it
was
one
less
step
we
had
to
take
into
the
kubernetes
world
right.
It's
super.
We
use
it
similar
to
the
way
in
nginx
is
used
to
wear
its
host
and
path
based
routed.
So
once
a
request
gets
to
the
traffic
Ingress
load
balancer,
based
on
the
host,
that's
passed.
A
We're
able
to
pass
it
down
to
the
service,
that's
that
is
specified
and
also
supports
certificate,
cert
manager
and
external
DNS
and
gcp
load
balancing.
We
can
kind
of
see
how
that
works
here.
This
is
the
same.
Ingress
I
showed
you
guys
a
minute
ago
with
our
friendly
red
boxes
right,
and
so
we
have
the
Ingress
class
of
traffic
that
identifies
hey.
This
Ingress
is
is
associated
to
traffic,
and
so
traffic
starts
listening
and
paying
attention
to
this
Ingress
and
based
on
the
hostname
that
is
set
traffic.
A
A
So
now
we
we
have
the
application
running.
We've
got
our
cluster
and
our
load
balancer
listening
for
the
hostname
right,
so
we
technically
could
with
a
host,
hit
the
load
balancer
and
get
there.
The
problem
is,
we
don't
have
DNS
in
the
past,
I'd
be
a
support.
Ticket
external
DNS
allows
us
to
set
up
a
a
tool
that
will
automate
DNS
creation
for
us
right.
This
is
actually
a
configuration
on
the
external
DNS
service.
A
I
tell
it
my
cloud
provider
and
I
tell
it
the
gcproject.net,
and
then
this
is
kind
of
what
kind
of
allows
the
external
DNS
pod
to
make
some
DNS
changes.
So
external
DNS
comes
up
in
the
cluster,
it
doesn't
have
permissions
against
Google.
So
we
have
to
authorize
that
somehow
right
so
gke
has
a
has
a
feature
called
workload.
A
Identity
AWS
has
a
very
similar
tool
as
well,
but
workload,
and
it
allows
us
to
bind
a
kubernetes
service
account
with
a
Google
service
account
right
so
that
my
external
DNS
pod
can
inject
routes
or
inject
DNS
records
as
needed.
Business
authorized
to
do
that
in
inside
of
Google
Cloud,
based
on
the
same
Ingress
object.
I
created
earlier,
you
can,
you
can
use
external
DNS
or
external
DNS
a
couple
ways
we're
using
it
to
Target
a
host
name.
That's
pointed
at
a
load
balancer.
A
So,
what's
going
to
happen,
is
the
host
spec
on
the
on
the
Ingress
will
have
a
c
name
created,
pointed
at
my
target,
that's
listed
in
The
annotation,
and
so
that
takes
approximately
a
minute
and
a
half
at
most
for
that
to
propagate
right.
It's
five
minutes
is
the
default
to
say,
but
it
paying
attention
to.
It
is
really
really
fast,
and
so
now
we
can
get
traffic
to
to
my
containers.
To
my
workload
we
can
see
our
beautiful
comic
stands
and
that's
allowing
us
just
to
get
there,
but
the
problem.
A
The
next
problem
we
have
to
deal
with
is
certificate
management
right.
So
in
the
past
that
was
always
a
support.
Ticket
going
out
to
some
provider
filling
out
a
massive
form,
getting
an
email
stuffing
that
into
into
a
random
secret
somewhere,
putting
that
in
swarm
days
we
would
have
to
manually
put
that
into
a
secret
and
then
update
our
workload
in
order
to
like
pull
that
into
the
actual
application
certificate
manager.
Automates.
A
All
that
I
went
to
the
booth
earlier
this
week
and
and
thanked
those
guys
so
much
because
I
saved
about
a
month
and
a
half
Dev
time
annually,
just
by
automating
certain
rotation,
I,
love,
kubernetes,
cert
manager
may
be
my
favorite
tool
in
in
the
pool
chain:
no
joke,
okay,
so
cert
manager
very
similar.
You
have
some
containers
running
in
your
cluster
right
and
then
you
have
to
create
a
certificate
issuer.
Basically,
it's
an
issuer
that
points
at
an
essay
this
one's
looking
at
let's
encrypt
and
is
doing
DNS
challenge
authorization
right.
A
Why
that's
important
for
us?
So
you
can
do
HTTP
validation
where,
where
your
container
comes
up
and
it
comes
out
from
the
inside
and
it
validates
hey
yeah
you
own
that
domain.
But
we
do
a
lot
of
internal
work
right
because
we
don't
want
to
surface
the
front
end
Dev
version
of
the
front
end
of
CNET
and
Google,
scrape
it
scrape
it
and
then
kill
our
SEO
scores,
so
I'll
be
able
to
do
a
lot
of
internal
work
right.
A
So
we
set
up
the
cert
issuer
and
then
we
have
to
do
the
same
thing
with
cert
manager
to
tie
the
service
account
for
cert
manager
to
external
DNS.
I
mean
sorry,
it's
to
to
Google
service
account
so
basically
allowing
cert
manager
to
do
the
same
kind
of
DNS.
Writing
as
external
DNS
does,
and
what's
going
to
happen,
I
think
I've
got
this
okay,
yeah
sure,
so
the
we
specify
the
issue
we
want
to
use
and
we
set,
and
we
also
specify
the
TLs
information
under
the
host
of
the
TLs
information.
A
That's
the
sand
that
that
the
assert
is
provisioned
for
and
then
the
secret
name
is
the
name
of
the
the
kubernetes
secret
that
the
certificate
is
stuffed
into
right
and
so
yeah.
Let
me
walk
through
that
whole
process.
So,
what's
going
to
happen,
is
a
request
is
going
to
be
created
for
a
certificate?
A
Cert
manager
is
going
to
create
a
DNS
record,
an
Acme
DNS
record,
with
a
text
record
from
the
response
from
from
from
let's
encrypt
and
then
let's
encrypt
is
going
to
say,
hey
yeah,
you
own,
that
here's
a
certificate
and
it's
going
to
stuff
it
in
that
secret
right
and
then
there's
a
crd
available
with
cert
manager,
and
you
can
watch
it
happen
in
real
time
and
see
the
status
of
the
certs
and
then
once
that
all
happens,
the
cert
is
actually
inside
the
sequel.
So
what
was
really
beautiful
about
this?
A
For
those
of
us
who
care
about
mtls
or
certificate
validation
at
all
is
not
only
can
my
Ingress
use
this
or
any
other
object
inside
of
kubernetes,
but
also
my
pods
can
mount
them
as
actual
files.
So,
if
I
need
to
give
nginx
a
valid
certificate,
I
can
create
one
and
hand
it
to
it
or,
if
I
need
to
give
Envoy
proxy.
So
in
this
situation
we
give
it
both
to
nginx
and
to
traffic.
A
So
all
of
that
lets
us
put
Comic
Sans
on
a
temporary
environment
right.
So
that's
great.
That's
a
lot
of
work
to
get
Comic
Sans
out
there.
The
next
thing
that's
going
to
happen
is
the
engineer
is
going
to
go
to
the
product
manager
and
be
like
hey
look:
I.
Did
my
job
I'm
going
to
merge
this
pull
request
in
right
once
they
get
the
approval
and
then
we're
going
to
forget
about
this
environment
right
because
we're
terrible
at
cleaning
up
after
ourselves.
A
Everybody
agree,
so
we
wrote
a
tool
internally
called
deckhand
based
on
our
cscd
process,
and
this
is
a
process.
We
want
to
clean
up
and
automate
a
little
bit
better,
but
today,
based
on
our
cicd
process,
we
get
to
say
how
long
those
containers
run
and
we
said
a
day
and
what
we
do
is
we
create
a
config
map
that
has
a
special
label
on
it.
A
That
specifically
says
that
you
can
delete
this
thing
with
the
date
and
time
I'm,
okay
with
you
deleting
it,
and
then
we
have
a
Cron
job
that
runs
hourly.
Maybe
there
it
goes
a
Cron
job
that
runs
alley
hourly
to
validate
where
when
and
where
that
that
namespace
can
be
deleted.
Once
you
hit
that
Purge
date,
the
namespace
namespace
will
be,
will
be
cleaned
up
and
we've
cleaned
up
after
ourselves.
A
So
that's
really
how
our
ephemeral
environments
work,
I'll
talk
about
them,
the
move
to
to
prod
in
a
second,
in
all
of
our
environments,
we
have
very
similar
observabilities
to
actually
that's
Prometheus,
which
is
a
Time
series
database
that
allows
us
to
scrape
all
the
containers
and
in
our
cluster,
as
well
as
resources
outside
of
our
cluster.
We
use
it
actually
to
monitor
uptime
of
GCE
ingresses
as
well,
not
just
stuff
inside
of
our
cluster,
and
that
all
of
that
data
can
be
visualized
with
the
tool
called
grafana.
A
This
is
one
of
my
favorite
dashboards.
It
shows
us
latency
throughput,
that's
all
using
the
traffic
Ingress
controller
metrics
the
error
rates
as
well,
and
then
I
can
in
the
same
workload.
This
is
just
one
workload.
I
can
see
how
how
saturated
the
CPU
and
memory
is.
So
this
is,
if
you're
familiar
with
the
SRE
principles
of
the
golden
signals.
These
are
the
five
or
sorry
for
the
bottom.
Two
are
really
the
same.
It's
just
memory
and
CPU.
A
All
of
that
information
then
can
be
serviced
to
a
tool
called
alert
manager
which
allows
us
to
pay
attention
to
how
well
our
services
are
are
running
right.
So
we
can.
We
can
write
alerts
that
say
Hey
if
we
have
a
Delta
change
on
on
error
rate,
so
we
all
of
a
sudden
have
a
50
error
rate
increase
or
10
percent
error
rate
request,
increase
page
the
person
who
owns
this
service
or
memory
or
whatever
thing
you
care
about,
and
additionally,
we
are
investigating
on
all
of
all
this
together.
A
Looking
at
our
cloud
provider
Google
with
their
with
their
observability
tooling
as
well.
This
is
the
same
dashboard
reimagine
with
Google's
dashboarding
as
well,
so
it
so.
The
cool
thing
about
kubernetes
and
using
your
Cloud
providers
native
tooling,
is
that
we
have
like
crazy
visibility
into
our
workloads
today
right
and
we
can
see
when
things
are
going
well
when
things
aren't
and
we
can
be
alerted
on
them
as
necessary.
A
Okay,
so
I've
talked
about
a
Sandbox
environment
and
that's
probably
not
what
you
want
to
hear.
You
want
to
hear
what
we
do
for
production.
We
do
the
exact
same
thing.
All
the
way
top
to
bottom
development,
sandboxing
production,
the
only
things
that
change
with
these
things
right,
how
we
handle
internal
versus
external
traffic,
routing,
whether
it's
coming
through
an
internal
load,
balancer
external
load,
balancer
and
that's
usually
handled
with
annotations
on
Ingress
and
logic,
gates
and
helm.
How
we
handle
Redbook
accounts.
A
We
don't
run
one
pod
in
prod
right,
we're
going
to
run
close
to
a
couple
hundred.
We
also
open
up
resource
requests
and
limits
in
production
we
do
over
commit
because
we
want
to
make
sure
that
we're
not
throttling
the
application.
We
want
good
user
experience,
that's
more
important
than
being
really
really
tight
on
resource
utilization
and
then
workload
separation.
So
this
is
new
for
autopilot,
a
guy
I've
been
by
the
name.
A
William
Dennis
talked
about
this
last
kubecon,
where
you
can
specify
basically
create
ephemeral,
node
groups
based
on
a
label
you
put
on
your
workload,
so
that
for
say,
for
instance,
you
have
a
workload
that
is
your
your
back
end
workload
right
or
workload.
That
is
your
front
load
workload
and
you
want
to
make
sure
they're
separated
so
that
you
don't
have
Noisy
Neighbor
problems.
A
So
this
is
a
new,
a
new
feature,
but
also
the
idea
if
you've
not
read
about
openness,
I'm,
blanking,
pod,
anti-affinity,
there
are
ways
using
labels
to
say
based
on
the
name
of
my
pods
mix
or
try
to
separate
the
the
the
workload
across
multiple
nodes.
So
you
have
true
High
availability
having
50
pods
on
one
node
is
not
high
availability.
It's
not
the
same
thing
right,
so
we
want
to
make
sure
we
have
50
pods
on
10
nodes.
So
we
have
five
deep
across
across
our
cluster.
A
We
want
to
make
sure
they're
making
really
smart
decisions
and
not
running
his
route,
for
example,
and
also
mutating
web
hooks.
We
like
to
label
our
things
for
information,
so
we
can
force
with
mutating
web
hooks.
We
found
ways
we
can
force
some
labels
onto
some
workloads
so
that
we
are
able
to
follow
billing
costs
and
security
costs
and
stuff
like
Security,
Management
and
stuff
like
that
and
obviously
supply
chain
hardening
and
improved
observability.
It's
obvious
from
our
observability
slide.
That's
something
we're
currently
actively
looking
at
is.
A
How
do
we
look
at
this
stuff
in
in
a
much
much
better
way,
and
then
my
big
one
right
now
is
is
get
Ops
in
a
pool
mentality.
So
we
we've
come,
we've
been
around
for
a
long
time.
Push
mentality
has
been
around
for
a
long
time
right,
and
so
this
get
Ops
pulling.
The
changes
into
your
cluster
into
your
into
your
environment
is
new
and
it's
something
we're
investigating.
We
looking
at
Argo
and
other
tools
as
well
for
that.
A
A
So
cnet's
been
around
for
20
something
years
right,
but
I
was
almost
as
old
as
I
am,
which
is
kind
of
funny
and
and
fun
to
work
on
to
a
degree.
But
before
we
adopted
containerization
we
could
deploy
once
maybe
twice
per
week.
The
process
was
slow
and
tedious.
We
had
to
have
release
Engineers.
We
had
to
do
a
lot
of
coordination.
We
had
to
think
about
heavily.
A
How
do
we
take
this
change,
this
one
line,
change
and
March
that,
through
our
our
production
to
our
production
environment
right
today,
we
man
I,
don't
have
a
really
good
metric
because
it
varies
so
much,
but
we
deploy
anywhere
between
10
to
20
times
a
day
to
production
and
then
much
more
than
that
in
non-production
right.
So
we
can
make
a
change
in
hours
and
get
it
to
the
front
door
of
CNET.
That's
honestly,
the
big
value
proposition
for
all
of
this
tooling.
A
A
So
that's
why
I
like
it
and
also
yeah
and
also
have
been
a
huge
kubernetes
fan
for
years
and
I,
was
brought
in
to
do
this,
so
it
was
fun,
it
was
fun.
You
know,
that's
how
we
do
it.
If
you
have
any
questions,
I'm
more
than
happy
to
answer
as
much
as
I
can
sorry
for
the
vast
amount
of
yaml
and
speed,
we
went
through
that
yeah.
Let's
get
it
Mike,
okay,.
A
A
A
I'm,
not
really
on
that
team,
trying
to
think
of
the
name
of
the
Tool
there's
a
node
framework
that
they
that
they're
using
for
the
node
applications,
and
then
we
use
PHP
and
Symphony
quite
a
bit
and
they
have
some
Frameworks
around
that
too
I
know
those
tests
passed
and
fail
pretty
regularly
because
I've
seen
them.
But
it's
not
part
of
my
my
purview
right
yeah.
Another
question
yep.
C
A
On
how
we're
looking
forward
to
the
move?
Okay,
so
at
the
moment
we're
looking
towards
to
be
honest,
you
so
we
use
Jenkins
today
right
and
so
it's
been
around
for
a
while.
It's
going
to
be
a
slow
migration
out
of
that
for
us
most
likely,
we've
played
a
lot
with
Cloud,
build
and
Cloud
deploy
and
then
Argo
CD.
Those
are
kind
of
the
three
things
we're
kind
of
exploring
we'll,
probably
move
our
see
our
our
integration
pieces
to
Cloud
build
because
it's
native
to
what
we're
doing
and
it
ties
into
GitHub.
A
But
then
the
deployment
process
is
still
up
in
the
air
and
that's
really
going
to
be
us
just
kind
of
like
using
both
for
a
while
and
going.
We
like
this
one
better.
We
like
that
one,
better,
tecton,
no,
but
actually
I'm,
really
interested
in
flux.
After
watching
a
couple
of
demos
this
week,
just
to
be
completely
open,
I
think
is
a
cool
tool.
Yeah.
A
A
A
F
E
Also
are
compatible
with
like
exporting
and
importing
all
kind
of
Prometheus
metrics
to
other
Prometheus
and
senses.
Sure.
Would
you
consider
using
alert
manager
at
scale
for
everything
or
with
your
other
move,
the
other
way
around,
that
you're
taking
stuff
out
of
alert
manager
and
moving
it
down
to
a
managed.
A
I
I,
don't
they're
like
so
Black
Box
exporter
not
being
available
right
now,
with
with
managed
Prometheus
is
going
to
hurt.
Also
autopilot
doesn't
support,
managed
Prometheus
at
the
moment.
So
it's
going
to
be
a
minute
before
we
make
that
that
shift,
but
it
is
something
we're
exploring.
Does
that
make
sense,
he's
got
a
mic
right
behind
you.
G
A
So
we're
a
legacy
company
right,
so
we
have
a
VPN.
So
it's
it's
truly
internal
right,
but
IAP.
If
you
haven't
read
about
a
Google's
Service,
it
allows
you
to
expose
stuff
externally,
but
validate
a
Google
cap
before
you
get
into.
It
is
one
way
that
we
are
exploring
moving
away
from
that,
but
also
use
of
headers.
So
we
can.
We
can
do
some
header
magic,
but
we
we
can
flip
that
internal
external
flag
with
a
true
false
right.