►
From YouTube: What is Cloud Native and Why Should I Care?
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello
and
welcome
to
this
on-demand
webinar
from
the
cloud
native
computing
foundation.
My
name
is
jamie
dobson.
I
am
the
co-founder
and
chief
executive
of
container
solutions.
Solutions
is
a
professional
service
firm
that
specializes
in
cloud
native
and
cloud
native
transformation.
We
are,
of
course,
members
of
the
cncf
before
we
begin
the
webinar.
Let
me
just
bring
your
attention
to
the
cncf's
website.
A
It's
here
that
you
can
find
out
different
information
about
certification
projects
and,
of
course,
all
the
amazing
open
source
projects
that
are
governed
by
the
cncf.
If
you
look
down
here,
you
can
see
the
sandbox
projects,
the
archive
projects
and,
of
course,
the
cloud
native
trail
map
if
you're
interested,
there's
also
the
interactive
landscape.
A
The
cncf
is
a
force
for
good
in
our
community.
It
brings
together
both
end
users
and
individual
contributors,
so
without
any
further
ado,
let's
now
move
from
that
little
plug
for
the
cncf
and
this
wonderful
website
of
theirs
and
get
into
our
webinar
over
here,
on
the
left
hand,
side
with
a
different
set
of
slides.
A
A
If
you're
on
your
journey
or
are
about
to
start
your
cloud
native
journey,
you
do
not
need
to
make
these
classic
mistakes
because
wealth
grid
has
made
them
already
for
you.
After
that,
we're
going
to
look
at
what
is
cloud
native.
Can
we
settle
on
a
definition,
and
can
we
look
at
cloud
native,
not
just
from
a
technical
point
of
view,
but
also
from
a
cultural
and
a
teaming
point
of
view?
A
And
finally,
the
third
thing
we're
going
to
look
at
is
a
number
of
different
tools
that
will
help
you
on
your
cloud
native
journey.
So,
on
the
one
hand,
this
talk
is
philosophical,
but
on
the
other
hand
it's
also
hugely
practical,
so
fingers
crossed.
You
can
learn
a
little
bit
about
what
cloud
native
is
and
pick
up
some
tools,
techniques
and
tricks
that
are
going
to
help
you
get
there
with
your
team
or
with
your
company.
A
All
great
literature
is
one
of
two
stories
so
said:
tolstoy
a
man
goes
on
a
journey
or
a
stranger
comes
to
town.
So
the
question
is:
which
story
is
the
story
of
wealth
grid?
Well,
let's
meet
them.
Shall
we
wealth
grid?
Is
a
mid-sized
firm,
it's
profitable!
It's
a
nice
place
to
work,
it's
probably
about
20
or
30
years
old.
Maybe
it's
a
bit
conservative.
A
Maybe
it's
a
bit
stuffy,
but
they've
got
product
and
service
market
fit,
so
all
of
the
startups
out
there
would
love
to
be
where
wealth
could
are
today.
Wealth
grid
is
made
up
of
a
cast
of
characters.
On
the
one
hand,
we've
got
steve
the
chief
executive
now
steve
cares
about
a
few
things.
One
of
them
is
getting
features
into
the
hands
of
their
customers.
You
know
reasonably
regularly
recently
steve's
learnt
about
a
new
acronym
or
a
new
phrase,
called
time
to
value.
A
That's
the
time
it
takes
from
an
idea
to
come
into
his
head
or
into
the
head
of
one
of
his
products,
people
into
the
hands
of
one
of
their
customers.
So
steve.
Naturally,
don't
we
all
wants
to
shorten
the
time
to
value
without
a
doubt,
steve
has
seen
what
cloud
native
applications
look
like
and
he
thinks
to
himself
well
if
those
companies
can
do
it.
Why
can't
we?
A
However?
It's
also
2021,
and
nowadays
we
are
pretty
unforgiving
when
it
comes
to
systems
going
down
if
you
serve
customers
and
especially
if
you
work
in
the
financial
sector,
if
you
serve
customers
online
and
your
system
stops
working,
this
can
very
often
be
front
page
news.
Steve
wants
to
stay
off
the
front
page
news
and
he
wants
to
stay
out
of
the
headlines
in
the
evening.
He
definitely
wants
to
avoid
being
having
system
failures
pointed
out
on
social
media
such
as
twitter
and
linkedin.
A
Now
jenny
shares
a
lot
of
steve's
ambitions
and
goals.
She
definitely
wants
to
shorten
time
to
value
right,
unfortunately,
or
not,
unfortunately,
but
put
a
different
way.
She
wants
to
sort
out
time
to
value.
She
also
wants
to
stay
off
the
front
page
of
the
news,
but
she's
also
got
a
different
set
of
duties,
because
she
also
has
to
help
her
engineers
develop
in
their
careers,
reach
their
ambitions
and,
of
course,
she
needs
to
help
them
satisfy
their
curiosity,
to
explore
new
technologies.
A
The
engineers,
exactly
like
jenny
and
steve,
also
care
about
time
to
value
they've
also
heard
about
this
thing
called
the
cloud
they've
heard
about
kubernetes
and
their
curiosity
is
super
peaked
right
now
together.
They
think
that
clown
native
could
be
a
way
to
shorten
time
to
value
and
to
stay
out
of
the
newspapers.
A
A
A
They
moved
to
what
we
would
call
devops,
10
or
12
years
ago,
and
then
nowadays
are
very
active
with
public
cloud
kubernetes
containerization.
What
we
would
call
cloud
native
ing
knew
what
everybody
knew
back
then
they
knew
that
the
internet
and
cloud
technologies
would
change
the
way
we
produce
applications.
A
The
difference
is
ing,
acted
on
the
strategic
insight.
By
doing
so,
they
managed
to
win
two
separate
wars.
The
first
war
that
they
won
was
the
war
for
users,
their
digital
products,
their
mobile
app
their
tablet.
Application
is
absolutely
beautiful.
Once
they
started
producing
to
produce
these
amazing
digital
products,
all
of
a
sudden,
they
started
attracting
users
and
new
customers.
A
A
A
What's
remarkable
is
they
went
from
being?
They
went
from
having
no
bank
in
january
2016
when
they
raised
70
million
in
funding
to
having
a
fully
functional
bank
only
one
year
later.
They
were,
of
course,
able
to
do
this.
For
numerous
reasons,
a
strong
vision,
a
powerful
executive
team,
but
they
could
build
on
cloud
and
cloud
native
technologies,
they
could
consume
the
public
cloud
and
by
doing
that,
they
could
get
the
scalability
and
the
reliability
that
they
needed
to
launch.
A
The
third
type
of
stranger
that
really
scares
jenny
and
steve
is
the
stranger
they
cannot
see
coming
so,
for
example,
kodak.
The
film
company
was
not
destroyed
by
its
main
competitor
fujifilm,
but
rather
kodak
were
destroyed
by
an
alternative
way
to
share
photographs,
myspace
email
and
then
later
facebook,
twitter
and
whatsapp.
A
A
A
A
A
She
does
this
through
the
normal
way
of
working
six
to
12
months
later,
but
in
reality,
it's
often
more
like
18
to
24
months
later,
they're
stuck
the
backlog
is
still
quite
full,
and
these
cloud
native
tasks
or
tools
are
actually
still
in
there,
with
only
a
number
of
features
and
new
parts
of
the
product
becoming
cloud
native
and
moving
over
to
the
delivery.
The
delivered
side
of
their
work
what's
happened.
A
It
was
a
little
bit
harder
than
jenny.
Originally
thought.
Okay,
this
is
the
second
wake-up
call.
This
stuff
is
not
business
as
usual.
This
is
not
the
same
as
changing
from
one
programming
language
to
another,
but
it's
a
whole
other
way
of
thinking
and
a
whole
other
way
of
working.
No
problem.
Jenny
knows
how
to
deal
with
this.
A
She
works
with
steve.
Steve
was
a
little
bit
miffed
about
the
first
failure,
but
okay,
we've
learned
lessons
and
we're
moving
forward
together.
They
come
up
with
a
more
structured
plan
and
the
structured
plan
says
something
along
the
following:
we're
going
to
build
a
cloud
native
platform
team,
we're
going
to
take
some
of
our
most
creative
and
productive
engineers
and
pop
them
into
a
cloud
native
platform
team.
A
A
The
building
of
the
cloud
native
platform
was
really
a
lot
harder
than
anybody
could
have
imagined
now,
because
the
platform
stalled
out
so
too,
as
the
feature
backlog,
not
least
because
the
creative
power
of
the
engineering
team
were
split
into
two.
So
it's
not
just
that
this
new
way
of
working
was
difficult,
but
the
engineering
capacity
has
simply
not
changed.
A
Why
is
this
so
difficult?
Well,
simply
put
they've
never
done
cloud
native
before
this
is
what
most
people
think
of
when
they
think
of
clown
native.
They
think
it's
somehow
to
do
with
architecture.
So,
for
example,
a
company
might
have
a
tightly
coupled
monolith
in
the
last
10
years.
They
might
have
broken
that
monolith
up
into
a
range
of
client
applications
each
consuming
similar
services,
so
the
mobile
application
might
consume
the
same
backend
services
as
the
web
application
and
it's
a
logical
progression
to
think
hey.
A
A
A
So
if
we
start
up
at
the
top
of
the
maturity
matrix,
you
can
see
something
along
these
lines.
You
have
excuse
me,
sorry.
If
you
look
at
the
top
of
the
matrix,
you
see
that
we
collaborate
a
lot.
What
does
this
even
mean?
Well
in
cloud
native?
We
collaborate
very
differently
to
how
we
usually
collaborate
in
large
organizations.
A
So,
for
example,
different
teams
might
look
after
one
or
a
collection
of
microservices.
Now,
other
teams
will
consume
what
come
out
with
what
comes
out
of
your
services.
Now.
What
they
can
do
is
if
they
want
changes
or
if
they
want
updates,
they
might
submit
a
change
request
to
you.
Alternatively,
they
might
submit
a
pull
request.
They
might
actually
fork
your
repo,
build
it
and
then
submit
a
pull
request
back.
A
A
We
also
design
our
products
differently,
so
we're
not
just
thinking
about
feature-driven
product
development,
but
we're
thinking
about
data-driven
product
development.
We
do
things
like
a
b
testing.
We
test
a
version
of
a
feature
on
one
set
of
users.
We
test
a
variant
on
another
set
of
users
and
whichever
variant
works
best
is
the
one
that
will
integrate
into
the
product.
This
is
one
of
the
ways
in
which
products
live
and
evolve,
along
with
users
needs
and
aspirations.
A
The
way
we
build
products
and
we
design
products
is
radically
different
in
cloud
native
and
because
of
this
and
the
way
we
collaborate,
it's
extremely
powerful,
this
collaboration
model
and
this
design.
The
way
we
design
products
in
cloud
native
is,
of
course,
supported
by
the
technology,
kubernetes
containers
and
those
methods
of
rapid
software
development.
A
Usually
we
have
platform
teams
and
we
adopt
either
a
devops
or
an
sre
mindset.
This
is
radically
different.
This
is
what
wealth
grid
discovered.
The
same
type
of
people
who
used
to
build
products
at
wealth
grid
are
not
exactly
the
same
type
of
people
who
would
build
products
in
the
new
cloud
native
wealth
grid.
They
have
got
missing
capabilities
and
they've
got
a
missing
mindset
for
most
people
out
there,
for
example,
here
in
london
today,
most
people
don't
want
to
run
what
they
built.
A
They
want
to
build
it
and
let
somebody
else
run
it,
but
this
is
different
when
it
comes
to
cloud
native
as
a
heuristic
or
rule
of
thumb,
we
say
the
following:
if
you
build
it,
you
run
it
all
of
these
different
practices.
Heuristics
and
technologies
work
together
to
produce
what
we
call
cloud
native,
it's
not
as
simple
as
containerizing
a
few
apps
and
chucking
them
on
a
cluster
and
chucking
them
up
into
the
cloud.
A
A
A
A
She
might
have
also
discovered
our
cloud
native
transformation
patterns,
so
what
we've
done
in
the
last
five,
six
or
seven
years
is
we've
been
studying
companies
that
both
failed
with
cloud
native
and
who
succeeded
with
cloud
native
and
it
turns
out
there
are
over,
at
least
over
110
different
patterns.
These
are
our
patterns
collected
on
cards.
This
one
is
a
proof
of
concept.
A
This
one
is
about.
No
regrets
moves.
How
do
you
make
a
move
in
the
cloud
native
space
or
with
your
cloud
native
strategy
that
yield
no
regrets,
and
it
turns
out
that
these
patterns
reoccur
frequently
often
they
come
from
making
mistakes.
So
all
of
a
sudden
jenny
starts
to
view
cloud
native
transformation
radically
differently.
A
So
what
does
she
learn
about
patterns?
What
does
she
pick
up
here?
Let's
talk
about
patterns
for
a
few
minutes,
so
a
pattern.
Language
is
essentially
a
collection
of
design
decisions,
so
you
can
think
of
a
pattern
as
a
word
in
a
dictionary
table
chair
sofa.
These
are
words
that,
for
example,
were
taken
from
a
furniture
pattern.
Language
now
take
a
look
at
the
left.
A
All
three
of
these
things
are
instantly
recognizable
as
tables
and
yet
they're
instantly
recognizable
as
being
completely
different.
This
is
one
of
the
unique
features
of
patterns
or
design
patterns.
They've
got
this
very
strange
and
peculiar
feature
baked
into
them
that
something
can
be
obviously
something
a
table,
whilst
being
obviously
very
different
from
other
implementations.
A
In
that
sense
patterns
are
implementation,
free,
they
don't
say
anything
about
how
you
should
implement
them.
When
you
bring
these
words
together,
you
have
a
language.
This
is
a
furniture
language.
The
language
in
our
book
is
a
cloud
native
transformation
pattern,
language
and
you
build
designs
by
writing
stories.
So,
for
example,
there
is
a
square
table
with
four
chairs
and
a
sofa
in
a
room.
This
is
the
design
of
a
room
based
on
the
furniture
pattern.
Language
now
I
did
say
that
patterns
were
implementation
independent.
A
A
So
in
summary,
then,
what
is
a
cloud
native
transformation
pattern,
language,
it's
very
simple:
it's
a
collection
of
design,
decisions
about
cloud
native
practices
and
technologies
and
the
context
in
which
they
work
right.
That's
really
really
important
patterns
are
a
bridge
between
experts
and
novice
users,
and
the
bridge
comes
through
the
context.
So,
for
example,
there
are
contexts
out
there
where
public
cloud
is
not
a
suitable
pattern.
You
need
to
understand
both
the
pattern
and
the
context
in
which
it
works.
A
A
A
This
is
the
companion
website
to
our
pattern:
language,
it's
free,
it's
also
open
source,
so
you
can
copy
this
and
use
this
for
them,
for
whatever
purposes
you
have,
the
first
page
just
gives
you
an
introduction,
no
problem.
Let's
now
pick
a
pattern.
Well
in
the
pattern
language,
it
turns
out
that
there
are
four
key
categories:
strategy
and
risk
reduction
organization,
culture,
infrared
cloud,
development
and
design.
A
The
categories
are
not
so
important.
Only
to
tell
you
that
you
know
this
stuff's
reasonably
complicated.
Let's
just
pick
a
pattern,
it
doesn't
matter
which
one
we
pick.
Let's
pick
strategy
and
risk
reduction.
Now
here
you
see
a
number
of
different
patterns,
big
bet,
learning,
loop,
objective,
setting
and,
of
course,
the
classic
business
case.
A
So
here
you
see
the
structure
that
I
just
shared
in
the
main
slide.
You
see
an
introduction
before
launching
a
cloud
transformation
and
enterprise
leadership
must
make
sure
the
initiative
is
needed
and
the
benefits
justify
the
investment,
and
then
we
keep
scrolling
down
this
pattern
works
in
the
following
context,
therefore,
and
consequently
the
concept,
the
context
in
which
this
works
is
cloud
native
transformations
are
a
big
commitment
and
they
require
significant
investment
of
budgeting
time
too
many
organizations
get
caught
up
in
the
hype
of
cloud
conversion.
A
If
you
are
caught
up
in
the
hyper
clock
conversion
or
if
this
context
speaks
to
you,
then
the
business
case
cloud
native
transformation
pattern
could
be
useful
for
you.
A
So
the
first
time
jenny
tried
to
do
this
was
as
follows:
she
split
she
put
kubernetes
cloud
native
and
microservice
onto
what
we
could
call
the
proficient
or
business
as
usual
work
streams.
This
was
the
first
failure,
the
second
time
jenny
did
something
different.
She
reversed
this.
She
put
a
lot
of
energy
and
she
took
a
lot
of
her
creative
people
and
put
a
tremendous
amount
of
creative
energy
into
building
this
cloud
native
platform.
A
The
idea
was
that
that
creative
thinking
would
lead
to
a
platform
that
was
easy
to
onboard
to
and
therefore
the
productivity
gains
from
the
platform
would
be
reflected
in
business
as
usual
and
features
would
come
out
at
exactly
the
same
rate
or
better
still,
even
quicker
than
they
used
to.
This
was
a
second
classic
mistake.
A
A
A
These
three
things
are
what
are
needed
in
order
to
create
the
right
leadership.
Alignment
on
the
wealth
grid
side
they've
got
nothing
to
do
with
technology.
That's
very
important
that
we
notice
that
what
they're
actually
doing
is
showing
the
cloud
native
transformation
for
what
it
is
something
radical.
So
when
we
talk
about
change,
we
think
about
changing
one
thing
for
another
cloud
native
is
not
a
change
to
your
organization,
it's
an
utter
transformation
in
how
you
think
and
how
you
work
and
how
you
build
digital
products.
This
is
why
it's
so
hard.
A
The
next
part
is
all
about
the
strategy.
What's
the
vision
that
we
want,
where
do
we
want
to
be
as
a
company?
What
do
we
value?
Do
we
value
safety?
Do
we
value
risk?
Do
we
value
learning
as
we
go?
Do
we
want
to
hire
the
right
people,
or
do
we
want
to
train
our
own
people,
all
very
sensible
business
questions
that
must
be
asked
and
they
must
be
answered
on
the
back
of
this.
A
We
get
something
like
a
transformation
strategy
and
not
wanting
to
make
the
same
mistake
that
they
made
earlier
wealth
grid
now
think
about
their
world
in
two
different
ways.
They
think
about
the
proficient
use
of
their
people
and
their
technologies,
but
they
also
realize
that
to
do
something.
Transformative
requires
great
creativity
down
on
the
creative
side
of
their
work,
they're
looking
into
things
like
exploratory
experiments,
proof
of
concepts
minimal,
viable
products.
A
A
Of
course,
there
is
a
connection
between
these
two
work
streams,
but
when
we
onboard
our
applications
to
the
cloud
we
want
to
do
it
repeatedly
safely
and
in
a
way
where
we
learn
as
we
go
onboard
into
a
cloud
platform
can
be
mechanical
together.
These
two
worlds
start
to
come
together.
The
platform
evolves,
our
proficient
teams
know
how
to
onboard
to
it,
and
then
we
start
to
gradually
bring
different
applications
and
different
teams
onto
the
cloud
native
platform.
A
A
Gradual
onboarding
is
once
again
another
pattern
that
helps
you
reduce
the
risk
and
therefore
reduce
the
cost
of
change
now.
You'll
notice
that
this
is
very
systematic.
This
is
not
the
type
of
natural,
quick
ramp
up
to
the
cloud.
That's
often
followed
by
a
quick
ramp
down.
This
is
systematic.
This
is
planned,
this
is
careful
and
when
the
rubber
hits
the
road,
it's
gradual
and
it's
iterative.
A
This
is
not
done
at
the
beginning.
You
cannot
get
your
credit
card
out
and
move
your
landscape
to
amazon
web
services
and
say
now
we're
cloud
native,
because
you're,
not
all
you've
done,
is
moved
a
lot
of
applications
over
here
to
a
lot
of
applications
over
there.
You
will
not
reap
the
benefit
of
evolutionary
design
and
you
will
definitely
not
reap
the
benefit
of
these
amazing
tools,
such
as
kubernetes
and
all
the
tools
that
you'll
find
up
on
the
cncf's
website.
A
How
does
this
happen
practically
right,
so
you
were
like
jenny.
You
want
to
get
cracking.
What
do
you
do
well?
This
is
you
know
this
might
sound
low
tech,
but
actually
you
grab
the
cards
and
you
throw
them
on
the
table
and
you
talk
about
it.
What
should
come
first
in
your
organization,
the
the
transformation
plan
or
the
transformation
strategy
is
not
setting
stone.
It's
a
way
to
discuss
what
might
happen
traditionally
one
second,
please
I'll,
show
you
something.
A
A
It
comes
from
first
year
business
school
when
you
plan
different
ways
of
working
or
different
futures,
you're,
doing
something
called
scenario
planning
and
what
you
do,
then,
is
you
look
at
the
scenarios
that
are
most
useful
or
most
probable
and
you
throw
the
other
scenarios
away.
It's
it's
in
exactly
this
way
that
we
can
plan
with
the
whiteboard
or
on
the
table
in
one
hour
what
some
companies
take
one
year
to
discover
on
their
own.
A
So
when
it
comes
to
strategy,
you
must
never
ever
spend
time,
building
and
planning
scenarios
and
discovering
scenarios
what
you
could
have
realistically
discovered
on
a
tabletop
with
with
a
bunches
of
with
with
pieces
of
paper.
This
is
the
section
of
the
book.
This
is
known
as
scenario
planning
for
anybody,
who's
interested
in
strategy
and
strategic
execution.
You
can
google
that
now,
unfortunately,
scenario
planning
with
the
patterns,
even
though
it's
very
cheap
has
been
quite
difficult
to
do
during
the
pandemic.
A
So
let
me
now
introduce
you
to
a
new
version
of
this
tool,
which
is
our
interactive
platforms,
mural
whiteboard,
so
you
will
once
again
see
all
the
different
patterns,
the
first
set
around
strategy
and
risk
reduction,
and
there
we
can
see
our
friend
again
the
business
case
there.
He
is
right
here
I
can.
I
can
select
that
business
case
and
to
the
right
of
that
vision.
First,
objective
setting
for
all
of
you
who
work
in
business.
A
As
I
said
earlier,
the
strategy
you
produce
is
not
set
in
stone,
but
it
lets
you
and
your
teammates
reason
about
effects
and
build
a
strategic
plan
that
works
for
you
and
your
cloud
native
transformation.
By
doing
this,
you
can
avoid
the
expensive
mistakes
that
jenny
and
the
team
at
wealthgrip
made
back
to
the
presentation.
A
A
It's
about
8
to
20..
80
of
all
engineering
effort
is
on
new
features
and
testing
engaging
with
users,
but
we
still
dedicate
15
to
20
of
our
time
on
creative
ideas,
a
a
and
b
variants
and
new
concepts.
We
use
design
thinking
to
get
inside
users
heads,
but
because
we
have
linked
the
way
we
design
products.
With
this
amazing
ability
to
rapidly
deploy
new
features.
A
A
No
we've
now
got
a
system
of
innovation.
We've
got
a
way
to
understand
users
to
meet
their
needs
and
to
do
it
quickly.
So
when
you
zoom
out
far
enough,
you
start
to
see
cloud
native,
not
just
as
provisioning
and
containers,
but
it's
a
whole
system
of
innovation
when
it
comes
to
digital
products.
It's
this.
That
makes
it
so
exciting,
and
it's
this
that
will
give
wealth
grid
an
amazing
competitive
advantage
over
their
rivals
in
their
space.
A
A
So
if
you
would
like
further
tools
or
tricks
or
tips
to
help
you,
you
can
sign
up
to
our
newsletter
here.
You
can
of
course,
sign
up
to
the
cncs
newsletter
too,
and
you
can
subscribe
there
or
or
click
the
qr
code,
and
every
month
you
will
get
delivered
to
your
inbox,
new
ideas,
new
concepts
and
they're.
All
designed
to
do
the
same
thing
avoid
you
making
classic
mistakes.
A
You
can
also
grab
the
patterns,
they
appear
on
our
website
and
they
also
appear
in
our
book
and
speaking
of
the
book.
You
can
now
get
this
for
free,
it's
available
on
our
website
or
by
scanning
that
qr
code.
Everything
we
discussed
today
is
freely
available
at
the
companion
website
or
through
our
website,
which
you
can
follow
down
to
the
left
or
follow
by
clicking
on
the
qr
code.
A
A
Thank
you
for
listening.
I
hope
you've
enjoyed
this
on-demand
webinar
from
the
cncf
about
cloud
native
and
cloud
native
transformation,
and
I
hope
to
see
you
all
again
and
best
of
luck
with
your
journey
and
best
of
luck
with
whatever
comes
next
for
you
during
the
pandemic,
stay
safe,
wash
your
hands,
wear
the
mask.