►
From YouTube: Choosing Cloud Native Technologies for the Journey to Multi-cloud - Adelina Simion, Form3
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Choosing Cloud Native Technologies for the Journey to Multi-cloud - Adelina Simion, Form3
Building, deploying and maintaining systems has become increasingly more complicated in recent years. Now, as engineers look toward migrating to multi-cloud architectures, systems and processes may need to be migrated to new technologies. But what choices are available, how do they fit together and how can the CNCF landscape help? This talk discusses the cloud native technologies that can be used to convert to a multi-cloud architecture and highlights some of the lessons learned from taking this journey on at Form3. The audience will learn: - How to decide if multi-cloud is essential for them - The fundamentals of deploying services across multiple clouds with Kubernetes - How to leverage Cilium to mesh together multiple clusters - The basics of event sourcing using NATS in the multi-cloud world - Resilient and performant data storage using CockroachDB This talk is useful for any new comers to the cloud native landscape, as well as those curious about going multi-cloud!
A
Okay,
thanks
for
joining
this
session,
so
our
next
section
is
about
choosing
cloud
native
technology
for
the
journey
to
the
multi-cloud
and
thanks
for
joining
this
session
once
again,
including
the
butcher
audience
as
well,
so
quick
introduce
to
myself.
My
name
is
danielle,
I'm
cnc
ambassador
and
then
a
lot
of
stuff
in
track
chair
and
a
track
committee
member
in
kubecon,
I'm
so
happy
to
be
here
to
introduce
now
our
great
speaker,
dalina
from
a
form
3
as
technical
evangelist.
B
B
So-
and
I
really
appreciate
that
so
many
of
you
took
the
time
to
hear
me
so
daniel
already
said
that
I'm
a
technology
evangelist
of
form3,
but
I
just
wanted
to
to
give
a
shout
out
to
our
amazing
engineering
team,
who
have
done
all
of
the
great
work
that
I
will
pre,
that
I
have
the
honor
to
present
to
you
today,
all
right.
So
this
talk
will
consist
of
a
quick
introduction
of
why
we
decided
to
go
multi-cloud
and
what
it
actually
means.
B
As
you
can
imagine,
banks
don't
directly
integrate
with
each
other.
That
would
be
a
maintenance
nightmare.
Instead,
when
they
process
payments
in
betwee
between
banks,
they
go
through
external
payments
infrastructure
that
actually
define
the
standards
that
we
use
for
interbank
transactions
and
we
make
our
customers
lives
easier
because
we
take
care
of
all
of
the
securing
of
actual
payments
processing
and
then
they
integrate
with
our
apis.
B
First,
we
process
a
huge
number,
a
huge
number
of
transactions,
so
we
have
a
large
volume
that
comes
from
virtually
an
unlimited
number
of
users.
Next
we
have
reliability
and
durability.
We
cannot.
We
need
to
recover
from
outages
without
dropping
or
repeating
transactions,
because
if
we
drop
transactions
then
money
disappears
and
if
we
repeat
it,
then
we
invent
it
in
thin
air.
So
that's
not
really
good,
except
you
know.
B
Hopefully,
if
we
gave
you
more
money,
you
wouldn't
be
upset
with
us,
and
thirdly,
there
is
quite
a
bit
of
maintenance,
the
external
payments
infrastructures
that
you
saw,
there's
a
few,
a
few
kind
of
different
payments
and
they
also
update
their
external
payment
schemes
or
endpoints.
So
it
can
be
difficult
for
a
client
that
has
a
maybe
a
smaller
engineering
team
to
keep
on
top
of
these
all
of
these
changes-
and
this
is
another
thing
that
we
are
able
to
take
care
of
all
right.
B
B
So
going
multi-cloud,
obviously
that's
going
to
be
really
easy
right,
like
what
could
possibly
go
wrong.
In
fact,
the
team
identified
a
large
amount
of
challenges
from
the
very
beginning
and
in
particular,
networking
and
service
discovery
was
expected
to
be
the
most
difficult
part
of
going
to
the
multi-cloud,
and
we
needed
to
look
to
continue
keeping
our
latency
down
as
our
platform
is
strongly
consistent.
B
Okay,
so
first
off
the
challenge
of
deployment,
and
in
particular
we
wanted
our
teams
to
have
the
same
development
and
deployment
experience,
regardless
of
what
cloud
they
were
running
on
and
regardless
of
whether
it
was
po,
it
was
the
public
or
the
private
cloud
we
needed
to
abstract
away,
whether
in
which
cloud
you're
running.
So
you
know
it
didn't
really
matter
what
you
were
doing
and
we
also
wanted
to
be
able
to
not
hinder
them
in
any
case
in
in
any
way
so
deployment.
B
So
we
decided
to
use
kubernetes,
and
you
know
obviously,
kubernetes
is
so
well
known
that
I
won't
that
I
won't
go
into
actually
presenting
it
to
you,
but
it
it
allows
us.
These
are
the
like
the
main
three
reasons
why
we
decided
to
go
with
it
first
off.
It
allows
automation
of
deployment,
scaling
and
management
of
even
more
most
difficult
applications.
B
B
So
this
is
what
we
ended
up
doing
like
we.
We
deploy
our
payment
services
across
three
cloud:
vendors,
aws,
azure
and
gcp,
and
we
decided
to
opt
for
the
managed
kubernetes
offering,
because
that
would
allow
us
to
offload
a
lot
of
the
work
and
expertise
that
was
needed
to
run
the
kubernetes
clusters.
B
B
So
we
from
the
very
beginning
we.
This
is
one
of
the
things
that
our
engineers
always
do,
which
is
like
to
push
as
much
responsibility
to
the
ex
to
the
specialists.
If
you
can
call
them
that
to
the
specialists
that
maintain
the
public
cloud,
and
this
allows
us
to
to
use
our
engineering
resources
optimally
and
have
our
engineers
do
as
much
do
what
they
do
best.
So
we
like
to
push
as
much
responsibility
to
the
public
cloud
vendor,
while
avoiding
lock-in
as
possible.
B
So
this
shows
you
a
little
bit
an
overview
of
our
stacks
and
environments.
We
have
multi-cloud
stacks,
as
you
can
see,
on
aws,
gcp
and
azure,
and
then
they,
the
deployments,
go
in
in
order
from
dev
to
test
to
production
and
stacks
are
exact,
contain
exactly
the
same
services,
except
that
they
are
ring-fenced
copies
that
allow
our
engineers
to
test
their
work
end-to-end.
B
B
These
are
some
of
the
requirements
that
we
had
from
our
cloud
connectivity.
We
needed
a
very
quick
networking
solution
that
would
form
the
backbone
of
our
entire
multi-cloud
architecture
in
particularly
in
particular,
it
should
be
resilient
and
fault,
tolerant
and
have
automatic
failover
built
into
it,
and
the
the
latency
should
be
kept
down
since
we
don't
want.
We
don't
want
the
multi-cloud
platform
to
have
higher
slas
than
before.
B
B
B
It
is
cloud
agnostic,
so
it
provides
connectivity,
service,
discovery
and
load
balancing
across
the
clouds
making.
It
really
easy
for
us
to
deploy
it
anywhere
and
it
has
the
inbuilt
observability
with
hubble,
which
was
written
for
psyllium
in
particular,
and
we
already
used
prometheus
and
grafana.
So
that's
you
know
that
was
a
great
fit
for
our
platform.
B
On
the
cloud
side,
we
have
gateways
that
can
then
forward
the
traffic
to
the
correct
service
and
the
cloud
vendors
provide
native
right
routing
with
their
kubernetes
cni's
and
psyllium
provides
cni
chaining.
So
it's
able
so
we're
able
to
use
psyllium
together
with
the
with
the
cloud
vendor
nate
with
the
cloud
vendor
cni's
we
use
where
we
need
to
make
sure
we
make
sure
that
the
addresses
of
ours
of
our
stacks
don't
overlap,
but
because
we
choose
very
widesider
ranges,
then
we
have
lots
of
room
to
grow.
B
So
psyllium
also
provides
the
ability
to
run
the
multi-cloud
solution
using
cluster
mesh,
but
that's
not
something
that
we've
built
in
you
can
read
about.
The
good
folks
at
psyllium
have
done
an
excellent
presentation
about
cluster
mesh
on
their
on
their
blog,
which
I
encourage
you
to
read
or
watch,
and
if
you
want
to
learn
more
about
it,
we
might
decide
to
mesh
our
multi-cloud
and
our
multi-cloud
multi-cloud
solution
in
the
future.
But
right
now
it
does
not
run
in
cluster
mesh.
B
B
B
Then
it
should
be
persistent
because
we
again
we
don't
want
to
lose
messages
and
we
need
to
ensure
that
they
get
delivered
and
it
needs
to
have
good,
go
client
support
because
our
platform
is
written
and
go
so
enter
nats
jet
stream.
So
I'm
going
to
give
you
a
quick
introduction
to
what
nats
is
and
then
we
will
look
into
how
we
use
it.
B
On
the
other
hand,
nas
jet
stream
does
provide
exactly
one's
message
delivery
and
it
has
inbuilt
persistence
and
durability
guarantees.
So
we
just
thought
we
this
is.
We
are
only
using
that
jet
stream
messages
are
messages,
so
in
gnats
messages
are
organized
into
subjects,
and
then
the
stream
defines
the
retention
of
an
of
a
given
subject.
B
B
B
So
the
reason
we
chose
nat
jet
stream,
as
you
remember,
from
our
initial
architecture.
We
did
have
some
some
in-house
experience
with
using
that
streaming,
but
we
decided
to
use
nat's
jet
stream
in
the
multi-cloud
project,
because
it
has
the
push
and
pull
clients
that
I
was
talking
about,
and
it
also
supports
wildcard
subscriptions,
which
is
another
really
cool
feature.
It's
cloud
agnostic,
open
source
and
written
in
gold.
So
obviously
the
go
client
support
was
there
and
it
provides
horizontal
scalability
as
as
well
as
exactly
one's
message
guarantees.
B
So
it
is
a
very
fast,
very,
very
fast,
very
scalable
solution
that
we
decided
to
leverage
in
our
multi-cloud
platform.
So
this
is
what
it
looks
like.
We
have.
The
data
centers
run
in
one
cluster,
so
remember
that
there's
two
data
centers,
not
one
with
one
in
the
cloud
for
replication
and
together
they
make
one
cluster
and
then
the
multi-cloud
makes
it
another
cluster.
The
two
clouds
together
form
a
nats
supercluster
inside
a
cluster.
B
So
this
allows
us
to
actually
pass
information
between
clouds
very
easily.
So,
finally,
we
get
to
the
database
storage
part
and
we
can
look
at
cockroachdb.
We
needed.
We
had
some
requirements
for
our
database
solution.
It
should,
of
course,
support
multi-cloud
and,
if
possible,
it
should
have
sql
compatibility.
As
we
were
running
our
previous
solution
in
postgres.
It
would
be
great
if
we
could
still
use
those
kind
of
the
same
kind
of
patterns,
as
opposed
to
like
rewriting
a
whole
bunch
of
code
as
well
as
going
to
multi-cloud.
B
So
what
is
cockroachdb
so
cockroach
is
a
distributed
database
and
you
can
write
and
read
from
any
node.
It
organizes.
It
organizes
data
into
ranges
which
cockroach
then
rebalances
and
partitions.
Accordingly,
a
each
range
is
assigned
a
node
that
is
the
lease
holder
and
that
node
is
in
charge
of
coordinating,
reads
and
rights
to
a
particular
to
the
particular
partition
to
the
particular
range
apologies,
and
it
is
a
distributed
database
that
is
strongly
consistent
and
is
asset
compliant.
B
So
why
did
we
choose
it?
First,
the
postgresql
postgres
sql
compatibility
was
huge.
It
was
a
huge
plus
for
us
because
it
allows
us
to
switch
our
workloads,
and
I
use
the
same
kind
of
like
data
structures
that
we
have
from
from
using
postgres
and
it's
cloud
agnostic
and
is
able
to
run
in
kubernetes
across
vendors,
which
again
is
is
great
for
us
strongly
consistent
because
it
does
it.
You
requires
a
quorum
to
write
any
to
write
data
to
ranges,
so
that
was
absolute.
That
was
great
for
us
as
well.
B
So
this
is
why
what
I'm,
representing
with
the
different
colored
nodes,
each
each
range,
is
replicated
across
each
each
cloud,
because
we
have
very
fast
connectivity
in
between
the
clouds.
Then
this
allows
us
to
actually
spread
the
ranges
across
clouds
and
then
still
have
the
strong
consistency
on
each
right.
B
B
Okay,
so
this
brings
us
to
the
end
of
the
exploration
of
our
platform,
but
we
can
leave
you
with
three
rules
of
thumb.
So
when
it
comes
to,
if
you,
if
you're
thinking
about
going
to
the
to
multi-cloud,
then
we
recommend
that
you
test
your
services
end-to-end
with
a
variety
of
load
types.
This
has
been
absolutely
crucial
for
us
and
we
use
toxipro
toxiproxy
to
be
able
to
test
our
services
in
a
variety
of
like
connectivity.
Scenarios
expect
errors
in
retries
in
multi-cloud.
We
have.
B
B
We
use
nat's
jet
stream
as
our
event,
bus,
which
runs
on
multi-cloud
and
we
use
cockroachdb
as
our
distributed.
Sql
storage.
We
haven't
changed
anything
on
the
other
side
on
the
to
on
the
data
center
side,
but
we
might.
There
is
a
project
ongoing
to
replace
nat's
streaming
with
nat's
jet
stream,
as
that
is
being
deprecated.
B
So
this
is
the
end
of
my
talk.
Thank
you
so
much
for
listening,
remember
to
check
out
our
podcast
and
our
engineering
site
as
well
as
our
twitter
account
there.
We
have
so
many
we're
very
proud
to
say
that
we
have
a
lot
of
engineers.
Reform
from
form3
at
cubecon,
so
do
come
to
our
stand
in
pavilion
1,
and
we
can
chat
more
about
multi-cloud
and
yeah
just
like
embrace
the
community
feeling
of
this
conference.
A
C
B
So
I
may
have
phrased
so
the
question
was
whether
about
how
our
clients
choose
where
they
connect
to,
to
which
cloud
provider
they
connect.
So
our
clients
have
high
availability
connections
to
all
of
our
cloud
providers,
so
they
can
connect
on
any
payment
service
and
then
they
can
choose
exactly
which
one
to
connect
to
they
don't
have
to
like
only
connect
to
one
and
then
that's
the
one
you've
got
and
then
yeah.
If,
if
there's
an
outage,
then
they
can
go
and
connect
to
the
other
provider.
D
B
So
that's
an
excellent
question.
The
question
is
about
how
we
secure
connections
in
multi-cloud,
so
all
of
the
connections
in
between
the
clouds
are
secure,
but
I'm
not
a
security
expert,
we'll
be
happy
to
tell
you
more
about
exactly
how
our
client,
how
the
client
side
security
works.
If
you
come
to
our
stand,.