►
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.
What's Going ARM: Adopting ARM64 At Airbnb - Melanie Cebula, Airbnb
Speakers: Melanie Cebula
What’s going ARM? With all the recent developments in the architecture space, you may be wondering how these changes apply to your infrastructure. At Airbnb, we’re going through a multi-year journey to evaluate and adopt support for ARM64 and “multi-arch” support-- from our local laptop developer environments, to CI infrastructure, all the way through to production workloads. In this talk, we will go over: - An overview and evaluation of the current state of ARM - The pitfalls and challenges we faced - How we designed multi-arch support - And more!
A
Hi
I'm
Melanie
I'm
here
to
talk
about
what's
going
on,
adopting
arm64
at
Airbnb,
so
for
the
agenda
I'm
going
to
first
give
an
overview
of
arm,
then
the
pitfalls
and
challenges
we
face
and,
finally,
how
we
designed
multi-arch
support
at
Airbnb.
So
what
is
going
on
arm
armed
is
a
company
that
designs
the
arm,
architecture
and
licenses
licenses
it
to
other
vendors
and
who
then
develop
their
own
arm-based
processors.
A
Now
there
is
a
competitive
arm,
design
that
targets
both
Energy
Efficiency
and
performance,
so
who
here,
has
an
apple
M1,
laptop
okay,
great.
So
these
new
advantages,
combined
with
licensing
terms,
allows
other
vendors,
like
apple,
to
switch
out
their
Intel
processor
for
their
own
custom,
Arm
based
processor.
So
if
you're,
a
developer
that
uses
the
MacBook
M1
I'm
sure
you've
noticed
that
Apple
switched
completely
from
their
Intel,
based
processors
to
their
own
M1
design.
A
So
now
developers
are
exposed
to
arm
64
as
they
had
to
build
some
developer
support
for
Darwin
and
arm
in
their
tool
chains,
so,
like
Apple
Cloud
vendors
want
to
create
their
own
processors.
Similarly,
they
work
with
arm
to
create
custom
systems
on
Chip's
designs
and
sell
it
to
the
consumer.
All
major
Cloud
providers
now
have
custom
arm-based
VMS
and
generally
they
advertise
Energy,
Efficiency
and
performance,
and
our
price
varies
deeply
compared
to
the
other
instances.
This
encourages
customers
to
adopt
arm
support
to
run
on
cheaper
Hardware.
A
However,
there
are
pitfalls
and
challenges
with
arm
okay,
so,
firstly,
the
architecture
you're
using
and
developing
for
historically
is
x8664,
which
is
not
compatible
with
arm
64..
In
the
past,
you
may
have
switched
between
maybe
AMD
and
Intel
instances,
for
example,
but
that's
less
challenging,
because
the
instruction
set
is
pretty
much
the
same
Additionally.
A
A
Another
challenge
is
the
high
surface
area,
so
anything
running
on
your
servers
is
affected,
for
example,
everything,
including
the
base
infrastructure,
build
tool,
chain
applications,
common
functionality,
running
on
machines
such
as
security
and
observability
and
more
so.
This
makes
the
challenge
a
full
stack
and
cost-functional
team
effort
that
requires
expertise,
Staffing
commitment
and
coordination.
A
A
pitfall
we
ran
into
early
on
is
that
a
lot
of
our
migrations
are
sort
of
treated
as
All
or
Nothing
migrations,
but
for
arm
we
don't
actually
need
a
scope
to
migrate
all
possible
workloads
to
arm,
and
so
most
companies
are
also
running
the
migration.
This
way,
and
in
this
end
it's
actually
a
benefit
because
we
can
target
support
where
it
makes
the
most
sense,
and
we
want
to
Target
workloads
to
run
on
the
right
Hardware
based
on
their
price
performance
needs,
so
it
makes
sense
for
some,
but
maybe
not
the
others.
A
I
included
a
diagram
that
has
priced
on
the
y-axis
and
perf
on
x-axis
and
on
the
right.
I
have
a
few
choices
of
Hardware.
I
could
run
my
workload
on
these.
Each
will
land
somewhere
on
the
graph
in
the
end,
I
will
choose
to
run
this
workload
based
on
what
I'm
optimizing
for
and
the
results
of
the
analysis
and
just
note
that
actual
price
performance
comparison
depends
on
many
factors
such
as
the
workload
Cloud
vendor
and
Hardware.
A
Okay,
one
other
challenge
is
that
this
is
also
a
performance
problem,
so
this
is
because
arm
64
is
in
catch-up
mode
compared
to
xa664.
Intel
specifically
has
for
years
and
years
put
optimizations
across
the
software
stack
and
put
them
in
place.
So
it'll
take
time
for
software
to
catch
up
with
the
same
kinds
of
optimizations
for
arm64
and
in
the
meantime
it
may
require
sophisticated
performance
analysis,
tooling
comparison
and
tweaks
to
achieve
competitive
performance.
A
So,
finally,
before
I
go
further
a
note
on
architecture,
naming
you'll
see
all
of
the
following
combinations
and
probably
more
to
describe
what
is
basically
two
architectures,
so
xa664
x64
AMD,
64,
Intel,
64
versus
ARG,
64
and
arm
64..
The
reason
for
this
is
due
to
inconsistency
in
how
the
architectures
are
named
references
in
various
parts
of
the
stack,
for
example,
packaging
versus
Docker
images,
so
I'll
probably
end
up
using
them
interchangeably,
and
that's
why
finally
I'm
going
to
give
a
deep
dive
in
how
we
designed
multi-arch
at
Airbnb,
so
on
a
high
level.
A
The
goal
of
multi-arch
is
that
our
workloads
can
run
on
the
best
hardware
for
their
price
performance
needs
without
developers
being
concerned
with
the
underlying
architecture.
Note
that
as
you'll
notice
in
this
talk,
while
the
goals
for
the
developers
to
not
be
concerned
with
the
architecture,
the
platform
Engineers
involved,
such
as
myself,
need
to
do
a
lot
of
heavy
lifting
to
make
that
possible.
A
So
designing,
multiracy
Airbnb
has
closely
resembled
the
hero's
journey.
So
first
was
the
Call
to
Adventure.
The
community
in
our
peers
began
to
embrace
arm
64
support
several
years
ago,
and
we
were
pretty
excited
by
what
we
were
hearing
and
seeing,
but
then
the
refusal
of
the
call
we
had
some
initial
analysis
that
this
was
not
quite
compelling
enough
yet
and
we
need
for
our
infrastructure,
would
be
a
pretty
heavy
lift
so
with
unclear
benefit.
We
sort
of
took
a
pause
on
the
project.
A
Some
time
went
by
and
then
we
invested
in
Supernatural
Aid
with
performance,
expertise
and
Analysis,
and
we
also
pivoted
to
a
small
Focus
team
to
kind
of
pilot
this
effort.
So
now
we
are
deep
into
the
road
of
trials
with
many
challenges
and
significant
progress
toward
multi-arch
support,
so
we're
not
complete
in
our
journey
but
I
figured.
We
have
enough
to
share.
A
So
that's
what
I'm
doing
okay,
so
first
we
focus
our
efforts
on
one
or
two
workloads
that
have
a
business
need
for
better
price
and
performance
that
really
incentivized
us
to
find
something
that
was
best
for
the
business.
We've
formed
a
small
pilot
group
with
subject
matter
experts
and
we
figured
out
prerequisites
ahead
of
time.
So
this
is
what
the
pilot
group
looks
like.
We
have
a
few
subject
matter:
experts
across
the
stack,
particularly
in
systems
kubernetes
performance,
as
well
as
a
developer
or
two
from
the
application
side.
A
This
is
the
overall
plan.
First
prerequisites,
then
infrastructure,
then
kubernetes
then
running
the
application
itself
and
note
the
performance
analysis.
Canon
should
be
done
independently
of
other
works
right.
We
don't
need
to
stand
up
all
of
the
arm
infrastructure
to
necessarily
kick
off
an
arm
build
and
do
some
analysis
talk
a
little
bit
about
that
later.
So,
let's
dive
into
prerequisites,
mostly
in
the
form
of
upgrades
and
migrations.
A
First,
the
good
news
near
the
old
software
that
we
have
looked
at
has
arm
64
support
bad
news.
You
probably
have
to
upgrade
to
get
to
it,
so
this
includes
the
operating
system
and
arm
64
packages
for
that
OS
languages
and
runtimes
and
open
source
software.
Let's
start
with
the
bottom
layer,
which
is
the
operating
system.
Choosing
the
right
OS
for
arms
64
depends
on
your
unique
context.
A
This
is
a
brief
analysis.
I
performed
on
a
West
package
support
for
some
of
the
popular
os's
older
os's
such
as
Ubuntu
1804,
don't
have
robust
support
and
I'll
go
out
of
support
soon,
anyway,
Amazon
Linux
2,
like
other
os's,
that
use
apple
7,
like
I
mentioned,
don't
have
that
third-party
support.
So
the
latest
of
these
and
other
operating
systems,
for
example,
Ubuntu
2204
Amazon
Linux
2022,
which
is
based
off
of
Fedora
Linux.
A
A
So
no
that
since
we've
selected
our
OS,
we
need
to
be
able
to
build
upload
and
sign
packages
like
if
you
have
internal
packages
or
third-party
packages,
you
want
to
mirror
so
at
openview
we
automate
that
process
with
cicv
jobs.
This
is
what
publishing
packages
internally
could
look
like.
I
have
two
examples,
one
of
our
RPMs,
the
other
for
Debian
files.
A
So
you
store
your
packages
and
get
get
Repose
and
get
push
triggers
the
CI
job
which
actually
builds
and
deploys
each
of
these
packages,
because
these
are
architecture
dependent,
CI
jobs
are
dispatched
for
each
architecture
to
CI
workers
that
are
running
on
that
architecture.
These
are
pushed
to
internal
repositories
in
our
package
repository
which
stores
it
in
the
cloud.
A
So
you
can
easily
support
building
your
RPMs
on
all
platforms,
but
some
might
take
some
work
to
actually
build
properly
on
arms
64..
So
one
way
we
did
this
is
we
just
added
arms
for
support
to
just
automatically
dual
build
everything,
but
we
excluded
a
few
packages
to
start
with
this
exclude
Arch
aarch
64
flag.
Then
we
went
back
and
added
rm64
support
one
by
one
for
packages
where
it
was
challenging.
A
Giving
support
also
supports
architecture,
agnostic
packages,
as
well
as
multiple
architectures
in
the
architecture
section.
So
you
should
check
to
see
if
you're
missing
rm64
in
this
list.
Also,
this
has
happened
to
me
a
few
times.
Arm64
and
AMD
64
texts
look
pretty
similar,
especially
you've
been
staring
at
it
all
day.
So,
if
you're
looking
in
this
list
and
scanning
just
make
sure
you
see,
arms,
64
amd64
is
the
other
one,
so
you
probably
need
both
okay.
A
So
next
you
need
to
check
the
language
software
you're
running
and
update
for
arm64
support,
because
it
is
relatively
new.
Some
language
support
is
more
of
a
challenge
than
others,
for
example,
commonly
run
older
versions
of
Ruby
and
Native,
ruby,
gems
and
commonly
run
older
versions
of
python
and
python
Wheels.
A
Okay:
here's
my
best
effort
analysis
of
several
common
computer
languages,
the
minimum
officially
supported
version
for
arm64
and
the
latest
stable
version.
No
I
wrote
minimum
officially
supported
version,
but
there
are
definitely
instructions
online
for
folks
that
can
run
arm64
on
older
languages
that
are
technically
out
of
support,
not
necessarily
recommending
it
just
I
found
it
on
the
internet.
A
Okay.
Finally,
you
need
to
update
open
source
software.
This
list
is
much
longer
than
what
I've
put
in
there,
but
I
gave
just
some
examples
of
Open
Source
software.
You
may
need
to
update
form
64
support,
istio,
Envoy
and
kubernetes
all
added
support
pretty
recently,
so
this
can
be
challenging.
Who
here
is
Donna
kubernetes
upgrade
or
an
istio
upgrade
yeah?
A
So
for
us,
infrastructure
includes
infras
code
such
as
chef
and
terraform
build
test
and
deploy
support,
missing
tools,
agents
and
Daemon
binaries
and
missing
multi-arch
container
support.
So,
let's
start
with
infras
code,
there
was
basically
some
work
we
needed
to
do
just
so.
We
could
launch
an
instance
in
our
infrastructure,
so
we
did
it
pretty
iteratively.
A
We
tried
to
launch
it
and
it
failed
like
the
Ami
was
wrong
and,
like
certain
scripts
were
wrong,
then
we
launched
it
and
it
was
running
in
a
healthy
State,
and
so
we
needed
to
update
our
instance
launcher
logic,
some
of
our
provisioning
scripts,
our
packages
and
our
machine
images,
a
note
on
the
provisioning
scripts
or
just
writing.
Multi-Art
software
in
general.
You
may
have
previously
hard-coded
things
like
pulling
AMD
64
binaries
and
now
like
to
update
a
script
like
that.
A
You
need
to
have
logic
that
sort
of
inspects
the
architecture
and
pulls
the
right
binary
for
the
architecture
that
the
script
is
running
on,
so
I
use,
youname,
Dash,
M
or
Arch,
one
fun,
gotcha
I,
don't
know
if
it's
actually
fun,
but
if
you
have
any
script
that
runs
on
developer
laptops
and
it
runs
on
servers.
Beware
that
these
commands
actually
return
different
things.
You
know:
I
talked
about
like
naming
not
being
standardized
so
on
an
M1
MacBook,
it'll
return,
rm64
and
on
a
server
it
will
return.
A
Okay.
So
next
you
need
CI.
Cd
support
basically
need
to
be
able
to
run
CI,
CD
jobs
on
arm
64
machines,
and
you
need
to
be
able
to
write
and
dispatch
on
64
jobs
for
the
first
part
being
able
to
run
on
arms
64
machines.
So
this
is
pretty
easy
if
you
use
a
CI
vendor
who
uses
a
CI
vendor,
okay,
who
like
runs
and
hosts
their
own
CI,
okay
I
feel
bad
for
you.
So
it's
going
to
be
a
little
harder
if
you
try
to
do
arm.
A
The
reason
for
that
is
that
the
CIA
vendor
probably
did
well.
If
they
support
arm,
they
probably
did
all
the
hard
work
themselves
of
provisioning,
their
CI
workers
getting
them
run
on
arm.
So,
if
you
host
it,
you
have
to
do
it.
That's
what
I
did
I
updated
RCI
to
work
on
average
64..
So
once
you
have
a
willing
and
able
rm64ci
worker,
then
you
just
need
to
update
your
job
to
be
able
to
dispatch
to
them
so
dispatching
the
different
platforms,
usually
it's
configured
via
an
option
in
the
CI
job.
A
In
our
case,
we
added
a
platform
option.
This
isn't
actually
what
it
looks
like.
This
is
just
the
basic
idea,
so
you
can
specify
a
Linux
arm64
CI
worker
in
the
job
and
it
gets
dispatched
to
you
guessed
it
at
Linux,
Pharmacy
for
CI
worker
and
then
from
here.
We
just
need
to
determine
which
jobs
need
to
actually
run
on
multiple
platforms,
and
so
this
came
up
quite
a
bit
for
building
common
binaries
packages
builds
which
I'll
talk
about
soon.
A
But
while
we're
here,
I
wanted
to
talk
about
some
more
gotchas
that
I
ran
into
when
it
came
to
multi-arch
builds
so
problem
number
one.
If
you
have
two
different
architecture
builds,
and
you
have
build
caching
enabled
see
I
will
see.
I
will
try
to
save
time
by
checking
the
cash
if
you've
already
built
it
problem
is.
If
your
cache
is
not
actually
encoding,
architecture
information,
you
can
upload
an
arm64
build
and
pull
down
the
arm64
build
on
an
x8664
worker.
These
architectures
are
not
compatible
so
it'll
blow
up.
A
The
same
problem
can
happen
with
container
images.
If
you
have
two
different
architecture,
images
image
builds
it's
the
same
cash
issue,
but
with
the
docker
image
cache.
So
you
need
to
add
platform,
information
or
disable
the
cache
temporarily
to
add
the
platform
information
and
get
it
all
working
for
your
CI
workers.
Similarly,
otherwise
you
could
accidentally
pull
down
an
arm.
64
image
from
the
cache
on
an
x8664
machine,
it'll
run
the
First,
Command
and
then
it'll
blow
up
so
you'll
want
to
avoid
those.
A
Airbnb
already
have
a
tool
chain
that
supports
building
artifacts
tagging
them
with
build
tag
metadata
and
then
later
pulling
them
down.
Based
on
that
metadata.
So,
with
this
schema
in
place,
we
can
update
the
tool
chain
to
support
multiple
platforms.
So
first
we
build
a
project
for
our
Target
OS
and
Arch.
Then
we
update
the
build
tags
to
include
the
platform
information
for
OS
and
Arch.
Finally,
we
update
the
clients
to
pull
in
the
right
platform
artifact,
based
on
what
they're
running
just
a
side.
A
Note
in
this
example
to
make
it
easy,
I'm
cross
compiling,
go
Lane
code
for
a
developer
tool,
but
in
general,
don't
cross,
compile
any
important
going
binaries
with
c
dependencies,
as
these
could
unexpectedly
fail
and
crash
during
runtime
has
not
happened
to
me,
but
someone
told
me
it
happened
to
them.
So
you
don't
you
don't,
okay,
so
in
the
history
of
supporting
multi-architectures
I
found.
Another
neat
schema.
That's
sort
of
the
opposite
of
this,
which
is
this
idea
of
multi-architecture
or
Universal
binaries.
A
So
the
Saturn
is
pretty
tempting
and
I
did
see
it
pop
up
as
well.
So
if
you
were
already
building
binaries
for
MacBook
laptops
and
for
Intel
servers,
for
example,
you
might
have
been
building
all
the
binaries
writing
a
wrapper
script
that
selects
and
writes
the
right
binary
for
the
OS
and
with
M1
and
arms
64
servers.
You
could
update
this
script
to
add
more
platforms
and
then
also
yeah
with
arms
64,
like
Ci
workers,
you
get
updated
again.
A
So
now
we
have
like
the
full
Matrix
of
os
and
architecture.
So
the
upside
of
this
is
it's
relatively
straightforward
right.
It
doesn't
require
making
changes
to
the
client
it
just
sort
of
introspects.
What
like
what
should
I
run
on
and
picks
the
right
binary.
The
downside
of
this
approach
is
that
you
are
now
storing
quite
a
few
binaries
in
your
executable,
which
could
have
significant
storage
costs
or
other
you
know,
impacts
on
the
client
and
the
interaction
logic
itself
can
be
kind
of
brittle,
so
it
needs
to
be
updated
every
time.
A
This
approach
does
require
some
work
to
set
up
if
you're
building
your
own
multi-arch
images.
However,
so
to
actually
do
this
internally,
so
we
each
for
each
platform,
you
need
to
dispatch
a
CI
job
to
build
the
platform
specific
image
on
the
platform.
Specific
CI
worker
push
that
intermediate
image
the
container
registry
with
a
unique
platform
tag.
A
A
So
we
sort
of
avoid
that
image
and
image
cache
Behavior
issue
from
before,
but
I
noticed
that
if
you're,
not
careful,
you
can
still
sort
of
mess
this
up.
So
one
thing
I
noticed
is
that,
because
image
tags
are
a
unique
and
mutable,
you
can
accidentally
clobber
on
override
a
tag
which
you're
pointing
something
at
so.
In
this
example,
I
went
through
all
that
work
to
push
my
super
cool
multi-arch,
manifest
to
my
cool
project,
shot
tag
and
then
later
a
rogue
platform.
Specific
build
is
pushed
to
the
same
tag.
A
The
behavior
I
observed
at
least
with
Dr
and
ECR-
is
that
Upstream
in
the
registry
basically
just
removes
the
tag
from
the
Manifest,
which
is
now
untagged
and
it
uploads
the
platform
specific
build
with
the
same
tag
so
later
on.
My
client,
which
is
perhaps
expecting
my
fancy
multi-arch,
manifest,
actually
actually
pulls
down
the
platform,
specific
image
and
blows
up.
So
what
I
was
trying
to
accomplish
is
seamlessly
replacing
the
previous
logic
with
multi-arch
manifests,
but
you
just
need
to
be
careful.
A
If
you
don't,
you
know
clobber
on
accent,
so
that's
something
I
ran
into
so
final
note
on
container
images.
Something
I
find
kind
of
fascinating
is
that
if
you
inspect
a
machine
for
architecture
yeah
with
Arch
or
you
name,
it's
different
than
the
what
I'll
call
normalized
architecture
that
containers
use
for
platform
metadata,
so
Upstream
code,
which
I
found
and
likely
your
own
image
building
code
will
need
logic.
Just
like
this.
That
translates
to
the
normalized
architecture
that
Docker
recognizes.
A
If
you're,
using
the
hosted
one
it'll
be
a
little
bit
more
talented
if
you're
running
your
own,
so
kubernetes
four
involves
for
doing
it
internally,
updating
the
infras
code,
updating
the
binaries,
creating
multi-arch
images,
it's
pretty
much
all
the
same
tools
we've
already
developed,
but
for
kubernetes
specifically,
so
the
main
thing
I
noticed
about
this
is
that,
at
least
for
us.
We
need
to
build
a
lot
of
multi-arch
images
and
I'll.
A
Tell
you
why
so
a
quick
recap
on
a
kubernetes
pod
who
here
actually
uses
sidecar
containers,
okay,
cool
a
lot
of
you
well,
so
the
downside
of
that
is
that
you
know
it's
like.
Oh,
we
just
need
to
run
Java
on
arm.
Okay,
it's
Javas!
That
should
be
easy.
You're!
Like
oh
wait.
You
know.
Let's
look
at
our
kubernetes
pod,
all
right.
A
We
have
all
these
sidecar
containers
so
for
each
of
these
we
actually
need
those
containers
as
well
to
build
on
arm
and
to
upload
a
multi-arch
manifest
okay,
oh
and
then
for
those
of
you
who
aren't
familiar
with
Sally
Cars.
It's
just
like
a
way
to
run
common
logic
like
observability
and
security
Etc
in
its
own
container.
A
Okay,
so
also
on
the
Node,
we
have
a
lot
of
PODS
running
that
do
kubernetes
logic
like
cluster
scheduling,
cni
other
third-party
functionality,
internal
functionality.
So
these
also
all
have
to
be
migrated
to
multi-arch
images
so
for
a
kubernetes
cluster
into
sport,
multi-arch
as
well.
We
need
each
node
to
pull
in
these
multi-arch
images
and
we
also
need
each
cluster
to
support
different
instance
types,
including
architecture
for
every
node.
A
A
Okay,
so
testing
out
the
new
arm64
nodes
also
requires
a
little
bit
of
careful
coordination.
Who
is
familiar
with
like
the
no
schedule
taint
you
put
on
a
node
cool
yeah.
So
it's
basically
just
that
you,
you
taint
the
node,
you
put
no
schedule
on
it
and
that
way
you
can
like
launch
and
test
on
this
node
and
kubernetes
won't
schedule
like
a
real
workload
onto
your
node
and
cause
chaos,
for
you
know
your
customers.
A
So
we
do
that
and
then
we
also
can
tag
the
nodes
and
the
auto
scaling
groups
and
things
with
the
right
metadata
and
that's
sort
of
how
we
actually
roll
it
out.
Okay.
So,
finally,
let's
talk
about
the
multi-arch
application
so
running.
A
multi-arch
application
requires
reproducible
arm
64
build
for
performance
testing,
which
I
mentioned
at
the
very
beginning,
as
well
as
updating
the
application
itself
to
run
on
arm
64.,
so
that
could
include
Library
dependencies.
So
we
limited
the
scope
of
the
application
work
by
focusing
on
Java
Services.
A
A
So
much
of
this
application
work
is
focused
on
achieving
Superior
performance.
We
have
a
tight
feedback
loop
between
a
performance,
engineer,
who's,
building,
testing
and
running
analysis
on
an
arms
64
build.
They
then
share
findings
with
a
cross-functional
group
which
uses
the
feedback
to
update
the
build.
Now
that
this
work
does
not
fully
depend
on
arm
64.,
we
actually
invested
a
little
bit
in
a
reproducible
build,
so
we
didn't
have
to
depend
on
all
this
internal
infrastructure
being
built
just
a
performance
test,
and
so
that
way
we
could
parallel
parallelize
these
tracks
at
work.
A
So
one
example
early
on
is
the
performance
engineer,
tries
to
build
the
application,
but
a
library
fails
to
build.
The
application
engineer
looks
into
it.
They
upgrade
the
binary
farm64
support
and
then
the
proof
engineer
can
try
again
so
once
it's
building
the
prevention
year
runs
in
arms
before
it
made
the
third
party
provides
and
they
share
lots
of
analysis.
The
third
party
infrastructure,
engineer,
Narrows
down
performance
issue,
updates
their
images
and
provides
new
instructions.
So
the
performance
work
was
pretty
much
just
very
iterative
like
this.
A
So
that's
actually
it
so.
Here's
a
summary
of
how
we're
doing
multi-archy
Airbnb,
like
I,
said
before
the
actual
work
fairies,
depending
on,
if
you're,
using
third
parties
versus
running
your
own
for
a
lot
of
the
infrastructure.
We
talked
about
the
prerequisites,
the
multi-arch
infrastructure,
the
kubernetes
work
and
then
the
actually
application
work.
A
And
here's
the
takeaways
so
arm
64
is
in
the
cloud,
it's
in
all
the
clouds
and
it's
cheaper
and
that's
why
we're
doing
the
work?
It's
not
an
All
or
Nothing
migration.
So
we
focused
on
a
single
workload.
Focus
on
the
capability.
Don't
try
to
migrate
everything,
but
you
probably
need
to
upgrade
and
update
all
the
things
which
you
probably
want
to
do
anyway.
In
order
to
get
arms
for
support,
build
all
the
things
multi-arch.
A
That
was
the
binaries,
the
images
the
builds
and
invest
in
performance,
tooling
and
Analysis
quick
shout
out
to
the
folks
at
Airbnb
who
helped
work
on
this
very
valuable
team
effort.
And
if
you
want
to
join
the
team,
go
to
airbnb.com
careers,
you
can
also
reach
out
to
me
on
Twitter.
That's
all
I
have
thank
you.