►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi,
everyone
welcome
to
the
cncf
end
user
launch,
where
we
explore
how
the
cloud
native
technologies
are
adopted
by
end
user
organizations
across
different
industries
and
sectors.
The
cncf
end
user
community
is
formed
of
more
than
160
vendor
neutral
companies
that
use
open
source
software
to
deliver
their
product.
I
am
abubakar
city
angle,
I'm
a
cncf
ambassador,
and
today
with
me,
I
have
dumped
the
bus
calling
as
a
guest
speaker
in
these
live
streams.
A
We
bring
end
user
members
to
showcase
how
the
organization
navigates
the
cloud
native
ecosystem
to
build
and
distribute
their
services
and
products
join
us
every
fourth
thursday
at
9
00
am
pt.
This
is
an
official
live
stream
of
the
cnc
event
as
such
is
subjected
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
will
be
in
violation
of
that
code
of
conduct.
Basically,
please
be
respectful
to
all
of
your
fellow
participants
and
presenters.
A
A
This
week
we
have
dom
de
pascali
here
with
us
to
talk
about
how
linkedin
enables
the
software
engineering
team
at
penn
state
university
to
quickly
troubleshoot
performance
issues
when
sending
68
000
coffee
test
invites
to
students,
faculty
and
staff.
Member
earlier
this
year
before
we
dive
into
the
questions,
come
to
pascalli,
introduce
yourself
and
your
organization,
your
workforce.
B
B
It's
a
couple
years
ago,
fewer
less
than
five,
but
I
don't
remember
exactly
when
and
cloud
native
journey
we
we
wanted
to
get
into
containerization
and
and
at
the
time,
I'm
not
even
sure
we
were
thinking
about
kubernetes
yet,
but
we
were
getting
close.
The
idea
of
breaking
out
our
monolith
into
microservices
is
what
we
wanted
to
do.
B
Eventually,
we
fell
into
kubernetes,
and
this
was
early
on
kubernetes
when
we
didn't
have
a
lot
of
great
packages
for
deploying
it
and
kubernetes
provided
systems
like
eks
aks
gke
they
weren't
available
at
the
time.
So
we
were,
we
were
young
in
the
process
when,
when
it
first
came
out
and
yeah,
we
we
wanted
to
get
there
because
of
the
we
wanted
to
build
that
microservice
architecture
out
wow.
A
B
Sure
so,
like
I
mentioned
kubernetes,
we
dockerize
everything
now
we're,
I
believe,
100
our
apps
are
100
containerized
at
this
point,
and
I
mentioned
active
mq
and
postgres,
but
we
also
use
a
lot
of
the
other
native
like
the
tools
that
are
kind
of
native
to
that
kubernetes
landscape,
which
include
prometheus
and
alert
manager
and
cloud
auto
scaler
for
ek,
or
it's
not
cloud
outer
scale
anyway,
the
auto
scaler
for
eks
and
other
other,
like
kubernetes
native
things.
Oh,
I
use
prometheus.
B
A
B
B
I
ended
up
just
I
cherry
pick,
videos
after
they
get
posted
on
youtube
and
I
usually
focus
on
security
related
things
like
the
best
practices
of
not
just
arbok
but
pod
security,
so
security
contacts
and
getting
into
emission
controllers
with
opa
and
gatekeeper
things
like
that
are
currently
my
interest,
the
other
big
interest
that
I'll
focus
on
in
videos
for
that
is
cve
scanning
of
live
pods
or
at
least
the
pod
definitions.
So
you
could
get
a
good
idea,
especially
when
it
relates
to
things
like
log4j,
maybe.
A
A
B
Well
nicely,
luckily
enough,
we
had
all
the
infrastructure
as
code
in
place
to
to
tear
using
terraform.
We
tear
you
know,
terraform
this
entire
environment,
utilizing
eks
to
build
that
platform
within
a
matter
of
hours
or
days
so
like
we
had
kubernetes
and
everything
we
needed
up
and
running
with
no
time
at
all,
and
because
we
have
that
cloud
native
platform
that
kubernetes
platform
and
everything
that
goes
around
with
it,
we
were
able
to
deploy
apps
very
quickly.
B
Well,
we
wrapped,
we
chose
linker
d
a
little
while
ago,
and
it's
just
our
default
now
there's
there
are
only
exceptions
to
using
linker
d.
Otherwise,
it's
it's
there,
and
so,
when
we
built
this
new
covet
environment,
one
of
the
first
things
that
gets
installed
is
linker
d,
so
automatically
all
the
new
apps
we're
getting.
B
A
B
Originally,
we
were
on
istio
and
this
I
can't
remember
how,
many
years
ago,
two
or
three
three
or
four
years
ago
and
my
team
went
to
kubecon
in
the
fall.
I
forget
what
year
it
was,
and
they
got
to
see
the
presentation
by
william
from
buoyant
and
they
fell
in
love
with
the
idea
that
it
was
everything
you
needed
out
of
a
service
mesh
without
the
complexity,
and
that
that
meant
that
it
meant
a
lot
to
us.
A
B
B
It
helps
sell
its
importance
to
you
know
the
bureaucrats
of
the
university,
so
let
them
know
that
this
is
not
just
an
open
source
project
that
we're
pulling
in
like
a
library.
This
isn't
like
a
big
deal
to
many
many
organizations
so
yeah.
It
was
like
a
feather
and
a
cap
for
them,
but
it
was
important
for
us
them
being.
You
know,
linker
d,
but
it
was
important
for
us
to
as
users.
B
B
B
A
B
B
Internal
so
like
we
bring
in
new
products,
even
if
it's
prometheus,
it's
kind
of
already-
I
don't
say
it's
built
into
kubernetes,
but
it's
it's
there,
like
everybody
knows
it's
going
to
be.
There
like
having
folks
know
that
they
can
get
metrics
about
their
deployments
and
things
like
that.
It's
a
learning
curve,
it's
just
yet
another
tool
tool
to
learn
when
they
were
used
to
coming
from
older
systems
or
or
maybe
no
metrics
available
at
all
of
some
other
systems
right.
B
A
A
B
B
Name:
space
splits
after
that,
based
off
of
project
or
whatever,
but
in
the
future
we
are
going
to
a
multi-tenant
deployment
and
we
are
going
to
be
worried
about
things
like
sharing
resources
and
network
policies
and
rbox
security.
All
this
kind
of
good
stuff
to
you
know,
share
the
resources
as
well
as
we
can
and
also
keep
each
other.
You
know
projects
secure
from
each
other
yeah,
even
though
that
sounds
mean.
B
B
All
versioned
and
taken
care
of
there.
As
far
as
testing
that
changes,
like
I
mentioned,
we
have
a
non-production
cluster
that
gets
all
the
changes.
First
on
prem
we
use
cube
spray
currently
to
manage
cluster
upgrades.
So
that's
that's
more
human
involvement
there
other
than
just
a
terraform,
apply
and
kick
your
feet
up,
but
you
know
eventually
we'd
like
to
do
more
eks
and
less
cube
spray.
B
B
So,
as
I
mentioned,
we're,
we
have
a
big
presence
on
prem
on
top
of
vmware
for
our
clusters,
and
our
plan
for
2022
is
to
migrate
to
a
eks
for
all
of
our
kubernetes
clusters.
Okay,
at
least
we
haven't,
found
a
situation
where
we
have
to
stay
on
prem.
Yet
there's
always
that
possibility,
but
we
haven't
found
it
so
more
managed
services
still
kubernetes
and
we're
bringing
more
more
groups
within
the
university
on
board.
A
B
You
begin
to
realize
when
you
make
things
so
complicated
that
people
can't
get
their
job
done,
that
maybe
things
are
too
locked
down
or
too
stiff
to
use
and
what
we
did
to
begin
with.
Like
we
really
trained,
we
tried
to
train
everybody
to
use
cube
control
for
all
their
work,
so
if
they
want
to
see
the
status
of
their
pods
wanted
to
see
their
logs,
we
expected
them
to
do
everything
via
you
know:
command
line.
A
B
And
as
we
matured
like
we
put
metric,
we
created
a
lot
of
grafana
dashboards,
so
you
can
see
the
status
of
your
deployments
that
way
we
shared
splunk
searches,
so
you
can
just
use
splunk
for
your
logs
search.
Is
there
I
think?
As
far
as
the
evolution
of
the
clusters,
we
I
think
we
learned
that
a
lot
of
people
are
still
dependent,
I'm
not
dependent.
I
prefer
not
to
use
the
command
line
for
everything.
A
Yeah,
that's
good
and,
like
you
mentioned,
you've
been
creating
instrumentation
around
to
make
it
easier
for
your
team
to
interact
with
the
clusters
like
how
do
they
currently
okay,
you've
already
said,
you
don't
use
the
cli,
because
a
lot
of
them
shy
away
with
it.
What
other
ways
have
you
provisioned
to
enable
them
easily
interact
with
the
clusters
and
was
like
the
typical
lifecycle
of
application,
deployment,
maintenance
and
troubleshooting
for
your
team.
B
All
right
so
the
way
that
our
folks
interact
like
to
actually
make
change
to
the
cluster.
We
follow
strict,
get
ops
methodologies
in
our
department
and
we
use
flux
for
that.
So
we'll
have
our
I'll
just
tell
the
story
of
how
you
get
an
application
out
to
production.
I
think
that'd
be
easier,
so
yeah.
A
B
Make
changes
to
a
program
on
my
laptop
and
it's
it's
good
to
go
and
I've
tested
it
in
mini
cube,
because
we
wrote
a
tool
that
will
automatically
compile
dockerize
and
deploy
in
the
mini
queue,
so
you
can
test
it
locally.
Yeah
from
there.
The
git
push
into
the
our
git
lab
repositories
will
trigger
pipelines
to
do
that
same
work
again,
and
it
also
does
a
bunch
of
you
know.
Cbe
scans
of
the
of
the
docker
container
run
sonar
cube
against
the
code,
all
that
kind
of
good
stuff
yeah.
B
Eventually
it
creates
a
docker
image
in
a
docker
registry
yeah
from
there
we
have
flux
watching
those
registries
for
updates.
So
we
do
automatic
deployments
of
non-production
services.
So
hopefully,
at
that
point
with
everything
being
good,
the
you
know,
non-production
deployments
are
automatically
updated
and
running
and
either
developer
and
external
user
can
start
testing
that
within
a
reasonable
amount
of
minutes
for
production,
we
do
merge,
request
only
changes.
B
A
B
A
A
B
B
Wonderful
and
and
of
course,
just
going
to
regular
sessions
where
you
can
learn
about
something
new
like
when
our
folks
went
to
the
link
or
d
session
and
learned
about
that.
It's
all,
but
very
positive.
I
also
really
enjoy
it
could
be
overwhelming,
but
the
cncf
landscape
map
is
super
helpful,
like
I
don't.
I
don't
know
if
that's
everybody's
experience,
but
to
have
that
one-stop
shop
about
trying
to
find
a
tool
to
help
solve
a
problem
that
that's
really
convenient.
A
B
B
I
tend
to
keep
going
down
those
paths
of
of
security
related
tooling
for
cloud
native
yeah
now
I
know
there's
also
parts
of
my
team
that
are
looking
at
switching
from
active
mq
to
more
of
a
cloud
native
messaging
platform
as
well,
and
I
think
I
mentioned
cubed
m
cube
mq,
but
yeah.
There
are
others
out
there
as
well.
A
A
B
B
We
were
trying
to
you,
know,
schedule
68,
000
students
to
hurry
up
and
get
logged
into
the
system
and
schedule
their
testing,
and
we
were
doing
it
in
batches,
maybe
a
thousand
per
so
many
minutes
or
per
hour
or
whatever
we
needed
to
get
it
all
done
in
one
day
I
think
was.
That
was
the
goal
though,
and
what
was
happening
is
every
time
we
unloaded
a
new
mass
of
notifications.
B
Students
would
log
in
and
bring
us
down,
yeah
so
long
story
short.
We
had
an
on-prem
resource
that
was
very
much
single
threaded
and
couldn't
keep
up
with
the
requests,
but
the
way
we
found
it
was
because
of
all
the
built-in
dashboards
that
linker
d
provides
okay.
So
we
we're
able
to
go
into
the
grafana
dashboards
for
link
or
d
and
find
like
all
right
well
service.
A
depends
on
b,
c
and
d
and
well
according
to
the
dashboards
d,
is
really
slow
extremely
late.
A
B
That
took
us
down
to
like
this
was
all
in
aws,
but
all
the
services
in
aws
depended
on
our
authorization
and
authentication
systems
on-prem,
okay.
So
then
we
jumped
down
to
on-prem
and
realized.
Oh
look,
and
we
also
have
linker
d
down
there,
so
we
and
we
started
digging
into
the
same
types
of
dashboards
for
the
on-prem
services
and
found
out
that
this
one
in
particular
service
was
causing
us
lots
of
problems
yeah
to
the
point
that
everything
was
backing
up
everywhere.
B
So
what
you
know
we
had
to
make
a
code
change
to
the
on-prem
service
to
to
remove
that
single
threaded
dependency
and
the
floodgates
opened
at
that
point.
But
without
that
you
know
the
ability
to
dig
into
the
microservices
and
find
out
who's
calling
what
and
which
of
the
downstream-
or-
I
guess
it's
upstream,
which
is
the
upstream
calls
as
being
slow
yeah.
You
would
lost
there's
no
way
like.
I
think
we
fixed
it
in
a
matter
of
an
hour
or
you
know
I
might
be
exaggerating.
A
Awesome
it
it's
nice
to
share,
I
think,
most
times
a
lot
of
companies
share
success
stories
and
it's
hard
to
hear
some
of
the
struggles
and
challenges
that
goes
into
getting
some
of
these
things
running.
Thank
you
very
much.
Sharing
that
yeah.
We
still
don't
have
any
questions.
Yet,
if
you
still
in
the
chat,
you
can
ask
any
questions.
A
B
A
A
Thank
you
very
much
everyone
for
joining
the
latest
episode
of
the
cloud
native
end
user
lounge.
It
was
great
to
have
them
talking
about
penn
state's
usage
of
cloud
native
technologies.
We
also
really
love
the
wealth
of
experience.
He
has
also
shared.
We
bring
to
you
the
latest
cloud
native
end
user
stories
on
the
fourth
thursday
of
the
month
at
9am.
Pt,
don't
forget
to
join
us
for
kubecon
cloud
nativecon
eu
on
may
from
may
17th
to
20th
of
2022
to
hear
the
latest
from
the
cloud
native
community.
A
Also,
if
you
would
like
to
showcase
your
usage
of
cloud
native
tools
as
an
end
user,
join
the
end
user
community
with
more
details
on
cncf
dot,
io,
slash,
end
user.
Also,
remember
the
cfp
for
kubecon
eu
is
ending
tomorrow,
so
get
your
talk
submitted
to
be
to
be
able
to
share
your
stories.
Thank
you
very
much.
Thank
you
very
much
for
joining
us
today
and
see
you
next
time.