►
From YouTube: Helping One of Europe's Banks Re-platform with Declarative, Self-hea... Stuart Harris & Aayush Attri
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.
Helping One of Europe's Banks Re-platform with Declarative, Self-healing, Multi-cloud WasmCloud Clusters on Kubernetes - Stuart Harris & Aayush Attri, Red Badger
Next-generation platforms are evolving away from containers, and towards server-side WebAssembly. wasmcloud leverages a NATS messaging substrate to provide self-healing clusters that can span clouds, whilst remaining unaware of underlying network topology and vendor-specific products. Developer productivity is improved by avoiding boilerplate and building highly focused, lightweight, reliable and secure services. Our talk explores this paradigm shift, and demonstrates a declarative way to deploy distributed applications on a wasmcloud lattice that spans multiple cloud providers across geographic locations. It will also show seamless failover (and recovery) between cloud providers when there is a server outage or a network partition. Red Badger was engaged by one of Europe’s largest banks to help them understand what their future state architecture should look like. Multi-cloud is a must, and resilience and portability are highly desirable. We believe that such a platform looks something like k8s+service mesh+wasmcloud+NATS+GitOps. We've built a PoC platform around this technology which we'd love to talk through, demonstrate, and talk about why this approach is game-changer for the finance industry and beyond.
A
Hi
everyone
we're
really
excited
to
be
at
cloud
native,
north
america
wasn't
a
2021,
it's
a
real
honor
to
be
selected
to
talk
today
and
we
have
some
really
exciting
stuff
packed
into
the
next
20
minutes.
Or
so
we
want
to
talk
about
the
use
of
webassembly
server
side
and
how
it's
driving
a
revolution
in
platform.
Design
coupled
with
products
like
wasmcloud
and
nats
webassembly,
is
creating
a
new
paradigm
for
cloud
native
which,
as
new
paradigms,
should
eliminates
entire
classes
of
problems
that
we
struggle
with
today
when
building
distributed
applications.
A
A
We're
a
london-based
consultancy,
that's
obsessed
with
helping
organizations
streamline
their
ability
to
deliver
digital
products
or
services,
we're
very
honored
to
be
here
and
a
big
thank
you
to
cncf
for
organizing
this
event.
Today,
as
a
consultancy,
we've
experienced
the
pain
over
and
over
again
of
building
microservice
applications
with
today's
architectures.
A
It's
not
straightforward
by
any
stretch
of
the
imagination
and
there's
a
lot
to
think
about
one
of
our
clients.
One
of
europe's
largest
banks
engaged
us
recently
to
describe
to
them
what
a
future
pla
state
as
future
state
platform
architecture
could
look
like
they
want
to
prepare
themselves
for
a
world
where
they
can
easily
deploy
workloads
securely
and
reliably
across
on-premise
and
any
cloud
without
having
to
constantly
adjust
network
topology
to
suit.
A
A
A
The
cost
of
moving
everything
to
another
cloud
provider
is
going
to
be
prohibitive.
Containers
and
kubernetes
have
been
at
an
io,
not
for
our
industry.
It's
the
first
time
that
there
has
been
a
standard
and
consistent
and
uniform
way
to
deploy
our
applications,
regardless
of
which
cloud
provider
we
want
to
use,
but
we're
still
locked
into
cloud
provider.
Specific
services
aws
is
famous
for
the
number
of
services
it
keeps
introducing,
and
every
cloud
provider
specific
service
that
we
use
locks
us
in
even
further
kubernetes
was
the
first
step
on
this
ladder.
A
A
The
next
step
on
the
ladder
out
of
the
cloud
or,
let's
say
above
the
cloud,
is
webassembly
running
server
side
on
one
of
the
many
runtimes
that
we
have
now
and
probably
with
a
platform
like
wasn't
cloud
running
on
top
of
nats
on
top
of
kubernetes.
For
now,
on
top
of
cloud
today,
aisha-
and
I
want
to
talk
about
how
these
technologies
are
changing
the
game
completely.
B
Cool
thanks
to
so
yeah,
as
you
mentioned,
I'm
going
to
be
demonstrating
a
service
vault
tolerance
in
a
multi-cloud
architecture,
in
other
words,
we're
going
to
be
running
same
application
code
in
two
different
clouds.
Well,
two
different
kubernetes
clusters
within
that
and
so
yeah,
we'll
just
see
once
one
of
the
actions
become
unavailable
or
unhealthy.
For
whatever
reason,
how
does
a
service
fail
over
to
be
another,
our
healthy
service
running
in
the
other
cluster?
But
before
we
jump
into
our
demo?
B
I
wanted
to
talk
a
little
bit
about
the
architecture
of
what
a
platform
looks
like
when
you're
working
with
wysom
cloud.
So
here
we
have
two
clouds,
two
cloud
providers,
so
you
have
gcp
and
aws,
and
within
that
you
have
this
dotted
line
or
dotted
container,
which
is
essentially
our
pod.
So
it's
running
a
kubernetes
and
it
has
a
pod
and
a
server.
A
B
And
obviously,
with
you
leveraging
the
kubernetes
capabilities,
you're
able
to
scale
your
parts
as
well.
So
that's
what
our
platform
looks
like,
but
when
you're
working
with
ryzen
cloud
host
runtime,
but
for
this
group
of
concepts,
the
architecture
that
we
went
with
was
having
a
a
pod,
a
business
card
host
runtime
pod,
each
for
a
type
of
workload
that
we
wanted
to
run.
So,
as
you
can
see,
our
ryzen
cloud
part
b
is
running
our
business.
A
B
And
respectively,
our
cloud
part,
a
and
c
are
running
our
capability
providers,
so
it
just
becomes
easier
for
us
to
identify
and
also
simulate
outage
when
we
have
this
kind
of
architecture.
So
that's
why
we
went
with
something
like
this,
so
yeah.
So
just
talking
about
our
business
logic,
so
we
have
our
to-do
application.
So
it's
just
another
to-do
application
that
also
supports
all
the
crud
operations
and
it
complies
with
our
buddha
to
do
back-end
spec.
B
So
we
have
a
to-do
actor
running
in
both
of
the
clouds
and
then
we
want
to
be
able
to
make
a
request
to
those
2d
reactors
running
into
the
clouds.
So
we
have
an
external
ip.
That's
why
we
have
two
http
capability
providers
as
well:
sorry,
one
each
and
so
yeah.
You
can
make
a
request
here
to
director
so
yeah,
and
then
we
have
just
one
database.
This
was
to
represent
our
clients
mainframe
system,
so
where
they
have
only
one
database,
then
everything
is
just
built
on
top.
A
B
B
B
So
nats
is
essentially
you
have
your
topics
and
services
subscribe
to
those
topics,
so
they
have
messages
being
passed
through
and
when
and
in
a
scenario
where
our
service
wants
to
talk
across
to
the
different
cluster,
we
are
using
ngs
that
essentially
sits
right
between
both
of
our
clusters.
So
ngs
is
that's
a
global
service,
so
nasa
is
essentially
another
cluster
that
you
have
working
as
a
acting
as
a
gateway
between
your
clusters,
so
our
message
is
propagated
up
and
then
down
to
the
other
cluster.
B
So
now
is
the
fun
time
for
demo
time.
So
so
we
have
our
terminal
here,
which
is
a
lot
of
terminal
windows.
So
the
reason
we
have
this
kind
of
setup
is
because,
if
you
go
back
to
this
logical
representation
here
that
I
showed
you
earlier
so
on
the
left
hand
side
we
showed
all
the
gcp
stuff
and
on
the
right
hand,
side
we
have
all
the
aws.
B
So
that's
the
just
wanted
to
replicate
that
in
in
terms
of
terminal,
so
just
easier
to
visualize
in
this
demo,
so
yeah.
So
similarly
we're
going
to
use
two
two
top
windows
here
as
our
clients,
so
I'm
just
going
to
be
using
curl.
So
it's
like
curl,
gcp
and
hull
to
aws
and
these
two
windows
here,
I'm
going
to
be
using
stern
to
pull
the
logs
from
the
to
do
actor
running
in
gcp.
B
So,
as
you
can
see,
the
context
is
gcp
running
two
director
and
excluding
some
of
the
noise
that
we
are
getting
from
our
logs
from
the
health
checks
and
stuff.
So
just
it
just
makes
it
easier
for
us
to
identify
the
logs
we
care
about.
So
I'm
just
going
to
run
that
and
now
we're
fetching
all
the
logs
we
are
pulling
all
the
logs
and
similarly
I
want
to
do
the
same
for
aws.
So
so
in
the
middle
windows
we
are
listening
to
parts
on
the
left.
B
We
listen
to
actor
running
for
gtp
on
the
right.
We
have
our
actor
running
aws
and
at
the
bottom
we
have
our
ops
windows,
and
this
is
where
I'll
be
doing.
Some
cube,
cuddle,
fun
and
pretending
to
be
a
chaos
monkey,
so
I'm
going
to
be
taking
down
actors
and
bringing
them
back
up
so
yeah.
So
this
is
the
this
is
the
setup
and
hopefully
it's
easy
enough
to
follow.
B
So
if
I
curl
here
so
you
can
see
we're
getting
some
logs
from
the
actor
running
in
gcp
and
if
I
make
a
call
across
aws,
we
are
seeing
some
logs
from
actor
running
in
aws,
but
we
don't
have
any
to-do's
at
the
moment,
so
we
might
as
well
go
ahead
and
create
one.
So
we
can
create
to
do
that
goes
to
our
gcp
service
and
then
we
can
make
it
to
dude,
saying
something
hello
to
gcp.
B
Just
easy
to
identify,
so
we
make
a
request
and
our
actor
running
in
gcp
handles
our
request.
And
similarly
we
can
actually,
let's
just
curl,
that
to
show
that
how
our
actor
running
in
aws
is
still
able
to
fetch
the
data
from
redis
running
in
gcp.
So
it
has
the
consistency
already.
So
it
can
see
the
data,
and
that
was
quick.
So
I'm
going
to
go
ahead
and
just
create
a
to
do
from
aws
as
well.
Just
we
have
two
easily
identifiable
to-do's
that
we
created.
B
I
should
clear
these
consoles,
so
I'm
going
to
go
ahead
and
create
that
so
yeah.
As
expected,
our
request
to
aws
is
handled
by
the
actor
running
in
aws,
and
now
I'm
just
going
to
make
a
get
request
again
and
we
should
be
able
to
see
the
two,
the
two
two
to-do's
that
we
just
created
and
they're
already
here.
So
we
can
see
our
hello
to
gcp
and
hello
to
aws
and
similarly
here
as
well,
so
we
can
see
that
both
of
the
access
when
we
call
from
gcp.
B
So
what
I'm
gonna
do
next
is,
as
I
said,
I'm
gonna
be
a
chaos,
monkey
and
I'm
gonna
go
ahead
and
delete
the
actor
running
in
sorry,
so
the
actor
running
in
in
gcp.
So
this
will
be
the
business
logic
that
we
have
that
handles
our
incoming
requests
that
we
want
to
create
to
do
or
get
to
do
so.
What
what's?
What
have
we
actually
done?
So
we
we
initially
we
saw
the
happy
path.
B
B
Does
the
work
and
then
responds
back
to
the
client
so
now,
by
deleting
the
actor
we've
done?
Something
that's
represented
in
this
diagram.
So
we've
deleted
the
actor
in
running
in
gtp
and
we
can
see
what
let's
see
what
happens
when
when
the
actor
has
been
removed
so
that
actor
should
be
deleted.
So
what
we
can
do
is
get
the
pods
from
gcp
and
cw.
B
The
actor
has
been
removed
and
we
only
have
http
capability
redis
capability
in
the
redis
itself,
and
if
we
just
do
the
same
thing
to
aws
and
just
get
the
parts
that
are
available
right
now
and
we
should
have
acta
and
hdb
capability
both
available
in
aws.
So
we
have
one
actor
healthy,
but
it's
a
different
cluster.
B
B
So
just
one
more
time,
so
we
can
make
a
request
to
gcp
and
it's
worked
and
the
work
is
done
by
the
actor,
the
healthy
actor
running
in
aws
in
a
different
cluster,
and
when
we
make
a
request
to
aws,
it
should
just
behave
the
same
as
it
should,
because
it
has
a
local
actor
to
do
the
work
cool
and
for
so
now
I'll
just
bring
that
actor
back
up.
So
just
we
can
see
how
the
cluster
recovers.
B
So
now
we
can
see
the
logs
coming
through.
So
we
have
always
some
more
pods
coming
up.
Our
cloud
host
is
coming
back
up
as
well,
and
we
just
can.
We
can
quickly
go
back
to
the
diagram
here.
So
what
we
just
witnessed
was
I
took
down
the
actor
running
in
gcp,
which
made
our
service
to
fall
onto
the
unexpected
path
or
the
unhappy
path
represented
by
the
dotted
line.
So
it
went
across
to
the
healthy
to
the
actor
running
in
a
completely
different
cluster.
B
B
So
what
we've
done
now
is
just
now
is
we
bring
back
the
service
of
recovering
the
service
back
up,
which
means
we
are
back
to
where
we
started
with
the
full
service?
Oh
both
were
two
actors
being
healthy
and
we
should
go
back
to
how
the
things
were
when
we
started.
So,
if
I
make
a
request
now
to
gcp
that
we
can
see
our
actors
back
up
and
can
then
handle
the
request
again,
and
we
can
do
a
similar
thing.
Sorry,
actually,
before
I
move
on
to
move
on.
B
Like
oh
sorry,
that's
aws
before
I
move
on,
I
just
want
to
show
you.
The
actor
is
back
up,
so
we
have
an
access
part
running
previously.
We
didn't
have
that,
and
now
it's
all
back
up
and
that's
why
we
gained
a
successful
response
and
similarly
we
can
do
the
same
thing
as
we
can
see
on
the
on
on
aws
that
we
still
have
lecture
available.
So
what
we'll
do
is
delete
that
actually
as
well
just
so,
we
can
see
both
clusters.
B
How
do
both
of
the
clusters
handle
the
failover
so
I'll
go
ahead
and
delete
that,
and
what
essentially
we're
doing
now
is
is
doing
something
like
this.
So
on
aws,
the
only
thing
we'll
be
left
with
is
the
http
capability
provider
and
that's
it
and
we'll
see
how
that
kind
of
works
out
for
us
in
a
minute.
So
what
I'll
do
is
I'm
just
gonna
wait
for
the
pod
to
terminate
just
we're
gonna.
Do
a
watch
command
on
here.
So
we
can
see.
B
Even
though
we
have
nothing
here
see
we
have
nothing
other
than
http
capability.
That's
all!
There's
no
actors
that
can
do
the
business
logic,
there's
not
even
a
database
in
the
aws
cluster.
It
still
can
handle
the
incoming
requests
successfully
so
yeah.
So
I'm
just
going
to
go
ahead
and
bring
that
service
back
up
again
and
we
can
see
it
will
recover.
A
B
And
our
so
yeah
we
can
see
the
action
module
has
started,
so
I
want
to
click,
go
ahead
and
clear,
and
just
for
one
last
time
you
can
see
the
recovery
of
our
service
back
to
our
site.
So
we
can
see
the
logs
coming
from
the
respectful
respectively
from
the
clusters
they
belong
from,
belong
to
so
yeah.
B
What
we
saw
essentially
is
our
service
is
running
in
two
clusters
or
axis
running
in
two
different
western
cloud,
runtimes
and
two
different
kubernetes
cluster
and
in
a
two
different
major
cloud
providers,
and
we
can
see
our
servers
just
seamlessly
failing
over
and
in
following
the
unexpected
path
and
just
recovering
and
and
yeah
recovering,
as
it
comes
back
up
automatically
so
yeah.
That's
what
I
had
to
show
and
now
I'm
going
to
hand
it
all
to
street.
A
Thanks,
aisha,
that
was
absolutely
amazing.
I
think
this
is
the
first
time
I've
seen
anything
like
this,
really
where
you
can
have
a
true
multi-location
cluster
spread
across
geographic
locations
across
the
world,
and
it's
made
possible
because
of
webassembly
for
lightweight
portable
workloads,
wasn't
cloud
for
the
application,
application,
runtime
and
that's
for
location
independence.
A
I'm
absolutely
convinced
that
in
the
next
few
years,
or
maybe
even
months,
server
side,
webassembly
runtimes
will
make
significant
inroads
into
platform
design
subtly
influencing
our
software
architecture
on
the
way-
and
I
say
this
because
there's
another
thing
happening
here-
microservices
that
today
are
delineated
by
network
boundaries
will
give
way
to
much
smaller,
lighter
act
as
compiled
to
web
assembly
that
talk
over
potentially
global
messaging
backgrounds
and,
importantly,
they'll
be
freed
from
almost
all
the
boilerplate
code
that
sucks
up
so
much
of
our
energy.
Today.
This
is
already
happening.
A
A
These
help
us
to
make
our
services
smaller
and
more
focused.
Excuse
me,
then
we
have
the
paradigm
shift
with
webassembly
and
wasn't
cloud.
This
is
where
our
services
are
now
more
like
actors
sitting
above
the
network
layer
and
representing
our
pure
core
in
the
future.
This
may
go
even
further
hosting
immutable
functions,
for
instance
on
platforms
such
as
the
upcoming
unison
cloud.
A
Imagine
a
typical
microservice
today
say
it's
built
with
rust,
good
choice
and
placed
in
a
docker
container
say:
www,
that's
an
operating
system
which
we
need
because
we
need.
We
want
to
talk
to
services
over
http,
so
we
need
a
networking
stack
and
we
want
to
write
a
log
to
standard
out.
We
also
want
to
talk
to
a
database,
so
we
need
to
pull
in
all
the
code
to
do
that
now,
we're
quite
chunky
and
we
need
direct
access
to
a.
B
A
A
B
A
A
The
application
runtime
is
built
with
elixir,
otp
leveraging
years
of
battle
testing
and
it
schedules
capability
providers
and
actors.
The
actors
talk
to
capability
providers
through
a
contract
declared
with
amazon's
smithy
idl,
which
is
protocol
and
language
independent.
The
capability
providers
are
where
the
side
effects
are.
We
build
them
once
and
we
use
all.
We
use
a
first
party
provider
out
of
the
box
they're
just
like
frameworks
of
old
but
they're,
independently,
scalable
and
resilient,
and
also
language
agnostic.
A
This
theme
has
come
through
from
through
from
istio
and
dapper.
It's
the
same
sort
of
thing
like
pulling
this
stuff
to
the
edge
and
doing
it
once
instead
of
every
single
time.
So
wasn't
cloud.
Has
this
concept
of
composable
actors
compiled
from
any
language
into
webassembly
that
talk
to
the
capability
providers,
which
can
be
either
first
or
third
party
actors,
are
scheduled
to
run
on
hosts
that
self-form
into
a
self-healing
lattice
made
from
a
nats
backplane?
A
B
A
Enterprise,
you
might
expect
a
single
global,
multi-tenant,
nats
backplane,
to
be
the
ceiling
for
the
infrastructure
team
and
the
floor
for
the
platform
team.
Wilson
cloud
becomes
the
ceiling
for
the
platform
team
and
the
floor
for
the
application
teams,
and
it
provides
a
great
developer
experience
for
building
modern,
distributed
applications
with
high
velocity
and
a
core
focus
on
building
customer
value.