►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
How Intuit Manages Cloud Resources Via GitOps - Jerome Kuptz & Ameen Radwan, Intuit
Speakers: Jerome Kuptz, Ameen Radwan
At Intuit, there are 1000 development teams consisting of 7500 developers given freedom to pick infrastructure as code (IAC) solutions that best fit their needs for the cloud. In addition to this autonomy, we support teams defining their own automation using different tools. While this freedom gives developers flexibility, creating a process that supports all teams across multiple cloud providers in a large, multi-platform organization with authorization & access controls was overwhelming. Intuit needed a solution for these challenges while keeping developer friction to a minimum. In response, we have created an open source project named Cello, which is a service for running IAC solutions via GitOps. By utilizing GitOps process with IAC, Cello improved developer velocity managing the lifecycle of cloud infrastructure, while maintaining flexibility & security standards. Come learn how Cello helps Intuit engineers unify management of cloud resources while retaining existing processes.
A
A
And
quick
agenda
so
we're
gonna
go
over
a
little
bit
about
our
history.
What
our
landscape
looks
like
at
Intuit
discuss
a
little
bit
about
the
problem
and
we'll
go
over
a
solution.
Show
you
a
demo
and
do
a
q
a
so
with
that
go
ahead
and
get
started
into
it's
been
on
this
journey
for
quite
a
while
back
in
about
2013..
We've
got.
A
A
So
yeah,
okay,
we
we
started
very
narrow.
We
declare
we're
going
to
be
all
in
the
cloud,
so
we
were
getting
out
of
data
centers
at
that
time
and
we
started
with
just
a
few
applications.
Few
of
our
services,
and
once
we
had
success
with
those
we
decided
about,
let's
say
2017
or
so
dates
are.
Yours
are
a
little
hazy.
At
times
we
shifted
the
scale.
So
we
we
had
such
good
success.
A
We're
like
we're
going
to
push
everyone
now,
let's
all
go
into
the
cloud,
so
there's
much
broader
adoption
within
the
company,
so
Engineers
were
creating
all
kinds
of
cloud
resources:
AWS
accounts.
What
whatever
they
needed
to
do,
they
were
pretty
free
to
to
meet
the
needs
of
their
services
and
applications,
and
then
we
just
stumbled
into
the
kind
of
I
think
a
problem.
A
Many
of
you
may
have
had
working
at
larger
companies
and
you
end
up
with
a
large
ec2
Fleet,
and
that
gets
to
be
a
bit
painful
to
manage
which
about
I
think
2018
to
around
there
led
us
to
Containers,
which
obviously
led
us
to
kubernetes
and
and
scaling
up
on
that.
So
all
our
services
are
pretty
much
in
kubernetes
on
containers.
Now
we
don't
really
run
as
much
in
ec2
anymore,
and
that
was
a
modernization
of
our
services.
A
A
A
So
for
a
lot
of
our
services,
they
had
to
have
RDS
sqs
buckets
things
like
that,
all
the
kinds
of
persistence
and
messaging,
you
would
need
to
do
the
job.
So
we
categorized
that
as
supporting
resources,
then
we
had
some
things.
We
were
using
Cloud
resources
that
weren't
really
container
based.
These
would
be
like
Sage,
maker
or
Amazon
connect,
or
something
like
that
without
couldn't
put
those
in
containers,
so
we
just
had
to
kind
of
figure
out
how
to
deal
with
those.
A
And
finally,
we
still
had
some
what
we
would
consider
legacy,
not
necessarily
Legacy
from
the
perspective
of
the
Technologies
but
Legacy
to
us,
because
we
couldn't
move
these
into
containers
necessarily
and
we
weren't
ready
to.
We
aren't
ready
to
just
completely
turn
them
off
or
or
do
something
else
with
them.
At
this
point.
A
A
If
you
will
it's
custom,
automated
automation,
so
from
Soup,
To
Nuts
doing
everything
they
can
possibly
do
to
manage
their
their
Cloud
resource
and
then
it
would
get
down
to
just
doing
something
in
Jenkins,
I
just
wrote
a
little
script
and
just
pop
it
into
that
whole
workflow
good
enough
and
then
you've
even
got
as
well
the
manual
people.
This
would
be
laptops
my
bash
script.
A
Maybe
someone
goes
and
console
and
does
some
random
things
they
needed
to
do,
or
just
deploying
even
a
cloud
formation
stack
in
there,
and
once
we
found
that
we
looked
at
what
was
it,
they
were
using
well
on
the
whole
cloud
formation
a
lot.
We
had
some
use
of
com,
Cloud
development
kit,
and
we
also
had
use
of
terraform
as
well
so
and
it
could
be
cross
these
different
orchestrations.
They
could
be
using
cloudformation
and
Cloud
development
kit
or
cloudformation
and
terraforming,
even
as
well.
A
A
So
we
stepped
back
said
we
need
to
come
up
with
a
few
principles
here.
Otherwise,
whatever
solve
would
come
up
with
is
not
going
to
be
able
to
solve
everything
or
at
least
give
the
engineers
enough
of
a
platform
to
to
do
their
business
first
thing
was
to
align
with
our
existing
standards.
They
may
be
internal
standards,
industry
standards,
but
whatever
those
were,
we
need
to
make
sure
we
were
within
guidelines
of
those.
A
A
A
So
we
realized
some
things
were
missing.
We
could
certainly
align
with
860
standards
and
we
could
already
isolate
from
the
cloud
environment
in
multiple
ways,
but
we
didn't
have
anything
that
open
source
really
met
the
needs
of
the
engineers
being
able
to
pick
whatever
they
wanted.
Whatever
we
were
currently
doing
was
definitely
not
Cloud
agnostic
and
then
they
weren't
using
infrastructure
as
code
with
Git
apps.
That
was
sometimes
just
foreign
for
them.
A
B
All
right,
thank
you
so
before
that,
before
we
actually
get
into
the
demo,
first
I
want
to
talk
a
little
bit
more
about
where
cello
fits
into
our
overall
ecosystem
from
a
developer
perspective.
So,
first
we
are
going
to
walk
through
a
brief
hypothetical
scenario
for
a
developer
that
wants
to
work
on
a
new
project.
Let's
say:
I'm
a
developer
and
I
want
to
make
a
new
Lambda
project
that
into
it
or
something
so
the
process
from
from
my
perspective
would
be
I'm
going
to
come
to
some
internal
developer
portal.
B
B
So
we
take
that
information.
We
end
up
sending
it
to
an
orchestration
layer,
the
details
of
that
orchestration
layer,
don't
matter,
but
essentially
we
need
to
talk
to
a
bunch
of
different
systems,
because
we
just
have
infrastructure
for
our
users
right,
because,
when
I
make
a
new
project,
I
need
a
place
to
store
my
code.
I
need
a
way
to
deploy
it
and
I
need
that
nice
integration
so
that
I
have
continuous
integration
deployment.
B
So
the
first
thing
that
orchestration
layer
will
call
is
GitHub.
We
need
to
start
with
our
code,
so
we'll
make
a
couple
repositories
for
our
project
for
the
sake
of
consistency
with
our
services,
we
end
up
making
a
application
code
repo
where
we'll
store
our
infrastructure
as
code
as
well
as
a
deployment
repo
where
we
store
our
manifests
I'll
get
into
some
of
the
more
specific
details
about
what
I
mean
by
manifests
when
we
get
to
the
actual
demo
part,
but
we
basically
in
a
similar
way
to
kubernetes
manifest.
We
have
shallow
manifests.
B
So
once
I
have
my
GitHub
repositories,
then
we
end
up
talking
to
cello
I.
Have
this
I?
Have
these
repositories,
where
I'm
going
to
be
doing
some
Cloud
infrastructure,
I'm
going
to
be
writing
Cloud
infrastructure
code
I
need
a
way
to
deploy
it.
So
we
end
up
calling
cello
and
telling
it
we've
got
this
new
project
going
on.
We've
got
we're
going
to
be
deploying
things
out
of
this
repository.
Cello
will
do
some
work.
B
These
that
token
will
allow
us
to
essentially
make
calls
to
cello
so
that
we
can
deploy
specifically
for
this
particular
project.
So
we'll
take
that
token
and
then
we'll
use
that
token
to
talk
to
Jenkins
Jenkins
is
our
CI
CD
platform
that
we
use
at
Intuit
you.
This
doesn't
necessarily
have
to
be
Jenkins.
This
could
be
any
CI
platform.
It
could
be
GitHub
actions
Travis
whatever.
As
long
as
you
have
the
ability
to
store
Secrets.
B
So
the
moment
that
code
gets
in
our
Master
remain
whatever
your
default
branch
is
so
the
moment
that
code
gets
into
our
default
brand.
We're
going
to
kick
off
a
gen,
we're
going
to
kick
off
a
Jenkins,
build
so
immediately
we'll
go
through
we'll
start
our
CI,
Pipeline
and
it'll
do
all
the
things
you
would
normally
expect.
Let's
build
our
let's
build
our
infrastructure
as
code
make
sure
it
passes
all
our
tests
make
sure
it
passes
any
like
Security
checks
or
linting
rules.
B
Anything
like
that
and
then
once
we've
made
sure
all
our
code
looks
good,
we'll
package
it
up
and
then
now
is
the
part
where
we
get
back
to
our
actual
deployment
process
we
want
to.
We
know
our
code
is
good.
We
know
it's
all
ready
to
go
so
now
we're
going
to
deploy
it
to
our
various
accounts,
so
this
is
where
Jenkins
will
actually
use
that
token.
We
talked
about
earlier
it'll.
Take
that
token
from
or
take
that
token
and
then
use
it
to
call
the
channel
apis
and
tell
it
hey.
B
Yeah
I
want
to
actually
deploy
that
right.
Now,
pressing
approve
button
and
then
same
thing,
Jenkins
will
end
up
calling
cello
cello
will
go
through
the
deployment
process.
Kick
off
that
kick
off
that
build
whatever
infrastructure
as
code
process.
That
is
whether
it
be
like
terraform,
apply
or
cdk
deploy,
or
just
whatever
cloud
formation
or
like
whatever
thing
it
needs
to
do.
Depending
on
the
infrastructure's
code
language,
it's
going
to
use
that
it's
going
to
make
run
those
commands
and
stream
those
logs
back
to
Jenkins
and
the
developer
will
be
able
to
see
oh
cool.
B
My
my
resources
are
deploying
awesome,
and
so
you,
through
that
whole
process,
the
developer
within
as
as
little
as
potentially
five
minutes,
depending
on
how
complicated
their
infrastructure
is,
they'll
go
from
I
merged.
A
PR
and
I
got
my
code
into
my
default
Branch
to
oh,
my
resources
are
all
deployed
and
ready
to
go
and
I
can
actually
start
testing
against
it.
I
can
actually
start
making
API
calls
or
to
my
Lambda
or
whatever,
whatever
they
end
up
needing
to
do.
So,
that's
a
so
that's
what
the
ends
up.
B
B
Actually.
Oh,
it's
a
slightly
different.
Oh,
it's
a
slightly
different
screen
size.
I!
Guess!
That's
fine!
It's
not!
Actually
me!
Okay,
whatever
so
we're!
Basically
gonna
walk
through
this
quick
demo.
I
had
to
have
it
pre-recorded,
just
because
I
didn't
want
to
worry
about
like
network
connectivity
or
anything
like
that.
But
essentially,
this
is
what
I
would
be
running
on
my
computer,
so
for
for
a
little
bit
of
context
here.
The
idea
here
is:
we
have
a
sample
cdk
application,
you
don't
need
to
know
necessarily
cdk.
B
In
particular,
this
could
be
any
interest
infrastructures
code,
language.
The
thing
you
really
need
to
know
is
I
write
some
typescript
code.
It
makes
a
q
and
a
topic,
and
we
want
to
get
that
into
our
AWS
account
and
so
I
have
cello
running
locally
in
this
terminal
right
below
this
code,
and
so
what
we're
going
to
be
doing
be
doing
here
is
we're
kind
of
going
to
walk
through
the
API
calls.
B
That
would
be
happening
if
I
want
to
actually
see
how
I
could
diff
and
deploy
this
code
to
some
sample
AWS
iconic
head.
So
now
we
are
going
to
skip
forward
a
tiny
bit
all
right.
So
the
first
thing
that
would
happen
is
we
need
to
create
a
project
in
cello.
So
going
back
to
some
of
those
principles,
you're
talking
about
of
separating
out
our
isolating
our
environments,
grouping
making
sure
we
follow
infrastructure
as
code
as
a
main
principle.
We
want
to
create
a
we
want
to
create
this
nice
little
project.
B
That
way,
you
can
say,
we've
got
this
project
here.
It
will
be
deploying
out
of
this
repository
and
anything
I.
Do
any
operations
I
do
related
to
this
repository,
we're
going
to
basically
be
using
we're
going
to
be
deploying
by
reading
some
information
from
that
repository
and
applying
to
it.
In
this
case,
we
happen
to
be
using
the
cello
project,
because
we
have
some
example
example
infrastructure
and
manifests
in
that
repository,
but
this
could
be
whatever
your
repository
you
want
to
use.
It's
just
a
matter
of
coincidence
happens
also
be
the
cello
project
repo.
B
So
we
would
end
up
I'm
gonna
skip
ahead,
a
tiny
bit
so
I
keep
talking
about
these
manifests.
I'll
talk
a
little
bit
more
about
that,
so
essentially
kind
of
like
how
in
kubernetes
you
have
the
idea
of
a
manifest
kind
of
describing.
Oh,
these
are
types
of
things
we
need
to
deploy.
We
have
this
idea
of
cello
manifest
so
like.
If
I
have
a
couple,
different
environments
and
I
have
a
couple
of
different
things:
I
need
to
deploy
and
I
want
to
deploy
them
a
certain
way.
B
We
have
a
couple
different
manifests
to
say:
oh,
we
have
this.
We
have
this
cdk
application.
It's
going
to
be
we're
going
to
be
using
cdk.
We
have
a
couple
args.
We
need
to
pass
whenever
we
do
this
deployment
some
environment
variables.
We
have.
We
want
to
use
this
particular
project
we
need
to
do.
We
want
to
do
these
types
of
operations,
so
we'll
just
we'll
declare
this
manifest.
B
That
has
that
information,
and
so
these
manifests
will
live
in
that
deployment,
repo
that
I
was
talking
about
earlier
and
so
we'll
we'll
have
that
set
up,
we'll
call
our
create
project
API
and
now
we'll
get
back
this
cello
project
token.
So
this
is
a
token
I
was
talking
about
back
in
that
initial
onboarding
overview.
I
was
I
was
talking
about,
and
essentially
the
idea
of
the
behind
us
token
is.
B
We
want
to
have
a
token
specific
to
this
particular
project,
because
we
want
to
make
sure
if
I'm
doing
operations
I'm
really
only
doing
operations
specific
to
my
particular
project,
my
particular
application.
So
we
make
a
so
we'll
make
a
token
and
we'll
end
up
just
saving
it
somewhere.
So
that
later,
when
we
actually
call
some
of
our
other
apis
later,
we
will
actually
be
able
to
use
it
for
this
project
so
that
we'll
end
up
saving
that.
B
Let
me
go
forward
a
bit,
so
we
end
up
saving
that
away
and
then
so
next
step
is
we
end
up
creating
a
Target
so
to
get
behind
targets.
Is
you
might
have
a
couple
different
places
you
want
to
deploy
to?
Maybe
you
have
like
a
pre-prod
environment
like
a
production
environment
or
like
maybe
you
have
different
environments
or
whatever,
and
going
back
the
idea
of
that
separation
of
concerns.
B
We
want
to
make
sure
we
use
as
little
permissions
as
possible
when
we
do
different
operations,
so
the
idea
here
is
we
will
create
a
Target
specific
to
each
thing
we
want
to
deploy
to
so
that
when
I
do
a
deployment
using
my
qal
target
or
something
I
only
have
the
permissions.
I
really
need
to
do
that.
So
in
this
case
we
will.
B
We
are
creating
a
Target
here
and
we
actually
say
we
want
to
scope
it
down
to
this
specific
AWS
role
or
we
want
to
use
these
specific
permissions,
and
so
we
end
up
creating
that
Target.
The
name
sort
of
these
projects
and
targets
are
just
kind
of
sample
ones.
You
can
name
them
whatever.
You
really
wanted
to.
Probably
sounding
more
useful
to
like
how
you
want
to
actually
you'd,
probably
name
it,
something
like
the
name
of
your
environment
or
the
name
of
your
account,
or
something
like
that.
B
Now
that
we've
done
that
we
can
actually
get
to
the
actual
the
actual
like
main
operations
we
want
to
do
so
idea
here
is
we're
going
to
take
that
that
cello
token
we
decided
earlier,
and
we
end
up
using
that
as
as
our
authorization,
so
we
can
call
our
main
operations
API,
and
so
the
idea
here
is
we
we
want
to
do
an
operation.
We
know
what
project
we
want
to
what
project
we're
using.
We
know
what
Target
we
want
to
deploy
to
and
we'll
tell
it
hey
we
have
we
want
to.
B
We
want
to
make
a
new
deployment.
We
have
this
manifest
here
at
this
in
our
GitHub
repo,
here's,
the
shaw
that
we
actually
want
to
deploy,
and
so
it
will-
and
so
we
will
call
this
operate.
We
will
call
this
operations
API
and
cello
will
do
the
process
of
looking
up
that
manifest
and
actually
kicking
off
an
operation.
So
what
do
I
mean
by
operation?
B
Well
up
an
operation
essentially
kicks
off
in
our
go
workflow
and
the
idea
of
what's
Happening
Here
is
based
on
the
configuration
that
we
had
in
that
manifest
we're
going
to
kick
off
a
new
workflow
and
we're
going
to
actually
do
whatever
that
workflow,
whatever
that
manifest
tells
us
to
do
so.
In
this
case,
this
API
call
is
actually
kicking
off
a
cdk
diff,
which
is
essentially
telling
us
is
essentially
how
cdk
lets
us
see.
B
Oh
here's
what
you
previously
had
and
here's
what
you
here's,
what
you
your
changes
would
do
into
your
account,
so
we
assign
that
API
call
over
and
we
get
back
a
workflow
name,
basically
just
the
name
of
the
workflow
that
got
kicked
off
by
cello,
and
so
now,
once
we
have
that
workflow
name,
we
can
actually
see
some
of
the
different
details
about
about
the
status
of
that
workflow.
So
we
can
actually
see
things
like
the
we
can
see
like
the
status
of
that
workflow.
B
We
can
see
to
succeed
or
not,
we
can
see,
we
can
see
the
yes,
we
have
an
API
to
get
the
sas.workflow
and
we
can
see
things
like
the
logs
if
we
wanted
to
so
you
can
see
this
one
already
succeeded
and
we
can
actually
get
details
for
the
logs
and
these
logs
will
kind
of
show
us
what's
happening.
We
can
actually
see.
Oh,
we.
We
use
that
cello
token
to
talk
to
Vault
and
get
some
get
some
get
a
temporary
AWS
credential.
B
We
can
actually
see
it
hold
down
our
cdk
code
and
we
can
see.
Oh,
we
did
some
bootstrapping
and
then
there
is
a
giant
stack
of
text
at
the
bottom
saying.
Oh,
these
are
the
resources
you.
These
are
the
resources
we're
adding
or
deleting
or
whatever.
This
would
obviously
look
different
depending
on
what
infrastructure's
code
language
you're
using
and
what
exactly
you're
trying
to
deploy.
But
that's
essentially
the
main
idea
this
you
in
practice,
you
probably
wouldn't
use.
You
would
probably
wouldn't
want
to
read
it
like
this.
B
B
So
that's
essentially
the
idea
there.
That's
it
for
the
demo.
So
now
I
will
go
back
to
the
presentation,
all
right,
so
that
was
so.
That
was
so.
That
was
our.
That
was
our.
That
was
our
Deep
dive
into
cello.
Now
I'm
going
to
talk
a
little
bit
about
how
we've
been
using
cello
add
into
it.
So
internally,
we've
been
using
cello
for
on
essentially
the
past
year,
and
in
that
time
we've
been
getting
a
lot
of
adoption.
B
Internally,
we've
been
we've
created
over
a
thousand
projects
using
cello
for
various
Cloud
deployments,
as
well
as
150
of
those
more
than
150
of
those
projects
deploying
Cloud
resources
all
the
way
up
to
production.
So
we've
been
getting
a
lot,
we've
been
getting
a
lot
of
internal
usage,
but
we
still
have
more
things.
We
want
to
do
with
those
so
now
I'm
going
to
talk
a
little
about
what's
next,
so
there
are
a
couple
key
features:
we
want
to
work
on,
one
of
them
being
a
better
credential
provider
extraction.
B
B
We
another
feature
we
want
to
work
on
is
more
multi-cloud
support,
so
one
of
the
things
we
really
focused
on
was
when
we
were
like
designing
our
principles.
Was
we
want
to
be
able
to
support
multiple
clouds?
That
being
said
internally
at
Intuit,
the
one
we
obviously
have
a
grand
majority
of
our
things
on
AWS,
so
we
want
to
do
more
to
actually
support
other
other
Cloud
providers
like
gcp
Azure,
whatever.
So
that's
something
we
want
to
improve
on
further
and
then
finally
potential
things
like.
B
Oh
it's
great
that
we
have
it's
great,
that
we
have
these
apis
that
allow
us,
through
these
operations,
but
it'll,
be
nice.
If
we
could
make
that
process
a
little
easier,
because
not
everyone
wants
to
use
apis
for
everything
right.
So
one
of
the
things
we
were
thinking
about
for
eventual
for
eventual
plans
would
be
like
having
a
nice
user
interface
that
people
could
just
press
a
button.
B
A
So
yeah,
so
thank
you.
Ameen
yeah,
we'd
love
for
you
to
come
out.
Try
cello
out,
give
us
feedback.
We
have
a
great
quick
start.
I
think
you
could
set
up
fairly
quick
less
than
a
few
minutes.
It'll
have
Vault
it'll
have
all
the
things
it
needs
and
you
can
try
it
out
with
an
AWS
account.
We
have
examples
in
the
repo
and
we
have
all
our
documentation
up
there
as
well
to
help
you
along.
C
A
So
our
our
Engineers,
we
have
about
6
000
engineers
and
traditionally
they
have
always
picked
their
own
ISE
or
their
own
deployment
method
mechanisms.
So,
in
order
to
support
them
widely,
we
didn't
want
to
push
them
down
one
homogeneous
solution,
because
that
has
not
traditionally
worked
for
us.
So
we
went
with
a
more
open
solution
which
allowed
also
easier
path
to
migration
for
those
for
our
engineers,
yep.
E
B
The
token
rotation
process,
so
these
project
tokens
are
medium.
Long
live
tokens
so,
like
I,
think
they
expire
automatically
been
a
year
by
default,
but
we
have
a
couple
apis
in
place.
This
kind
of
goes
back
to
that
thing.
We
were
talking
about
credential
provider
abstraction,
but
in
the
case
of
Vault,
that
means
we
have.
We
will
we
will.
We
have
an
ability
to
clear
out
and
revoke
those
tokens
or
make
new
ones
using
some
apis.
If
we
need
to.
F
You
have
to
probably
manually
call
them
like
Postman
and
stuff,
like
that,
could
you
give
a
little
bit
more
insight
if
of
the
experience
of
an
Intuit
developer
team
having
to
you
know
when
they
Leverage
The
API?
How
that
generally
looks-
and
maybe
some
metrics
like
how
long
it
takes
for
them
to
on
board
with
it
and
all
of
those
kind
of
things
sure.
A
I
think
you've
got
one
thing
to
say
at
least
two,
so
they
don't
directly
interact
with
the
API.
We
give
them
tooling
around
that
within
Jenkins
and
we
have
a
onboarding
UI.
That
amine
was
showing
you
the
the
uml,
for
they
mostly
interact
with
GitHub
and
the
code.
They
need
to
create
their
resources
or
their
application
code.
So
typically
they
don't
have
to
see
that
at
all,
that's
mostly
our
world.
Anything
you
want
to
add.
B
Yeah
we
we
try
our
best
to
abstract
a
lot
of
like
the
more
nitty-gritty,
Parts
away
from
our
developers
as
much
as
possible.
So
in
practice
a
developer
doesn't
even
necessarily
need
to
know
that
we're
using
cello
under
a
hood
for
this.
The
idea
here
is
mainly
we
give
them
the
tools
to
allow
them
to
do
their
deployments
and
as
far
as
they're
aware
they
have
a
Jenkins
pipeline,
they
can
see
how
what
it's
doing
so
they
can
see
that,
like.
B
G
Any
other
questions
I've
got
one,
so
just
making
sure
I
understand
that
cello
is
extracting
itself
as
a
layer
outside
of
any
of
the
cdk
CFN
or
IE
like
terraform.
Is
that
correct,
yeah,
yeah,
so
who's
in
charge
of
writing,
like
say,
say
for
instance,
you
first
question
you
mentioned
it
was
Cloud
agnostic,
so
would
I
assume
that
it
doesn't
matter
what
environment
I'm,
creating
it
for
AWS
gcp
Azure
cello
is
intuitive
enough
to
create
whatever
environment
I'm
asking
for.
B
So
one
our
long-term
plan
is
to
try
and
support
all
these
different
Cloud
providers.
That
being
said,
we
need
to
build
out
the
adapter
layers
for
those
different
providers.
So
right
now
the
one
we
have
in
place
is
AWS.
We
want
to
build
out
more
as
we
go,
but
right
now,
that
is,
that
part
is
a
little
bit
specific
to
each
other
implementation.
If
that
makes
sense.