►
From YouTube: Cloud Native Transformation at CIO Leadership
Description
William Chia speaks on Cloud Native Transformation at an Argyle CIO Leadership event in Seattle on March 12, 2019. Here are the slides from the presentation: https://docs.google.com/presentation/d/15FN3tebw8LZMYkOMtqaPmHV17NDVZy0K6Tou1-TS-Ac/edit#
A
This
was
a
phenomenal
innovation
because
it
was
an
improvement
over
existing
signalling
patterns
such
as
loop,
disconnect
that
rotary
phones
used,
because
that
signalling
pattern
was
not
able
to
travel
long
distances,
and
this
meant
that,
in
order
to
make
a
long-distance
phone
call,
you
needed
to
have
an
operator
manually
connect
that
with
the
introduction
of
DTMF
keypads,
like
the
one
pictured
here
on
the
screen
almost
said
now,
the
signaling
could
travel
a
longer
distance.
You
could
automate
that
process
and
it's
scaled
the
phone
network.
Of
course.
A
Today
we
live
in
a
world
of
digital
transformation
where
digital
technologies
are
disrupting
and
replacing
analog
technologies
in
fact,
take,
for
example,
my
iPhone
right.
It's
nothing
at
all
like
this
keypad
I
mean
it's
a
digital
technology.
It's
completely
different,
has
zero
similarities
or
does
it?
If
you
look
at
the
phone
app
on
my
iPhone,
it's
actually
almost
exactly
identical
to
the
1963
keypad.
In
fact,
making
a
phone
call
today
is
pretty
similar
to
what
it
was
like
in
the
60s
and
it
even
uses
DTMF
signaling.
Now.
A
Why
is
this
the
case
that
often
when
we
have
new
technologies
and
they
emerge
it's
almost
a
cliche
or
a
trope
that
we
start
to
implement
those
new
technologies
using
the
same
old
pattern
instead
of
being
new
and
innovative
today,
I
hope
to
talk
to
you
about
digital
transformation
and
in
particular
about
cloud
native
transformation
at
gate
lab.
We
are
one
of
the
unicorns
that
Sahara
talked
about.
We
have
a
focus
on
software,
development
and
delivery,
and
so
this
is
the
bent
that
I
want
to
talk
to
you
about
cloud
native
transformation.
A
Instead
of
implementing
the
same
old
thing
with
new
technologies
that
you
can
implement
something
new
and
innovative
and
reap
the
rewards
of
that
to
talk
about
this
doing
things,
the
same
old
way,
we'll
look
at
the
world
of
software
development
and,
of
course,
with
software
development,
we
have
a
familiar
pattern
of
waterfall
software
development.
I.
Imagine
that
for
many
folks
in
the
room,
your
software
engineering
organizations,
probably
in
some
parts,
are
still
using
waterfall,
and
you
know
the
pain
points
of
having
that
methodology.
A
In
fact,
doing
waterfall
is
really
like
delivering
software
like
it's
a
hardware
product.
When
you
have
a
physical
product
to
ship,
it
has
to
go
through
all
of
these
various
stages,
and
so
when
we
went
to
go
deliver
software,
we
said:
let's
go
through
all
of
these
stages
in
a
waterfall
fashion,
but
it
ignores
the
unique
properties
of
software.
A
It
doesn't
take
advantage
of
what
you
can
do
with
software
and,
as
we
know,
the
pain
points
of
waterfall
are
that
it's
a
very
long
time
from
the
time
you
develop
that
software
to
the
time
it's
actually
delivered
to
a
customer.
That
feedback
cycle
is
very
long
and
you
may
be
aiming
for
a
target,
but
by
the
time
you
actually
get
there,
the
market
has
shifted,
so
it's
very
hard
to
avoid
disruption.
A
If
you
are
have
these
long,
waterfall
software
development
cycles,
of
course
the
world
changed,
and
then
we
have
the
agile
software
development
and
for
many
of
you,
your
organizations
are
going
through
an
agile
transformation.
This
is
making
smaller
changes
shrinking
the
cycle
so
that
it
software's
developed,
faster
and
released
quicker,
and
these
small
iterative
changes
allow
us
to
reach
the
target
faster
and
get
feedback
sooner
so
that
as
the
market
and
the
world
shifts,
we
can
adjust
to
that.
A
But,
of
course,
as
you
know,
if
you're
using
agile
software
development
in
your
organization,
there
are
pain
points
with
agile,
predominantly
if
you
are
doing
agile
development.
You're
development
team
is
delivering
software
very
quickly,
but
then,
when
they
ship
it
over
the
fence
to
the
operations
team
to
actually
deploy
and
operate
that
software,
that
can
be
a
very
long
cycle.
It
can
take
six
months.
A
So,
of
course,
to
address
this
pain
point
the
world
changed
and
we
have
DevOps
and
DevOps
is
really
about
having
development
teams
and
Operations
teams
coming
together,
both
culturally
and
technologically,
to
bridge
that
gap,
so
that
your
shipping
and
iterating
software
very
quickly,
but
also
so
that
you're
automating
your
deployment
processes.
So
those
are
also
fast.
So
you
move
from
six
months
to
six
weeks
to
every
six
days
to
six
times
or
six
thousand
times
per
day.
It's
maybe
a
little
bit
high
I've
heard
about
a
thousand
thousand
deployments
per
day.
A
The
idea
is
when
you
are
implementing
DevOps
and
you
can
iterate
very
quickly.
It
then
ties
that
software
development
lifecycle
together,
but,
as
you
know,
if
you
are
using
DevOps
in
your
organization,
there's
still
yet
another
pain
point,
and
this
pain
point
is:
is
that
your
infrastructure,
where
you
are
going
to
run
your
software,
you
need
to
pre
provision
it,
so
you
need
to
determine
what
your
load
is
to
figure
out.
Am
I
going
to
have
very
high
load?
A
Is
my
app
all
of
a
sudden
going
to
become
very
popular
with
my
user
base
tomorrow,
I
need
to
provision
up
to
scale.
The
problem
is,
is
if
I
miss
estimate
what
that
should
be,
then,
all
of
a
sudden
I'm
paying
a
lot
of
money
for
a
lot
of
infrastructure,
with
very
little
load
or
worse.
If
I
underestimate
and
a
provision
too
little,
then
the
I
get
too
much
load
and
my
software
goes
down
and
we
know
what
that
when
the
software
goes
down,
the
business
is
not
moving
forward.
Revenue
is
stalled.
A
These
are
really
big
challenges.
So
again,
the
world
is
changing
to
address
these
pain
points,
and
this
is
where
cloud
native
comes
in
now.
Cloud
native
is
really
about
developing
new
software.
In
innovative
ways
and
taking
advantage
of
the
unique
properties
of
the
cloud
in
order
to
deliver
that
software,
so
just
like
avoiding
the
trap
of
having
a
phone
that
doesn't
change
for
a
half
a
decade
or
I'm,
sorry,
half
a
century
cloud
native
is
about
adopting
new
technology.
So,
yes,
it's
about
using
agile.
Yes,
it's
about
DevOps,
but
it's
also
about
implementing
technology.
A
It's
like
micro
services
and
containers
in
order
to
take
advantage
of
the
unique
properties
of
the
cloud
to
deliver
specific
values.
So
looking
at
one
of
some
of
these
is
why
why
is
it
that
companies
go
cloud
native
or
why
do
they
go
through
a
cloud
native
transformation?
Well,
it's
really
about
agility
with
resiliency
or
delivering
better
software
faster
at
a
lower
cost.
The
cost
savings
are
tremendous,
as
I've
already
started
to
allude
to
when
you
Smoove
the
cloud
native
and
it's
about
these
dynamic
environments.
A
No
longer
are
you
pre
provisioning,
but
you're
dynamically
scaling
up
and
down
based
on
load.
This
means,
if
you
get
more
load,
you
scale
up.
This
means,
if
you
have
reduced
load,
you
scale
down
so
you're,
eliminating
those
wastes
of
costs
but
you're
also
running
more
stable,
so
that
you're
eliminating
the
risk
of
going
down.
Of
course,
in
addition
to
the
cost
savings
of
cloud
native,
there's,
also
the
speed
advantages
that
being
able
to
deliver
software
faster
and
iterate
the
true
principles
of
agile
coming
to
fruition.
A
This
is
why
companies
adopt
this
and
then
stability
again,
if
you're
releasing
once
every
six
months
that
software
released
there's
a
lot
of
risk
when
that
goes
out,
a
lot
of
things
can
go
wrong.
It's
it's
a
keeps
you
up
at
night.
However,
if
deployments
become
very
boring,
if
you
everything
is
automated
and
things
scale
dynamically,
then
all
of
a
sudden
releases
are
routine.
Your
software
runs
more
stable
and
then
adopting
micro
services
spreads
the
load
out
so
that
your
app
is
more
stable.
Let's
dig
into
these
just
a
little
bit.
A
One
of
the
shifts
in
this
world
is
moving
from
servers
and
virtual
machines
to
containers
and
can
orchestration
technologies
such
as
open
source
kubernetes
at
its
heart.
This
is
a
cost
savings,
but
also
advantage.
So
if
we
look
at
the
technology
of
containers,
when
you
deploy
an
application
on
a
bare
metal
server,
you
have
the
application
within
the
server.
A
But
if
you
need
to
scale
that,
if
you
need
multiple
instances
of
that
application,
it
means
you
need
a
server
per
application
which
is
very
expensive
or
running
multiple
applications
in
an
environment
where
they
can
all
interfere
with
each
other,
which
is
insecure
and
has
other
problems
that
where
they
can
affect
the
performance,
so
servers
don't
work
all
that
great,
but
thankfully
we
have
virtualization
and
virtualization
allows
us
to
segment
out
our
applications
within
a
virtual
machine.
There's
a
wonderful
innovation.
Things
are
more
secure.
We
can
now
scale.
A
We
can
fit
multiple
virtual
machines
on
a
single
machine,
but
the
problem
is:
is
that
virtual
machines
are
very
heavyweight
right.
Each
each
copy
of
that
virtual
machine
contains
a
copy
of
the
kernel,
has
the
entire
operating
system.
These
are
things
that
we
really
don't
need
within
an
application
instance.
So,
in
order
to
gain
scalability
benefits,
you
have
containers.
Containers
are
a
lightweight
way
of
packaging,
your
application,
software
that
only
contains
the
application
and
the
libraries
and
doesn't
have
overhead
that
VMs
have
such
as
that
the
kernel
and
operating
system.
A
So
this
means
you
can
fit
many
more
containers
on
the
same
amount
of
hardware,
getting
that
cost
savings
of
using
less
infrastructure
or
less
cloud,
compute
cost.
In
fact,
Gartner
says
that
today
and
this
report
actually
just
came
out
in
late
February
there's
about
30%
of
global
organizations
using
containers
today,
but
by
2022,
the
world
is
changing.
More
than
75%
of
global
organizations
will
be
running
containerized
applications
in
production,
so
containers
are
wonderful
technology,
but
you
can
still
run
the
risk
of
doing
the
same
old
thing
it
honestly.
A
It
reminds
me
of
a
taco
night
at
my
house
and
if
you
have
taco
night,
my
tacos
are
delicious
and
let
me
say
that
we
always
make
a
ton.
He
was
always
some
leftover
and
the
tacos
the
next
day.
The
deliciousness
of
those
tacos
depends
on
who
picks
up
I,
don't
know
if
it's
like
this
at
your
house,
my
wife
does
a
great
job.
She
puts
the
tomatoes
in
a
container
the
cheese
in
one
another
container.
Everything's
all
separated
goes
in
the
fridge,
pull
that
out
the
next
day
it's
fresh
and
delicious.
A
If
I
pick
up,
the
tacos
I
have
been
known
to
a
time
or
two
just
kind
of
shove,
everything
in
one
spot
and
just
put
that
in
the
fridge.
Of
course,
you
pull
it
out
the
next
day,
it's
a
bit
of
a
soggy
mess,
and
so,
in
the
same
way,
your
business
outcomes
may
be
like
my
leftover
outcomes,
if
you're
not
separating
into
micro-services.
A
So
containers
and
micro
services
go
hand
in
hand,
and
this
is
really
about
separating
concerns
of
your
application
in
a
monolithic
application
architecture.
This
is
what
many
of
us
deploy,
whether
we're
deploying
software
applications
consumed
by
our
users
or
internally
within
our
IT
teams.
The
monolith
is
usually
a
single
application,
usually
written
in
a
single
language,
usually
deployed
as
a
single
package,
and
what
this
means
is,
as
you
try
to
scale
and
different
teams
want
to
work
on
different
parts
of
the
app
they
have
to
coordinate
with
each
other.
A
They
can
have
conflicts
and
all
of
that
overhead
slows
them
down.
It
also
means
that
there's
a
lot
of
risk
if
one
part
of
the
app
breaks
it
breaks
the
whole
app
and
so
monolithic
architectures
are
risky,
but
breaking
out
into
micro
services
can
alleviate
one
of
these
pain
points.
It
means
that
instead
of
one
single
application,
you're
deploying
many
applications
as
services
that
communicate
to
other
parts
of
the
app
over
API,
and
then
development
teams
can
own
a
service
and
to
end
it
means
they
can
iterate
and
test
very
quickly.
A
Try
new
things
out
without
the
worry
of
breaking
the
rest
of
the
app.
This
type
of
marker
services
architecture
is
what
is
fueling
the
innovation
of
native
and,
of
course,
as
I
mentioned,
containers
and
microservices
go
together,
and
this
gives
you
the
benefits
of
container
orchestration,
and
so,
if
you
have
just
containers-
and
you
are
trying
to
schedule
those
containers
onto
different
pieces
of
infrastructure
to
run
them
or
what
we'll
call
nodes,
consideration
notice
server,
you
need
to
fit
those
containers
in.
You
are
using
far
too
many
nodes
to
scale.
A
However,
with
container
orchestration
like
kubernetes,
it
bim
packs
into
the
most
efficient
place
possible
kind
of
like
a
Tetris
game.
So
you
can
see
the
orchestration
is
far
more
efficient.
This
is
where
you're,
taking
advantage
of
automation
in
order
to
have
cost
savings,
so
research
done
by
a
dimensional
research.
They
say:
eighty-six
percent
of
IT
leaders
expect
micro
services
to
be
the
default
architecture
within
five
years.
This
is
the
world
changing
to
cloud
native
transformation.
So
this
is
some
of
the
technologies
that
enable
it.
A
A
It's
the
Steve,
Jobs
wardrobe
change
agent
is,
if
you,
if
you
think
about
it,
Steve
Jobs,
you
know
he
wore
the
same
thing
every
day
and
actually
one
of
my
former
friends
and
CEO
of
my
last
company
he
actually
adopted
this
model
wore
the
same
outfit
opened
up
his
closet.
It
was
one
big
template,
a
thing.
Why
do
you
like
this?
He?
This
is
very
efficient
wakes
up
in
the
morning.
Doesn't
he
decide
what
to
wear,
but
also,
if
you
get
a
hole
in
your
shirt,
you
just
pull
out
another
shirt.
A
It's
all
part
of
a
template.
You
don't
have
to
worry
about
it.
Matching
and
I
said.
Okay,
this
this
interchangeability
reminds
me
a
lot
of
DevOps
there's
this
concept
of
in
the
old
world.
A
server
is
a
very
bespoke
thing
where
it
has
a
certain
operating
system
in
certain
packages,
and
you
have
to
care
about
that
server.
A
lot
and
if
it
goes
down,
is
very
hard
to
replicate.
However,
if
everything
is
just
software-defined,
if
you
have
infrastructure
as
software,
then
that
can
be
templated
out
and
one
server
goes
down.
A
Another
server
can
come
up
and
take
its
place
and
that's
what
cloud
native
and
kubernetes
runs
in
that
model,
but
it's
not
just
a
technological
process.
It's
also
a
people
process
and
a
way
of
structuring
an
organization.
I'll
show
you
I'm
talking
about
this
is
what
I
call
the
cloud
native
enterprise
platform
pattern
and
over
and
over
and
over
again,
as
I've
seen,
businesses
of
all
sizes
adopt
kubernetes
but
in
particular
larger
organizations.
They
are
using
this
pattern
between
their
development
teams
and
their
operations
teams
and
they're
using
templates.
A
The
idea
here
is
the
operations
team,
builds
a
platform
and
builds
a
template
for
what
that
application
is
supposed
to
have
this
way
as
a
development
team,
I
don't
need
to
understand
all
of
the
complicated
technology.
I
have
my
operations
team
managing
the
platform
for
me
and
I
can
get
going
right
away,
so
you
might
have
a
template
and
that
application
I
bring
it
in.
It
has
a
CI,
CD
DevOps
pipeline,
that's
already
built
out
for
me.
A
It's
basically
ready
to
run
and
plug
into
my
existing
microservices
architecture
with
that
template
adapt
and
that
way
the
service
team
only
needs
to
add
their
business
logic.
So
this
type
of
architecture
and
interaction
between
teams
really
allows
you
to
take
the
best
parts
of
each
team
and
leverage
those
skills,
best
parts
of
each
organization,
levers
of
skills
and
again,
an
allowance
of
software
developers
to
spend
all
of
their
time,
focusing
on
business
logic
and
driving
value
versus
doing
undifferentiated,
lifting
this
type
of
enterprise
platform.
A
In
fact,
there
are
hundreds
of
companies
that
have
already
begun
their
cloud
native
transformation.
Some
of
them
are
in
this
room.
These
are
folks
of
all
sizes,
but
you
know
if
you
look
at
some
of
these
at
AIC
New
York,
Times,
Nordstrom,
Goldman
Sachs.
Some
of
these
are
large
complicated
enterprises
but
they're
adopting
this
new
technology,
because
it's
allowing
them
to
realize
dramatic
cost
savings.
It's
allowing
them
to
move
faster
and
increase
the
pace
of
innovation.
A
It's
allowing
them
to
run
stabili,
so
they
can
sleep
better
at
night,
and
so
my
hope
is,
as
you've
just
taken
a
little
nugget
of
this
or
seen
what
cloud
native
looks
like
you
think
about
agile
and
DevOps
and
cloud
native
to
implement
these
processes
and
your
organization.
So
really
just
leaves
me
with
one
last
question,
which
is:
when
will
you
begin
your
cloud
native
transformation?
Thank
you.
A
Key
lessons
learned
when
shifting
to
micro
services-
that's
a
great
question,
so
I
would
say
in
a
nutshell:
there
are
the
benefits
of
the
micro
services
which
I
dug
into
but
of
course,
didn't
dig
into
the
full
time.
Some
of
the
pain
points
so
essentially
what
you're
is
a
trade-off
between
simplicity
and
complexity
and
an
inverse
graph
of
the
risk
and
innovation
pace.
So
that's
something
to
manage.
I'll
give
you
an
example.
So
the
idea
is
when
you
break
a
part
of
monolith
and
that
could
be
five
services
that
could
be
500
micro
services.
A
Folks,
like
uber
I,
think
have
1,400
micro
services.
If
you
think
of
an
app
like
that,
that's
at
that
scale
and
at
that
scale
it's
very
very
complicated.
There
are
things
like
service
discovery.
How
does
my
application
even
get
to
all
of
these
other
routes
and
how
do
I
manage
all
of
that
complexity?
You
need
additional
tooling
to
to
manage
that.
So
what
I've
seen
is
a
best
practice.
Is
that
folks
do
that
gradually?
There's
a
pattern
called
the
strangler
pattern.
A
A
One
example
is
there's
a
phenomenal
talk
from
my
company,
one
of
my
colleague,
Jeff
plum.
He
did
a
talk
at
coop
con
this
year
on
get
labs
cloud
native
transformation
and
there
was
a
decision
made
about
whether
to
break
each
service
into
its
own
container
or
actually
to
have
what
we
call
a
sidecar
pattern
where
there
multiple
app
parts
of
the
app
in
a
container,
and
we
actually
decided
to
go
with
that.
A
B
A
A
What
I've
seen
successful
is
when
folks
are
first
starting
out,
they
will
tend
to
use
a
kubernetes
managed
service,
so
you
can
think
of
managed
services
go
along
great
with
micro
services.
Some
of
the
services
are
internal.
Your
teams
develop
them
some
of
them
you're
consuming
from
a
cloud
provider.
So
this
might
be
your
your
database.
You
might
use
RDS
from
Amazon
or
you
might
use
Amazon
lambda
to
get
some
some
serverless
functionality.
A
So
these
kind
of
managed
services
go
really
well
in
a
micro
services
architecture
and
one
of
these
managed
services
will
be
kubernetes
managed
service.
All
of
the
major
cloud
providers
offer
them.
Google
kubernetes
engine
amazon,
kubernetes
asher,
has
a
kubernetes
engine
and
so
that
abstracts
away
some
of
the
complexity.
It
means
you
don't
need
to
to
manage
and
update
that
infrastructure.
A
You're
just
consuming
that
kubernetes
and
there
are
tools
not
just
like
git
lab
but
tooling,
that
will
allow
you
to
containerize
your
applications,
store
those
containers
in
a
registry
and
then
deploy
those
on
to
a
kubernetes
managed
service,
and
all
of
that
tooling
works
together.
So
there's
many
ways
to
do
it:
I've
seen
folks
roll
their
own
I've,
seen
folks
be
able
to
spin
up
and
test
quickly
with
those
managed
services,
and
it's
something
I
probably
recommend.
C
Hi
so
right
now,
I
have
a
hybrid
ecosystem,
so
we
started
moving
pretty
heavily
into
cloud
probably
about
two
years
ago,
and
what
we're
finding
is
it's?
Not
it's
not
less
expensive.
It
is.
It
is
really
some
cost
avoidance.
So
what
you
can
all
the
capabilities
you
talked
about
with
cloud
infrastructure
and
environments
really
support
the
requirements
for
continued
velocity
increases
in
the
velocity
and
scale.
What
we're
struggling
a
little
bit
with
from
an
investment
perspective
is,
is
taking
the
enterprise
there
as
a
shift.
C
If
I
wanted
to
do
those
things
on
Prem
I
couldn't
do
it
at
cost
that
I
can
get
in
cloud,
but
the
cloud
isn't
any
cheaper,
it's
just
a
different
place
to
do
it
and
then
I'm
also
getting
hit
with
operational
expense
versus
capitalizable
expense.
So
I'm
just
wondering
if
there
is
there
a
financial
model
that
you're
using
or
you've
come
across
that
helps
when
companies
need
to
make
this
kind
of
transformation,
especially
because
of
all
the
capabilities
that
are
unlocked
ya.
A
Okay,
awesome,
yeah,
I,
think
you're,
spot-on
migrating
the
cloud.
A
huge
challenges
is
the
op
X
cost
model
and
the
the
challenge,
of
course,
is
when
everything's
in
your
data
center
it
can
feel
much
more
controlled
and
predictable,
and
then
you
move
to
the
cloud
somebody
can
ship
out
a
bug
and
all
of
a
sudden,
your
usage
spikes
and
it
can
take
costs
off
the
rails.
So
there
are
those
risks
involved.
It
definitely
involves
usually
folks
managing
those
costs,
especially
on
something
like
Amazon.
A
So
I
have
seen
that
type
of
hybrid
model
help
to
control
some
of
those
costs
and,
in
my
experience,
I
haven't
seen
an
easy
answer
there.
It
is,
it
is
a
risk.
It
is
something
that
is
complicated,
I've
seen
dedicated
personnel,
the
simply
owning
cloud
cost
optimization
and
that's
that's
a
challenge
and
I'd
love
in
the
networking
to
hear
more
what
you're
doing
and
how
you
attack
it.
That's
a
great
question.
D
Yeah
I
mean
during
deployment
there
should
be
monitoring
by
infrastructure
right
and
basically
a
reversion
to
the
original
set
of
containers.
If
you
know
the
new
set
of
containers
runs
off
the
rails
right,
that's
the
beauty
of
it.
You
don't
have
to
do
a
full
blue,
blue,
green,
like
you
did
with
VMs.
You
can
kind
of
ooze
whose
containers
back
and
forth
until
you're
sure
it
was
pretty
hairy
when
you
had
to
do
blue
green
right,
because
you
probably
leave
it
running,
maybe
for
20
minutes,
both
the
blue
and
the
green.
D
A
Really
glad
you
made
that
point,
I
didn't
talk
about
it
in
the
talk,
but
the
value
of
monitoring
and
observability
is
is
tantamount
and
crucial
in
this
space.
Again,
when
everything
is
broken
up,
tiny,
tiny
parts,
those
those
reversions
become
a
lot
easier.
That's
a
big
ones,
we're
just
about
on
time
the
network,
or
we
have
a
few
more
questions.
E
A
That's
a
that's
a
phenomenal
question:
I
tend
to
see
agile
as
a
as
a
process,
enhancement,
cloud
native,
heavier
on
a
technology
or
architecture,
enhancement
and
DevOps,
as
both
technology
and
culture,
and
so
really
cloud
native.
A
component
of
it
is
DevOps.
Essentially
cloud
native
is
DevOps,
see
I,
CD
containers
and
micro
services,
so
that
cultural
component
is
is
very
heavy
in
adopting
those
and
the
teams,
I
would
say
that
the
the
idea
of
owning
the
pager
this
is.
A
This
is
one
where
I've
seen
where
you
you
break
out
into
micro
services
in
an
older
world
style
in
a
pre
DevOps
world
you
would
have
one
organization
is
writing
the
code
and
they
ship
it
over
the
fence,
and
somebody
else
is
responsible
for
keeping
it
up
and
that
type
of
cultural
breeds
animosity
it.
It
makes
it
very
difficult.
This
organization
is
rewarded
for
moving
innovation
forward,
and
this
organization
is
essentially
they're
rewarded
on
reliability,
so
they're
incentivized
to
actually
slow
innovation.
A
So
those
two
cultures-
don't
necessarily
mishmash
I've,
seen
this
in
in
several
ways
broken
up
where
folks
can
be
on
a
cross-functional
team
where
that
cross-functional
team
ships
and
then
operates
the
software
and
I've
also
seen
it
as
like,
where
I
showed
on
the
slide,
where
they
own
different
parts
of
it,
but
that
ownership
of
the
operation
of
the
service
is
a
cultural
component.
That
says
when
this
thing
goes
down,
I'm
gonna
get
paged
for
it.
I
have
an
ownership
of
it.
I'm
going
to
frankly
ship
higher
quality
code.
A
I
heard
a
story
recently
that
there
was
and
the
car
warranty
manufacturing
line
when
they
took
the
folks
that
were
responsible
for
engineering,
the
car
and
then
said.
Ok
in
three
years,
you're
gonna
be
responsible
for
warranties.
Well,
they
really
changed
how
they
designed
the
car
and
they
avoided
things
like,
for
example,
making
it
so
that
you
had
to
take
out
the
entire
engine.
A
If
you
want
to
replace
a
headlight,
because
they
knew
I'm
going
to
have
to
deal
with
that
problem
down
the
road,
and
so
so,
culturally,
the
culture
of
ownership,
where
you're
not
siloing
out
your
teams
by
function
but
they're
they're
able
to
work
across
functionally
that
type
of
cultural
enhancement
is.
It
comes,
comes
part
and
parcel
with
DevOps
and
cloud
native.