►
From YouTube: Keynote: The Cloud Native Journey @Apple - Alena Prokharchyk, Software Engineer, Apple
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
Keynote: The Cloud Native Journey @Apple - Alena Prokharchyk, Software Engineer, Apple
If you want to evolve your applications, services and user experience around Cloud Native technologies, then adaptability is key. Apple identified the ecosystem’s potential early on, and worked hard to adopt the technologies to support the scale and variety of use cases necessary for Apple’s adoption. This talk will cover Apple’s Cloud Native journey and what it took to build a Kubernetes offering that focuses on Privacy, Security, Multi-Tenancy and Scale. - Why Cloud Native at Apple? - Why we migrated from Mesos to Kubernetes? - Technical challenges faced and solutions applied - Testing things at scale: operational challenges and collaboration with the community - Cloud Native ecosystem projects we leverage, such as etcd and containerd
https://sched.co/eoDx
A
Hello,
everyone,
my
name
is
alina
and
I
work
for
apple.
I
joined
the
company
as
a
software
engineer
about
a
year
ago
to
work
on
kubernetes
and
cloud
native
projects
since
then.
So
many
people
from
the
open
source
community
have
asked
me
what
attracted
me
the
most
to
my
new
job,
and
the
answer
is
easy.
It
is
the
scale
of
the
cloud
infrastructure
and
the
variety
of
applications
running
on
it
before
I
mainly
focus
on
kubernetes
clusters
provisioning.
A
A
Messes
has
been
used
at
apple
for
over
five
years,
with
an
internally
built
container
orchestrator
called
jrvis.
It
had
a
good
reputation
as
a
scheduling
platform
and
it
scaled
well
to
support
multiple
frameworks
for
running
a
variety
of
services
like
bich,
stateful
and
stateless,
but
the
container
orchestrator
soon
became
a
bottleneck
for
skills
and
responsibilities
delegation.
So
we
started
considering
other
choices
in
addition
to
messes
apple
used.
Some
other
solutions
for
compute
management,
along
with
the
transition
we
wanted
to
consolidate
them
and
provide
the
unified
platform
for
better
capacity
utilization.
A
A
We
knew
that
it
was
just
a
plug-in
choice
and
the
choice
could
always
be
reevaluated
without
refactoring
the
entire
system.
Another
big
point
of
attraction
for
developers
was
an
ability
to
extend
kubernetes
apis
and
core
functionality
by
leveraging
crds
and
custom
controllers.
The
kubernetes
community
was
a
huge
asset
to
the
platform.
A
Its
transparency
and
power
was
so
obvious
and
provided
a
great
level
of
comfort
to
developers.
The
goal
was
to
meet
the
demand
of
diverse
user
base.
We
had
teams
who
were
already
successfully
running
kubernetes
clusters
in
their
organization,
and
we
had
people
who
had
never
worked
with
kubernetes
before
but
trusted
the
technology
and
wanted
to
adopt
it.
A
A
All
the
platform
features
that
were
built
in
the
past
had
to
be
reevaluated
is
the
features
current
design
aligned
with
the
cloud
native
best
practices.
Is
this
feature
even
relevant
to
the
new
platform?
Asking
and
answering
these
questions
can
be
uncomfortable
for
people
and
software
is
built
by
people.
We
had
to
accept
the
fact
that
there
would
be
a
need
for
a
change
to
the
current
processes
and
people
would
have
to
adapt.
A
A
A
A
A
So
we
have
this
big
infrastructure.
Pool
of
compute
and
storage
resources
managed
by
kubernetes,
providing
it
to
users
can
be
done
in
two
ways:
cluster
as
a
service
and
namespace
as
a
service
namespace
as
a
service
is
our
primary
model.
Today,
sre
manages
multi-tenant
kubernetes
clusters
and
user
operates
in
one
or
multiple
namespaces.
A
A
A
The
system
would
do
a
dynamic
balancing
between
clusters,
priority
usage
and
limits
to
find
the
best
placement
for
the
user
application
resource
isolation
would
be
handled
by
assigning
priority
and
quarter
to
each
workload.
However,
we
still
had
to
address
privacy
and
security
concerns
of
running
applications
in
multi-tenant
clusters.
A
A
Solving
these
technical
challenges
would
not
have
been
possible
without
the
wide
array
of
cloud
native
tools,
those
we
use
on
the
platform
level
and
those
we
recommend
to
application
developers.
This
list
is
not
complete
and
keeps
on
growing
as
we
constantly
evaluate
new
projects
and
find
more
areas
for
development
and
integration
with
all
the
careful
planning.
Only
running
things
at
scale
could
reveal
certain
issues.
We
have
chosen
open
source
kubernetes
per
test
cluster
loader
tool
to
challenge
our
clusters.
A
A
Another
area
of
immediate
focus
was
scheduling.
We
run
mixed
types
of
workloads
on
kubernetes,
including
watch
workloads
and
want
to
maintain
a
reasonable
resource.
Utilization
participating
in
six
scheduling
and
contributing
back
is
very
important
to
us
as
we
want
to
stay
as
close
to
the
upstream
as
possible
for
some
people
in
our
team
it
was
their
very
first
experience
contributing
to
upstream
kubernetes,
going
through
the
process
of
joining
sick
for
discussions
filing
first
kubernetes
issues
and
recognizing
the
various
ways
to
help
the
community.
It
was
all
new
and
exciting.
A
A
We
are
seeking
to
enable
this
level
of
isolation
with
micro
vms,
with
that
multiple
untrusting
tenants
can
run
on
the
same
nodes
and
share
the
same
control
plane,
while
continuing
to
provide
two
layers
of
isolation.
Virtual
machine
and
container
cluster
as
a
service
comes
with
the
cost
of
increased
security
management,
resource
utilization,
inefficiency
and
operational
burden
in
the
companies
of
apple
scale.
A
It
eliminates
the
majority
of
security
and
operational
concerns
with
the
deployment
footprint,
growth
and
distribution
across
data.
Centers
comes
the
demand
for
multi-cluster
workload
management.
We
are
researching
on
api
proxy
solution
to
offer
improved
self-healing
utilization
efficiency,
high-level
abstractions
and
developer
workflow
experiences
for
teams
that
manage
workloads
across
multiple
clusters.
A
A
With
the
constant
additions
of
the
new
features
and
user
workloads,
observability
becomes
one
of
the
top
priorities.
We
want
to
keep
the
platform
management
same
as
the
platform
growth,
end
user
productivity
and
happiness
is
our
end
goal.
We
are
always
looking
into
ways
to
improve
it
with
compiling
ci,
cd
and
developer
tooling.
A
Adopting
new
technology
on
such
a
big
skill
often
comes
hand
in
hand
with
organizational
changes.
You
need
to
change
everything
and
everyone
from
managers
in
finance
to
tech
teams
and
yourself.
It
is
a
long
road.
With
a
lot
of
growing
pains,
our
security
team
grew
and
took
on
extra
responsibilities.
A
Insurance,
security
and
multi-tenant
cluster
is
not
a
trivial
task.
We
had
to
have
a
clear
separation
of
concern
between
application,
security
and
kubernetes
platform
security.
To
maintain
a
shared
responsibility
model,
one
of
our
goals
was
to
rethink
capacity
planning
having
a
dedicated
resource
management
team
working
close
with
the
finance
department
was
necessary.
A
Some
new
teams
were
formed,
some
grew
in
size
and
responsibilities
and
some
developed
a
new
set
of
priorities.
Sre
team
used
to
be
more
operational
and
systems
focused.
Now
it
has
an
emphasis
on
engineering
and
a
much
stronger
voice
in
the
platform.
Architectural
design
having
a
solid
and
stable
platform
made
it
possible
to
maintain
focus
on
the
customer's
needs
and
innovate.
Faster
innovation
is
impossible
without
collaboration
forming
a
cross-team
technical
review
board
for
cloud.
Native-Based
projects
was
invaluable
to
us.
It
is
a
safe
place
to
get
peer
feedback
from
people
having
different
backgrounds.
A
A
A
The
ongoing
transformation
leaves
a
very
little
time
for
reflection,
but
the
reflection
is
always
necessary.
Migration
is
not
something
everyone
wants
to
do,
but
those
who
invest
in
the
modernizing
their
application
and
a
platform
benefit
in
the
future
by
adopting
more
cloud-native
technologies.
On
top
of
the
foundation,
migration
at
scale
has
taught
us
to
embrace
the
community
best
practices
and
shared
learnings.