►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Outgrowing Terraform - Nic Cope, Upbound & Dalorion Johnson, Guidewire
Curious how Crossplane compares to Terraform? In this session Dalorion and Nic will discuss some of the challenges organisations can face when they need to scale their Terraform use to empower multiple teams to collaborate on declarative infrastructure management, and how Crossplane addresses these challenges. The session will be rooted in Dalorion’s experiences building and managing advanced Terraform configurations for a large software engineering organisation. Nic will highlight how the kind of challenges faced by Guidewire have informed Crossplane’s architectural decisions, allowing it to overcome some of Terraform’s pain points.
A
B
A
Okay,
so
guidewire,
but
prior
to
becoming
a
platform
as
a
service
company,
we
provided
on-premise
solutions
to
our
customers.
Our
development
process
used
to
involve
developing
complex
software
installations
at
our
customers
offices,
so
the
cost
and
effort
of
doing
so
of
installing
these
snowflake
on-site
installations
is
not
very
cost-effective.
A
It
doesn't
scale
very
well
and
it
takes
a
long
time
to
upgrade
because
the
installation
will
take
a
two
year.
It's
a
two
year
process
to
get
you
know
any
new
features
in
there,
so
we
decided
to
make
a
shift
towards
the
cloud.
So
given
guidewear's
long,
extensive
history
in
property
and
casualty,
we
were
set
in
a
better
position
to
try
to
unify
try
to
put
our
current
customers
on
a
platform
where
the
ecosystem
can
better
serve
our
customers.
A
A
A
Platform
is
you
know,
growing
and
getting
large,
and
now
we're
maintaining.
You
know
about
73
000
lines
of
hcl,
so
now
we're
starting
to
we're
starting
to
feel
some
of
the
limitations
of
terraform
we've.
We
really
use
the
heck
out
of
it,
so
one
limitation
that
we've
come
to
encounter
is
that
one
thing
I
didn't
forgot
to
mention
was
the
fact
that
our
infrastructure
is
basically
consisting
of
three
layers.
We
have
our
account
level
configuration
which
is
one
module.
A
We
have
our
infrastructure
mob
layer,
which
is
a
another
module
that
is
built
on
the
resources
that
the
account
level
module
provisions,
and
then
we
have
our
more
customer
facing
module
our
tenant
module
that
uses
those
res
those
two
previous
layers
to
provision
resources
that
the
user
did.
Our
customers
can
use
to
develop
and
customize
our
products.
A
So,
having
said
that,
one
limited
limitation
is
drift,
so
terraform
defines
our
resources
in
a
you
know,
pretty
much
in
a
file
a
you
know.
You
have
one
your
terraform
file
and
you
have
your
terraform
state
so
and
they're
stored
either
well,
the
terraform
state
is
stored
in
a
remote
bucket
and
the
terraform
source
of
truth.
What
defines
our
actual
defines?
A
What
resources
we
need
for
a
given
module
is
stored
in
git,
so
unfortunately,
there's
no
way
for
these
two
pieces
of
information
to
be
constantly
and
up
to
date
with
what
is
you
know
actually
out
there.
So,
unfortunately,
things
happen
like
automatter
up
arnold
minor
version
upgrades
or
somebody
mistakenly
goes
in
and
into
the
console
into
the
actual
provider,
console
and
changes.
Something
there's
no
way
for
terraform
to
know.
A
So
let's
say
you
want
to
change
a
tag
on
one
resource.
If
you
were
to
do
a
terraform
plan
or
an
apply
you
have
to
be,
you
have
to
take
into
account
that
there
might
be
drift
and
your
plan.
You
have
to
make
sure
that
your
plan
is
not
either
it's
not
basically
worst
case
destroying
another
resource
that
you
don't
need
to
do.
A
B
So
crossplane
approaches
managing
infrastructure.
Similarly,
to
terraform
you
know
they
both
use
declarative
configuration,
but
a
big
difference
that
crossblind
has
is
that
it
is
a
always-on
control
plane.
So,
whereas
the
open
source
version
of
terraform,
at
least
is
a
is
a
command
line
tool,
that's
invoked
on
demand.
I
know
guidewire
uses
it
via
ci
cd
a
lot,
but
you
know
you
can
away
that.
You
can
also
invoke
it
from
developer
laptops
and
like
delorean
was
saying.
B
A
B
Databases
need
updating
as
well,
and
you
weren't
expecting
that
crossplane
kind
of
approaches
this
by
by
leaning
in
to
constant
reconciliation.
So
instead
of
checking
the
world
whenever
someone
tells
crossfit
hey,
you
know
I
want
to
change
something:
there's
sort
of
two
levels
with
crossblade.
First,
you
tell
you
question:
I
want
to
change
something
that
crosstalk
saves
that
as
its
desired
state
and
then
it
just
sits
there
forever
applying
that
desired
state.
B
Go
change
this
here's!
What
I
would
change
is
this:
okay,
cosplay
and
you
say:
hey,
go
change
this
and
then
crossband
will
just
always
be
running
every
30
to
60
seconds,
correcting
any
any
problems
it
finds
in
the
world.
So
if,
for
example,
someone
goes
into
your
aws
console
and
changes
a
database
from
20
gig
to
30
gig.
A
B
A
B
B
A
A
So
within
those
different
modules
there
are
hundreds
of
resources
again
several
modules
and
they
pretty
much
all
have
to
be
within
the
same
range
of
the
terraform
version
and
aws
provider
version.
In
our
case,
I
guess
the
you
know,
aws
provider
version.
So
if
again,
if
one
layer
needs
to
basically
be
applied,
they
all
every
resource,
every
model
which
is
controlled
by
different
teams,
especially
in
the
tenant
level.
A
B
So
the
you
know
the
client,
the
declarative
configuration
of
what
you
want
to
be
running
in
the
world,
so
providers
are
versioned
in
cross
plane
as
well
and
honestly,
you
can
hit
some
some
problems
with
with
virgin.
You
do
need
to
be
careful,
you
could
say,
for
instance,
some
providers
can
declare
what
version
of
cross
plane
they're
compatible
with,
and
it
could
be
that
you
hit.
B
B
Inconsistency
in
cosplay,
2
or
your
compatibilities,
but
one
thing
that
makes
the
problem
a
lot
simpler
in
crossplane
is
that
because
it
is
a
service
because
it's
a
control
plane,
that's
just
off
running
somewhere
that
doesn't,
you
know,
need
to
have
providers
installed
on
different
people's
laptops
and
different
providers
configured
for
different.
You
know
modules
of
of
of
terraform
code.
In
that
example,
you
have
a
centralized
place
that
you
can
go
and
upgrade
your
terraform.
B
A
B
And
crossplane
takes
pretty
seriously
following
the
kubernetes,
strict
versioning
policies,
so
in
kubernetes
resource
versions,
everything
v1,
beta,
1
or
above
has
a
pretty
strict,
no
breaking
changes
policy.
So,
theoretically,
in
dolorean's
case,
where
one
team
wanted
a
a
new
feature,
you
should
be
able
to
upgrade
to
the
new
version
of
cosplay
provider
aws
in
just
one
place
in
your
cross
main
control
plane,
and
then
everyone
should
get
access
to
that
new
feature
and
everyone
who
doesn't
want
to
use
that
new
feature.
Everything
should
just
have
same
defaults
for
them.
B
B
Those
kind
of
whole
bets
are
off
because
we're
still
experimenting
with
the
features
there,
so
we
think
we
might
actually
put
those
behind
a
feature
flag
or
something
soon,
so
that
you
know
just
really
shows
people.
These
are
the
ones
that
we
don't
provide
that
contract
for
there.
If
you
want
to
try
them
but
be
aware
that
if
you
upgrade
they
might
break
but
for
everything
else,
all
of
our
v1
beta1
and
our
core
v1
apis,
it's
a
it's
a
really
safe,
upgrade
path.
A
Okay,
one
another
excuse
me:
another
access
control.
Another
limitation
is
access
control
again
going
back
to
our
you
know
the
beginning,
when
I
said
that
we,
our
infrastructure,
is
through
different
modules,
lots
of
resources,
a
lot
lots
of
sub
modules
in
those
layers
we
actually
provision.
I
am
roles
for
the
next
layer,
so
for
one
layer
we
have
for
the
account
level
layer.
A
We
have
the
we
provision,
the
admin,
iam
roles
that
will
be
used
in
the
infrastructure
layer
where
we
provision
the
resources
and
then
the
next
level
provides
the
imm
roles
for
the
tenant
level
and
whatever
they
whatever.
That
level
needs
to
provision.
Whatever
resources
they
have.
So
it
is.
Essentially,
I
am
roll
food.
A
We
rely
heavily
on
aws
to
to
configure
resources
within
our
cluster.
Terraform
has
no
concept
of
access
control,
so
we
have
to
basically
rely
on
the
cloud
provider
to
and
cloud
provider
in
combination
with,
you
know,
clever
naming
conventions
to
get
what
we
want
down.
You
know
our
walled
garden
as
one
of
my
colleagues
put
it
for
our
developers,
so
it's.
A
So
yeah,
so
it
kind
of
just
undermines
self-service
and
it's
not
a
lot
of
people,
so
our
admins
have
to
be
aware
of
a
lot
of
different
things.
So
if
a
user
wants
to
do
something,
they
have
to
go
back
and
refer
to
us
to
or
to
ask
us
for
access
instead
of
having
it
more
of
a
more
natural
configuration.
So
there's
a
lot
of,
I
guess
tribal
knowledge
amongst
admins,
a
bunch
of
a
few
teams
to
get
this
going.
B
So
I
think
the
the
fundamental
nice
thing
about
access
control
and
cross
plane
there's
some
technical
details
that
sort
of
touch
on,
but
but
sort
of
from
a
fundamentally.
The
nice
thing
is
that
in
cross-plane,
access
access
control
is
framed
around
your
business's
concepts,
not
necessarily
your
cloud
providers
not
aws
concepts.
B
That
you
can
deliver
these
configurations
to
crossblade,
and
what
these
configurations
include
are
what
we
call
compositions
and
composite
resources
which
are
effectively
your
own
custom
apis.
So
in
guidewire's
case,
instead
of
saying
a
team
has
access
to
aws
concepts
like
s3
buckets,
and
maybe
I
think,
s3
bucket
website
policies
or
all
the
various
things
you
can
do
with
the
bucket.
At
that
api
level,
you
could
just
come
up
with
an
opinionated,
guidewire
abstraction
that
might
be,
like
you
know,
a
guidewire
storage
or
a
guideline
bucket
or
a
guideline
database.
B
Can
you
just
give
it
a
config
file
with
sorry
a
secret?
I
should
say
rather
with
your,
your
aws
account
keys
and
you
can
even
have
multiple
of
those
providers,
so
you
can
say
some
of
these
resources.
You
know
this
team
are
gonna,
go
use.
This
account
this
team's
gonna
use
that
account
et
cetera,
et
cetera,
but
it's
kind
of
layered.
B
A
A
Hey
again,
gonna
keep
recapping
our
structure,
so
basically
our
our
infrastructure,
the
layers
are
very
well
one.
The
bottom
layer
is
the
okay,
so
the
top
layer
depends
on
the
next
one
and
then
there's
the
next
one
depends
on
the
bottom
layer.
So
tenant
relies
on
the
infrastructure
which
relies
on
the
account
level,
so
there
is
no
way
within
terraform
itself
for
one
for
the
tenant
level
to
access
what
we've
already
provisioned
for
the
infrastructure,
so
they're
just
configured
in
isolation.
A
So
even
though
the
infrastructure
level
is
necessary
for
the
tenant
to
sit
on
top
of
there's
no
way
to
actually
access
these
resources
or
kind
of
write
configuration
where
we
can
dynamically,
I
guess
use
it
to
refer
to
that
lower
level.
So
we
have
to
either
rely
on.
You
know
already
knowledge
that
somebody
knows
to
name
this
certain
resource.
This
way
like
our
like,
for
example,
our
back-end
state
file
or
state
bucket,
that
stores
our
terraform
state
file
for
the
tenant
has
been
provisioned
by
the
infrastructure
level.
A
A
B
B
That
the
crossplane
has
here
is
is
sort
of
the
interoperability
that
comes
from
being
a
control
plane
with
a
rest
api.
So
you
know
in
terraform
you
could.
Theoretically,
you
know
you
can
run
terraform
and
maybe
write
some
output
sort
of
thing,
but
you
end
up
having
terms
of
rap
terraform
in
a
script,
sort
of
thing
or
start
using
complex,
shared
state
relationships
and
things
like
that
to
to
refer
to
other
modules.
B
B
Be
in
this
bbc,
I
just
tell
you
to
go
point
to
that:
vpc,
that's
also
modeled,
with
crossplane
and
it'll
it'll
kind
of
figure
it
out.
We
built
that
at
the
the
managed
resource
layer
we
also
support.
Basically
many-
maybe
maybe
most
of
our
crossplane
resources
are
able
to
write
some
or
all
of
their
interesting
connection,
details
to
a
secret
to
make
it
extra
easy
to
compose
to
consume.
I
mean
again,
everything's
just
a
rest
api.
B
One
limitation
that
we
that
we
need
to
figure
out
and
cross
plane
in
the
motor,
that's
on
our
sort
of
backlog
is
crossplane,
does
not
yet
have
anything
like
a
terraform
data
source.
So
crossbow
is
really
good
at
giving
you
information
about
stuff
that
crossland
manages,
but
it's
as
yet
doesn't
have
great
functionality
for
giving
you
information
about
arbitrary
other
stuff.
Let's
say
you
know,
there's
a
there's
a
database
running
over
there
or
a
cluster
running
over
there
or
a
vpc
running
over
there.
B
That
cross-plate
is
not
in
charge
of
it's,
not
the
source
of
truth
for
its
state.
It's
it
doesn't
currently
have
any
functionality
to
go
and
grab
details
about
that
thing.
But
there
is
a
bit
of
an
escape
hatch
here,
at
least,
which
again
is
just
that
we
we
exist
within
the
kubernetes
api.
So
while
it's
not
the
easiest
thing
in
the
world
to
write
a
kubernetes
controller,
it
is
possible
to
write
your
own
code
to
interact
with
our
apis
and
glue
this
together
at
the
moment.
So
it's
possible.
A
A
And
one
last
limitation
I
know
earlier,
I
said
that
hcl
has
allowed
us
to
scale
very
quickly
and
well
to
allow
us
to
get
our
platform
implemented
in
a
very
in
you
know,
in
a
relatively
short
amount
of
time,
while
we're
we're
getting
to
we're
starting
to
get
a
little
bit
more
sophisticated
with
how
we
manage
and
we
need-
and
it's
we're
starting
to
understand
that
we
need
to
work
closer
with
the
cluster.
So
it's
just
turning
into
another
thing.
A
To
maintain
again,
our
file
is
in
git,
our
state
is
an
s3,
and
then
we
also
currently
right
now
work.
You
know
we
run
our
cube,
ctl
commands.
So
would
it
be
nice
if
we
could?
Just
you
know,
kind
of
work
a
little
bit
more
closer
with
the
cluster,
have
our
kubernetes
resources
and
be
closer
to
kubernetes,
so
yeah,
so
we
can
be
more
productive,
so
we
don't
have
to
worry
about
again.
You
know
where
things
are
in
a
somewhere
else.
That
is
not.
B
So
I
think
the
the
advantage
that
crossplane
has
here
is
pretty
much
what
delorean
just
touched
on
it's
tool
and
consistency
effectively.
I
think,
if
you're,
a
hypothetical
organization
that
does
not
either
use
terraform
or
kubernetes
and
you're
thinking,
hey
I'd
like
to
go,
manage
my
cloud
infrastructure
declaratively,
it's
probably
about
the
same
level
of
maintenance
and
burden
and
learning
to
go
using
the
cross,
plane
or
terraform,
but
increasingly
we're
seeing
that
a
lot
of
people
are
just
using
kubernetes
already.
You
know
they've
already
bought
into
kubernetes
for
maybe
managing
their
apps.
B
A
B
It's
a
smaller
shift
to
sort
of
add
crossplay
as
a
kubernetes
add-on
that
uses
similar
patterns
basically
run
that
off
of
that
as
a
platform
team
to
your
users
that
it
is
to
learn
a
different
dsl
for
terraform
sort
of
thing
and
keep
all
the
tooling
and
plumbing
running
to
get
terraform
going
here.
Ci
cd
system
or
all
that
kind
of
thing-
and
you
know
even
further
than
just
necessarily
saying
that,
if
you
know
kubernetes
cross
plane
is,
is
easy
to
pick
up.
B
We
can
sort
of
lean
on
the
fact
that
again,
at
its
heart,
kubernetes
is
sort
of
like
a
really
good
rest
api.
So,
even
if
you
have
developers
who
aren't
so
familiar
with
with
kubernetes,
you
could
always
position
it
as
hey.
You
can
make
these
rest
api
calls
to
manage
your
infrastructure.
You
know
if
you're,
a
python
developer
or
a
java
developer,
or
something
like
that,
you
can
say:
hey,
there's
a
really
well
documented
rest
api
for
managing
infrastructure.
Even
if
you
don't
want
to
learn
the
intricacies
of
kubernetes.
B
A
So
right
now
we're
working
with
my
team,
in
particular
we're
working
with
managing
s3b
of
crossplay
and
another
one
of
our
teams
is
working
with
ecr,
we're
working
with
composing
both
of
these
resources
and
crossplaying,
so
yeah
so
anyways.
We
we
are
hitting
the
ex
we
are
experiencing.
The
freshness
of
you
know
this
bleeding
edge
technology,
but
the
cross
plane
community
has
been
very
responsive
and
very
helpful.
A
Because,
again
you
know
I'm
tech,
I'm
very
new
to
you
know
to
kubernetes
into
all
this
stuff
myself,
but
so
maybe
sometimes
your
questions
are
going
to
be
a
little
bit
obvious
to
consider
a
little
bit
more
seasoned
in
the
technology.
But
you
know
again:
everybody's
been
nice
and
helpful,
and
and
maybe
one
day
once
you
know
our
you
know,
our
team
gets
a
little
bit
more
familiar
with
go
and
everything
else.
We
can
contribute
back
to
the
community.
B
You
know
some
people
come
to
crossblade
and
they
really
they
really
just
want
what
we
think
of
as
like
the
core
drivers
they
just.
They
just
want
to
have
raw
apis
modeled
in
kubernetes
and
there's
value
in
and
of
itself
there
that
you
know
that's
valuable
by
itself,
but
crossplane
really
sweats
the
separation
of
concern.