►
From YouTube: Journey From On Prem to the Cloud with Kubernetes
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
So,
just
to
give
you
an
idea
of
what
we're
going
to
go
through
today,
I'm
just
posting
an
agenda,
and
basically
you
know
I'll
start
out
I'll.
Tell
you
a
little
bit
about
broadridge
I'll.
Tell
you
about
the
project
that
we
completed
we'll
go
through.
Why
we
made
the
switch,
how
we
prepared
the
process
we
went
through
from
moving
from
on-prem
to
the
cloud,
we'll
take
a
look
at
what
we
should
have
done
differently.
A
A
A
A
A
We
also
have
something
where
we
manage
shareholder
voting,
so
a
proxy
vote.
If
you
use
that
app
at
all,
that's
again
powered
by
broadridge
last
year
we
hosted
nearly
2
000
virtual
shareholder
meetings,
and
the
shareholder
meetings
are
something
that's
required
by
the
sec
a
lot
of
times
they
used
to
be
done
in
person.
A
You
know
whether
it's
at
a
small
venue
for
smaller
companies,
or
even
at
larger
venues
and
even
hotels,
things
like
that
for
a
larger
company,
it's
where
the
board
will
go
through
their
annual
meeting
they'll
present
any
information
that
needs
to
be
presented
and
then
they'll
hold
their
voting
well
because
of
the
pandemic.
Obviously
this
was
still
a
requirement,
but
people
were
able
to
take
advantage
of
a
broader
service
that
we've
had
for
years
and,
like
I
said
there
was
over
2000
meetings
that
were
held
last
year.
A
A
A
A
A
A
Now
some
of
that
was
done
by
the
devops
teams,
but
some
of
that
was
done
by
the
development
teams,
but
still
everything
interacted
and,
like
I
said
mostly
vms.
But
there
were
some
agents
that
were
running
in
aws
and
we
even
had
some
older
agents
that
were
running
things
like
solaris
and
these
agents
were
located
all
around
the
world.
A
A
So
if
you
use
pods
instead,
you
can
put
in
different
containers
that
are
required
within
the
pod.
So
if
I
have
one
team,
that's
building
with
certain
software
and
then
does
testing
with
other
software,
I
can
easily
swap
in
and
out
different
containers
and
in
the
pods
to
accomplish
that.
So
I
don't
have
to
worry
about
having
everything
installed
beforehand.
A
A
So
in
preparing
for
the
project,
if
you're
doing
your
own
project,
the
first
thing
I
would
say,
is:
if
you're
going
to
move
to
kubernetes,
you
want
to
take
advantage
of
that
move
and
re-architect
what
you're
doing
now.
In
our
case,
since
we
were
using
a
third-party
application,
you
know
we
were
limited.
We
were
following
their
architecture,
but
if
you're
going
to
build
your
own
application,
that's
currently
on-prem
and
you're
going
to
move
that
to
the
cloud
or
to
kubernetes.
A
A
There's
a
lot
to
it
and
if
you
have
a
simple
application
that
maybe
just
needs
to
use
a
few
containers
or
could
even
go
serverless,
then
you
probably
should
consider
that,
in
my
opinion,
kubernetes
is
not
the
right
environment
for
doing
a
lift
and
shift,
and
I
know
there
will
be
vendors
that
will
tell
you.
You
know
we
can
lift
and
shift
and
it's
very
easy
with
kubernetes.
But
again
it
all
goes
back
to.
A
There's
an
expression
that
a
friend
of
mine
always
sees
to
say,
and
it
goes
something
like
fast,
cheap
and
good
pick
two
right,
but
the
idea
is
that
you
can't
do
a
project
fast,
cheap
and
good.
At
the
same
time,
it's
just
not
possible,
but
you
can
choose
fast
and
cheap.
You
can
choose
fast
and
good,
or
you
can
choose
good
and
cheap.
Now,
if
you're
going
to
be
going
to
kubernetes.
A
What
I
would
say
is
pick
good,
whether
you
pick
good
and
fast,
and
it's
going
to
be
a
little
bit
more
expensive
to
get
it
done
or
you
chip
cheat
or
you
choose
good
and
cheap,
and
it's
going
to
be
a
little
bit
slower
again.
Kubernetes
is
pretty
complex.
So
if
you're
going
to
go
that
route
choose
good
and
then
one
of
the
other
two.
A
All
right
when
it
comes
to
preparation,
there's
an
expression
rockets
are
hard,
and
you
know
if
you're,
following
all
the
commercial
space
travel
that's
going
on.
I
think
thursday
there's
actually
another
spacex
launch
along
the
way.
You
know,
there's
a
lot
of
mishaps,
a
lot
of
testing
a
lot
of
explosions
and
a
lot
of
times.
When
that
happens,
you'll
you'll
see
tweets.
That'll
say
you
know.
Rockets
are
hard.
A
A
A
And
as
part
of
the
process,
you
want
to
document
what
you're
doing
you
want
to
review
it,
and
you
want
to
test
it.
So,
like
I
said
with
the
mvp,
you
want
to
do
a
quick,
poc
and
test
your
assumptions,
and
we
actually
did
that
early
on.
We
were
thinking
of
using
one
type
of
file
system
and
then,
after
doing
some
testing
and
running
through
it,
we
realized
it
wasn't
going
to
work,
and
so
we
switched
that
up
and
we
ended
up
using
something
different.
A
So
it
was
good
that
we
did
this
poc
up
front
before
we
got
too
far
down
the
line
and
then
it
would
be
harder
to
make
changes.
What
I
would
say
is
use
the
native
services
whenever
possible.
So
a
lot
of
these
cloud
providers
have
native
services
like
storage,
like
databases,
you
know
figure
out
what
cloud
provider
you're
going
to
use
and
then
embrace
those
native
services
and
use
them.
It's
going
to
help
you
tremendously
when
it
comes
to
being
able
to
manage
and
scale,
and
even
do
things
like
dr.
A
You
know.
On
the
one
hand,
it
may
be
interesting
to
use
a
database
for
some
of
the
storage
and
then
maybe
use
a
network
file
system
for
other
stuff
and
then
maybe
ssds
for
a
third
of
your
storage,
but
then,
when
it
comes
time
to
do
disaster
recovery,
when
it
comes
time
to
do
backing
up,
you
have
to
figure
out.
How
am
I
going
to
do
all
that?
How
am
I
going
to
keep
it
in
sync?
How
long
is
going
to
take
to
do
that?
How
long
does
it
take
to
restore
that?
A
You
may
make
different
choices
in
your
architecture
than
if
you
have
a
product
that
you
just
have
to
back
it
up
once
a
day
and
that's
fine
now
keep
in
mind
as
part
of
the
cloud
you're
following
a
shared
responsibility
model
the
code
and
data,
the
operating
system,
a
lot
of
times.
It's
your
responsibility.
A
You
know
some
of
the
serverless
functions.
You
don't
have
to
worry
about
the
os,
but
still
have
to
worry
about
the
code
and
the
data
and
that
the
cloud
is
not
magic.
So
because
of
the
shared
responsibility
model,
you
still
have
to
make
sure
that
you're
doing
proper
security,
you're
doing
proper
monitoring
and
you're
doing
proper
backups.
A
A
A
Now
the
idea
behind
this
is
you
want
to
push
your
problems
to
the
left
again,
another
common
thing
in
devops,
meaning
that
when
you
have
your
configuration
as
code,
you
work
your
problems
out
in
your
dev
environment
and
you
get
it
right
in
once.
That's
done,
you
check
it
in
you
capture
it,
and
then
you
go
on
to
qa.
A
A
Generally,
what
happens
is
you
know?
You've
got
a
fire
drill
right.
You've
got
customers
that
are
now
impacted.
You've
got
to
get
all
these
teams
together.
You
got
to
figure
out
a
fix.
You've
got
to
push
the
fix
quickly,
try
to
test
it
quickly
where,
if
that
same
problem
is
found
in
dev,
the
developer
can
pretty
much
fix
it
by
themselves.
They'll
just
check
it
in
it'll
run
some
tests
again,
and
you
know
it's
it's
a
lot
easier
to
handle.
A
You
know
where
we
don't
necessarily
have
certain
types
of
resources,
we're
able
to
bring
them
in
as
consultants
or
even
some
of
the
people
that
we
buy
products
from
you
know.
They've
got
a
lot
of
knowledge.
For
example,
working
with
caston
they've
got
a
lot
of
really
good
kubernetes
people,
they
understand,
storage
and
backup.
A
A
A
A
So
if
you're
not
familiar
with
helm
and
you're,
deploying
a
kubernetes,
you
really
want
to
become
familiar
with
home.
It'll
become
your
new
best
friend
when
it
comes
to
kubernetes.
Now,
as
a
package
manager.
What
happens
is
you
know
you
might
think
of
installing
software?
You
know
if
you're
into
linux,
rpms
or
packages
with
windows.
There's
the
windows
installer
the
msi
file
well
with
kubernetes,
it's
very
similar.
A
A
A
There
were
different
secret
managers,
dns
all
that
good
stuff,
even
caston,
had
an
helm
chart
a
datadog
had
a
helm
chart,
so
we
were
able
to
take
advantage
of
all
that.
You
know
we
didn't
reinvent
the
wheel.
We
didn't
write
those
ourselves.
We
just
used
the
third
party
charts.
We
obviously
reviewed
them
made
sure
that
they
did
what
we
needed
to,
but
then
we
were
able
to
take
advantage
that
more
quickly.
A
A
The
other
thing,
I
would
say,
is
our
mvp.
We
should
have
defined
less
features
up
front.
You
know
created
a
smaller
mvp
and
got
people
using
it
sooner.
So
you
know
one
of
the
things
we
wrestled
with
was
okay.
If
we
give
this
to
people
now
and
they
start
using
it,
but
we
don't
have
everything
in
place.
Are
we
gonna
get
caught?
A
You
know
with
a
problem
and
then
not
be
able
to
service
them
properly,
and
so
we
put
in
more
features
and
tried
to
do
more
things
where,
if
I
were
to
do
this
again,
what
I
would
say
is
you
know
we'll
we'll
put
the
basic
features
in
up
front,
we'll
work
with
some
of
those
customers
and
basically
tell
them.
Look
it's
not
ready
for
production,
but
we
really
need
to
do
some
basic
stuff
with
it.
A
A
We
also
built
a
bunch
of
reusable
helm
charts.
So
again,
you
know
we
needed
monitoring,
we
needed
backup.
We
needed
a
dns,
we
built
out
those
charts
and,
as
we
were
building
them,
we
built
them
in
such
a
way
that
they
were
reusable.
So
other
teams
are
now
pretty
much.
They
can
drop
them
right
in
and
get
going.
A
We
we
wrap
third-party
home
charts.
So
my
background,
I
I
was
working
on
chef
before
working
on
this
project
and
so
there's
an
idea
in
chef
about
wrapping
third-party
cookbooks
and
basically
what
that
means
is
that
you're
going
to
take
a
cookbook
somebody
else
wrote
you're
going
to
not
change
it,
but
you're
going
to
write
your
code
around
it
and
include
included
in
your
code
and
this
way
it
makes
it
easy
to
maintain.
So
I
add
my
logic
and
my
data
to
my
cookbook.
A
So
we
took
that
same
technique
and
we
wrapped
third-party
helm
charts.
So
again,
when
nginx
ingress
comes
out
with
a
new
chart,
we
can
just
drop
their
new
chart,
their
new
version
into
our
chart,
and
you
know
maybe
we
have
to
update
some
values
or
things
like
that,
but
we
don't
have
to
port
any
patches
or
anything
like
that.
So
it's
a
good
technique
to
use
along
those
same
lines.
A
A
A
So
you
might
ask:
what's
next
well,
like
I
said
before,
you
know:
we're
migrating
our
internal
customers
to
the
new
platform
and
that's
ongoing
and
that's
going
to
take
a
while
scaling.
You
know,
scaling
is,
is
still
something
we
we're
going
to
have
to
work
out
as
we
move
more
and
more
of
these
customers
onto
this
platform.
A
Automating,
the
testing.
You
know
the
cicd
pipeline,
it's
great
if
you
can
build
stuff
automatically,
but
the
goal
is
not
only
building
it
but
being
able
to
automatically
test
it
and
then
automatically
deploy
it.
So
you
know:
we've
gotten
good
at
the
build
part
now
we're
working
on
the
automated
testing
part
and
then
we
can
get
to
automatically
deploying
things.
A
A
A
So
that's
something
to
keep
in
mind
right
as
you're
building
your
team
as
you're
bringing
new
technologies.
As
you
start
out
with
that
small
group
you
want
to
bring
people
on
who
can
then
help
spread.
The
word
right
you
want
to
be
able
to
take
your
techniques,
take
the
right
way
of
doing
things
and
push
that
out
company
wide.
A
So
that's
really
it.
As
far
as
my
presentation,
I've
talked
about
some
different
technologies,
and
so
here's
just
a
reference
again
helm
is
really
the
package
manager
for
kubernetes
that
we're
using
terraform
if
you're
familiar
if
you're,
not
familiar
with
terraform
terraform
allows
you
to
deploy
infrastructure
to
develop
infrastructure
as
code
and
it's
used.
You
know
in
our
case
we
use
it
with
aws,
but
they've
got
different
modules
for
other
cloud
providers.
They
even
have
some
helm
and
kubernetes
modules.
So
it
gives
you
a
lot
of
flexibility.
A
Eks,
amazon,
eks,
that's
amazon's,
managed
kubernetes
service
cloudbees
is
what
I
talked
about
as
far
as
cloud
bci
and
cd.
The
two
products
that
we're
using
for
continuous
delivery,
continuous
integration
casting
was
the
backup
project
that
I
a
product
that
I
talked
about.
Aqua
security
is
what
we
use
for.
Container
security
and
data
dog
is
used
for
monitoring.