►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Panel Discussion: Leveraging Cloud Native Technology to Transform Your Enterprise - Cheryl Hung, CNCF; Brad Topol, IBM; Ken Owens, Mastercard; & Jeff Brewer, Intuit
Cloud Native Technologies are experiencing dramatic growth and achieving widespread support as the de facto standard platform across a variety of industries. Kubernetes, containers, and related cloud-native technologies and tools have the potential to dramatically transform the enterprise. From enabling enterprises to modernize legacy applications, to automated DevOps release pipelines, to automated failure recovery and improved testing methodologies, the list of innovative development and operational practices emerging based on cloud native technologies is amazing and a tremendous opportunity for enterprises. This panel will bring together stakeholders from enterprise IT & open src cloud vendors to discuss how the various facets of cloud native technologies can dramatically transform the enterprise. Panelists will discuss the key innovations that are emerging from cloud native technologies to drive more efficient development and improved standardized operational practices to accelerate the digital transformation and modernization of the enterprise.
https://sched.co/Mnlb
A
C
My
name
is
Brad
Topal
I'm,
an
IBM
distinguished
engineer
of
open
technology
and
developer
advocacy,
I'm,
a
coop
contributor.
Remember
the
coop
conformance
workgroup
and
a
coop
doc.
Maintainer
I
also
lead
a
large
team
that
contributes
upstream
to
kubernetes
and
I
have
responsibility
for
the
content
we
create
for
containers
and
kubernetes
tutorials
blogs,
learning
paths
for
external
developers.
D
Hi
I'm
Ken,
Owens
I
work
at
master
code
I
lead
the
cloud
native
engineering
team,
which
consists
of
all
the
app
dev
development
teams,
the
tooling
for
the
teams.
Some
of
the
infrastructure
automation
work
that
we
have
to
do
to
kind
of
get
ready
for
cloud
and
I
work
with
a
lot
of
the
platform.
Engineering
teams,
doing
kind
of
the
pivotal
platform
stuff
as
well
great.
A
So
the
way
this
is
going
to
work
is
I'm,
going
to
ask
a
few
questions
to
the
group,
and
each
of
you
can
respond
in
turn
and
hopefully
we'll
have
some
time
for
audience.
Questions.
There's
a
microphone
here,
so
I'll
run
around
and
we'll
get
that
for
the
video
so
but
first
off
these
around
for
applause
to
welcome
and
we
thank
you.
Every
panel.
B
We
decided
to
invest
very
heavily
in
building
our
own
private
data
center,
and
so
we
were
a
private
data
center
in
Quincy,
Washington,
hosted
system
for
the
most
part
and-
and
we
started
to
have
you
know
some
outages
and
whatnot
and
into
it
wasn't
really
even
had
outages
before
that
and
into
it.
Isn't
really.
You
know
the
the
house,
not
expertise
to
run
and
build
a
datacenter,
and
so
at
the
time
we
reach
out
to
AWS
and
started
a
big
partnership
with
them
and
mostly
have
lifted
and
shifted.
B
But
what
we
really
want
as
the
developer
experience
that
is
provided
by
the
community
and
so
our
journey
started
with
we
acquired
a
company
called
a
plot
X,
which
was
a
consulting
company
doing
kubernetes
and
some
super
super
talented
engineers
that
were
working
in
the
kubernetes
space
really
understood.
It
very
very
well
understood
how
to
do
enterprise
projects,
and
we
immediately
after
that
acquisition
closed,
started,
rolling
out
kubernetes
as
a
as
a
as
a
deployment
orchestra,
container
orchestration
system
add
into
it
and
started
onboarding
hundreds
and
hundreds
of
our
services
onto
that
platform.
B
We
had
to
make
it
a
little
bit
into
it.
We
have
frozen,
you
don't
know
into.
It
is
a
little
bit
like
a
bank
not
fully
a
bank,
but
we
have
a
lot
of
compliance
needs.
We
also
have
a
lot
of.
Obviously.
Security
is
extremely
extremely
important
because
we
deal
with
financial
data
both
on
tax
filings
and
also
financial
data
for
small
businesses,
and
so
on
top
of
that
base.
Kubernetes
we
started
adopting
technologies
like
service,
mash
and
open
policy.
Agent
is
something
that's.
A
C
So
IBM's
journey
is
one
that
includes
having
private
cloud
public
cloud,
hybrid
cloud
and
multi
cloud
offerings,
so
providing
a
lot
of
flexibility.
A
lot
of
the
lessons
learned
would
come
on
the
public
cloud
side.
We
have
airline
companies
and
car
rental
companies
and
weather.com
that
that
all
run
on
our
public
cloud
and
lots
of
lessons
learned.
We
migrated
wthr.com
over
in
six
months
to
run
on
our
managed
kubernetes
service.
C
That
is
most
of
you
see
this
and
when
you
ever
get
your
weather
forecasts,
that's
something
that
has
30
million
users
a
day,
it'll
ramp
up
to
a
hundred
million
users
a
day
it
will
have
when
there's
like
a
hurricane,
and
it
has
it
does
one
kill
of
a
one.
Kilometer
grid
forecast
every
day,
250
billion
of
those
a
day.
C
So
what
we
learned
is
scale
is
huge
and
the
ability
that,
when
major
storm
hits
to
be
able
to
rapidly
Excalibur
came
comes
the
amount
of
data
that
it's
processing
and
giving
out
to
the
to
its
stakeholders
will
increase
like
five
times
and
then
the
other
huge
thing
is
curity
from
from
our
enterprise
customers,
image
scanning
security,
trust
of
what
the
images
are
doing
and
DevOps
tools
there's
no
way.
We
can
do
this
and
have
those
types
of
applications
without
providing
a
large
amount
of
DevOps
tools
to
make
that
possible.
A
D
Master
Kota
has
a
store
on
the
journey,
I
would
say
when
I
quite
arrived.
Yet,
as
you
know,
as
a
credit
card
company,
you
have
a
lot
of
payment,
transaction
processing,
Network
stuff,
a
lot
of
security
fraud,
detection
authorization,
we
our
own
certificate
authority.
We
don't
trust
anyone
else
right.
D
So
we
have
to
you
know,
there's
a
lot
that
you
had
to
kind
of
design
and
build
into
that
that
transaction
network,
and
so
a
few
years
ago
we
started
acquiring
acquiring
companies
that
were
built
in
cloud
and
the
speed
and
agility
was
so
much
greater
than
what
we
could
do
and
master
kai.
That
I
president
said
you
know
we
need
to
be
like
instant
and
perfect
every
time,
and
so
I
came
over
not
too
long
after
that.
D
I
started
working
on
on
the
move
towards
cloud
native
moved
towards
cloud
services
which
we
played
around
in
the
cloud
a
little
bit.
Well,
not
there,
yet
mostly
on
trend
clouds.
What
we've
been
developing
and
a
lot
of
legacy
automation
needed
to
like
just
build
infrastructure,
a
lot
quicker,
a
lot
more
efficiently
and
a
lot
less
error-prone
as
I
kind
of
started.
D
This
whole
journey
and
the
lessons
we've
learned
have
a
lot
to
do
with
just
the
people
and
the
culture
having
to
really
change
the
way
people
think
about
their
jobs
as
as
engineers
that
are
automating
what
they're
doing
not
just
you
know,
technicians
that
can
log
into
a
device
and
make
configuration
changes
to
it.
A
lot
of
the
DevOps
practices
were
not
there,
and
so
we've
been
kind
of
building
this
DevOps
culture
within
the
operations
team,
but
also
within
the
development
teams.
D
They
were
writing
their
own
pipelines
and
each
development
team,
even
each
application
itself,
depending
on
who
the
last
app
update
was
the
pipeline
was
completely
different
for
each
one
of
them,
and
so
just
doing
things
like
helping
them
understand
what
DevOps
means,
what
you
know
a
CI
capability
processes
how
to
do
Bluegreen
deployments.
You
know
these
are
things
that
they
just
never
thought
of
Bluegreen
deployments
performance.
D
We
do
a
lot
of
I
do
a
lot
of
education
and
a
lot
of
you
know,
sitting
down
and
pair
programming
next
to
them
to
help
them
understand
how
to
do
these
things,
and
so
a
lot
of
a
lot
of
good
lessons
learned
a
lot
of
progress
made
and
turning
things
around
within
two
years
that
I've
been
there.
It's
gone
from
well
I
thought
we'd
never
make
the
turn
to
actually
were
accelerating
what
we've
been
doing.
So
it's
been
good
great.
C
Marya
ly
great
question
and
what
we
like
to
do
is
show
them
what
the
art
of
the
possible
is,
when
you
start
embracing
the
capabilities
of
something
like
kubernetes
and
the
declarative
model.
So,
for
example,
we
can
start
by
showing
how
there's
these
docker
files
that
you
can
always
as
a
dev
of
small.
You
can
always
be
generating
your
daughter,
your
docker
files,
and
so
you
can
store
them
in
your
source
code
repository
and
you
can
also
have
all
the
yeah
mole
for
kubernetes
everything's
in
jamol's.
So
you
have
all
this
stuff.
C
That's
now
declarative,
and
so
you
know
previous
cloud
infrastructures.
You
would
use
something
like
a
chef
or
puppet.
Nobody
knows
exactly
what's
happening
here.
You
can
talk
about
these.
This
is
describing
exactly
what
you're
gonna
deploy.
Everybody
can
see
it.
If
anybody
makes
a
change,
it's
gonna
be
in
github,
it's
in
the
zoom.
You
know
you're
the
you.
You
can
see
the
changes
that
were
made,
and
so
you
start
there
and
then
you
show
the
power
of
being
able
to
deploy
cloud
native
applications
and
obviously
that
no,
you
can
have
multiple
replicas.
C
You
can
do
lots
of
deployments,
and
so
it's
easy
to
do.
Upgrades
it's
easy
to
scale
up
all.
That's
really
good
and
you
show
them
with
sort
of
the
new
application
and
they
think
well,
that's
great.
But
all
my
stuff
is
is
legacy
Enterprise
middleware
and
then
that's
where
we
like
to
come
in
and
say:
well,
you
know
we
have
all
that
legacy.
Enterprise
middleware
already
made
available
as
containers,
and
we
already
have
helm
charts,
which
is
the
kubernetes
templating
model
for
for
those
jamol's
to
the
play.
C
So
now,
I'm
not
focused
on
the
new
stuff
that
you
weren't
quite
as
excited
about.
Let
me
show
you
all
this
middleware,
whether
it's
a
db2,
an
MQ,
something
with
Kafka
all
of
this
available
for
you
and
now
you
can
get
this
up
and
running
in
minutes
as
opposed
to
weeks
and
when
you
take
them
on
that
journey,
and
then
you
get
to
the
point
where
it's
all
about
that
done
prize
middleware!
That's
when
it
clicks
that
hey
I
really
can't
make
this
work
can.
B
Is:
we've
really
found
that
the
innovations
in
the
community
have
really
resonate
with
the
developers
and
it
speaks
for
itself
a
lot
when
you
see
teams
onboarding
onto
onboarding
their
service
on
the
kubernetes
and
they're
like
wow.
This
is
I
can
understand
this.
This
is
this.
Is
you
know
the
the
declaration,
the
separation
of
concerns?
It
all
makes
a
lot
a
lot
of
sense,
and
so
that
is
a
argument
that
also
works
very
well
for
force
or
the
CTO
in
this
year.
Leadership
style
just.
D
Just
to
add
one
last
thing
to
this:
the
in
a
company
that
has
you
know
a
global
presence.
This
24/7
can
never
go
down
right.
Your
CTO
really
doesn't
care
if
their
application
teams
are
happy
or
not,
they
want
to
deliver
the
service.
They
want
the
service
to
be
reliable,
they
don't
want
to
ever
go
down,
and
so,
if
you're
in
that
type
of
a
environment
where
you
you
really
can't
just
say
look,
this
is
a
better
way
to
do
it
because
it
it's
obvious,
it's
a
better
way
right
and
the
CTO
isn't
dumb.
D
B
A
So
for
an
enterprise
CTO,
there's
three
areas
that
they
need
to
consider
when
moving
from
traditional
IT
to
ords
cloud
native.
So
the
first
is
the
architectural
decisions.
Architectural
design.
Second,
is
the
impact
that
it
will
have
on
application
developers
and
platform
developers,
and
the
third
is
the
impact
it
will
have
on
operations.
A
A
D
Start
this
one
so
I
think
that
the
first
consideration
I
would
bring
up
is
what
we've
been
through
at
MasterCard
is
helping
making
sure
that
the
legacy
infrastructure
is
moving
towards
the
new
cloud
native
infrastructure.
App
teams
want
to
get
kind
of
tied
up
and
do
I
deploy
to
the
legacy
or
do
I
deploy
to
the
new,
and
we
don't
want
them
to
even
think
about
what
it
is
legacy.
D
You
just
write
your
code
test,
the
code
deploy
the
code
and
where
it
lands,
you
don't
need
to
worry
about
that
right,
and
so
that's
kind
of
what
we
started
was
the.
Let's
make
sure
the
platform
becomes
a
platform,
and
it's
not
a
bunch
of
disparate
systems
that
the
app
teams
have
to
try
to
figure
out.
How
do
I
use
them?
It's
they
write
their
code
deployed
and
it
doesn't
have
to
matter
where
it's
at
I
think.
B
Just
adding
on
one
more
thing
to
that
really
on
architectural
consideration
is
about
the
the
deployment
process
right,
having
a
lot
of
integrity
in
the
deployment
process
from
you
know
whether
you're
in
public
or
private
cloud.
It's
it's
really
about
you.
What
you
the
the
thing
that
we've
found
the
best
mechanism
for
that
is
really
is
doing.
Something
called
get
ops
where
you're
we're
get
is
really
the
source
of
truth
for
your
for
both
your
deployment,
deployment,
description
and
your
code,
and
so
it's
really
clear
from
you
know
from
the
source
code
system.
C
What
we
look
at
is
from
an
architectural
perspective,
we're
gonna
really
emphasize
flexibility.
You
know
you
make
sure
you
have
things
such
that
you
can
run
stuff
on
Prem
if
it
needs
to
run
on
Prem.
You
have
stuff
that
if
you
choose
to
run
on
one
or
multiple
public
clouds
that
it
can
run
on
one
or
multiple
public
clouds,
so
being
able
to
support
all
of
that
and
a
hybrid
cloud
is
very
important,
also
as
part
of
the
architecture.
You're
probably
gonna
have
to
have
a
discussion.
C
It
always
comes
down
to
security,
so
they're,
probably
going
to
have
a
security
team
and
the
security
team's
gonna
have
lots
of
concerns
and
being
able
to
look
at
like
how
in
kerbin
Eddie's
a
lot
of
security
is
done
with
declarative
policies.
Just
like
everything
else,
you
can
sort
of
hopefully
bring
that
security
team
out
of
the
Stone
Age
and
say:
look
you
can
have
buy-in,
you
can
help
define
the
policies.
You
can
see
everything
this
shouldn't
make
you
nervous,
let's
feel
comfortable
moving
forward,
would
do
these
news
technologies
and.
C
C
Based
on
you
know,
are
they
willing
to
move
to
the
to
the
to
the
managed
service,
because
the
the
the
wonderful
thing
you
can
say
is:
listen
if
you're
willing
to
go,
try
the
public
cloud.
You
get
to
start
tomorrow
right
if
you're,
gonna
you're
not
quite
comfortable
yet
well,
and
you
want
to
do
our
on
print
stuff.
It
might
take
a
few
months
before
you
get
up
and
rolling,
so
they
have
to
to
make
that
trade-off
of.
Well,
do
I
want
to
start
tomorrow,
which
would
really
be
great.
C
B
Gonna
add
on
on
on
there.
You
know
from
the
Intuit
perspective,
I
think
one
of
the
hurdles
that
we
have.
We
really
preferred
the
public
cloud
overall,
just
you
know
learning
from
not
being
able
to
manage
our
own
data
centers.
We
had
a
pickup
truck
drive
into
a
light
pole
in
San,
Diego
and
I
took
down
one
of
our
data,
centers
right
and
so,
and
and
so
with
that
consideration
that
the
really
the
barriers
were
around
a
lot
of
it
was
around
compliance,
and
so
that's
a
thought
can
be
a
really
key
consideration.
B
Do
you
have
things
like
HIPAA
and
or
or
NIST,
or
some
some
things
where
there
isn't
necessarily-
and
maybe
this
is
true-
a
little
bit
more
a
couple
a
few
years
ago,
I'm
in
the
public
cloud,
where
you
wouldn't
be
able
to
get
those
certifications
there,
but,
but
you
know,
as
that's
all
progressed.
Gdp
are
all
that
stuff
that
you
can
now
do
these
certifications
and
in
the
public
cloud
and
so
there's
there.
You
know
there
may
be
some.
B
D
But
there's
been
the
the
other.
The
other
important
lesson
there
is
from
a
security
standpoint.
You
you
really
need
to
understand
the
security
posture
you're
moving
towards,
as
was
brought
up
and
in
a
MasterCard
case.
We
have
contracts
with
a
lot
of
banks
and
a
lot
of
other
third
party
issuers
and
other.
You
know
merchants
out
there,
and
so
each
of
those
contracts
was
signed
back
in
the
Stone
Age.
Were
you
know?
Internet
was
a
everybody's
afraid
of
us.
They
put
in
their
closets.
D
D
You
don't
get
that
in
the
cloud
you
you
have
to
kind
of
trust
that
your
development
teams
wrote
their
applications
to
be
turned
off,
to
be
ephemeral,
to
lose
state
and
be
able
to
come
back
up
and
recover
on
their
own
that
they
were
designed
for
failure
which
a
lot
of
app
teams
again.
Don't
have
that
muscle
built
very
well
yet,
but
if,
if
it's
done
right,
I
think
it's
the
best
place
to
run
your
applications,
but
you
have
to
you
have
to
do
it
right.
That's.
A
C
D
Was
definitely
I
was
going
to
say
to
it
the
easier
you
make
the
integration
between
the
two,
the
better,
the
API
first
kind
of
designed?
If
you
don't
go
out
in
that
path,
you
just
and
I've
seen
this
in
other
companies.
You
have
a
lot
of
tension
between
the
two
groups,
because
once
they
line
on
the
other
one
to
do
something
and
that's
not
a
good
place
to
be
in.
B
We
still
have
a
few
amount
of
monolithic
code
bases
where
the
platform
and
the
application
is
is
a
little
bit
merged
together.
But,
but
you
know,
I'd,
echo
of
those
things
I'd
also
add-
is
that
the
you
know
that
the
API
and
that
layer
that
think
of
that
as
a
as
a
product
and
think
of
that,
as
that
is
the
interface
you
know
really
between
the
applications
and
the
more
backend
of
the
platform
and
it
it.
It
needs
to
be
well-documented,
clear,
clear
contracts.
It's
not
super
super
important,
so.
C
B
B
It's
not
like
rolling
out
something
like
sto
is
not
for
the
you
know,
not
for
the
the
newbie
right
and
but
we
see
the
we
see
those
benefits
we're
always
after
those
those
benefits
of
you
know,
ubiquitous
mesh
where
you
can
get
telemetry,
you
can
get
tracing
and
get
all
that
kind
of
stuff
for
free
right,
and
so
that's
what
makes
us
ready
for
it
is.
We
feel
like
we're
kind
of
blind
app
operating
our
applications
right
now
and
that
that
lets
us
see
and
and
introspect
into
them
on
the
server
list
front.
B
B
C
You
know
my
short
answer
is
going
to
be:
yes,
we
have
a
service
mesh
sto
available
as
a
beta.
We
also
have
server
lists
and
form
of
K
native
available
on
our
public
cloud
as
experimental
and
the
interesting
thing
about
it.
You
know
when
you
take
something
like
kubernetes
and
sto
and
k
native
you,
you
know
what
we're
starting
to
see,
and
this
is
for
some
of
the
folks,
like
myself,
who've
been
around
for
a
while
we're
starting
to
see
these
types
of
things
come
together
and
actually
provide
you
a
unified
platform.
C
So
the
analogy
I
like
to
use
is
way
back
when
I
know
the
sky
remembers,
as
you
know,
remember:
j2ee
right.
We,
it
was
the
the
application
platform
and
you
worried
about
just
building
your
app
right
and
then
the
whether
it
was
WebSphere
or
what
have
you,
provided
you
so
much
functionality,
what
we're
expecting
to
see
and
what
we're
seeing
is
between
the
kubernetes,
the
K
native
and
the
ISTE.
Oh,
you
got
to
use
certain
things
for
the
right
things.
C
D
I
know
we're
working
with
them,
but
they're
not
quite
to
the
point
that
our
security
team
feels
secure
in
it.
And
then
you
guys,
if
you
use
your
credit
card
I'm
hoping
you
agree
with
that,
you
don't
want
us
just
trying
out
new
things
just
because
we
can,
and
so
so
what
we're
looking
at
it.
It's
kind
of
you
we're
testing
it
out
same
thing
with
serverless.
We
have
some
very
early
experimental
testing
going
on
with
Sevilla
stuff,
and
we
do
have
a
lot
of
use
cases.
There's
some
things.
D
We
feel
like
really
interesting
with
a
core
product
line
that
we're
looking
kind
of
next-generation
of
a
switch
architecture
and
the
switch
architecture
is
the
core
that
has
action,
processing
network
and
so
we've
done
a
little
bit
of
X.
You
know
experimentation
with
server
lists
out
at
the
merchants
and
out
in
the
cloud
so
that
the
credit-card
process
that
happens
out
at
the
edge
as
close
to
the
merchants
as
it
can,
which
is
kind
of
cool.
D
But
again
we
won't
be
doing
any
any
changes
there
until
we
have
it
all
rock-solid,
but
there's
definitely
interested
interest
in
looking
at
it.
And
that
kind
of
brings
that
the
big
point
I
want
to
make
was
that
in
this
environment,
things
are
changing
so
quickly.
You
almost
have
to
have
this
continuous
model
of
looking
at
new
technologies
and
and
playing
with
it,
because
at
least
at
magic
eyes
case.
D
D
Six
to
nine
months
before
they'd,
say
yeah,
you
can
put
this
in
the
stage
environment
and
have
app
teams
test
on
it
right,
and
so
it's,
if
you
get
the
technology
and
sooner
then
you
give
you
other
operational
teams
a
chance
to
kind
of
look
at
it
and
make
sure
that
they
buy
into
it,
which
takes
time
for
some
companies
and
that's
why
I
said.
Maybe
the
MasterCard
it's
a
no
for
other
enterprise.
That's
probably
yes,
because
they
can
move
faster
and
go
quicker,
but
we're
still
kind
of
it.
That
would
investigate.
Unit
phase
provides.
B
A
D
B
I
forgot
to
mention
earlier
than
I'm
the
end
user
representative
on
the
technical,
Oversight,
Committee
and
I.
Think
that
that's
the
there's
something
called
a
trail
map
I
think
you
guys
might
have
heard
of
and
I
think
that's.
That's
that's
one
of
the
biggest
things
I
think
that
the
that
the
kubernetes
community
or
the
the
overall
CN
CF
community
can
do
here
is
is
provide
some
of
those
guideposts
and
examples
for
what
to
use
right.
It's
a
it's
a
bit
of
a
paradox
of
choice
out
there
right,
there's
like
over
30
projects.
B
You
know
in
the
different
phases
of
graduated
incubation
and
whatnot
and
and
it's
a
little
bit
difficult,
sometimes
like
and
there's
open
source
projects
outside
of
the
CMC
F
official
projects.
And
how
do
you
figure
out?
You
know
what
you
should
use
to
piece
together?
Should
I
install
Jaeger
should
I,
you
know
you
just
don't
know
right
and,
and
so
with
this
large
end-user
community,
that's
growing
I
think
it's
over
80,
80
members
I
think
you
can
find
a
buddy.
B
C
I
I
mean
part
of
his
sort
of
keep
doing
what
we're
doing
the
community
from
what
I
could
see.
Does
an
outstanding
job
of
reaching
out
and
trying
to
grow
the
community
with
office
hours
with
mentoring,
feedback
sessions,
and
so
the
one
thing
I
would
like
to
point
out
for
enterprise
companies,
and
some
of
them
are
starting
to
see
this
and
there's
some
of
the
literature
out.
There
is
pointing
to
it.
C
It's
one
thing
to
just
consume
open-source
as
an
enterprise,
but
what
they're
seeing
is
if
they
let
their
folks
actually
join
in
the
community
and
contribute
upstream
to
the
open-source.
The
benefits
are
actually
much
greater,
there's
something
that
happens
as
you.
Let
your
people
go
mingle
in
with
the
community
and
then
think
of
all
the
people
that
they
learn
from
all
that
they
learn
from
and
all
that
they're
the
new
tools.
You
know.
C
Whenever
you
write
code
in
an
upstream
community,
you
write
it
and
then
20
people
smarter
than
you
show
you
20
better
ways
to
do
what
you're
doing
so.
The
amount
of
knowledge
that
comes
back
to
your
enterprise,
by
allowing
your
folks
to
actually
contribute
to
the
open-source
community
is
huge
and
I
just
say
you
know,
let's,
let's
keep
pushing
on
that
fantastic.
A
F
B
So
you
know
it
has
been
a
little
tricky
right
like
we.
We
noticed
that
languages
like
node
go
raus
these
ones
they
operate
better.
You
know
in
the
cloud
native
and
I
think
the
the
very
specific
problems
are
about
the
way.
Java
manages
its
memory.
It
usually
likes
to
take
a
big
chunk,
and
then
it
does
all
this
garbage
collection
inside
you
know
just
from
from
oh
well
and
also
the
the
open-source
aspect
of
all
of
us
are
aware.
B
What's
going
on
with
Oracle
and
the
JDK,
and
so
we've
we've
decided
to
move
towards
something
like
careto,
but
Red.
Hat
actually
has
a
really
interesting
thing,
and
this
isn't
something
that
I've
learned
yet,
but
I
want
to
learn
is
a
is
a
more
cloud
native
Java
container.
That's
not
just
a
JDK
installed
on
an
operating
system,
right,
they'll,
actually
more
natively
run
a
code
and
I.