►
Description
Have you started your Cloud Native journey? The first thing you need to do is containerize your applications. Now that you’ve gotten past that first hurdle, JJ Asghar is here to say there’s more to think about. In this talk, JJ discusses stumbling blocks that a masked enterprise called AsgharLabs had to deal with, and hopefully shed some light on things you haven’t thought about.
---
Jakarta EE gives developers a comprehensive set of vendor-neutral, open specifications that are used for developing modern, cloud native Java applications from the ground up. With Jakarta EE, technology developers and consumers can be confident they have the best technologies for developing cloud native, mission-critical applications. And they can build on decades of Java developer expertise to move existing workloads to the cloud.
Learn more: https://bit.ly/3IPrxOq
Follow us on Twitter: https://twitter.com/home
Follow us on LinkedIn: https://www.linkedin.com/showcase/jakartaee/
Like us on Facebook: https://www.facebook.com/JakartaEE/
A
He
mainly
focuses
on
the
ibm
kubernetes
service
and
openshift,
trying
to
make
companies
and
users
have
a
successful
onboarding
to
the
cloud
native
ecosystem
he's
also
been
known
in
the
devsops,
tooling
ecosystem
and
generalized
linux
communities
if
he
isn't
building
automation
to
his
work.
Streamlined
he's
building
the
groundwork
to
do
just
that.
If
you
have
any
questions
for
jj
as
we
move
through,
today's
presentation
feel
free
to
ask
in
the
chat
or
use
the
ask
a
question
tab
without
any
further
delay.
Jj
over
to
you.
B
Thanks
so
much
yes,
hello,
wow,
already
off
to
a
great
start
voice.
Cracking
thank
you
for
being
here,
if
you
wouldn't
mind
doing
a
plus
one
or
a
high
inside
the
chat
to
make
sure
I'm
coming
in
just
fine
for
y'all
and
I'll
slip
over
to
my
slides
here,
we'll
see
how
we'll
get
going
here
perfect.
Thank
you
dennis.
Also,
if
you
have
questions
while
I
actually
do,
this,
don't
hesitate
to
throw
them
in
the
chat.
B
While
I'm
speaking
I
like
to
have
an
interactive
conversation,
I've
been
told
that
I'm
a
whiteboard
presenter
where
I'm
I
come
in.
We
start
talking
about
it
and
whatever
the
questions
y'all
have
will
help
get
the
more
out
of
the
information
that
will
be
more
valuable
to
you.
My
slides
are
just
kind
of
like
an
outline
kind
of
keep
the
conversation
going,
but
if
you
have
questions,
please
don't
hesitate
to
post
them
and
I
will
do
my
best
to
tie
them
into
the
conversation.
B
B
If
I
can
ever
help
so
here
to
see
migrating
a
monolith
to
cloud
native
and
the
stumbling
blocks
you
might
not
might
might
not
know
about
it
might
be
that
you
don't
know
about
so.
Your
company
has
finally
just
decided
to
move
to
the
cloud
native
ecosystem.
You've
landed
on
containerization.
As
your
first
step.
You
heard.
All
you
need
to
do
is
containerize
your
first
app
push
it
to
kubernetes
open
shift
nomad,
and
this
cost
savings
will
just
come.
You've
done
this
and
well
things
just
haven't
gone
as
planned.
B
B
B
So,
let's
start
out
what
is
asgard
labs.
Asgar
labs
is
a
multinational
tech
conglomerate
that
bought
hard
into
the
vm
ecosystem.
They
make
ones
and
zeros
like
no
other
company
but
notice
they
were
falling
behind
in
all
seriousness.
Asgore
labs
is
a
collection
of
different
companies.
I've
I've
seen
I've
seen
and
worked
with
and
stories
I've
taken
from
them
that
I
saw
the
same
issues
over
and
over
again
and
yes,
it's
a
fake
company
and
no
they're,
not
hiring.
B
So
what
did
you
ascribe
think
they
had
to
do?
They
only
thought
they
could
take
their
migration
from
the
physical
data
center
or
the
co-location
to
the
vm
ecosystem.
Oh
just
like
the
vm
ecosystem,
they
use
the
same
technique
to
move
their
monolithic
applications
to
cloud
native.
If
you
ever
played
around
in
vmware
or
ec2.
B
You
know
when
you
had
that
one
bare
metal
machine
back
in
the
day
that
ran
your
application.
You
could
just
take
that
application
use
some
type
of
configuration,
management
and
shove
it
up
into
ec2
instance
or
or
another
cloud
instance
or
whatever
bare
metal
to
the
vms
is
the
same
as
vms
to
containers
right.
B
B
I
beg
to
differ
that
they
were
successful,
but
they
believed
they
were
they're
nowhere
near
where
they
thought
they
could
have
been
being
nowhere
near.
They
thought
they
could
be
for
the
time
and
effort
and
the
money
they
have
spent.
I
come
in
as
the
cloud
native
person
and
ask
some
very
simple,
yet
tough
questions.
B
B
When
I
walk
into
a
room-
and
I
talk
to
a
company
about
these
things-
the
first
thing
I
ask
when
I
actually
get
to
the
people
who
actually
do
the
work,
because
you
know
companies
usually
have
a
few
layers
of
people
before
you
get
to
the
people
who
actually
do
the
work.
You
have
to
talk
to
the
project
managers,
the
executives
and
all
that
jazz
and
then
finally,
you
get
to
the
get
to
the
engineers
who
are
actually
doing
it,
and
I
I
sit
down
in
a
row
before
this
world
we
live
in
today.
B
B
Was
it
more
than
were
there
more
than
a
couple
status
meetings,
asgard
labs
between
the
project
teams
and
who
shipped
it,
but
who
sat
down
and
actually
turned
this
into
the
container
that
you
used
to
to
push
off
to
your
your
application.
Like
did
you
anyway,
we'll
get
to
we'll
get
into
more
details
in
a
minute.
B
B
I
got
allowed
to
spend
a
lot
of
time,
time
and
effort
in
the
openstack
and
vmware
space
and
this
one
company.
I
was
working
with
they're
moving
forward
from
their
their
co-location
data
center
and
moving
into
something
called
openstack,
which
is
vms,
and
I
remember
coming
in
there
to
try
to
help
them.
Do
that,
and
I
was
hired
on
to
make
this
happen
and
the
interesting
thing
was
eventually.
B
I
asked:
why
did
we
decide
to
go
down
this
path
and
it
was
because
the
ceo
was
on
a
way
to
a
conference
and
they
pulled
all
that.
You
know
that
cio
magazine
that
you
see
in
all
business
class
places
on
business
class,
airports
or
airlines,
and
they
saw
that
the
cloud
was
the
next
gen
and
they
she
wanted
their
company
to
be
next-gen
to
be
able
to
tell
their
their
their
board.
B
B
B
B
They
have
their
strengths
and
their
weaknesses,
and
you
need
to
understand
where
you're
going
to
put
your
application,
because
you
need
to
figure
out
if
that's
the
most
the
important
one
to
do
for
your
application
and
the
advantages
that
are
there
not
even
talking
about
multi-cloud
or
hybrid
cloud
or
all
that
jazz,
because
that's
where
people
are
moving
towards,
you
can't
put
all
your
eggs
in
one
basket.
So
you
need
to
figure
out
where
you're
going
to
deploy
this
or
where
you're
planning
on
deploying
it
to
be
successful.
B
B
Oh,
how
many
times
have
I
heard
that
it's
too
many?
This
comes
from
the
actual
architecture
of
what
you
containerized.
Now
I
realize
this
is
a
java
java
group
of
people.
So
if
I
say
this
wrong,
I'm
sorry,
but
this
is
how
I
understand
how
this
kind
of
works-
I'm
not
a
java
expert
by
any
standard,
but
I
can
run
the
map
run.
Those
applications
really
well.
Let's
just
put
that
away.
B
Asgard
labs
took
a
war
file
honestly,
it
could
have
been
an
ear
file
and
threw
it
into
the
java
docker
container
and
called
it
a
day
that
was
it
that's
how
they
that's
what
they
containerized.
There
was
some
java
app.
They
shoved
it
into
a
container
through
threw
it
up
on
kubernetes
and
called
it
today.
They're
like
we're
standardized
we're
we're
next
gen
all
right.
That's
lunch,
see
you
later
like.
That's
that's
the
kind
of
thing
they
would
do.
B
B
It
also
talked
about
the
architectural
changes
that
are
coming
from,
because
we
all
know
that
the
java
ecosystem,
the
the
war
file,
is
a
monolithic,
app
right,
like
you
can
run
a
war
file
and
it's
everything
you
need
to
run
inside
of
it.
That's
actually
not
great
for
the
cloud
native
ecosystem
and
this
talks
about
the
architecture,
architectural
architecture
role.
I
can't
speak,
I'm
a
professional
speaker
and
I
can't
speak
some
architectural
changes
that
actually
have
to
come.
B
B
B
This
is
another
good
example
of
how,
instead
of
just
taking
that
war
file
and
shoving
it
in
they,
they
take
their
legacy
application
in
their
ear
file
and
break
up
into
multiple
war
files
and
then
put
those
migrated
apps
onto
kubernetes
or
openshift,
and
then
have
a
shared
message.
Queue
of
some
sort
between
them,
inter
communication
inside
of
kubernetes
cluster,
is
actually
done
in
a
really
interesting
way,
and
it
reuses
these
things
called
services
so
that
everybody
can
find
each
other.
So
they
can
talk
and
work
together.
B
B
Then
finally,
the
the
final
step,
which
is
actually
the
longest
step,
is
refactoring
into
something
called
the
strangler
pattern.
The
strangle
pattern,
if
nobody
knows,
is
the
idea
of
basically
slowly
but
surely
turning
your
monolithic
application
into
smaller
and
smaller
smaller
microservices
over
time,
basically
strangling
down.
If
you
will,
if
you
imagine,
strangling
that
an
application
do
smaller,
smaller
bits.
B
A
B
You
have
your
application,
your
monolithic
app
has
that
feature
inside
of
that.
Well,
the
strangler
pattern.
The
idea
is,
is
to
be
able
to
on,
by
by
its
side,
spin
up
another
microservice
with
with
the
same
ocr
ability
it
doesn't
matter
what
language
it
is
in
now,
because
the
beauty
of
containerization
is
that
it
doesn't
matter
what
language
it's
been
written
in,
which
is
great
for
performance.
You
start
looking
at
the
different
languages
and
the
advantages
they
have
for
that,
and
you
write
that
new
feature
beside
your
application.
B
B
B
You
can
release
new
features
or
or
bug
fixes
to
just
that
portion
of
the
application
now,
instead
of
having
to
do
a
full
cycle
release
of
your
monolithic
app,
so
you
do
that
over
time
you
strangle
it
down
to
much
little
different,
small
little
applications
with
the
microservices
and
then
before
you
know
it.
You
have
all
these
different
microservices
running
and
you'll
be
able
to
run
and
have
their
own
get
home
their
own
history
and
their
own
ability
to
deploy,
and
you
can
work
for
it
now.
You
can
run
this
in
java.
B
Absolutely
you
can
do
java
across
the
board.
It
does
not
matter
what
language
is
run
inside
of
inside
of
the
the
container
it's
more
of
the
architectural
change,
so
you
start
focusing
on.
Instead
of
big
bang
releases,
you
have
small
batch
releases
right
of
your
different
little
bits
of
application
and
before
you
know
it
that
velocity
of
your
of
your
architecture
will
just
skyrocket,
yes
up
front
it'll
take
some
time
but
it'll
skyrocket
before
you
know,
so
I
kind
of
already
hinted
towards
this.
B
So
where
are
these
architectural
advantages
and
disadvantages-
and
I
did
already
say
this-
but
I'll
say
it
again-
the
velocity
will
just
completely
change
your
ability,
the
ability
to
focus
on
their
own
histories
and
scoping
to
your
clusters,
for
what
you
actually
need
going
back
to
that
one
company
that
just
shoved
their
java
container
or
sorry
their
java
war
file
into
a
container
and
shoved
on
kubernetes
cluster.
That
was
one
of
their
biggest
problems,
this
fortune,
50
company-
that
is
a
subsidiary
of
asgard
labs.
B
Let's
just
call
it
that
they
brought
me
in
because
they
actually
saw
it
as
a
cloud
data
problem
they're
like
jj.
We
have
this
application
and
we
have
this
three
node
cluster,
three
node
kubernetes
cluster,
which,
by
the
way
three
node
kubernetes
cluster.
You
can
pretty
much
run
your
your
your
business
on
on
an
open
shift
cluster,
a
three
node
openshift
cluster,
it's
good
stuff,
it
really
is,
but
they
they
did
it
and
they
shoved
their
their
their
war
file
in
there
and
they
they
wanted
to
spin
up
more
pods.
B
So
they
wanted
to
be
able
to
carry
more
load
because
they
had
overnight
over
u.s
night
time
their
traffic
would
go
down
and
would
pick
up
again
during
the
morning
so
they're
like
oh,
we
need
just
more
resources,
so
they
brought
me
in
and
said,
hey
jj.
Why
doesn't
this
like
scale
horizontally,
like
we
have
this
three
note
clusters
shouldn't?
We
have
three
pods
running
with
this
thing
to
like
work
on
it
to
work.
Do
it
I'm
like
yeah,
I
mean
sure
why
not
like,
let's
do
it
like?
B
B
B
Like
no
longer
do
you
need
to
spend
hundreds
of
thousands
of
dollars
a
year
on
hardware
that
just
does
nothing
now.
You
can
actually
scope
your
cluster
to
be
that
x,
number
of
dollars,
cluster
that
can
horizontally
handle
the
amount
of
load
that
you
expect
to
have
because
you've
changed
this
into
microservices
again.
B
This
requires
a
huge
higher
level
of
cooperation
and
you
need
to
build
out
more
integration
tests
and-
and
you
need
to
spend
the
time
to
really
build
into
this
world-
it
doesn't
come
by
just
shoving
a
container
up
into
openshift
and,
frankly
speaking,
you're
going
to
need
a
different
deployment
system.
It's
that
simple,
like
you're,
going
to
have
a
different
way
to
do
it.
No
longer,
are
you
going
to
to
do
what
you
do
to
deploy
your
application?
B
Now?
I
didn't
realize
this
at
the
time
when
I
wrote
this
talk,
but
this
I
used
to
work
at
a
dell
technology
subsidiary
and
we
had
something
called
the
ccb,
which
I
thought
was
just
a
normal
industry
term,
but
we
all
have
one
of
these
things.
Inside
of
our
inside,
of
our
operations,
teams
or
development
teams
called
the
change
control
board.
You
might
call
it
something
else.
I
don't
know,
but
you
know
the
cc
there.
There
is
always
that
one
room
or
not
room.
Now,
I
guess
a
zoom
call.
B
B
It's
I'm
telling
you
you
need
to
move
away
from
this
because
you're
not
going
to
be
able
to
inside
the
cloud
native
ecosystem
actually
be
able
to
use
something
like
the
ccb.
No
longer
can
you
be
gated
by
dev,
qa,
prod,
random,
executive,
random
senior
executive.
Saying
yes,
don't
go
deploy
this
thing.
B
How
many
times
did
I
see
in
that
room
at
the
dell
technology
subsidiary?
I
was
working
at
where
they
would
literally
do
the
thumbs
up.
Say:
go
no
go
now
if
you're
deploying,
possibly
tens,
if
not
100
times
a
day,
because
you
have
all
these
different
micro
services
and
you're
in
this
this
this
advanced
and
mature.
A
better
word
is
mature
infrastructure.
B
You,
that's
all
they're
gonna
do
all
day
right,
like
they're,
not
gonna,
actually
know.
What's
going
on,
they're
gonna
have
to
say
yes,
yes,
yes,
yes,
yes,
so
the
idea
of
that
gating
mechanism
will
disappear.
You're
gonna
have
to
start
leveraging
leveraging
different
technologies
out
there
to
be
successful.
B
Why
do
I
have
this
load
balancer
now,
if
there's
a
load
balancer
inside
of
openshift,
or
you
know,
why
do
I
have
a
scheduler
inside
my
application
when
I
could
just
have
the
scheduler
that's
built
inside
of
openshift
yeah
yeah,
you
are
you're
going
to
double
up
on
stuff.
It's
that
simple
you're,
going
to
audit
you're
going
to
need
to
audit
and
verify
you
aren't
doubling
up
on
too
many
things.
B
B
It
would
spin
it
up
inside
of
the
pod
the
the
second
process,
because
that's
how
they
were
doing
it.
They
were
treating
a
pod
as
like
a
vm
and
in
their
mind,
they're
like
oh
okay.
So
I
spin
up
this
pod
this
this
new
job
it'll
kick
over
to
one
of
the
other
other
nodes
that
are
running
the
actual
application.
B
B
Now
you
just
spin
out
nodes
and
use
how
many
you
need
and
kubernetes
is
smart
enough
that
it's
like.
Oh,
I
see
a
lot
of
work
coming
down
the
line
you.
It
can
actually
request
from
the
different
clouds
out
there,
a
new
node
to
spin
up,
because
it's
like
oh
there's,
going
to
be
a
tidal
wave
of
work
coming.
I
need
to.
I
need
to
spin
up
another
node
of
some
compute,
so
it'll
be
ready.
So
now
I
can
schedule
a
bunch
of
stuff
over
there.
B
B
B
Back
to
the
load,
bounce
right
here
is
that
when
you
have
multiple
pods
behind
it,
you
can
have
n
number
of
pods.
So
you
need
a
load
balance
between
the
work
to
do
that.
So
there's
our
people
who
have
bought
web
balancers
from
major
networking
companies
out
there
and
they
they
spent
all
this
money
on
it
and
they
put
it
in
front
of
kubernetes,
saying
oh
yeah,
we'll
just
let
it
do
the
bouncing
forest.
B
Well
now
you
have
a
load
bouncer
in
front
of
another
load,
balancer
in
front
of
your
pods.
I'm
not
telling
you
to
wire
your
kubernetes
cluster
directly
into
the
internet,
god!
No,
I'm
not
saying
that.
I'm
just
saying
that
you
might
not
need
that
load,
balancer
anymore,
the
load
balancers
inside
of
kubernetes
and
openshift,
or
the
cloud
native
ecosystem
rival
those
those
data
center
load
balancers.
B
Now
so
all
of
a
sudden,
you
can
save
money
by
not
having
to
spend
insane
costs
on
hardware,
web
bouncers
and
just
let
the
software
do
the
work
for
you.
Of
course,
you're
gonna
have
to
work
on
your
networking
team,
et
cetera,
et
cetera,
but
that's
still
important
to
know
so.
Yes,
you
will
be
doubling
up
on
things
and
you
do
need
to
audit
these.
You
need
to
take
those
moments
and
really
think
about
it.
B
B
No
longer
are
you
going
to
have
those
people
sitting
around
a
room,
giving
go,
no
go
you're
going
to
have
some
jenkins
pipeline
travis.
It
doesn't
matter
good,
github
actions,
it
really
doesn't
matter
pipeline.
That
runs
those
integration
tests,
those
unit
tests
and
if
everything
turns
green,
the
4i
rule
is
important,
make
sure
you
have
four
eyes.
Looking
at
a
code
change
you
hit
that
merge
and
then
it
kicks
off
and
pushes
it
out
to
your
new
cluster
and
congratulations.
You've
done
a
deployment.
B
You
do
small
batch
deployments,
no
longer
big!
Bang!
No
longer
do
you
wait,
wait
till
three
o'clock
in
the
morning
on
a
tuesday
to
release
your
application.
No,
now
you
can
basically
deploy
when
everything
turns
green
again.
That
requires
a
lot
more
integra
collaboration
and
whatnot,
but
it's
important
to
know
and
why
everything
so
complicated.
Well,
honestly,
your
app
has
probably
always
been
this
complicated.
B
B
B
So
basically
the
short
of
it
is
is
you
need
to
let
the
bots
do
the
work
for
you
right
and
why
is
everything
so
complicated?
It
is
right.
No
longer
are
you
gonna
have
that
one
or
two
different,
our
enterprise
architects,
understand
how
your
application
all
comes
together.
Moving
into
microservices
you're,
going
to
start
being
able
to
share
the
load
across
the
board
and
I'll
get
into
more
details
in
that
in
a
little
bit,
but
a
good
friend
of
mine
came
up
with
this.
B
When
I
was
talking
about
this
talk
with
him,
he
actually
brought
this
up
to
me.
He's
like
jj
you're,
basically
telling
your
audience,
you
had
an
ornithol
mastiff.
Now
you
have
13
yipping
chihuahuas,
now
just
take
a
moment
and
think
about
that.
They're,
both
dogs,
if
you
didn't
know
bull
mastiff,
is
a
dog
chihuahua.
You
know
taco
bell
a
little
that
little
dog
right.
B
You
have
13
of
them
now
you
have
to
deal
with
or
you
have
one
really
big
dog
to
deal
with
and
that's
your
applications,
microservices
versus
monolithic
applications,
13
european
chihuahuas,
is
still
a
lot
of
work
to
deal
with.
There's
still
a
lot
of
things
to
toward
and
coordinate
with,
but
it's
much
easier
to
pick
up
a
yipping
chihuahua
and
you
know,
take
them
to
the
vet
compared
to
trying
to
trying
to
move
a
bull
mastiff
into
a
crate
or
whatever
to
take
to
the
vet.
B
B
B
B
More
importantly,
by
moving
to
microservices,
you
will
have
to
create
some
kind
of
standardized
logging
standard
you'll
be
able
to
have
to
agree
that
this
is
the
way
the
logs
need
to
come
out.
No
longer
is
it
just
a
catalina
dot
log
on
one
random
server,
now
you're
going
to
have
a
bunch
of
different
containers
having
to
ship
their
logs
to
something
a
person
who
understands
the
application,
can
dig
through
to
figure
out.
What's
going
on,
production
outages
happen
and
you
will
have
bugs
and
issues,
and
if
you
don't
have
this
level
of
cooperation.
B
By
the
way,
ken
is
an
amazing
amazing
guy
to
talk
about
ci
with
continuous
integration.
It
goes
from
comes
from
go
cd,
so
if
you
want
to
see
some
really
really
concrete
concepts
of
leveraging
automation
to
do
shipping,
your
code
can
look
them
up
on
online.
Basically
ken
I
can't
pronounce
his
last
name
for
the
life
of
me.
He's
he's
really
good.
B
So,
let's
have
some
questions,
you
questions.
You
should
ask
about
how
this
cultural
shift
to
happen,
and,
yes,
I
am
talking
about
a
cultural
shift.
Right,
like
you,
will
see
a
cultural
shift.
I
mentioned
that
ccb
earlier
at
asgard
labs.
The
ccb
became
something
almost
like
something
out
of
the
phoenix
project.
If
you've
never
read
the
phoenix
project,
you
absolutely
should
it's
it's
a
book
about
operations.
B
Basically,
it's
basically
iliyahu
gold
rats,
the
goal
just
with
it
instead
of
building
widgets
or
car
stuff,
I
think,
was
the
goal
it's
been
a
while,
but
it's
using
it
as
as
the
the
narrative
and
background.
It's
really
well
done
in
the
future
project.
Nobody
ever
showed
up
to
these
ccbs
or
the
equivalent
of
the
ccbs,
and
it
became
it
wasn't
engaging.
It
was
a
burden
right
like
nobody
wanted
to
go
there
and
do
the
go.
No
go.
B
Nobody
wanted
to
go
there
to
talk
about
this
stuff,
even
though
the
whole
idea
was
for
cross
communication
with
moving
the
cloud
native
you'll
naturally
have
to
start
allowing
for
self
orchestration
of
rollouts
and
updates.
If
your
developers
say
hey,
we
need
to
do
this
thing
right
and
they
got
the
patch
and
everything
is
green
and
the
tests
have
added
so
it
tests
how
they
expect
it
to.
B
They
should
hit
that
merge
button
and
you
know
ship
it
right
like
that's,
that's
the
way
the
cloud
native
works,
but
there
are
companies
out
there
that
are
going
to
be
horrified
of
this.
The
idea
that
you
put
that
power
into
developers
or
product
managers
or
project
manager,
whoever
they
are,
that's
going
to
force
some
really
strong
cultural
shifts,
you'll
lean
more
and
more
on
that
pipeline
and
collaboration
to
get
the
different
widgets
out
there
at
the
right
time.
B
One
of
the
main
reasons
why
golang
or
the
go
language
is
so
easy
to
read,
believe
it
or
not,
is
the
go
format
command.
The
geo,
fmt
command
go
came
along
with
a
standard
outside
of
the
box.
No
longer
is
it
like
pep,
8
or
blanking
on
the
java
standards,
but
or
the
javascript
standards
out
there
go
came
with
a
format.
Game
came
with
a
format
command
and
a
standard
outside
the
box,
and
it
forces
that
no
matter
what
so
at
3
am
when
something
goes
horribly
wrong.
B
B
They
they
they
visualize
it
because
they've
already
been
trained,
that
they
don't
have
to
argue
over
tabs
versus
spaces
or
anything
like
that,
because
they
have
a
standard
they
don't
they
don't
worry
about
the
the
syntax
placements.
They
just
think
about
the
logic
so
leveraging
ci
and
cd.
You
get
the
ability
to
have
these
types
of
linting
and
forcing
these
standards.
Yes,
your
different
developers
are
going
to
be
up
in
arms,
about
tabs
versus
spaces
and
stuff
like
that.
B
But
if
you
put
this
inside
of
your
actual
pipeline
and
agree
that
this
is
the
way
you
need
to
write
your
code,
some
people
are
going
to
be
annoyed,
but
eventually
everyone
will
follow
in
line
because
it'll
be
red.
The
green,
the
the
pipeline
will
be
red,
so
you
know
force
it
it.
The
downstream
ability
is
really
really
great.
B
You
need
to
learn
to
collaborate
with
other
teams.
The
hardest
thing
I
saw
at
asgard
labs
was
to
do
to
deal
with
the
actual
collaborations
between
teams.
They
had
some
great
propaganda
around
having
a
scrum
and
tribes.
I
still
don't
even
know
what
that
is,
and
what
not,
but
people
still
just
wanted
to
do
it.
The
old
way
and
collaboration
isn't
just
status
meetings,
it's
more
than
that.
It's
declaring
shared
contracts
for
jobs
and
responsibilities
with
constant
communication
between
teams.
B
B
B
Initially,
this
put
things
to
a
grinding
halt
right
because
now,
all
of
a
sudden,
you
got
to
write
all
this
documentation
because
you
got
a
new
homeboy
here.
Who
knows
nothing
about
what
you've
been
doing
the
last
n
number
of
years,
but
then,
all
of
a
sudden,
the
next
one
has
started
going
faster
because
you
you
rewrote
that
documentation.
B
You
now
train
that
new
person
and
now
that
new
person
that
just
came
in
turns
out
they
were
an
expert
on
that
api
that
you've
been
having
trouble
with
over.
On
that
other
portion
of
the
app
wait,
a
second
they
actually
know
who
wrote
that
thing
and
can
talk
to
them
before
you
know
it.
It's
no
longer
tribal
knowledge.
B
B
B
B
So,
with
every
talk
you
need
to
talk
about
visibility,
monitoring
because
everybody
needs
it
right,
asgore
labs,
so
they
could
just
buy
one
product
and
call
it
a
day.
One
product,
sorry
nagios,
isn't
going
to
cut
it
anymore
and
they
learn
this
the
hard
way.
Sometimes
you
have
to
build
multiple
you'll
have
multiple
monitor,
applications
and
visibility.
Only
portions
of
the
apps
that
your
teams
care
about
as
badly
as
azgar
labs
wanted
a
single
pane
of
glass.
It's
unrealistic
without
how
many
moving
parts
there
are.
B
Your
teams
are
going
to
need
to
focus
on
the
things
that
they
can
care
about
and
worry
about,
and
then,
of
course,
you're
going
to
have
to
like
bubble
it
up
to
be
high,
higher
and
higher
in
different
scopes.
But
it's
important
to
recognize
that
this
is
a
huge
culture
shift
inside
of
asgard
labs,
most
companies
that
I've
been
talking
to,
even
especially
through
these
coveted
years,
they're
still
dealing
with
this,
because
you
know
they
wanted
just
to
be
able
to
go.
B
A
B
So
something
that
people
don't
really
talk
about
too
much
until
it's
way
too
late.
Is
that
how
the
economics
of
the
cloud
differ
from
your
data
center?
I
mean
moving
to
the
cloud
native
ecosystem,
everything's
opex.
Now
everything
can
be
paid
with
a
credit
card.
Well,
okay,
most
of
it
can
be
paid
with
a
credit
card.
B
B
It's
amazing
how
many,
how
many
accounting
firms
tell
tech
companies
to
depreciate
their
their
their
hardware
to
to
for
the
gap
process
of
money
and
no
longer
is
this
massive
capex
of
buying
a
data
center,
something
they
can
help
balance
the
books
with
as
engineers
as
developers?
We
don't
really
think
of
it
this
way,
but
there
are
whole
teams
of
people
out
there
who
have
to
make
sure
all
the
stuff.
The
books,
zero
out
correctly
and
depreciation
is
something
they
lean
heavily
on
and
when
everything
turns
to
opex
or
cogs
or
cost
of
goods
sold.
B
That's
that
causes
some
friction.
So
it's
important
to
have
those
conversations,
and
hopefully
your
management
team
has
at
least
walked
through
these
changes
with
the
stakeholders,
so
they
can
at
least
talk
about
okay,
moving
to
cloud
native
now
we
have
to
think
of
it.
This
way,
no
longer
is
it
me
buying
a
data
center
with
a
bunch
of
vmware
clusters
inside
of
it.
Now
I'm
going
to
random
cloud
and
I'm
using
the
corporate
credit
card.
How
is
that
going
to
affect
our
bottom
line,
possibly
save
at
the
same
time?
B
B
Hey
jj,
what
do
you
mean
all
our
supports
on
stack
overflow?
That's
another
thing.
People
completely
forget
well,
yeah,
honestly,
yeah,
a
few
places
yeah,
that's
pretty
much
where
you're
going
to
find
it
because,
there's
not
you
know,
there's
few
experts
out
there
in
this
world
and
they
post
a
stack
overflow
they're,
totally
wrong.
It's
community
people
are
going
to
be
helpful,
but
there's
very
few
places
for
companies
to
turn
to
get
that
type
of
stability
that
they
want
to
run
their
business.
B
B
If
you
didn't
know,
openshift
is,
is
the
enterprise
grade
open,
kubernetes
cluster,
supported
by
red
hat,
and
when
you
buy
an
open
ship
cluster,
you
get
all
the
power
of
the
cloud
native
ecosystem
and
also
the
ability
to
leverage
the
best
in
breed
systems
for
kubernetes
for
your
downstream
developers
and
the
support
of
red
hat
behind
it.
So
it's
something
really
important
to
look
at,
especially
from
the
enterprise
space,
because
you
put
your
business
on
here.
B
B
So
I'm
going
to
the
end
of
it
here.
If
you
have
any
questions
or
thoughts,
please
don't
hesitate
to
throw
them
in
the
chat.
I'm
going
to
kind
of
wrap
this
up
and
maybe
we'll
I'll
answer.
Some
questions
live
here
in
just
a
second.
So
let's
talk
about
some
tangible
things.
You
can
start
with
to
help.
You
become
more
successful.
B
There
are
a
ton
of
technology
and
software
to
help
you
get
going.
The
best
thing
you
can
really
do
is
take
a
moment
and
figure
out
when
you
containerize
your
app.
What
did
you
really
containerize,
or
did
you
just
wrap
it
in
a
pod
and
wash
your
hands
of
it
have
large
conversations
about
why
you
did
this?
B
B
Ideally,
with
mescal
these
corporations,
I've
had
exposure
to
as
asgar
labs.
It
helps
highlight
some
of
these
consistent
issues.
I've
seen
the
best
thing
you
can
do
first
is
ask:
do
we
really
need
to
if
you're
really
committed?
Well,
then
take
a
beat
and
look
for
those
optimizations
instead
of
features?
B
You
know
it's
time
for
us
to
switch
out
that
engine
or
whatever
this
will
drive
your
teams
crazy,
but
the
more
you
pay
up
front
and
use
the
correct
tool
for
the
job,
the
better
you'll
get
the
better
returns.
You'll
get
or,
to
quote
another
great
friend
of
mine,
thomas
kate,
you
wouldn't
use
a
saw
when
you
needed
a
hammer
or
a
hammer
when
you
needed
a
saw
right
just
take
a
moment
and
think
about
that
he's
telling
you
use
the
correct
tool
for
the
job.
B
Of
course,
you
can
use
a
saw
to
hammer
in
a
nail
you're
going
to
look
like
an
idiot,
but
you
know
it'll
work
or
you
can
use
a
hammer
to
break
a
piece
of
wood
right.
It's
going
to
take
some
time,
but
it'd
be
much
easier
to
use
a
saw
so
take
a
moment
and
think
about
that.
As
you
move
down
this
path
to
cloud
native,
use
the
right
tool
for
the
right
job
and
do
your
homework.
B
A
Amazing,
thank
you
so
much
jj
for
that
excellent
presentation.
Today.
Just
a
reminder:
if
anyone
in
the
audience
has
any
final
questions,
please
feel
free
to
ask
them
in
the
chat
or
use
the
ask
a
question.
Tab
and
I'll
give
you
a
few
moments.
While
I
wrap
everything
up
so
the
next
jakarta
tech
talk
happens,
march
16th,
when
otavio
santana
and
carina
varela
join
us
to
present
the
five
skills
you
must
master
to
be
outstanding.