►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Cloud-Agnostic Design for Fun and Profit - Alex Meijer & Anusha Iyer, Corsha, Inc.
There is now sufficient competition in the cloud computing space that all the major cloud providers are competing directly on pricing. Like any other market, there are significant opportunities for savings if an organization is willing to periodically switch to more competitive service providers. However, the engineering cost of a cloud provider migration typically negates those savings – but that doesn't have to be the case. This talk will cover a two-year journey spanning several cloud providers, and how to avoid vendor lock-in by making cloud agnostic design a first-class consideration. A case study will be provided on how embracing open source projects like Kubernetes, Terraform, and Helm permitted lightning-fast migration to and from cloud providers driven by economic incentives. The high level details of Corsha's Infrastructure-as-code strategy will be discussed, and how an early commitment to this approach has resulted in flexible and efficient cloud native app deployments.
A
All
right
we're
gonna,
go
ahead
and
get
started
now
and
welcome
everybody
thanks
for
joining
session.
Today
my
name
is
danielle,
I'm
cncf,
ambassador
and
suburban
track
chair.
This
is
kubecon
and
I'm
so
glad
to
be
here
for
moderating
this
session
today.
So
we're
going
to
talk
a
little
bit
about
the
cloud
agnostic,
design
for
front
and
profit
today
and
then
just
one
quick
remind
and
then
you've
got
any
technical
question
during
the
session.
A
Please
raise
your
hand
end
of
the
session,
and
our
great
speakers
and
presenter
will
address
your
questions.
So
now
I'm
gonna
introduce
our
presenter,
our
alex
meyer,
the
impressive
team
lead
in
the
crochet
inc
and
then
also
the
anusha
iyer,
both
cto
and
co-founder,
and
yeah
kosher
inc.
The
please
welcome
on
the
stage
about
alex
and
anusha.
B
Great
thanks
daniel
welcome
everyone.
Thank
you
for
coming,
it's
good
to
be
here
in
person
and
thanks
to
those
of
us
who
are
also
online,
wanted
to
talk
today
a
little
bit
about
kind
of
our
approach
for
cloud
agnostic
design,
and
you
know
really.
We
I
just
wanted
to
convey
like
we're,
really
excited
to
talk
about
this,
because
we
applied
some
of
these
things
at
our
organization
really
and
it's
I
think,
I'm
not
exaggerating
when
it's
changed
the
way
we
do
business.
B
C
Absolutely
yeah,
I'm
anusha
iyer,
I'm
the
cto
and
one
of
the
co-founders
of
corsa
introduced
to
kubernetes
through
alex,
in
fact,
and
you
know,
just
fell
in
love
with
the
whole
concept
of
infrastructure
as
code.
I
think
it
really
elevates
the
idea
of
infrastructure
as
a
first
class
citizen
in
the
whole
software
engineering
development
deployment
process,
and
so
we've
really
embraced
it
head
on
right
into
integrating
into
code
reviews
and
the
whole
kind
of
dev
pipeline,
and
it's
fantastic
and
excited
to
tell
you
more
about
it
today.
B
Yes,
so
we're
going
to
structure
our
talk
today,
sort
of
as
a
case
study,
of
what
we've
done,
we'll
set
the
stage
early
about
our
app
just
to
kind
of
give
some
background
and
kind
of
motivate
why
we
even
care
about
cloud
agnostic
design
we'll
go
over
what
we
consider
the
fundamental
building
blocks
to
this
approach,
which
is
helm
and
then
helm,
charts
scaling
that
out
we'll
explore
some
economics
involved
in
the
modern
cloud
computing
market,
we'll
talk
about
terraform,
actually
corpse
terraform,
which
is
a
big
part
of
our
success.
Here.
C
Yeah
and
so
a
little
bit
about
what
we
do
to
just
set
the
stage.
We
are
an
early
startup
just
about
eight
people
where
about
five
of
us
are
on
the
engineering
side
and
there's
a
few
of
us
on
the
bd
side,
we're
based
out
of
the
dc
area.
A
lot
of
our
routes
actually
come
from
the
dod
intelligence
world,
and
so
you
know,
even
this
idea
of
embracing
cloud
took
a
bit
for
me
personally
and
in
terms
of
what
the
the
app
actually
is.
C
C
I
request:
have
it
go
with
a
one-time
use?
You
know
dynamic
credential,
just
the
same
way
that
you
do
with
google
authenticator
or
an
rsa
token
on
the
human
side,
the
way
that
we
had
to
go
to
get
it
fully
automated
was
we
actually,
you
know,
have
these
notions
of
authenticators,
just
like
a
google
authenticator
and
we
push
it
down
to
a
machine.
So
your
api
client
that
could
be
a
kubernetes
pod,
it
could
be
a
docker
container,
it
could
be
an
edge
iot
device.
C
This
is
what's
going
to
collect
the
identities
and
then
kind
of
verify
the
mfa
credentials
on
the
other
way
out,
and
so
the
notion
of
it
being
kind
of
a
distributed
base,
distributed
trust
really
fundamental
to
what
we
do
and
and
really
you
know,
led
the
way
to
a
lot
of
the
design
philosophy
we'll
talk
about
today.
Certainly
it's
a
security
product.
So
what
do
we
need?
We
need
things
like
high
availability.
C
We
need
to
be
able
to
support
the
platform
as
both
a
sas
as
well
as
on-prem
for
certain
you
know,
sensitive
customers
and
things
like
that,
and
because
we're
talking
about
api
requests
and
authentication,
we
need
scale.
So
we
need
to
be
able
to
support
thousands
of
api
requests
per
second,
and
so
you
know
look
for
those
themes
as
we
as
we
go
through
the
talk.
B
So,
to
give
a
little
bit
more
depth
as
we
hone
in
on
what
exactly
is
running
in
the
cloud
our
distributed
ledger
is
called.
It's
hyper
ledger
fabric.
It's
something
developed
by
ibm,
we've
taken
it
kind
of
to
the
edge,
so
if
portions
of
it
run
in
the
cloud
portions
of
it
run
in
the
customer
on
the
customer
systems,
the
customers
on
the
left.
Here,
the
cloud
portions
are
on
the
right
and
I
wanted
to
draw
everyone's
attention
to
these
ideas
of
these
peers
and
order
objects
that
hyperledger
uses.
B
Now
their
exact
operation
isn't
terribly
important,
but
the
orderers
themselves
form
a
distributed
system
right.
These
raft
and
elect
leaders
and
that
sort
of
thing
the
peers
use
gossip
to
establish
their
own
distributed
system.
So
you
know
we
get
this
sort
of
consensus
mechanism
and
you
know
that
that
will,
as
we'll
see,
has
been
really
an
important
decision
for
us
all
of
this.
We
have
been
able
to
run
darn
near
free
since
2018.,
and
how
do
we
do
this?
Well,
all
the
major
cloud
providers
have
startup
credit
programs
right.
C
Absolutely-
and
you
know
start-up
credit's,
obviously
great-
for
keeping
operating
costs
low.
I
guess
show
of
hands
here
for
those
in
person
and
maybe
out
there
virtual.
How
many
of
you
have
worked
in
a
startup
are
doing
a
startup
right
now,
quite
a
few
yeah,
so
I'm
sure
you're
all
familiar
with
that
cardinal
rule,
right
droom,
don't
run
out
of
money,
and
so
certainly
that's
been
a
big
driving
force
in
terms
of
being
able
to
do
this
kind
of
hopping.
But
I
will
say
that
you
know
one
of
the
unanticipated
benefits
of
taking
this
route.
C
Is
it's
a
great
way
to
at
least
it
was
for
us
to
understand
that
landscape,
the
whole
cloud
native
ecosystem
of
what
we're
trying
to
protect
and
also
to
meet
customers
where
they
are
so
now
we've
got
you
know,
say
a
sensitive
customer,
that's
running
in
azure
gov,
we
can
say
no
problem.
We
can
set
up
a
managed
service
for
you
there,
and
so
it's
really
turned
us
into
almost
a
managed
service.
That's
a
forest
as
opposed
to
just
a
large
tree.
B
Yeah-
and
you
know,
we
of
course
didn't
start
out
with
this
outcome
in
mind.
I
guess
you
could
say
we
originally
started
to
anusha's
point
is
that
we
need
to
run
on
a
wide
range
of
customer
systems.
Since
we
are
a
security
product,
we
have
customers
that
say
no
open
internet
right,
no
access
to
the
internet,
so
they
need
to
run
on-prem,
and
so
with.
B
In
that
case
we
say:
okay,
you
know
you
can
use
cops,
for
example,
kubernetes
operations
and
you
know,
deploy
a
kubernetes
cluster
and
we
don't
have
to
kind
of
take
on
that
that
effort,
because
you
know
cncf
already
handles
a
lot
of
that.
Some
of
our
customers
want
to
run
on
vms
right.
They
run
on
just
exei
other
vmware
stuff,
and
they
just
want
to
get
off
the
ground
and
running
as
quickly
as
possible
to
prove
prove
us
out.
B
So
for
that
we
install
k3s
a
lightweight
kubernetes
client
onto
a
vm,
deploy
it
to
the
customer.
They
can
run
it
in
their
legacy
infrastructure.
They
don't
even
know
kubernetes
and
helm
are
under
the
hood
and
then
we
you
know
we
get
it
in
that
way.
Other
customers
are
fine
running
on
the
public
cloud
and
they
just
need
massive
scale
right.
B
So
we
support
all
the
major
cloud
providers,
all
this
from
the
same
set
of
artifacts
that
we
developed
and
pushed
right
now
we're
using
azure,
so
we
develop
in
azure
through
our
helm,
chart
repo
and
our
docker
registry.
You
know
it's
that
point
of
indirection,
where
we
support
all
of
these
kind
of
transparent.
C
Absolutely
and,
and
so
you
know,
form
follows
function.
We
had
kind
of
a
set
of
requirements
in
our
minds
when
we
started
this
off
that
sort
of
took
us
towards
this
path.
One
was
certainly
we
wanted
a
distributed
consensus
model
where,
especially
as
a
security
platform,
there's
no
single
point
of
failure,
no
single
point
of
attack.
We
really
wanted
to
raise
that
bar
in
terms
of
attack,
effort
necessary,
and
so
you
know,
a
byzantine
fault.
Tolerant
system
like
a
distributed
ledger
network
made
a
ton
of
sense.
C
Sometimes
it's
just:
you
can
run
kate's
cluster
locally
and
deploy
us
there
and
then,
similarly,
you
know
putting
together
a
product.
You
want
to
get
to
production
grade
services
as
quickly
as
possible
right
and
that's
where
that
ecosystem
of
helm
charts
has
just
proven
invaluable
to
us.
It's
just
such
a
force
multiplier
in
terms
of
going
out
there
and
knowing
you're
getting
you
know
such
good
quality
stuff
that
you
can
get
up
and
running
quickly.
B
Yeah,
so
let's
take
a
look
at
one
of
these
charts
in
this
case
we're
looking
at
the
bitnami
postgres
charts.
So
what
we've
done
here
is
I've
gone
to
aws's
rds
site,
which
is
their
sort
of
managed
postgres
service
and
picked
off
kind
of
their
bullet
points
of
why
you'd
want
to
use
that
and
sort
of
compare
them
here
to
one
of
the
postgres
charts.
B
This
is
a
pretty
typical
advantage
of
one
of
our
diy
cloud
provider
services
and
what
we're
trying
to
get
across
here
is
that
a
lot
of
these
features
that
rds
gives
for
you
in
exchange
for,
of
course,
paying
them
you
can
get
using
already
existing.
You
know
unmodified
helm,
charts
that
you
just
pull
off
of
artifact,
for
example,
rds
says
we
have
fast,
predictable
storage.
B
Well,
you
know,
with
the
bitnami
postgres
chart
you
just
set
global.storage
class,
you
can
use
the
exact
same
type
of
storage,
rds
is
using
and
it's
a
parameter,
no
backup
and
recovery.
There
are
tons
of
kubernetes
and
you
know
backup
systems
and
like
valero,
which
is
what
we're
planning
on
using.
You
know
you
can
adjust,
read
replicas
high
availability.
Again,
all
these
features
you
can
get
from
configuration
metrics.
For
me,
this
the
bitnami
chart
has
built-in
prometheus
metrics.
B
The
one
thing
that,
of
course,
a
chart
that
you
do
on
your
your
own
doesn't
have
as
an
sla
right.
Rds
has
an
sla
financial
sla
that
it
will
be
up,
and
you
know
this
gave
us
pause.
I
guess,
but
we've
been
using
this
stuff
in
production
for
a
while,
and
really
I
mean,
if
you
flick
all
the
switches,
you
can
get
some
real
stability
out
of
this,
and
as
long
as
you
follow
back
up
best
practices,
you
can
recover
from
it.
B
B
Another
example
of
a
chart
that
this
this
time
we
implemented,
we
call
it
our
bootstrap
chart.
So
when
we're
onboarding
to
a
new
cloud
provider,
there's
there
are
some
differences
like
storage
classes
and
that
sort
of
thing
that
is
just
specific
to
the
cloud
provider.
And
you
know
you
really.
There
aren't
much
opportunities
there
for
a
generic
design,
so
we
concentrate
all
of
that
cloud
provider
specific
configuration
into
this
one
chart.
So
we
say
you
know
when
it's
time
to
onboard
a
new
provider.
B
What
do
we
need
to
even
look
at
to
begin
considering
to
make
sure
we
have
a
smooth
transition
and
it's
in
one
place?
So,
for
example,
I
have
part
of
a
helm
chart
here
and
we
pass
in
the
provider
as
a
helm
parameter,
and
it
just
renders
differently,
based
on
whether
you're
using
aws
as
storage,
provisioner
or
otherwise,
and
in
this
bootstrap
chart
we
have
of
course,
storage
classes.
Ingress
settings
since
load
balancers
are
slightly
different
between
different
cloud
providers.
B
B
B
So
what
we
rely
on
is
an
amazing
tool
called
helm
file
available
on
github,
and
you
basically
list
out
like
a
manifest
of
all
your
different
charts,
and
you
can
see
here
a
little
toy
example
of
an
elk
stack,
a
logging
stack
being
built
by
a
helm
chart.
So
we
have
you
specify
the
version
of
the
chart.
You
want
to
install
you
point
to
the
chart
online
and
it
supports
values
files.
So
again
you
can
see
you
point
to
a
file
that
has
the
values
for
that
chart.
C
Right,
so
you
know
you
put
all
of
these
pieces
together
and
the
emergent
property
that
we
have
is
we
have
a
cloud
agnostic
platform.
You
know
to
give
you
a
sense.
We
can
go
from
zero
to
fully
operational
for
our
dev
cluster,
a
staging
cluster
production
stacks
across
all
of
your
major
cloud
providers
in
the
matter
of
a
few
minutes
by
just
kind
of
pointing
the
cube
config
at
a
different
cluster.
So
it's
super
powerful
stuff
and
really,
you
know
a
couple
of
things
that
we've
leveraged
on
the
platform
providers
have
helped.
C
Us
is
one
we're
sticking
with
managed
kate's
on
the
platform
provider,
so
it
takes
some
of
the
burden
of
you
know,
running
running
the
cluster
yourself
and
and
managing
that
and
then
also
making
sure
that
we
don't
rely
unintentionally
on
any
managed
services.
So
you
know
there's
nothing
that
we
have
to
bring
with
us
when
we're
moving
over
and
we
really
are
kind
of
this.
This
self-contained
application
platform
in
a
box.
B
Absolutely
so
you
know
we
had
this
realization
right
that
we
can
operate
on
any
cloud
and
it
again
it
sort
of
came
on
us
as
a
surprise,
but
when
we
kind
of
get
the
self-awareness
we're
like
well,
what
can
we
do
with
it?
So
we
looked
at
the
most
straightforward
thing,
which
of
course
is
cost
right
of
a
cloud
instance.
Now
cloud
computing
is
increasingly
become
a
commodity
right.
B
We
have
all
the
big
players,
and
it's
again
commoditized
like
one
vcpu
on
aws,
is,
for
all
intents
and
purposes,
the
same
as
a
vcpu
on
an
energy
uke,
for
example,
some
cloud
providers
are
profitable
and
they
are
willing
to
defend
market
share
right
by
pricing.
Low
others
are
willing
to
just
take
a
loss
right,
an
example
that
is
gcp
gcp
because
they
are
trying
to
gain
market
share.
B
This
situation
obviously
is
very
beneficial
for
us,
the
users,
so
just
as
a
sort
of
example.
Here
I
I
grabbed
the
prices
on
in
late
august
from
all
the
major
cloud
providers
of
the
instance
type
we
used
primarily
in
m2
m5.2x
large
instance,
and
sort
of
compared
them,
and
these
are
all
roughly
in
the
same
region.
So,
for
example,
if
you
move
from
azure
to
aws,
that's
potentially
a
15
cost
savings
or
an
equivalent
on-demand
instance
type.
B
C
Yeah,
and
so
you
know,
here's
the
challenge-
it's
fantastic-
you
can
save
quite
a
bit
by
being
able
to
stay.
Nimble,
stay
agnostic
switch
providers,
but
you
know
we
don't
want
to
oversimplify
things.
There
are
nuances
between
the
providers.
As
you
know,
alex
has
mentioned.
Sometimes
the
load
balancers,
the
ingress
controller
storage
classes,
things
like
that,
and
so
even
things
like
well,
how
do
you
leverage
the
kate's
api
for
a
provider?
How
do
you
actually
set
up
your
configuration
for
that?
And
so
you
know
there
are
again
tricks
to
doing
that.
B
B
The
terraform
is
created
by
hashicorp,
but
it
is
open
source
and
it's
a
pretty
remarkable
piece
of
software,
and
it
is
basically
lets
you
codify
cloud
provider
configuration
and
then
it
uses
aws
apis
to
you
know,
install
those
resources
or
gke
or
so
on
and
so
forth.
It
really
did.
Let
us
go
from
zero
to
having
a
kubernetes
cluster
ready
to
receive
api
commands
in
under
two
weeks.
B
This
is
because
all
of
the
major
cloud
providers
have
lots
of
examples,
well
maintained,
terraform
modules,
because
again
they
want
your
business
right.
They
want
you
to
come
to
them,
so
we
sort
of
flipped
the
script
on
what
we
did
with
the
with
our
corsa
bootstrap
helm,
chart
where
we,
instead
of
concentrating
all
the
config,
that's
different.
We
concentrate
all
the
configuration
terraform,
that's
the
same,
because
the
sort
of
assumption
is
that
everything
is
going
to
be
different
in
a
terraform
module,
because
the
provider's
right.
B
So
in
our
comment,
you
know
in
this
little
example:
we
have
a
module
that
aws
eks
configures,
an
aks
cluster
and
or
eks
cluster
and
provisions.
It
azure
aks
configures,
an
aks
cluster.
All
of
these
rely
on
this
common
module
that
has
stuff
that
you
know,
transcends
cloud
providers
like
maximum
size,
for
example,
of
a
node
pool
or
your
your
ips
right.
B
Those
are
going
to
be
the
same
on
all
the
cloud
providers
and
we
index
into
this
list
of
variables
using
the
terraform
workspaces,
whether
it's
dev
or
prod,
and
then
just
smash
them
into
the
big
list
of
cloud
provider,
specific
configuration
and
there
you
go.
You
only
have
one
place
to
make
it
one
change
and
then
it's
applicable
to
all
your
cloud
providers.
B
For
us,
our
architecture
bails
us
out
in
that
it's
a
distributed
system,
that's
dynamic
right,
we
can
add
and
remove
nodes
slowly.
In
the
example
I
have
at
the
bottom
here
where
what
we
call
straddling
a
cloud
provider,
so
we've
gone
and
added
a
node
into
gke,
but
it's
still
communicating
with
other
blockchain
nodes
in
azure
and
then
slowly
one
by
one.
Those
will
come
over
as
we
move
completely
over
to
the
new
cloud
provider.
There
are
a
lot
of
other
examples
of
this
for
different
systems.
B
B
For
dr
again,
we're
going
to
kind
of
gloss
over
this
because
everyone's
situation
different
valero.
There
are
lots
of
other
kubernetes
objects,
kubernetes
volume,
snapshotting
right
there,
a
lot
of
non-cloud
provider,
specific
options
for
that,
and
you
know
we
would
definitely
recommend
at
least
a
little
automation
around
the
creation
and
restoration
of
this
just
to
again
make
it
all
all
varies.
B
B
C
Yeah-
and
so
you
know,
essentially
what
we've
done
is
kind
of
put
this
application
platform
into
a
box
as
well
as
wrapped
it
around
all
of
the
the
support
and
services.
We
need
to
manage
development,
testing,
continuous
pipelines,
and
so
it's
a
fantastic
way
for
a
small
team
to
kind
of
use
the
whole
ecosystem
as
a
force
multiplier.
C
We're
definitely
punching
beyond
what
you
would
imagine
for
the
size
of
the
team
to
be
able
to
maintain
all
of
this
and
still
keep
our
sanity
absolutely
yeah.
So
we
we
thought
this
might
be
helpful
to
any
of
you
that
are
considering
taking
this
path
is
to
just
kind
of
walk
you
through
what
our
journey
was
and
and
how
we
matured
and
added
elements
to
our
ecosystem
along
the
way
and
just
you
know,
kind
of
how
they
staged
out
and
stuff.
C
So
we
started
in
2018
when
the
company
was
founded,
and
this
is
pre
alex.
So
we
were
on
aws
very
much
in
the
world
of
vms
and
docker
compose
on
aws,
and
then
he
joined
in
q2
of
that
year
and
sort
of
opened
up
our
our
eyes
to
the
the
power
of
kate's.
If
you
will
and
helm,
I
think
q3
we
got
into
the
google
for
startups
program
got
a
little
bit
of
credit
there
and
so
decided.
It
was
worthwhile
transferring
over
learning
more
about
gcp
and
then
2019
introduced.
C
You
know
our
stack
was
getting
more
complex.
We
had
more
elements
to
it,
so
introduced
helm
file
at
that
point
for
better
organization,
and
then
q3
is
when
we
got
into
the
aws
startup
program,
and
that
was
a
larger
chunk
of
change
and
worth
kind
of
shifting
over,
and
that's
when
I
think
you
and
I
made
that
conscious
decision
to
be
like
all
right-
let's
go
full
in
here:
let's
go
with
kind
of
a
cloud
agnostic
approach
to
this
whole
thing
and
you
invested
in
terraform
at
that
point,.
B
Yeah,
absolutely,
I
would
say
yeah
when
we
switched
over
to
aws,
was
kind
of
our
inflection
point
in
terms
of
being
committed
to
this
as
an
approach,
and
you
could
sort
of
see
that
right
after
q3
of
2019,
when
we
use
terraform,
then
you
can
almost
see
us
sort
of
asking
ourselves
what
cloud
provider
services
are
we
relying
on?
What
do
we
need
to
do
to
build
our
own?
So
soon
after
we
were
using
a
lot
of
log
ingestion
features,
so
we
built
our
own.
B
We
built
an
elk
stack
right
a
little
bit
later:
okay,
we're
using
their
cicd
systems.
What
do
we
do?
We
build
our
own
right?
We
went
and
got
jenkins
deployed
that
in
at
that
point,
aws
credit
was
kind
of
running
out.
So
then
we
set
our
sites
on
azure,
again
terraformed
our
cluster
there
and
made
the
jump
pretty
soon
thereafter.
We
just
picked
our
next
thing.
B
What
are
we
relying
on
monitoring
right
and,
of
course,
there
is
a
terrific
pncf
project
prometheus,
so
we
went
all
in
on
that
got
that
deployed
more
recently,
we've
been
kind
of
tightening
our
supply
chain
for
software.
So
we
do
security
scanning
on
all
of
our
containers.
Again,
everything
is
nice
and
you
know
again
we
use
helm
charts
for
everything,
but
we
are
utterly
dependent
on
them.
B
So
we
began
to
sign
our
home
charts
right
so
that
no
one
can
intercept
that
portion
of
our
software
supply
chain
and
our
customers
can
also
verify
that
we
are
the
producers
of
it
and
you
know
our
credit
with
azure
is
about
running
out
now.
I
believe
so
we're
hoping
to
set
our
sights
on
our
next
cloud
provider,
which
we
may
go
back
to
gcp.
C
C
Yeah-
and
so
you
know,
I
know-
we've
been
talking
a
lot
about
kind
of
our
startup
journey,
but
hopefully
there
are
lessons
here
that
transcend
more
than
just
startups
right.
There
is
a
lot
of
negotiating
power
that
can
be
had
if
you
have
a
nimble
kind
of
agnostic
design
and
that
you
are
able
to
jump
across
as
alex
mentioned.
C
You
know
we
are
in
discussions
with
gcp
right
now,
and
you
know
the
the
providers
they're
very
incentivized
to
have
you
come
so
even
beyond
the
financial
benefits
oftentimes,
you
know
you
can
work
with
them
to
have
them.
Show
you
what
are
the
best
practices
for
terraforming
onto
their
cluster
or
what
are
the
the
trips
tips
and
tricks
of
you
know
optimizing
performance
or
storage
classes
or
node
types,
and
all
of
that,
and
so
we've
been
working
with
gcp.
B
Yeah
we're
a
little
bigger
right,
so
we
have
a
little
bit
more
clout,
and
so
you
kind
of
take
advantage
of
different
programs,
not
just
early
stage
startup
programs.
There
are
plenty,
so
you
know
looking
ahead.
We've
spent
most
of
this
time.
You
know
talking
about
our
economic
motivations,
right
saving
money
or
that
sort
of
what
we
are
really
interested
in
doing
is
using
these
cloud
agnostic
design
concepts
to
further
our
business
goals
right
so
as
again,
a
cyber
security
company.
B
We
are
like
pretty
paranoid
right,
and
so
we
ask
ourselves
what
if
we
went,
multi-cloud
and
deployed
one
portion
of
our
application
to
each
cloud
provider
and
then
they
communicate
at
the
application
layer.
We
call
this
a
zero
trust
deployment
right
because
we
are
guarding
against
the
compromise
or
crash
of
any
single
cloud
provider.
B
So,
to
kind
of
summarize
what
lessons
we've
learned
on
our
journey,
you
know
anusha
and
I
sat
down
and
talked
about
it.
You
know
if
we
could
go
back
in
time
three
years,
what
what
did
we
do
well
or
what
do
we
wish?
We
had
had
done
better,
but
one
thing
you
know
that
the
top
of
the
list
for
me
anyway,
is
way
back.
We
picked
a
distribute,
a
layer
of
persistence
that
stores
the
data
that
has
really
good
distributed
systems,
properties
right,
which
lets
us
chiefly
migrate
between
providers.
B
Right,
you
get
this
consensus
and
you
begin
to
straddle
cloud
providers
with
a
portion
of
your
consensus
on
one
portion
of
your
consensus
on
the
other
migrate
dev
to
your
new
cloud
provider.
First,
you
know
make
the
developers
put
up
with
any
sort
of
things
that
fell
through
the
cracks
in
terms
of
cloud,
friction
or
pain,
a
lot
better
than
the
customer.
C
But
be
nice
to
them
and
maybe
take
them
out
for
lunch
or
something,
and
then
you
know
there,
as
alex
mentioned,
we've
kind
of
kept
dns
on
aws
just
route
53..
This
isn't
black
and
white
in
terms
of
what
you
need
to
stay
agnostic
with.
If
it's
a
low-cost
service,
not
worth
the
effort,
that's
fine,
you
know
so
there's
obviously
choices
as
you're
going
through
this
and
then
definitely
you
know
that
whole
rich
world
of
free
source
software
and
the
ecosystem
of
helm
charts
it's
it's
such
a
great
force
multiplier.
C
C
We
turned
it
on
in
production
and
I
was
going
through
a
couple
weeks
of
just
a
whole
bunch
of
of
demos
like
back
to
back-
and
you
know
it's
a
very
stable
demo.
Environment
never
had
troubles
before
all
of
a
sudden.
The
demo
gods
are
just
like
pouring
terror
upon
me
and
about
every
two
or
three
demos.
C
Unreliably,
I
would
start
blocking
myself
like
literally
get
like
flagged
by
modsuck,
and
I
realized
we
didn't
realize
that
was
happening
time,
but
the
demo
flow
I
was
generating
poor
authentication
requests
and
I
was
triggering
the
defaults
in
our
modsig
chart
right.
So
those
types
of
things
you
just
really
have
to
to
watch
the
dials
yeah.
B
Yeah
and
again,
the
root
cause
of
that
was
minor
differences
in
the
way
that
different
cloud
providers
implement
kubernetes
load,
balancers
right.
So,
needless
to
say,
that
is
a
piece
of
config
that
now
lives
in
our
bootstrap
helm,
chart
and
is
installed
just
right
away
and
is
rendered.
You
know
in
a
cloud
specific
way,
yeah
that
one
was
definitely
paid
for
blood,
so
to
speak.
B
You
want
to
pull
as
much
off
the
shelf
as
you
possibly
can,
obviously
especially
terraform,
there's
a
lot
of
stuff
that
is
very
easy
to
adapt
and
begin
to
just
hobble
out
of
the
gate
with
and
and
iam
in
particular
right.
There's
a
lot
of
great
resources
for
that.
That's
something
great
to
manage
with
terraform
and
kind
of
simplifies
the
off
the
ops
workload.
C
Yeah
and
then
you
know,
resources
and
limits.
I
will
begrudgingly
admit
that
this
is
a
really
good
idea
for
the
scheduler
again
story.
We
were
going
through
kind
of
this
performance
tuning
phase,
where
we
really
wanted
to
keep
latency
low
and
keep
transaction
rates
high
and
everything-
and
my
my
vote
was
always
to
take
the
limits
off
right.
Hashtag,
no
limits,
let's
see
how
high
this
thing
could
go
and
we
quickly
learned
and
you'll
see
through
slack
every
time.
If
you
can
look
into
our
slack
every
time.
C
B
D
Hi
great
talk,
thank
you
very
much.
I
was
gonna
ask
about
the
terraform
bit.
You
guys
talked
like
how
are
you
approaching
the
cloud
agnostic
philosophy
with
working
with
something
like
terraform?
Are
you
building
modules
on
modules?
Are
you
are
you
abstracting
these
layers
and,
if
so
are,
is
it
open
source
or
is
it
called
sourcing
yeah?
Thank
you.
B
B
A
A
We
actually
at
the
top
of
the
hour.
So
please
continue
your
conversation
question
on
the
whole
and
then
our
president
are
more
than
happy
to
answer
his
question
and
we
actually
a
bunch
of
questions
from
the
patrol
audience
as
well,
and
please
join
the
slack
channel
and
ask
any
question
and
our
projector
will
be
be
there
to
address
the
question
and
thanks
for
joining
again
and
please
make
sure
to
submit
your
feedback
in
the
schedule.com.