►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Panel: End User Panel: GITOPS in the Enterprise -Real World Experiences - Cheryl Hung, Cloud Native Computing Foundation; Fabio Giannetti, Mastercard; Matt Young, EverQuote Inc.; & Amr Abdelhalem, Fidelity Investments
This panel brings together engineers from the CNCF End User Community to provide their insights on the journey their respective companies have undergone in their transformation to Cloud Native. Each End User member company will discuss their Cloud Native principles and what has worked along with what has not worked. Topics will include operating GITOPS in real world practice, developer experience (CI & CD), CNCF projects evaluated and implemented, and vendor management along with the lessons learned along the journey.
https://sched.co/ekB7
C
A
A
D
You,
yes,
thank
you
so
for
us,
gitops
really
has
been
a
journey
to
represent
our
infrastructure
through
code,
as
well
as
what
we
define
the
core
application
or
those
applications
that
we
deploy
on
our
kubernetes
cluster,
to
run
the
infrastructure
itself
and
the
reason
we
have
chosen.
This
is
to
allow
us
to
represent
everything
we
have
in
our
internal
cloud
as
a
git
commit
or
git
repository.
D
C
Yeah
yeah,
similar
to
fabian
mastercard,
like
fidelity
world,
we're
the
platform
team,
that's
responsible
to
build
the
platform
with
platforms,
so
we
are
responsible
to
enable
and
govern
and
regulate
about,
like
hundreds
of
clusters
and
platforms
like
different
ones,
different,
varied
dependent,
different
business
units
and
different
capabilities
and
features
as
well,
and
that
was
our
way
of
scaling.
That
platform
through
like
githubs
and
building
like
full
automation
around
it.
B
B
Our
customers
are
engineering
teams
and,
and
they
all
like
to
run
fast,
so
we've
spent
the
last
year
rebuilding
our
infrastructure
to
set
us
up
and
position
us
to
support
all
of
this
horizontal
scaling.
If
you
will
of
the
business
and
in
order
to
do
that
without
you
know,
bullying
or
quadrupling
the
size
of
our
team,
we've
really
leveraged
get
ops
in
two
contexts,
one
for
our
core
infrastructure,
as
others
have
have
said,
and
it's
really
for
us
about
toil
reduction,
disaster
recovery,
but
perhaps,
most
importantly,
self-service
mechanisms.
B
You
know
all
of
our
infrastructure
is
described
in
a
variety
of
ways,
but
it's
all
in
get
and
we
partner
with
a
lot
of
our
teams.
So
if
they
need
to
do
things
faster
than
we
can
prs,
are
welcome.
So
we've
been
quite
successful
over
the
last
few
quarters
of
employing
a
lot
of
open
source
methodologies
and
workflows
for
how
we're
managing
our
infrastructure.
B
B
B
C
B
There's
an
operational
or
procedural
aspect
to
them,
so
we
are
somewhat
polyglot
in
our
in
our
cincd
mechanisms.
For
example,
we
have
bamboo
as
well
as
flux,
cd,
we'll
get
into
that
later.
I
think
we
different.
We
definitely
have
some
teams
building
that
new
things
and
and
generally
those
we
would
get
ops
methodology,
but
we
have
to
be
realistic
that
it's
not
the
hammer
for
every
now.
I
know
that's
supposed
to
speak.
C
And
not
really
like
in
just
like
in
one
last
comment
is
like
you
know,
it
was
very
useful
mechanism
to
enable
our
platform
in
multi-cloud
model.
We
have
like
different
cloud
providers
and
different
infrastructure.
Besides
our
private
cloud
as
well
and
having
that,
like
you,
know,
different
differentiator
in
the
in
the
layer
underneath
the
kubernetes
itself,
we
have
like
different
network
model
and
different.
Like
you
know,
mechanism
and
and
virtualization
model
as
well
and
programming,
underneath
the
hood
that
were
actually
tops
was
like
is
abstracted
layers.
A
All
right,
thank
you
and
let's
go
to
the
next
question
and
I
think
this
is
the
one
it's
almost
jumping
to
the
end
immediately.
But
what
what
the
lessons
did
you
learn
I'd
like
to
I'd
like
you
to
talk
about
like
the
scale
of
what
you're
doing,
maybe
the
journey
that
you've
taken
to
get
here.
What
you
would
recommend
for
other
people
amir?
Why
don't
you
you
go
ahead.
C
Sure
so
I
would
say,
like
you
know,
fuels
the
lesson
learned
is
number
one
understanding
the
complexity
and
the
whole
the
whole,
like
you
know,
big
picture
about
like
we're
going
to
be
used
and
how
we
can
implement
that
and
how
we
can
introduce
that
to
the
development
team
was
building
that
guitars
model.
That
was
one
of
the
challenges
or
one
of
the
lesson
learned.
The
second
one
was
mainly,
as
our
team
is
more
of
like
the
engineering
team
who's
handing
over
that
automation,
piece
to
all
the
devops
communities
inside.
D
C
Our
business
unit,
we
have
about
many
of
them
actually
in
the
company
so
enabling
this
culture
and,
let's
understand
like
how
that
will
work
and
how
that
is
different
than
the
traditional
operational
model,
how
the
declarative
you
know
aspect
of
kubernetes
and
how
the
declarative
aspect
of
managing
your
infrastructure
that
that
was
new
that
was
unique
and
new
for
them.
There
was
always
like
this
aha
moment,
like
after
a
while,
like
how
we
do
that.
Where
is
my
process?
Where
is
my
validation
process?
D
You
know
the
company
has
set
audit
rail
based
on
traditional
ticketing
systems,
and
so
one
of
the
issues
we
were
facing
is
that
those
githubs
operations
needs
to
be
mirrored
into
the
audit
trail,
and
so
we've
spent
a
significant
amount
of
time
to
build
some
automation.
So
when
you
do
a
commit
and
you
create
a
pull
request,
we
open
a
ticket
automatically
and
then
the
the
approach
of
accepting
the
ticket
will
automatically
give
a
plus
one
into
our
pull
request,
and
we
made
that
plus
one
mandatory.
D
So
the
the
operation,
the
the
contact
emerged
unless
the
plus
one
exists,
and
so
this
has
been
for
us
a
game
changer,
because
you
allow
us
to
be
so
compliant
pci
compliant.
It
made
us
work
very
well
with
the
rest
of
the
company
without
forcing
us
to
be
to
change
the
process
that
the
company
follow
on
audit.
B
Yeah,
that's
a
that's
a
great
point
and-
and
we
have
similar
concerns,
you
know
as
we
partner
with
a
number
of
insurance
companies
and
and
other
other
entities.
We
have
a
lot
of
regulatory
and
compliance
issues,
not
issues
but
concerns,
and
one
thing
about
a
git
ups
methodology
is,
you
know,
effectively
access
to
git
and
the
and
the
role-based
access
control
around.
That
is
really
important
to
think
through,
because
now
git
is
your
control
surface
and
there's
different
ways
to
address
them
and
we're
employing
similar.
B
You
know
approaches
with
automation
around
web
hooks
and
pr's,
and
things
like
that.
We've
had
some
other
lessons
as
well
from
the
last
year.
At
the
top
level,
I
would
say:
ux
really
matters,
developer,
experience
and
and
usability
matters,
for
example
we're
using
flux
cd
for
most
of
our
infrastructure,
that
is
in
kubernetes,
and
it's
working
quite
well,
but
the
primary
user
of
that
is
our
cloud
engineering
team.
Who
knows
that
full
stack?
You
know
for
a
new
developer
or
a
new
development
team.
That's
that's
just
getting
started.
B
The
ux
of
that
is
really
look
at
logs
and
so
there's
lots
of
different
tools.
You
can
bring
to
bear,
but,
let's
think
up
front
about
who's
going
to
use
it
and
what
interactions
do
they
need
and
what
workflows
need
to
be
supported
when
choosing
tools
I'll
also
say
that,
particularly
for
kubernetes
workloads
and
kubernetes
itself,
one
thing
that
get
ops
will
really
shine
a
light
on
quickly
when
you
get
to
scale
out
horizontally
is
how
are
you
dealing
with
configuration
management?
B
It's
worth,
bearing
in
mind
up
front
I'll,
also
say
that,
in
terms
of
workflows,
around
branch
management
promotion
of
code
between
environments,
you
know:
how
are
you
running
things?
You
know
when
you,
when
you
move
to
get
ops,
if
you,
if
you
have
gaps
there
or
if
you
have
varying
points
of
view
in
your
organization,
you're
going
to
find
out
quickly
so
again,
I'm
up
front
to
work
out
how
as
an
organization,
you
want
to
do
that
and
if
you
want
to
support
different
methodologies.
A
C
Yeah
sure
so
I,
like
matt,
mentioned
actually
using
similar
frameworks
around
githubs
and
in
communities
in
general.
Like
so
flux
is
one
of
them,
helm
is
the
second
one,
and
in
additional
we
had
to
start
like
we
start
using
as
well,
like
you
know,
other
project
outside
of
coordinated
itself,
to
complete
the
picture
so
completing
that
ecosystem.
D
D
D
One
of
the
things
that
we
would
like
to
see
more
on
the
landscape
is
to
go
more
into
the
details
of
helm,
charts
and
operators.
We
use
those
quite
extensively,
and
you
know
the
technology
is
the
sweat.
Helm
is
a
graduated
project,
but
inside
helm
many
charts
are
in
different
state,
and
so
we
would
like
to
see
those
being
more
mapped
out
or
or
owned
by
the
project
themselves,
so
they
become
more
stable
and
more
reliable
and
the
same
applies
to
the
operators.
B
But
you
know
we
we've
certainly
evaluated
a
bunch
of
other
other
things
as
well.
You
know
we're.
You
know:
we've
looked
at
everything
from
spinnaker
to
argo,
github
actions,
bamboo
box,
cd,
there's
a
lot.
Why
and
that
just
kind
of
scratches
the
surface
of
what's
there
in
the
in
the
community,
but
for
us,
lux
city
has
been
very
good,
particularly
because
you
know
we
have
quite
locked
down
environments.
B
You
know
we
have
a
lot
of
security
concerns
and
so
flux
in
particular,
since
it's
you
know
effectively
a
bot
sitting
inside
the
cluster
reaching
out
versus
something
like
github
actions
or
more
traditional
things
where,
from
outside
the
cluster,
you
want
to
authenticate
over
the
internet
or
over.
You
know
just
somewhere
else
to
the
api
server
of
a
kubernetes
cluster.
B
B
Also,
when
evaluating
you
know
what
should
we
use
for
logging,
for
example,
we're
using
the
bonsai
cloud
logging
operator,
because
it's
declarative
in
nature,
so
once
you
start
down
this
get
ops
and
you
and
you
start
seeing
the
benefit
of
oh,
I
want
to
change
something
I'll
make
a
quick
pr
that
bumps
a
version
number
and
then
like
done
right.
No,
no,
no
toil,
no
drama.
You
start
taking
a
really
hard
look
at
at
systems
and
other
building
blocks
of
your
infrastructure
that
are
not
described.
Declaratively
and
that's
been
one
big
mind
shift.
B
I
think
in
our
organization
that
you
know
it
it's
just.
It
ends
up
as
a
as
a
filter.
You
almost
apply
to
say.
Well,
I
have
this
wonderful
thing
in
place
that
I
don't
have
to
deal
with,
because
it's
automated,
I
don't
want
to
add
something
that
has
a
manual
step
to
it,
or
that
is
not
declarative
and
item
potent
and
all
of
those
sort
of
things.
Yeah.
D
And
I
want
to
build
on
on
the
the
point
that
matt
was
making
on
giving
the
keys
of
the
realm.
So
one
of
the
approach
we
use,
you
see
we
created
what
we
call
a
control
cluster.
So
it's
the
cluster
where
the
deployer
sits.
So
our
argo
cd
will
sit
in
that
control
cluster,
which
only
the
platform
team
have
asked
us
to.
C
And
in
our
case,
actually
we
we
built
our
own
framework.
We
actually
it
was
released
like
a
couple
of
weeks
ago
to
the
open
source
communities
as
well.
It's
called
kiran
and
that's
kind
of
it's
a
management
here
for
all
the
operators
that
we
run
today
and
we
govern
and
call
we,
you
know
also
rise
within
fidelity
ecosystem
and
that
and
it's
based
on
githubs
as
well.
C
So
it's
pretty
cool
actually
because
it
does
allow
us
to
extend.
You
know
the
number
of
operators.
It's
also
it
puts
in
like
into
multiple
level,
with
its
production
grade,
operators
or
experimental
operators
that
can
only
get
exceeded
to
a
certain
level
of
maturity
and
can
be
all
only
go
for
like
a
dev
level
for
development
purpose
or
so
in
additional
it
will.
It
does
have
like
conversion
management
control
as
well
around
that
and
it
does
up.
You
know
it
follows
the
same
approach
for
how
we
can
with
github.
B
Yeah,
I
think
I
think
there
are
challenges
too,
as
organizations
scale
I
mean
if
you're
a
small
startup
and
everybody
can
fit
in
the
same
room.
You
can
just
pick
a
stack
or
pick
a
tool
and
just
you
know
altogether
do
it.
In
our
case,
however,
you
know
we're
only
you
know
six
or
seven
years
old
now,
but
you
know
we
have
existing
processes.
B
For
example,
you
know
some
teams
might
use
bamboo
or
some
other
system
for
smart
brands,
oxley
compliance
so
that
we
have
a
an
audit
trail
of
changes
to
the
code
as
well
as
the
infrastructure,
but
then,
on
the
other
hand,
we
might
want
to
use
flux.
So
so
I
would
encourage
folks
looking
at
this
not
to
be
too
absolute
and
just
keep
focus
on
what
problems
you're
trying
to
solve.
B
You
know,
for
example,
you
could
have
an
existing
ticketing
system
or
a
workflow
system
like
bamboo
or
jenkins
or
whatever,
that
you
know
that
is
used
for
compliance
and
then
provides
that
that
audit
and
that
control
workflow.
It
could
just
merge
a
branch
and
then
something
like
flux
could
pick
up
and
wake
up
and
do
it.
You
know
when
you
put
these
systems
together
and
everything
is
moving
in
in
parallel.
B
You
know
you
can
make
a
lot
of
work
for
yourself
that
you
didn't
expect.
If
you
say
oh
well,
since
this
is
get
ops
now
get
ops
has
to
be
our
control
surface
as
well.
So
we
need
to
get
rid
of
things
that
work
just
fine
and
move
everything
to
kubernetes
our
back
and
teams,
and
all
of
that
right,
you
can.
D
C
Like
you
know,
I
want
to
move
from
a
minor
version
of
kubernetes
to
the
next
one
or
major
version,
or
I
want
to
patch
my
ami,
like
you
know,
and
update,
like
the
images
that
I'm
using
for
my
nodes
and
so
on.
So
it
was
a
control
man
and
it
was
very
decent.
Actually,
the
second
use
case,
I
would
call
that
had
impact.
Our
cluster
is
large.
It's
multi-tendency,
so
we
build
using
a
git
ops
model
as
well.
C
A
mounted
multi-tendency
operator
that
operator
will
guarantee
the
same
application
on
boarding
so,
for
instance,
you
know
using
it
also
in
this
case
you
can
define
your
application.
You
can
connect
it
to
our
ticketing
system.
In
the
back
end,
you
can
define
who's
the
team
responsible
for
that.
What
rules
you
are
and
that
operator
attack
will
take
that
it
will
create
its
own
spaces.
It
will
connect
it
to
all
the
fidelity
ecosystem.
In
the
back
end,
it
will
set
up
that
name
space.
C
It
will
set
up
the
routing
the
ingress,
increases,
management
and
routing
rules
and
firewalls
or
like
old
aspect.
So
at
the
end
of
the
day,
you
know
the
developing
team
will
get
like
a
ready
environment
already
environment
within
that
cluster,
for
their
development
effort.
Again,
gitoffs
was
used
in
this
case,
and
it
was
actually
very,
like
you
know,
successful,
like
some
of
this
cluster
clusters
reach
out
like
217
spaces
or
applications
running
and
share
in
shared
environment.
C
D
Yeah-
and
I
I
like
that,
the
biggest
benefit
for
us
is
the
automation
that
we
can
drive
with
this
right.
So
when
we
have
a
minor
release
of
kubernetes,
we
can
basically
drive
the
automation
from
our
sandbox
environment.
If
that
passes
the
tests,
then
we
can
go
up
to
the
dev
and
we
can
do
selective
upgrades
of
different
clusters.
So
we
have
a
test
cluster
in
every
environment,
plus
our
control
cluster,
that
we
can
go
and
upgrade,
and
then
we
can
move
to
other
clusters.
D
We
have
like
a
hierarchy
of
clusters
depending
on
the
impact
that
those
applications
may
have,
and
so
we
go
to
a
certain
order.
The
other
thing
we
do
is
that
we
express
when
we
create
a
cluster
teams,
have
the
ability
to
choose
a
type
for
a
type
it
could
be
a
single
tenant.
It
could
be
a
single
tenant
with
pci
compliance
on
it.
It
could
be
a
multi-tenant
or
it
could
be
a
cluster
that
they
use
for
specific
things
that
may
be
created
and
destroyed
after
a
while.
D
So
all
of
that
is
pressing
it
and
that
will
trigger
the
automation
to
build
all
of
those
right
before
all
this
was
done
through
tickets,
with
our
vm
environment,
for
instance,
all
done
more
manually
than
what
we
were
able
to
do.
So
you
know
definitely
allow
us
to
see
what
happened.
Allow
us
to
automate
the
majority
of
the
operations.
Meanwhile,
keeping
compliance
with
it.
B
Yeah
I
mean
we're
operating
at
a
slightly
lower
scale
by
an
order
of
magnitude,
at
least
in
total
number
of
clusters
or
total
number
of
developers.
But
I
would
definitely
you
know
again
it's
sort
of
a
lesson
learned,
but
there's
a
lot
of
edge
cases
when
managing
kubernetes
clusters.
Generally,
we
run
across
multiple
clouds,
we're
running
both
gke
and
eks
and
production,
and
we
have
a
multi-account
setup
and
all
of
that
there
can
be,
for
example,
race
conditions
when
deploying
various
operators.
B
There
are
things
that
that
should
just
work,
but
in
in
reality
you
know.
Sometimes
they
still
do
need
a
human
intervention
and,
depending
on
the
size
of
your
team
and
your
ability
to
completely
automate
everything
you
know
you
might
have
to
make
some
decisions
as
we
have
to
to
automate
some
things
that
are
readily
automatable
but
take
care
with
others
going
back
to
the
helm
bits.
Another
just
small
concrete
example.
B
Is
you
know,
helm
has
a
plug-in
model,
so
you
might
use
a
helm
chart
that
when
doing
an
upgrade
actually
executes
things
right
to
help
mutate
or
migrate
migrate
state.
But
if
you're
taking
a
templating
approach
and
you're
not
actually
running
helm
against,
you
know
in
this
way
you
might
actually
inadvertently
not
realize
that
some
upgrade
to
a
helm
chart
that
was
put
in
uses
a
plug-in
and
and
that's
not
being
captured
by
your
workflow.
D
D
One
thing
we
do
in
our
upgrading
the
sandbox
to
validate
the
upgrade
happened
successfully.
We
run
sonoboy
and
qbench
to
basically
see
the
the
final
result
of
the
upgrade.
Has
some
sort
of
compliance
to
a
final
state
is
compliant
with
cis
benchmarking,
and
then
we
run
some
synthetic
tests
to
see
that
you
know
you
can
deploy
an
application
comes
up
and
all
this
kind
of
stuff.
So
that's
that's
been
a
way
for
us
to
enable
some
automation
around
you
know
upgrades
for,
for
especially
minor
upgrades,
more
than
major
upgrades.
C
As
a
similar
to
fibre,
actually
we
have
this
similar
process.
We
have
our
own
validation
process
that
run
after
most
of
these
processes
right
and
we
had
to.
We
had
a
full
framework
like
using
cucumber
another
actually
to
do
like
validation
for
each
one
of
these
operators,
and
some
of
them
are
very
critical,
like
you
know
our
secret
management
integration
piece,
for
example
like
so
that's,
that's
a
require.
That's
a
that's
a
must
and
yeah.
This
species
is
like.
C
C
The
the
challenge
for
us
between
rebuild
and
upgrade
is
mainly
the
ecosystem
around
kubernetes,
not
the
communities
upgrade
itself.
So
the
difficulties
like
around
everything
else
around,
like
you,
know
all
the
the
security
aspect,
the
regulation,
the
firewalls,
the
config
configuration
the
authentication
authorization
back
to
some
of
our
data.
You
know
our
data
center,
like
you
know,
resources
and
others.
That's
where
we
see
that
challenges
are
like
for
like
rebuild
besides.
B
C
B
Yes,
we
have,
we
have
well
so
I'll
say
we
are
a
work
in
progress,
but
earlier
this
year
we
had
a
couple
of
applications
moved
to
using
flux
for
application
deployments,
I'm
enthusiastic
about
what
comes
next
for
flux
with
the
new
version.
I
know
that
I
know
that
the
project
is
doing
some
work
around
observability
and
then
making
the
ux
around
that
a
little
easier.
I
think
for
for
some
teams
that
we
have
onboarded
their
first
few
services
to
use
flux.
There's
been
a
little
a
bit
of
a
learning
curve.
B
We've
also
had
really
good
luck
with
our
email,
remarketing
team,
using
loki
to
help
understand,
what's
happening
in
flux,
so
we've
got
dashboards.
You
know,
they've
got
you
know,
what's
happening
with
the
service
and
and
what's
happening
with
flux,
but
again
like
that.
That
tool
in
particular
is
sort
of
watch
and
look
for
things
in
logs.
It
doesn't
have
a
great
ux,
that's
broadly
accessible.
D
For
us
is
a
little
bit
more
complex
because
the
application
teams
are
basically
they
have
their.
You
know:
ci
cd
pipeline
around
jenkins
been
defined
and
used
for
for
a
very
long
time,
and
there
are
a
lot
of
security
hardening
and
things
have
been
built
on
top
over
the
years,
so
go
in
there
and
say:
hey
guys,
replace
all
this
with
something
different.
Eventually,
it
will,
but
I
think
it's
a
longer
conversation
and
it's
going
to
take
a
good
amount
of
time.
So.
B
So
we
use
terraform
heavily
right,
but
how
do
you
actually
deal
with
you
know
all
of
the
things
outside
of
the
actual
service
itself,
that
it
uses
the
databases,
the
buckets
the
cues?
All
of
that?
How
do
you
make
that
work
as
well?
And
there
are
approaches
to
do
that
as
well,
that
that
word
that
we're
using?
But
there
there
are
complexities
around
that
or,
for
example,
many
frameworks.
The
first
time
the
new
version
of
the
service
hits
an
older
schema.
They'll
do
a
schema
migration.
B
Well,
one
of
the
cool
things
about
get
ops
is
that
you
can
revert
things.
Those
migrations
don't
go
backwards.
So
there's
a
lot
of
things
that,
like
once
you
get
over
the
initial
hey,
I
could
deploy
my
service
again
like
when
you
really
think
through
you
know,
do
those
things
that
are
not
necessarily
declarative
or
if
they
are
declarative,
they're,
declarative
plus,
like
terraform
or
conformation,
or
something
that
actually
has
to
be
run
that
maybe
can't
be
rolled
back
just
like
you
know,
a
container
version
can.
D
Yeah,
I
did,
I
did
an
internal
experiment
was
very
really
an
experiment,
but
we
use
we
look
at
ohm,
and
so
I
think
you
know
application
manifest
will
which
includes
all
the
the
con.
All
the
dependencies
connectivities
and
network
boundaries
are
going
to
be
extremely
important
to
move
to
githubs
for
application
deployments,
and
so
the
open
application
model
is
a
new
format
that
came
out
and
still
evolving.
But
it's
a
very
good
starting
point.
If
you
guys
ever
look
at
it.
B
Yeah,
I
think
around
january
I
first
saw
the
initial
specs
for
c
c
c:
nab
cnab
we're
not
using
it
yet,
but
I've
been
following
the
project
over
the
year
and
I'm
quite
excited
by
the
potential
there
again
it's
a
cloud
native
application
bundle
and
I'm
not
involved
with
that
project.
We
we
don't,
have
you
know
we
don't.
I
don't
have
my
hands
dirty
from
from
playing
with
it
yet,
but
you
know
things
like
that.
B
That
encompass
not
just
the
application,
but
all
of
the
surrounding
infrastructure
and
tooling
that
can
be
packaged
together
in
a
version.
Bundle
that
for
us
is
I'm
quite
excited
about
that
in
particular,
and
a
lot
of
our
folks
use
vs
code
and
some
of
the
integrations
for
some
of
the
other
related
tools
to
to
cnab
look
promising
as
well.
Now
that
they've
matured
over
the
year
and.
A
C
It
did
mean
a
lot.
I
mean
it
started
number
one
I
think
for
fidelity
in
general.
It
did
reshape
our
like
multi-cloud
strategy.
So
right
now
we
have
like
a
very
united
strategy
or
using,
like
you,
know,
multi-public
cloud
provider,
even
in
our
private
cloud,
using
the
kubernetes
technology
and
and
container
technology
in
general
that
build
this
portability
between
the
cloud
provider.
It
did
united
that
the
company
was
one
direction
around
how
to
manage
your
workload
across
multi-clouds.
C
I
think
it
did
also
add
a
lot
of
value
for
our
teams,
like
you
know,
going
through
the
ecosystem,
with
cncf
explorer
to
all
the
projects.
That's
going
on
right
now,
understanding
what's
coming
and
where
is
the
community
is
and
where
to
invest?
It
did
also
achieve
our,
like.
You
know,
work
model
so
like
in
the
past.
Like
few
months,
we
started
releasing
our
own
open
source
project
like
we
released
like
two
of
them.
A
Fantastic
and
I'm
really
happy
to
hear
that
your
to
your
teams
are
getting
more
involved
with
the
community
and
with
open
source,
because
that's
how
all
of
this
runs
together
we're
pretty
much
out
of
time.
I
really
wanted
to
say
thank
you
to
matt
and
amy
and
fabio
for
giving
your
time
and
talking
about
the
challenges
and
the
experiences
that
you
faced.