►
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
Hello
and
welcome
everyone
to
a
very
special
live
stream
today,
with
the
team
from
Oracle
they've
been
incredibly
motivated
to
dive
into
contributions
around
all
of
our
Cloud
native
communities,
and
it
sounds
like
this
is
going
to
be
the
first
of
many
of
these
sessions.
I'm
really
excited
to
hear
more
of
their
experiences.
Today.
In
today's
session,
the
team
will
be
presenting
their
perspectives
on
cloud
native
adoption
in
an
Enterprise
setting.
A
This
is
an
official
live
stream
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct,
please
don't
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
Please
be
respectful
to
all
fellow
participants
and
presenters
be
excellent
to
one
another.
A
I
would
like
to
hand
it
over
to
rob
you
kick
off.
Today's
presentation
was
that
Rob,
please,
take
it
away.
B
Hey
thanks,
Taylor
I
appreciate
it.
It
has
been
a
great
pleasure
working
with
the
cncf,
especially
over
the
last
six
months,
and
we've
had
some
real
good
collaboration
in
terms
of
webinars
and
and
other
streams
of
you
know.
B
Projects
and
I
really
look
forward
for
the
series
of
webinars
that
we're
going
to
do
jointly
with
cncf,
Oracle
and
cncf,
and
my
role
with
an
oracle
is
I,
lead,
open
source
initiatives
for
Oracle
cloud
and
I'm
very
excited
to
have
this
panel
of
speakers
here
who
are
extremely
qualified
when
it
comes
to
cloud
data
with
that
I'll
pass
it
on
to
the
lead
speaker
of
today's
session
Nova.
C
Hi
hi,
everybody
welcome,
so
sure
goal
we
you
know,
we've
got
quite
a
bit
of
involvement
and
a
lot
of
different
open
source
ecosystems,
including
the
cnci
Athletics
Foundation.
E
C
Doing
our
part
to
be
good
citizens,
and
we
want
to
share
our
knowledge
and
our
experiences
where
we
can
so
for
this
particular
session,
we're
leading
up
to
a
major
conference.
We've
got
kubecon
coming
up
next
week
in
Detroit
for
those
of
you
who
are
watching
this
after
the
fact
now,
you'll
know
when
this
took
place
and
typically
there's
a
lot
of
conference-led
development.
You
you've
got
people
who
are
going
to
talk.
C
Et
cetera
and
knowing
that
that
was
going
to
be
flooding
your
stream,
we
wanted
to
give
everybody
a
little
bit
of
a
break
from
that,
so
we're
here
to
give
you
value
based
not
on
what
we're
trying
to
announce
but
based
on
our
experiences
with
the
expectation
that
anyone
who
might
be
attending
the
conference,
whether
it's
going
to
be
physically
virtually
watching
the
videos,
weeks
or
months
from
now
on,
YouTube
or
just
considering
the
content
and
trying
to
ingest
it
all
that
we,
when
you're,
trying
to
get
those
takeaways
from
the
sessions
that
you
can
bring
home,
that
you
can
apply
to
your
day,
job
that
the
Insight
that
we'll
be
able
to
share
here
can
help
you
get
additional
value
out
of
the
event
out
of
the
sessions
that
you're
going
to
watch
and
about
just
in
general,
being
able
to
apply
these
principles
to
whatever
it
is
you're
working
on.
C
So
the
people
we've
got
today.
We've
got
a
handful
of
folks
and
they
represent
several
different
product
teams
from
within
Oracle
we've
got
some
app
spokes.
We've
got
some
platforms,
some
Services
some.
C
The
truth
is
that
you
know
there
will
be
a
little
bit
that
will
make
it
special,
but
most
of
the
patterns
that
are
going
to
come
up
are
going
to
be
patterns
that
you'll
see
again
and
again,
they're
not
going
to
be
that
different,
especially
in
a
large
Enterprise
environment
like
we're
in
so
we're
here
today
to
ask
the
panelists
a
handful
of
questions,
we're
going
to
ask
each
of
the
teams
to
answer
each
of
our
questions
and
then
you,
the
viewer,
can
compare
and
contrast
mentally
those
answers,
while
you're
ingesting
that
future
content-
and
we
hope
it's
going
to
provide
some
perspective
on
how
you
ingest
the
content
and
how
you
approach,
learning
and
making
it
part
of
your
daily
life.
C
So
we
don't
have
any
slides
or
anything.
This
is
just
going
to
be
a
lot
of
q
a
and
we're
going
to
start
with
some
introductions.
I'll
start
with
myself.
I
am
Noah.
C
Am
the
first
AC
and
CF
Ambassador
and
now
a
senior
principal
technical
program
manager
here
at
Oracle
and
my
day,
job,
which
is
this
revolves
around
enabling
people
who
want
to
contribute
to
cncf
projects,
contribute
to
the
ecosystems
and
generally
being
in
good
system.
C
So
I
went
first
because
I
don't
have
a
product
or
project
on
the
line
here
now
for
each
of
the
panelists
I
want
you
in
a
couple
of
Senses,
introduce
yourself
and
also
if
you
could
very
briefly
describe
your
product
or
project
that
you
work
on,
so
that
when
we
go
through
these
questions,
people
will
understand.
Oh
that's!
That's.
C
Works
on
X,
Y
or
Z
I'm,
just
gonna
go
by
who's
on
my
screen
in
order,
so
I'm
gonna
start
with
Brad.
G
Thanks
Noah
Brad
Sergeant
I'm,
a
senior
architect
for
Oracle
CX
marketing
I've,
been
with
Oracle
for
20
over
22
years.
G
We
have
B2B
and
BDC
SAS
marketing
products
that
we
sell
and
build,
and
also
CDP
that
that
we
have
were
also
developing
and
selling,
and
we've
been
I've,
been
working
in
SAS
for
I've,
been
architecting
SAS
for
the
whole
time
been
at
Oracle,
20,
23
years
really
Oracle
and
before
that
responses
which
Oracle
bought
and
it
been
working
in
containers,
since
probably
2016,
is
when
we
had
to
make
the
change
from
our
own
bare
metal
servers
into
the
start,
using
more
of
the
open
source
and
container
mechanisms,
and
it
was
probably
around
that
era.
G
2016
and
since
then,
it's
been
straight
on
until
morning.
C
Awesome
next
introduction:
let's
go
to
subang
card.
D
Hey
hi
everyone
thanks
for
that
good
morning,
good
evening,
the
folks
running
from
everywhere,
so
my
my
name
is
Lanka,
so
I
I'm
part
of
Oracle
applications
lab
oil.
Here,
it's
an
internal
team
within
Oracle
and
we
kind
of
manage
all
of
Oracle
SAS
implementation,
so
HR
sales
Finance.
All
of
that
actually-
and
we
also
build
the
extensions
to
those
SAS
applications
on
the
platform
and
the
infrastructure
side
of
it.
D
Actually,
I
have
been
involved
with
the
cncf
projects
for
a
little
over
five
years
now,
actually
starting
off
with
kubernetes
service.
Mass
and
couple
of
other
projects
around
it
and
I
basically
lead
the
platform
and
infrastructure
engineering
team
here
at
oil
and
primarily
responsible
for
app
modernization
and
Cloud
native
adoption
within
the
organization.
C
E
Hey
guys,
hello,
everyone,
I'm,
udayan,
sahu,
I,
work
with
Brad
in
the
same
organization,
basically
working
on
CX
marketing,
the
platform,
both
V
to
B
and
b2c.
E
As
my
role
in
Oracle
before
Oracle
I
had
done
a
couple
of
startups
and
love
to
play
with
new
technologies
and
luckily,
in
Oracle
also
I
got
a
similar
role,
where
I
am
basically
typically
I'm
a
to
look
at
newer
Technologies
and
their
adoption
relevance
to
the
product
and
other
things,
and
when
we
started
our
move
into
oci,
that's
where
picked
up
multiple
cncf
projects
and
evaluated
in
many
of
them.
E
E
We
are
still
excited
with
the
products
which
they
offer
and
looking
forward
how
they
evolve
from
it.
Thank
you.
C
And
last,
but
certainly
not
least,
we'll
pass
it
over
to
Sandy.
F
Cool
thanks,
Noah,
hey
everyone.
My
name
is
Sandeep
gurum
I'm
part
of
CX
service
organization,
so
my
journey
with
Cloud
native
started
with
with
it
really
a
need
a
releasing
software
faster.
We
started
with
the
KV.
We
really
need
to
get
our
software
out
there
faster.
F
What
can
we
do
and
then
we
just
you,
know
one
thing
after
the
other,
we
kept
on
exploring
more
and
more
Cloud
NATO,
and
here
we
are,
you
know,
five,
six
years
later,
we're
fully
collab
native
and
everything
we
developed
in
all
the
new
applications,
so
yeah,
that's
kind
of
how
our
journey
started
with
with
the
need
to
get
software
out
there
faster.
C
Awesome,
thank
you.
You've
all
sort
of
touched
on
the
first
question
that
I
wanted
to
dive
into,
which
is:
how
did
your
project
start
using
the
cloud
native
ecosystem?
How
did
you
get
involved
with
using
the
projects,
and
you
know
it?
It
sounds
like
nobody
really
started
there
that
there
was
an
evolution.
So
if
people
could
talk
a
little
bit
about
what
the
evolution
was
for
incorporating
cncf
projects
into
what
you
were
working
on
and
what
you
were
building,
that
would
be
fantastic
as
well.
G
It
was
an
interesting
we
sort
of
backed
into
this.
We
we
had
been
building
our
own
data
centers
for
for
a
long
time
since
2000,
really
1999,
really
and
and
doing
SAS
products
and
using
bare
metal,
Oracle
bot
responses.
That
I
was
architect
for
in
2014,
and
we
were
having
to
convert
over
to
use
these
large
Computing
systems
much
too
big
for
a
single
application.
And
so
we
were.
G
We
first
looked
at
VMS
to
try
and
solve
that
problem,
but
the
VMS
had
performance
limitations
for
maybe
15
20
percent
of
our
applications
created
too
much
latency
the
with
a
lot
of
different
complex
systems
we
had
to
develop
and
and
the
latency
and
the
and
the
throughput
was
really
critical.
So
we
thought
well,
let's
look
at
containers
and
and
I
was
actually
given
the
job
to
do
that
and
found
that
I
could
I
could
develop.
G
I
could
use
container
technology
and
have
basically
no
overhead
in
IO,
and
we
use
Mac
VLAN
for
our
network
connection.
So
the
network
was
really
fast
and
direct
connection
for
that.
I
ended
up
taking
all
the
Legacy
applications
and
converting
them
into
containers
in
2016
and
and
that
that
was
still
in
our
in
our
Legacy
data
centers
our
data
centers.
We
were
running
over
the
next
couple
of
years.
G
We
evolved
and
picked
up
more
and
more
open
source
technology
from
that,
and
we
moved
to
the
oci
and
the
process
of
moving
to
oci.
We
picked
up
kubernetes
before
that.
G
We
have
been
using
Docker
compose
on
individual
machines
and-
and
you
know
the
using
Prometheus
and
filebeat
and
and
node
exporter,
and
things
like
that
to
to
handle
that
ourselves
moving
to
oci
opened
it
up
quite
a
bit
and
then
we've
focused
on
how
to
on
how
how
we
could
use
kubernetes
to
to
provide
a
more
elastic,
more
live
environment
where
we
weren't
managing
our
containers
and
statically
allocating
the
individual
servers,
so
that
really
shifted
for
us
around
2018
and
then
once
we
were
in
oci
it
just
in.
G
In
that
environment,
we
were
able
to
be
much
more
Cloud
native
and
all
of
our
approaches.
Automating
everything
and
and
using
things
like
we're,
we're
using
like
I
mentioned
Prometheus
and
I
I.
Didn't
write
it
down
a
bunch
of
projects
that
are
actually
even
newer
came
up.
What's
the
what's
the
what's
the
great
project,
that's,
that
is
the
is
the
workflow
engine
we're
using
Argo
for
custom
ETL,
which
has
really
been
a
lifesaver
for
us
cute
little
project
and
and
that's
actually
more
recent.
G
So
anyway,
it
continues
to
evolve.
Now.
Udai
is
more
Hands-On
on
that
stuff,
so
I'll.
Let
him
talk
more
about
the
details
going
forward
and
the
more
modern
stuff
we're
doing
go
ahead.
E
Thanks
Brad
yeah.
Basically,
as
you
know,
maybe
we
started
revolving
and,
as
we
started,
seeing
our
goals
so
one
of
the
goal
when
we
were
doing
with
Docker
compose
and
other
things,
it
took
a
kind
of
kind
of
a
quite
a
bit
of
a
time
to
actually
maintain
the
the
container
States
and
even
the
deployment.
E
So
like
the
one
of
when
we
moved
into
oci,
the
goal
was
like
okay:
how
can
we
cut
down
a
three-month
deployment
period
to
probably
weeks,
and
that
was
a
bit
possible
like
kubernetes
and
other
things?
They
they
really
managed.
Those
things
well
and
taken
basically
gave
us
a
really
leg
up,
as
we
moved
along
yeah,
there
were
okay,
I'll
I'll
pass.
Probably
I
I
can
keep
talking
on
the
this
topic.
But
let's,
let's
hear
from
other
panelist
yeah.
C
Okay,
let's
pass
it
over
to
subankar
for
the
same:
hey,
Evolution,
good.
D
Yeah,
so
our
journey
is
kind
of
similar
but
more
on
the
platform
side
of
things.
So,
as
I
said
so,
the
organization
itself
is
huge,
so
we
have
about
like
500,
2000
developers,
actually
right
so
across
various
functional
groups.
D
Now
our
journey
like
we,
we
run
this
corporate
applications
which
are
running
in
our
Legacy
data
centers
for
more
than
a
decade
or
so,
and
there
was
this
push
from
management
back
in
2015
to
16
when
they
wanted
to
move
everything
from
on-premise
data
centers
to
oci
and
also
on
the
SAS
side
of
things
he
wanted
to
move
to
the
Oracle
Cloud
Erp
Cloud
HTML,
those
right.
So
there
was
a
need
to
modernize
these
applications
and
the
monolith
applications
which
are
built
for
years.
D
I
mean
we
looked
at
how
we
could
re-architect
those
and
come
up
with
a
microservice
platform.
Actually
so
because
that
was
the
Crux
of
it
and
to
make
sure
all
these
developers
are
able
to
build
agile
applications
and
also
meet
our
timelines
aggressive
timelines.
So
we
we
looked
at
various
things,
so
we
started
off
initially
by
running
something
on
container
cloud
service
which
was
built
on
Docker
swarm.
D
This
was
back
in
2017,
but
the
world
has
already
moved
around
kubernetes
back
then
so
2018
roughly
I
joined
the
kubecon
in
Seattle
and
that's
where
we
kind
of
opened
up
to
the
whole
ecosystem
right,
it's
not
just
kubernetes.
Actually,
there
is
an
whole
ecosystem
around
it,
where
you
have
several
of
the
CNC
projects
that
enable
you
to
build
this
platform
thing
right.
D
So
we
come
back
back
and
start
putting
together
the
pieces,
and
then
we
decided
the
the
base
of
the
platform
is
going
to
be
obviously
kubernetes
and
luckily
oci
had
a
managed
kubernetes
offering
back
then,
which
was
okay,
that
that
helped
us
a
lot
because
kubernetes
itself
is
complex,
so
you
don't
want
to
be
managing
it
on
your
own,
actually,
the
control
plane,
at
least
so
we
took
that
as
the
basis
of
our
platform
and
then
what
we
needed
on
top
of
it
was
a
service
mess,
because
one
of
the
challenge
that
we
kind
of
heard
from
all
our
developers
is
when
you
move
to
microservices.
D
You
have
to
address
all
of
these
issues
around
service
load,
balancing
security
circuit,
breaker
pattern
and
observability,
and
all
of
that
right.
So
we
didn't
want
our
developers
to
start
coding
for
each
of
those
individually
right,
and
this
is
a
polyclot
environment
like
we
have
Java
containers,
python
containers,
node
containers
so
and
on
various
versions.
So
we.
F
D
To
standardize
the
time
and
that's
where
we
picked
up
HTO,
because
that
was
the
leading
Services
back
then
actually,
and
so
we
kind
of
had
kubernetes
with
okay
HD
on
top
of
it,
and
then
we
kind
of
added
a
lot
more
services
around
deployment
automation,
which
is
where
we
used
a
combination
of
Jenkins
and
Argo.
And
then
we
have
our
own
observability
solution
using
grafana
Prometheus.
D
Then
the
log
log
aggregation
happened
using
efk
stack
like
we
had
fluent
elastic,
and
all
that
so
yeah
I
mean,
if
you
can
see
like
the
whole
platform
play,
was
not
just
giving
vanilla
kubernetes
but
the
entire
gamut
of
services
around
it.
So
that
as
a
developer,
they
just
keep
the
focus
on
the
code.
D
Development
and
the
rest
of
the
things
is
taken
care
by
the
platform,
so
that
that's
how
we
have
been
evolving
actually
and
like
right
now,
I
would
say
like
we
are
spanning
across,
like
hundreds
of
worker
nodes,
with
thousands
of
course
running
actually
right.
Production
applications
for
the
last
couple
of
years.
C
D
C
Thanks,
let's
move
on
and
take
the
same
question
for
Cindy
cool
thanks.
F
Yeah,
so
although
we
arrived
pretty
much
nearly
the
same
spot
as
you
know,
what
Brad
then
mentioned
our
journey
was
a
little.
You
know
we.
It
was
a
little
bit
different,
so
our
our
need
to
move
into
Cloud
native
started
out
with
a
we
wanted
to
get
our
software
out
there
faster.
That
was
the
basis,
but
there
are
also
other
constraints
that
we're
starting
to
run
against
in
2015-16
time
frame,
like
that's
kind
of
the
time
frame
where
Oracle
and
a
lot
of
it.
F
As
mentioned
like
we're,
moving
in
our
on-premise,
our
own
data
centers
to
our
our
oci
cloud,
and
we
are,
we
were
not
expanding
our
footprint
or
Legacy
data
centers
so
and
we
have
we
wanted
to
use
our
existing
resources
more
efficiently
until
we
make
that
transition
and
combine
that
with.
We
also
need
you
know
at
the
time
we
were
doing
our
quarterly
deliveries.
F
We
really
wanted
to
cut
that
down
to
like
weekly
bi-weekly
as
a
so
you
know
putting
those
two
together
we
started
out
with
you
know
a
we
need
to
break
our
monoliths
down,
so
you
know
we
introduced
service
discovery
and
that's
you
know.
We
we
were
able
to
decouple
pieces
and
then
have
this
communicate
back
and
forth
with
service
Discovery.
That's
that's
our
first
step
into
like
the
cloud
cloud
native
journey
and
at
the
time,
and
we
also
wanted
to
use
a
resources
efficiently.
F
At
the
time
we
were
just
running
one
service
per
VM
and
yes,
we
have
multiple
instances
of
it,
but
they're
not
all
getting
used
at
the
same
time,
so
that's
kind
of
where,
like
we,
we
really
need
a
scheduler
like
we
need
to
use
our
resource
efficiently.
So
we
we
can.
You
know
we
can
get
another
year
or
two
of
runtime
before
before
we
move
to
Cloud.
F
We
have,
you,
know
more
more
resources
available
for
us,
so
so
we
actually
started
out
with
Nomad
and
orchestrator
or
Java
processes
for
for
a
good
six
months,
or
so
we
continue
doing
that
and
that's
kind
of
when
we
start
our
transition
to
oci.
That's
we
have
managed
kubernetes
available
for
us
and
which
made
it
a
lot
more
developer
friendly.
F
So
until
until
that
point
or
a
lot
of
our
investment
was
to
how
to
operate
what
what
developers
write
in
a
more
efficient
way
and
decouple
them,
and
then
how
can
we
enable
our
developers
to
take
advantage
of
all
the
self-service
they
can
do
all
the
tooling
that's
starting
to
be
available
with
kubernetes,
so
I
think
it's
about
2000
later
than
1718
is
when
we've
our
transitioned
to
like
more
developer,
Focus,
less
apps,
focused
and
more
developer
focused
on
how
to
enable
developers
to
take
advantage
of
you
know
schedulers
in
a
service
Discovery,
so
that
that's
kind
of
where
we
are
transitioned
to
like
developer-centric
Cloud
native
ecosystem,
and
that's
when
we
started
introducing
okay,
you
know:
developer
can
get
an
environment
with
you
know,
push-up
button
and
start
deploying
us
and
get
get
a
namespace
get
get
the
whole
supporting
ecosystem
like
like
Supergirl
mentioned
Prometheus,
grafana
and
tracing
it's
just
out
of
the
box.
F
Again,
as
long
as
you
comply
with
a
certain
contract,
that's
established
as
part
of
our
platform.
You
can
just
start
developing
getting
all
the
benefits
without
having
to
think
about
it.
As
long
as
you
meet
this
contract
that
opened
up
like
Ritz
observability
and
you
know
ability
to
like
see
what's
going
on
within
their
services,
all
of
that
just
made
it's
it's
eye-opening
for
a
lot
of
developers
who
have
been.
F
You
know
who
didn't
have
that
ability
until
that
point,
and
and
also
it's
reduced
stress
on
the
Ops
side
of
and
who
are
who
are
dealing
with
day-to-day
it
it.
You
know,
that's
when
the
overlap
between
apps
and
there
we're
we're
starting
closing
gap
between
what
was
Ops
and
Dev.
Now
we're
getting
closer
and
closer
to
devops.
F
So
that's
kind
of
you
know
our
transition.
You
know
five
years
later,
you
know
until
recently,
a
few
weeks
ago,
like
I,
was
running
that
our
Cloud
native
developer
platform,
which
provided
all
basically
all
of
the
tooling
observability,
tooling
and
CI
CD,
we
used
Argo
CD
to
deploy
and
enable
developers
to
deploy
apps
themselves
as
frequently
as
they
can.
We
went
from
in
three
months
to
two
weeks
to
like
whenever
you
want
so
yeah,
that's
kind
of
our
Evolution
towards
Club
NATO,
awesome,
awesome.
C
I
love,
it
so
I
think
the
net.
The
next
set
of
questions
that
we
want
to
ask
now
that
everybody's
told
us
a
bit
about
how
they
got
there
and
the
the
what
happened
it
was.
We
want
to
talk
a
little
bit
about
the.
Why
and
the
decision
processes
that
went
around
not
just
how
it
was
built
and
architected,
but
around
the
projects
themselves
and
how
they
got
Incorporated.
B
C
Like
to
talk
a
little
bit
about,
why
were
the
particular
projects
chosen?
Was
there
just
a
following
the
tide
because
everybody's
doing
kubernetes,
where
they're
technical
decisions
were
their
political
decisions?
I
know
if
people
are
watching
and
they're
they're
interested
in
what
it's
like
in
an
Enterprise
setting
everybody's
going
to
go?
Oh,
how
much
did
politics
push
down
from
the
top
to
make
sure
that
this
was
going
to
happen.
C
You
know
talk
about
the
decisions,
talk
about
autonomy,
Etc
and
we'll
go
back
to
the
top
and
start
with
Brad
again.
G
Yeah,
that's
actually
a
very
interesting
question.
I
already
mentioned
that
we
originally
got
into
the
Container
world
because
having
to
do
with
the
large
metal
that
needed
to
be
able
to
abstract
it
and
not
lose.
G
I
o
and
network
efficiency,
and-
and
we
were
able
to
do
that
with
containers
and
I
mentioned
that
we
started
out
in
in
in
our
Legacy
Legacy
data,
centers,
doing
everything
with
Docker
compose
and
hand
crafting
it
on
each
on
each
server,
with
making
sure
we
had
the
right
mix
of
containers
that
that
played
well
together
and
that
whole
process
was
manageable
because
we
had
a
small
number
of
servers.
G
Moving
to
oci
was
a
mandate
that
Oracle
has
had
for
its
SAS
organizations
because
of
the
the
the
operational
efficiency
and
the
higher
level
of
security
and
there
there
are
many
reasons
for
that,
so
that
that's
definitely
motivated
by
a
policy
from
from
our
organization
so
in
in
and
working
to.
How
do
we
get
there?
I
was
originally
tasked
to
do
that
as
well,
and
so
I
looked
at,
we
were
in
oci
and
I
was
basically
replicating
what
I
had
done
in
the
Legacy
data
center
using
Docker
compose
and
building.
G
You
know
a
few
machines
to
build
smaller
deployments
and
the
the
upper
level
VP
said
put
down.
It
said
no,
you
have
to
use
kubernetes.
In
fact,
you
have
to
use
oke
and
Okie
was
just
coming
out
with
limited
availability,
and
so
I
ended
up
being
an
up
there
in
the
first
week
when,
when
the
managed
kubernetes
that
Oracle
provides
an
oci
called
oke
when
it
was
available,
so
that's
in
2018
early,
that's
how
we
actually
got
in.
G
We
were
told
I
was
going
to
use
kubernetes
I
had
known
when
I
first
started,
I'd
been
working
for
maybe
six
months
in
containers
and
I
looked
at
at
Doc
at
swarm
and
I.
Looked
at
various
things
and
I
said:
kubernetes
is
what
I
want
to
use,
but
I'm
going
to
wait.
I
wanted
to
get.
We
have
a
lot
of
things.
We're
doing.
I
didn't
want
to
go
right
away
into
kubernetes,
but
when
we
were
in
oci
was
basically
a
mandate.
G
G
Another
thing
that
was
interesting
is
coming
from
our
own
data
center
environment,
the
security
we
always
use,
firewalls
and
so
I
was
very
knowledgeable
and
and
managing
the
security
using
firewalls,
where
there's
no
firewalls
in
oci,
and
we
had
to
and
when
you're,
when
you're,
when
you're
using
kubernetes
the
way
that
a
lot
of
this
can
be
handled,
you
get
the
security
you
need
is
if
with
network
policies,
but
Network
policies
are
not
automatically
enforced
by
kubernetes,
and
so
you
have
to
come
up
with.
G
How
are
you
going
to
enforce
Network
policies,
and
so
one
I
think
Sarah
mentioned
that
he
used
istio
I
looked
at
istio
and
I
looked
at
Calico,
and
so
both
open
source,
both
great
tools
and
for
my
world
I
thought
boy.
Istio
looks
really
interesting,
but
it
it
was
a
bigger
commitment.
It's
a
framework-
and
it
was
a
lot
more
at
that
time-
to
get
into
and
get
involved
and
adopt
all
the
different
aspects
of
it.
G
Calico
was
a
much
more
surgical
tool
that
I
could
use
as
a
plug-in
into
kubernetes,
and
and
do
the
enforcement
of
the
network
policies
to
take
the
place
of
to
get
the
security
we
needed
on
a
per
container
basis
to
take
the
place
of
what
we
used
to
do
with
firewalls
technology
in
in
our
own
data,
centers
and
so
I
went
the
other
way.
So
serako
went
with
istio
and
I
went
with
Calico,
and
so
we're
still
we're
still
using
Calico.
It
still
works
for
us.
I
do
really
see
the
value
in
istio.
G
It's
just
that
that
was
the
trade-off
we
made
because
we
had
so
much
other
things
and
complexity
and
also
a
lot
of
Legacy
applications
that
we
just
had
to
keep
going,
that
they
make
a
lot
of
money
for
us
and
that
we've
we've
developed
them
for
20
over
20
years.
They're,
complex
multi-threaded.
G
Some
of
these
are
heavy
things,
we're
moving
more
and
more
into
microservices,
and
all
the
new
stuff
we're
doing
is
with
microservices,
but
we
still
have
these
Powerhouse
complex
applications
and
and
so
we're
not
able
to
just
rewrite
everything
that
we
built
over
the
last
20
years
and
is
making
a
lot
of
money
for
us.
So
so
that's
the
trade-off
we
made
I
just
wanted
to
mention
that
that
was
a
decision
I
made
about
on
Calico.
G
The
decision
for
oke
and
kubernetes
up
front
was
really
a
management
decision
which
turned
out
to
be
the
best
one
for
us.
The
only
only
other
thing
I'll
mention
is
that
when
we
started
we
built
a
lot
of
stuff
by
hand.
I
wanted
everything
to
be
automated,
but
I
got
a
lot
of
pushbacks
from
managers
in
terms
of
time
they
had.
It
was
going
to
take
too
long.
G
We
went
through
a
couple
of
smaller
projects,
new
applications
that
we
had
built
and
published
a
couple
of
those
when
we
got
to
the
main
product
we
were
putting
it
out
in
2020,
I,
said
I,
put
my
foot
down
and
said
everything
is
going
to
be
automated
because
we
have
to
develop
deploy
all
around
the
world
like
40
50
deployments
separate
deployments
of
these
systems.
G
We
cannot
do
this
manually,
so
we
use
we
use
terraform
in
in
the
past,
we've
used
Chef
in
our
Legacy
environments,
but
we've
switched
to
Ansel
because
it
was
a
little
bit
easier
to
use
a
little
more
flexible
as
well
and
a
little
less
complicated
for
us
and
and
everything
we
do
is
now
required
to
be
automated.
That
took
a
lot
longer
up
front.
It's
a
lot
more
of
an
investment,
but
it's
really
important
I.
Think
that's
one
thing
I
wanted
to
just
provide
is
my
advice.
G
Is
that
is
really
try
and
and
value
complete
Automation
in
your
systems
rather
than
requiring
to
do
things
manually,
it
makes
a
big
difference
in
the
long
term.
That's
that's
what
I
wanted
to.
C
Love
it
love
it.
Let's
go
over
to
subankar
next.
D
So
yeah
I
think,
like
the
question
around
political
versus
technical
playing,
a
part
in
choosing
some
of
these
projects
again
I
mean
like
I'll,
lead
to
what
Brad
mentioned,
like
I
I
believe
Urkel
had
a
corporate
mandate
to
move
all
our
on-premise
data
centers
over
to
us
here,
right
I
think
it
made
sense
for
the
organization.
D
It
was
a
strategic
decision
for
the
organization,
so
kind
of,
like
all
the
teams,
internal
teams
and
product
teams
were
kind
of
moving
towards
that,
and
we
obviously,
since
we
were
running
on
on-premesh
data
centers
we
had
to-
and
these
are
like
these
applications
that
we
manage
are
kind
of
the
bread
and
butter
for
own
business
right.
So
these
are
actually
oracle's
own
sales
system,
HR,
System,
payroll
and
all
so
for
us.
D
I
think
the
most
crucial
aspect
of
it
was
time
right,
so
speed
of
delivery
for
the
developers
how
rapidly
they
could
iterate
and
rebuild
some
of
these
applications
to
make
them
Cloud
native.
That
was
very
important,
so
the
platform
was
very
important
and
I
think
we
had
full
backing
from
management
for
picking
up
kubernetes
or
the
technology
that
could
facilitate
this
speed
of
delivery.
As
far
as
picking
up
other
projects
on
the
CNC
transcript,
those
are
purely
like
technical
decisions
and
I.
D
Think
I
mean
if
you
look
at
the
whole
ecosystem
or
the
cncf
landscape,
I
think
that's
pretty
massive
2018,
kubecon,
2022,
coupon
I
think
the
number
of
projects
that
are
there
in
that
is
mind-boggling,
actually
right
so
tough
to
even
fit
into
one
page
where
you
can
actually
see
all
the
projects.
There's
tiny
little
icons
and
there
are
so
many
overlapping
functionalities
in
a
lot
of
these
projects
right.
So
it's
very
tough.
Actually.
D
So,
if
I'm
working
on
picking
something
on
the
security
side,
maybe
there
are
like
50
projects
out
there
which
are
trying
to
do
something
similar
right.
So
how
do
you
pick
the
right
project
which
is
which
you
can
maintain
over
time
and
which
also
meets
all
your
requirements?
So
I
would
give
couple
of
examples.
D
I
mean
like
on
the
security
front
or
security
policies
right,
so
that
was
one
of
the
core
requirements
for
us
to
make
sure
that
our
developers
are
not
running
privileged
containers
right
and
if
you
look
at
the
ecosystem
again,
there
are
so
many
tools
out
there.
We
have
Copa.
We
have
kyber
no
policy
engine,
there's
so
many
projects
which
kind
of
Meet
the
same
requirement.
So
for
us,
when
we
are
picking
up
some
of
these
projects,
it
was
very
important
that
we
can
maintain
that
over
time.
D
D
They
kind
of
give
the
same
same
kind
of
functionality
right
so
so
that
that
was
a
decision
that
we
had
to
make
right,
which
tool
to
use
so
same
goes
with
servicemeness
again,
I
mean
like
between
HTO
and
at
that
point
I
think
cncf
had
Linker
D,
which
was
there
a
primary
graduated
project.
D
I
would
say
for
servicemas,
but
again,
when
evaluating
both
we
kind
of
looked
at
what
functionalities
do
both
of
them
provide
and
with
Linker
did
there
were
a
couple
of
core
Constructors
are
missing,
like
Linker
didn't
have
an
Ingress
of
its
own,
so
we
had
to
add
an
interest
on
top
of
that
and
there
were
a
couple
of
other
functionalities
missing,
but
istio
kind
of
came
with
all
those
functionalities
inbuilt
right.
So
so
we
didn't
want
to
again
like
when
we
are
adding
a
framework.
D
D
Another
example
would
be:
let's
say
we
are
using
the
efk
stack
for
our
logging.
Now,
tomorrow,
I,
don't
one
elastic
I
want
to
switch
it
to
some
other
back
and,
let's
say
open
search.
So
what
is
the
effort
that
goes
into
switching
that
right?
So
I
could
keep
fluent
D,
but
I
could
kind
of
change
the
back
end
back
end
of
it
from
elastic
to
open
search
all
the
while
making
it
seamless
for
the
developer
right.
The
developer
doesn't
have
to
worry
about
what
is
going
in
the
back
background.
D
Actually
so
so
those
are
some
of
the
decisions
that
goes
behind.
Picking
some
of
these
projects
and
again
I
mean
it
is
a
continuously
evolving
thing.
So
the
whole
Cloud
native
ecosystem
moves
so
fast,
so
you
have
to
keep
looking
at
it
every
three
to
six
months
to
make
sure
that
your
projects
are
staying
up
to
date
and
you
are
trying
to
make
the
right
bets
at
the
right
time
right.
Yeah,
awesome.
F
Sure
so
one
of
the
initial
decisions
we
made
was,
if
you
look
at
it,
I
was
starting
out
with
Nomad
for
orchestration.
It
had
some
context
to
that
why
we
ended
up
doing
that.
So
originally
we
wanted
to
start
with
containers
just
running
our
applications
in
a
container,
but
this
was
15,
16,
2015
2016.
again
as
Enterprise,
we
are
very
security
conscious
and
our
Ops
themes,
there's
a
you
know,
there's
a
lot
of
discussion
about
security
of
the
containers
at
the
time
and
for
us
we
really
needed
to
move
again.
F
Our
Focus
was
moving
fast
and
tailoring
fast,
so
yeah
we
had
to
make
a
decision
right.
If,
if
we're
taking
time
to
do
containers,
let's
just
go
with
the
Nomad,
which
can
do
just
Java
process
orchestration.
For
us,
we
needed
efficiency,
we
need
orchestrator,
you
know,
Nomad
could
do
or
Java
proxy
orchestration
or
any
any
any
binary
orchestration
so
that
that
was
one
of
the
business.
So
we
ended
up
doing
a
or
surgical
approach.
Okay,
we
need
this
now.
F
This
provides
that
and
allows
us
to
move
to
the
next
level,
so
our
our
our
journey
was
very
surgical
in
the
in
the
beginning
to
get
us
to
what
we
need
at
that
moment
and
then
we,
you
know
slowly
started
evolving
and
you
know,
and
again
it's
the
same
as
What
Brad
mentioned.
You
know.
When
okay
was
available,
you
know
we,
it
was
kind
of
a
oracle-wide
okay,
we
are
adopting
kubernetes
at
that
point
it
was
like
great.
F
If
that's
we've
been
waiting
for
that
and
we,
you
know
we're
going
to
jump
on
that
and
it's
right
that
train
and
that's
going
to
be
I
mean
we
ended
up.
You
know
taking
as
soon
as
the
okay.
He
was
available.
That
was,
you
know
just
great
for
us
and
we
started
at
that
point
that
removed
any
any
questions
about
container
or
not.
F
But
it's
recommendations
contain
orchestration,
so
yeah
that
which
was
which
was
great
for
us
in
that
that
accelerated
adoption
too
Cloud
native
landscape
and
see
in
terms
of
other
decisions,
I,
don't
know,
I
think
I'll.
Leave
it
at
that.
C
Okay,
the
there
is
one
I
think
tangential
question
off
of
that
and
Sue
bunker
alluded
to
this
in
his
mention
of
the.
C
High
velocity
and
I'll
I'll
give
this
as
a
toss-up
to
whoever
wants
to
take
this
question
in
the
context
of
how
the
projects
continue
to
evolve
and
the
longevity
of
the
individual
projects.
How
much
build
versus
Buy
came
into
the
adoption
of
the
projects
as
a
long-term
maintenance
decision
and
I'll
give
that
to.
Whoever
wants
to
take
that
particular
question.
E
Well,
I'll,
take
it
okay,
so
and
the
reason
being
one
of
the
cncf
project
is
Helm.
So
when
we
started
our
journey
back
in
2020
2018
that
time
Helm
was
at
1.0
version
and
we
because
we
wanted
to
automate
things
from
get,
go
and
the
way
Helm
was
positioned.
At
that
point
of
time,
we
had
to
actually
build
our
own
orchestration
of
using
directly
kubernetes,
apis
and
and
other
things
and
for
the
overall
deployment
project.
E
But,
like
you
say,
these
projects
evolve
over
time
within
two
years,
when
film
3.0
was
released,
we
revaluated
our
decision
because
anything
which
you
build.
E
You
have
to
keep
investing
and
maintaining
and
doing
all
those
things
around
it,
and
probably
around
last
year
we
actually
pivoted
again
and
started
using
help
with
Helm
file
to
to
actually
satisfy
our
needs
and
that's
where
we
actually
stopped
funding
our
build
part
and
we
went
out,
went
into
and
adopted
something
which
was
off
the
shelf
and
which
matured
over
time
to
suit
our
needs.
G
Yeah,
so
the
trade-off,
the
trade-off
you
have
to
have
the
functionality
you'd
rather
not
have
to
build
it
and
maintain
it.
If
it
isn't
your
core,
your
you
know
your
core
strength
or
or
what
your,
what
Your,
what
you're
building
for
your
app
for
your
customers,
but
but
it's
got
to
have
the
functionality,
but
otherwise
you
know
it.
G
It
really
makes
a
lot
of
sense
to
leverage
these
open
source
technologies
that
are
they're,
providing
what
you
need,
even
if
you
have
to
Cobble
them
together,
but
then
you
have
to
stay
on
top
of
it.
You
have
to
you
really
do
have
to
watch,
keep
the
versions.
That's
the
other
side
is
there
is
a
cost
of
ownership,
which
is
you
you
can't
be
letting
things
get
too
old.
You
have
to
keep
evolving.
D
Both
both
indirectly
I
think,
indirectly,
it's
not
dollar
and
another
day
right,
I
mean
even
if
yeah
so
the
the
time
that
I
would
say
like
the
time
that
we
spent
on
maintaining
some
of
these
or
grading
them.
I
mean
like
look
at
the
like
the
rapid
versions
that
come
out
I
mean
kubernetes
is
almost
like
every
year.
There
are
four
versions:
I
mean
same
goes
with
istio
and
then
some
of
these
other
projects.
D
G
This
stuff,
so
that
you
can
so
you
have
less
overhead
and
updating
with
to
newer
versions,
fixes
whatever
very
critical
exactly.
D
G
C
So,
let's
take
that
in
a
slightly
different
direction.
Now
we've
got
a
scenario
where
everybody's
got
your
projects,
they're
all
built
up
and
we've
talked
about
the
decisions
that
went
into
them.
But
let's
talk
about
sort
of
the
Unseen
parts.
Let's
talk
about
speed
bumps
in
the
journey
everybody's,
going
to
run
into
issues
things
that
took
longer
than
they
expected
things
that
you
know
were
problems
that
you
ran
into
it's
going
to
happen
so
within
each
of
these
development
life
cycles.
C
What
came
up
that
you
had
planned
for
that?
You
said
this
is
going
to
take
long
and
it
took
six
months
instead
of
three
months
that
you
were
able
to
plan
for
and
what
came
up.
That
was
completely
unexpected,
that
you
know,
instead
of
being
able
to
plan
for
it
that
you
had
to
deal
with
it
so
Let's,
let's
go
in
reverse
order
for
this
one,
we'll
start
with
Cindy.
F
Yeah,
so
when
we
started
once
we
got
on
kubernetes
like
we
were
really
excited
and
we
were,
you
know
we
tried
to
go
all
in.
We
had
our
you
know
our
observability
with
you
know,
tracing
time
seas,
and
then
we
also
have
our
service
mesh
up
and
running,
and
then
now
we
started
adding
more
developers
and
enabling
everybody
to
be
able
to
do
everything
and
a
few
weeks
in
we
it
we,
it
created
more
nice
than
velocity.
F
You
know
start
small,
you
know,
in
fact
we
pulled
our
service
mesh
out
and
we,
you
know
we
didn't
even
go
with
ServiceMaster
production
and
even
though
it's
you
know
it's
decoupled,
it
just
caused
more
noise
with
development
teams
trying
to
adapt
I
try
to
it's
overwhelming,
sometimes
like
when,
once
she
came
in
okay
instrument,
your
applications
and
then
now
you
add
it's
you're
tracing
and
it's
a
it's
a
it's
like
what
you
used
to
do
before
what
you
have
what
you're
doing
in
Cloud
Network
applications
you're
doing
or
putting
a
lot
of
things
in
ahead
of
time,
but
taking
that
transition
is
in
the
in
the
beginning,
it
was.
F
It
was
hard
for
a
lot
of
our
developers.
Just
like
I'd
say
that
was
a
speed
bump,
and
that
was
a
lesson
to
not
start
with
all
of
it
like
just
start
as
small
as
you
can,
while
still
getting
your
achieving
your
business
objectives.
Just
because
you
know
we
can
do
tracing
can
do
we
can
do
service
message,
it
doesn't
mean
you
should
do
it
all
at
once.
Just
focus
on
your
business
and
see
what
what
improves
that
and
then
just
start
there.
F
D
Hey
I
would
agree
with
Sandeep
I
mean
we
had
similar
kind
of
experience
right.
So
when
you
do
this
platform
play,
like
obviously
like
everyone's
excited
to
get
onto
the
platform,
but
it
takes
time
to
build
a
production
ready
platform,
to
be
honest,
actually
right
so
with
all
the
bells
and
whistles
around
it.
Like
I
mean
security.
D
Is
one
of
the
core
concerns
here
so
and
like
kubernetes,
security
has
a
lot
of
elements
to
it
actually
like
starting
from
like
making
sure
you
have
like
hard-end
images,
all
the
way
till
container
scanning
Solutions
your
Security
on
the
runtime
itself,
where
you
don't
have
privileged
containers,
you
have
restricted
access
between
namespaces
through
Network
policies,
your
egress
and
Ingress
controls.
All
of
that
right
I
mean
it
takes
time
to
build
all
of
those,
and
so
one
thing
that
we
learned
is
obviously
like.
D
We,
we
went
slow
I
mean
we
started
off
with
maybe
a
couple
of
teams
like
two
or
three
core
teams.
We
wanted
to
do
the
end-to-end
workflow
just
to
make
sure
that
the
whole
platform,
the
value
of
the
platform,
can
be
demonstrated
right,
and
it's
not
just
like
on
the
deployment
automation
of
it
like
how
they
secure
containers,
but
also
like
once
the
containers
are
live.
How
do
you
observe
them
right
be
on
metrics
traces
logs?
All
of
this?
How
do
you
correlate
them?
D
If
there
is
an
issue
like
now
you're
breaking
down
a
monolith
into
maybe
10
different
micro,
Services
you're?
You
have
10
different
failure
points.
So
how
do
you
basically
correlate
the
traces
to
the
metrics
to
the
logs
and
then
end
of
the
day
like
give
it
to
the
developer?
Saying
that
hey
you
have
an
issue.
This
is
how
you
kind
of
debug
it
right.
D
So
it
took
us
a
while
having
a
good
amount
of
time,
maybe
like
nine
nine
months,
so
maybe
a
year,
actually
just
to
get
the
whole
production
ready
platform
up
and
running,
and
then
that's
where,
once
you
started
showing
the
value
of
it,
then
we
had
like
knowledge
transfer
sessions
with
all
the
developers
saying
that
hey.
This
is
how
you
can
build.
This
is
how
you
can
observe
that's
when
we
started
seeing
a
uptake
of
the
platform
more
and
more,
and
so
that
was
one
learning
and
the
other
from
an
off
standpoint.
D
I
would
say
which
was
very,
which
was
something
that
we
underestimated
is
the
velocity
with
these
projects
are
being
built
and
whether
you
have
to
maintain
we
hadn't,
we
had
a
very
small
team,
actually
the
Ops
team
that
was
building
the
platform,
so
we
had
our
hands
full
actually,
while
while
building
the
platform
and
at
the
same
time
maintaining
it
and
making
sure
that
we
have
all
the
automation
around
it
to
patch,
when
there
is
a
CV
or
even
just
the
regular
Cadence
upgrading
and
keeping
it
in
sync,
with
Upstream
versions,
I
mean
that
was
a
challenge
actually
right.
D
So
it
took
us
a
while
to
again
build
those
Automation
and
have
all
of
that
in
place.
So
those
are
something
that
we
had
and
anticipated,
because
traditionally,
when
you
do
monolith
and
on-premise
development,
you
don't
run
into
these
issues.
But
when
you
pick
up
open
source
projects,
I
mean
the.
There
are
a
lot
of
these
factors
that
have
to
be
considered
so
I
think
that
would
be
another
speed
for
learning.
I
would
say
that
we
had
to
factor
in.
C
Over
to
Diane
for.
E
So
yeah
I
think
being
in
Oracle,
the
security
being
the
topmost
Paramount.
There
are
the
processes
itself
make
make
the
overall
deployment
overwhelming
when
you
talked
about
speed
bump
the
instance
which
came
out
came
to
mind
was
more
the
way
we
had
implemented
so
now.
What
we
have
done
is
with
multiple
teams
contributing
their
own
containers
and
basically
with
kubernetes.
You
have
the
front
jobs
so
one
of
our
DBA
teams.
E
They
wanted
to
monitor
the
databases
and
they
started
adding
cron
jobs
and
within
no
time
no
time
we
didn't
realize
that
there
were
so
many
Crown
jobs,
starting
and
stopping
and
in
the
system
it
actually
slowed
down.
The
whole
system
because,
like
Suddenly
at
10,
AM
tons
of
chrome
jobs,
will
start
up
and
try
to
do
certain
things,
and
so
yeah.
E
Jobs
right
yeah:
these
tools
are
great.
They
enable
you
very
quickly
or
they
Empower
you
very
quickly,
but
at
the
same
time,
if
there
is
no
governance
placed
in
they
can
basically
it
can
become
a
very
bigger
problem.
So
yeah
it's
just
that
was
a
kind
of
a
big
learning.
We
had
to
actually
go
back
and
read
a
bunch
of
things
just
to
go
around
the
problem.
E
F
E
C
C
I
think
there's
so
much
good
content
here
with
all
the
experiences
that
we
could.
We
could
talk
for
hours,
probably,
but
unfortunately
we
have
a
time
limit
on
this
particular
session,
so
I
think
we're
going
to
try
to
end
it
there
for
the
questions
that
we
have
lined
up.
C
I
think
there's
some
questions
in
the
chat
that
people
want
to
talk
about,
but
I'm,
hoping
that
in
general,
that
being
able
to
have
seen
the
similarities
and
differences
from
each
of
these
teams
and
what
they
went
through
and
how
they
made
their
Journey
Through.
The
adoption
of
cloud
native
that
it's
going
to
help.
You
know
the
folks
that
are
watching
at
home,
assuming
they're
at
home
that'll
help
them
understand.
C
You
know
what
gaps
you
might
need
to
fill
in
in
your
own
knowledge
as
you're
adopting
these
Technologies
and
that
it'll
help
when
you're
attending
the
conference,
I
hope
you're
all
attending
the
conference,
at
least
virtually.
G
C
C
If
you're
physically
there
and
the
hallway
track
and
all
the
other
ways
that
people
on
Twitter
and
in
advertising
and
whatnot
are
going
to
try
and
pull
your
attention
in
all
these
directions,
I
hope
that
this
is
going
to
help
everyone
focus
a
little
more
and
get
a
better
experience
out
of
the
show,
there's
a
lot
of
different
opportunities
to
learn,
and
hopefully
this
was
helpful
to
all
of
you
as
you
either
adopt
this
expand
your
existing
footprint
or
just
think
about
how
you're
gonna
approach
the
the
system.
C
There
was
one
that
I
thought
was
interesting
and
is
history,
but
I'm
gonna
give
it
to
the
team.
What
is
your
perspective
on
kubernetes
cost
management
and
enables,
under
the
CNC
of
that,
at
least
as.
D
Toss-Ups
sure
I
think
we
looked
at
Cube
cost.
Actually,
so
that's
one
of
the
cncf
tools,
actually
Cube,
post
and
I
mean
obviously
we
looked
at
some
time
back.
It's
a
it's
a
nice
little
Tool
which,
which
kind
of
gives
you.
G
D
The
way
they
have
done
it
is,
they
have
plugins
for
each
cloud
provider,
so
they
kind
of
pull
in
the
billing
pricing
details
from
each
cloud
provider
and
then
they
kind
of
go
for
the
latest
cost
analysis
that
that
is
available
out
there,
so
so
yeah
I,
think
I
mean
if
you're
looking
at
cncf
projects.
Probably
that
is
one
tool
that
we
have
looked
at,
which
I
mean
depending
on
what
cloud
provider
you
are
using
they're.
Definitely
that's
something
that
you
can
leverage
actually
yeah.
C
So
here's
a
plug
for
something
I'm
not
really
involved
with,
but
that's,
okay,
the
cncf
has
a
tag
devoted
to
environmental
sustainability
and,
as
you
continue
to
use
more
resources,
you
are
also
using
electricity
you're
using
power.
You
are
using
more
air
conditioning,
etc,
etc,
and
the
impact
that
you
have
on
your
cost
management
also
has
an
impact
on
the
World
At
Large,
so
I
agree.
Hopefully.
D
C
And
dear
to
my
heart,
just
wanted
to
get
my
two
cents
in
there
I'll
get
off
my
soapbox.
Now,
let's
see
what
are
the
other
questions
that
we
have
in
here?
Observability
logging
in
metrics,
it's
very
important
to
ensure
your
apps
and
systems
are
monitoring
healthy,
24
7..
F
F
Visualization,
let's
see
Prometheus
for
time
series
Thanos
for
our
long-term
time
series
database
server,
so
basically
all
age,
every
each
and
every
one
of
them
were
are
cmcf
projects.
C
Awesome
and
related
to
another
question
up
there,
I
don't
even
know
the
answer
to
this.
Do
we
oci
offer
a
managed
Prometheus
now.
G
Chat
I
think
the
cost
cost
benefit
justification
is
is
it
is,
is
a
general
question
makes
a
lot
of
sense
as
I,
just
if
I
said,
okay,
I'll
jump
in
and
just
say
something
about
that
going
from
coming
from
speaking
as
someone
who
managed
their
own
data
center
for
SAS
for
for
15
years,
not
not
using
a
public
cloud
like
oci
before
we
went
to
oci
it,
we
built
everything.
So
we
were
responsible.
G
You
know
for
the
compute,
the
databases,
the
networking,
all
the
security,
everything
building
this
up
from
scratch
in
a
in
a
in
a
data
center.
It
took
it
for
the
for
the
deployments
we
had.
It
would
take
a
full
year
to
to
do
a
full
new
deployment
of
of
the
applications
which
is
complicated.
Moving
to
oci.
We
can
do
that
in
in
in
just
a
few
weeks,
just
like
just
maybe
even
in
a
brand
new
region.
It
takes
about
six
weeks
total.
G
It's
it's
a
huge
difference,
so
the
time
it
takes
to
deploy
is
is
a
big
part
of
the
cost.
G
You
just
can't
cut
down
if
you're
doing
it
yourself
if
you're,
if
you're
in
a
your
own
data
center,
it's
it's
a
I
can't
under
over
overstate
the
importance
of
of
the
time
value
you
you
gain
in
a
in
a
cloud
once
you
get
it
down
once
you
understand
the
tools
once
you
know
how
to
do
the
automation,
then
the
deployment
times
are
just
a
very
small
fraction
of
what
it
takes
to
do
it
yourself
in
a
data
center,
so
I
think
I
think
it's
it's
a
big
cost
benefit.
D
Yeah
and
I
just
want
to
add
to
what
Brad
said
like
I
mean,
like
I,
mean
moving
to
Cloud.
Definitely
I
mean
a
lot
of
benefits
so,
but
one
thing
that
we
we
try
to
be
very
careful.
Is
we
don't
over
provision
and
under
utilize
right
resources?
That's
very
critical
for
us
actually
I
mean
we
have
seen
I
mean.
Obviously,
like
you
have
this,
you
you.
D
Provisioning
time
and
all
of
that
and
developers
are
all
happy.
We
want
to
get
on
board
with
all
of
this,
but
then
we
ought
to
be
very
careful
about
how
we
use
the
resources
actually
and
not
waste
the
market
right.
So
yeah.
F
G
A
big
deal,
and
also
the
monitoring,
is
always
better
in
the
clouds
to
to
know
what
you're
doing
and
what
you're
using
and
then
you're
sharing
it
with
other
people.
Yeah
right.
C
Well,
thank
you
all
I
think
Taylor's
about
to
start
queuing
up
the
Oscars
music
to
play
us
off
a
huge
thank
you
to
Brad
and
subankar
and
Sandeep
I
hope.
Everybody
found
this
to
be
useful
for
all
the
perspective
and
all
the
experience
that
we
could
bring
to
you.
Our
viewers.
C
A
Thank
you
absolutely!
No!
Thank
you
so
much
Noah.
Thank
you
all
for
joining
and
just
sharing
those
stories
I
feel
like
as
we
work
through
different
Cloud
native
contexts.
That's
the
thing
that
we
don't
always
get
to
hear
right,
we're
not
always
on
the
same
teams.
We
have
the
same
missions
and
objectives.
We're
working.
You
know
same
team
different
company
for
sure,
but
we
don't
get
to
sit
next
to
you
all
the
time
and
hear
what's
going
on.
A
So
it's
really
informative
and
interesting
to
hear
kind
of
what
the
concerns
are
amongst
folks
within
the
community.
So
thank
you
so
much
for
taking
the
time
to
share
I.
Thank
you
all
for
joining
us,
whether
you're,
watching
real
time
or
again,
like
Noah,
said
watching
this
many
years
from
now
we've
been
trapped
in
Amber,
we've
broken.
You
know
help!
Thank
you
so
much
for
coming
on
by
and
joining
us
for
another
cognitive
live.
A
We
hope
to
see
you
again
soon
and
for
those
looking
forward
to
keep
content
right
here
in
North
America,
seeing
you
there
as
well
thanks
again,
everybody
thanks
for
watching.