►
From YouTube: Complexity of the cloud native ecosystem by Mike Chenetz
Description
Sri Lanka has a growing group of Cloud Native enthusiasts, students, professionals, and technology leaders. KCD Sri Lanka offers a platform for this community to come together and connect with other tech communities in India and neighboring countries. It provides an opportunity to experience conferences like KubeCon / CloudNativeCon together with the rich cultural heritage of Sri Lanka.
A
Foreign
everyone
and
welcome
to
what
I'm
sure
is
going
to
be
an
action-packed
day:
I'm
Michael
chenitz
I'm,
the
head
of
technical
marketing
at
retainer,
IO
and
I'm,
going
to
talk
to
you
a
bit
today
about
adapting
Cloud
native
Tech
and
why
this
is
awesome,
but
also
needs
to
happen
with
eyes
wide
open.
Hopefully,
I
can
share.
Some
insights
picked
up
over
the
many
years
working
with
kubernetes
and
Cloud
native
Technologies,
my
backgrounds.
A
So
let's
talk
a
little
bit
about
disruption.
Oh
my
goodness!
What's
up
with
the
global
economy,
it's
unbelievably
expensive
right
now
the
cost
of
everything
is
so
high.
Gas
prices
are
out
of
this
world.
Seven
dollars
for
a
head
of
lettuce
come
on
running
a
business
is
equally
as
challenging.
Staff
are
demanding
higher
pay
lots
of
six
leave
to
navigate
business.
Travel
costs
are
through
the
roof.
Vc
funding
is
super
tight
and
the
number
of
companies
that
have
unfilled
vacancies
is
just
insane,
so
this
is
causing
terrible
service
across
so
many
areas
of
business.
A
Have
you
traveled
lately?
Have
you
seen
what
traveling
is
like
the
cost
of
this
consumers,
and
even
businesses
with
spare
money
are
spending
it
extremely
wisely
and
only
spending
it
with
companies
that
have
a
clear
point
of
differentiation
and
for
business
purchases
only
with
proposals
that
have
a
rapid
Roi?
A
So
that's
right,
there's
an
economic
squeeze
right
now.
It's
impacting
not
only
b2c
but
B2B.
Most
companies
I
speak
to
have
Frozen,
spend
on
All
Points
of
I'm,
sorry
on
all
non-essential
projects,
and
lots
have
put
hiring
freezes
in
place
with
this
competition
and
the
money
being
brutal.
At
present,
every
single
company
should
be
looking
at
how
to
serve
their
customers
and
asking
can
I
do
it
better?
A
A
A
Just
take
a
look
at
amazon.com
and
alibaba.com
thriving
is
the
new
hyper-competitive
global
economy
means
embracing
change
and
embracing
technology.
Every
single
business
owner
and,
in
fact
every
single
business
employee
should
be
thinking.
How
can
I
help
my
company
thrive
and
what
disruptive
Services
can
we
deliver
or
which
one
of
our
Legacy
Services?
Can
we
improve?
A
If
you
are
not
looking
at
what
your
competitors
Global
as
well
as
domestic,
are
offering,
then
you
are
already
in
trouble,
you
just
don't
know
it.
Yet
problem
is
there's
only
so
much
existing
teams
can
do,
and
so
all
this
information
needs
to
be
done,
while
constraining
while
construct
with
the
constraints.
How
can
you
embrace
the
new
now
without
incurring
substantial
costs
increments
in
people
or
tooling?
This
is
the
art.
A
So,
let's
get
down
to
it.
How
this
is
where
the
magic
of
cloud
native
comes
in
Cloud
native
is
quite
simply,
the
very
best
architecture
for
digital
disruption.
Cloud
native
defines
the
way
that
you
deploy
and
manage
applications
that
support
Digital
Services,
it's
more
than
just
the
technology.
It's
an
architectural
philosophy.
A
Fabs
take
the
very
best
from
what
we
have
learned
over
the
last
10
years
around
how
we
should
architect
build
support
and
scale
applications
and
cloudnative
lets.
You
start
small
scale
on
demand,
innovate,
discrete
components
and
due
to
that
nature,
build
with
extreme
efficacy,
no
need
for
heavy
servers,
expensive
proprietary
software
are
anything
like
that
cloud
native
defines
the
applications,
are
inherently
portable
free
from
vendor
lock-in
and
provides
versions,
extensible
apis
that
make
it
simpler
to
manage
resources
and
services.
A
It
doesn't
matter
if
you're
innovating
in
the
data
center
in
the
cloud
on
the
factory
floor,
Cloud
native
apps
help
you
build
fast,
learn
fast
and
improve
fast,
Cloud
native
apps.
Let
you
get
a
product
into
Market
in
the
fastest
possible
way,
because
you
can
launch
an
MVP
and
then
iterate
quickly,
thanks
to
a
microservices
based
architecture,
you
can
evolve
discrete
elements
of
your
service
based
on
user
feedback
adoption,
and
you
could
do
this
in
a
really
low
cost
manner.
Heck.
A
The
vast
majority
of
modern
CN
applications
are
based
off
open
source
components,
so
you
have
no
expensive.
Db
costs
no
expensive
application,
server
from
Top
tier
vendors
and
no
expensive
API
gateways.
All
this
is
made
with
reusable
and
free
components.
So
no
commitment
upfront
costs
to
try
out
crazy
ideas.
A
Okay.
So
now
what
to
go
all
in
in
Cloud
native,
you
need
to
consider
three
things:
one:
how
will
you
get
the
apps
you
need?
Will
you
build
them
yourself
or
or
will
you
buy
them?
How
will
you
get
the
yourself
a
platform
to
run
these
apps
on?
How
will
you
support
it,
update
it
and
triage
it?
How
will
your
users
deploy
it
and
how
will
you
get
your
application
Live
and
keep
it
live,
no
point
investing
an
awesome
app
if
your
platform
is
up
and
down
like
a
yoyo.
A
A
Trust
me,
even
if
something
is
90
good
enough
to
try
and
develop
your
own
application
that
meets
a
hundred
percent
of
your
needs,
will
cost
way
more
and
take
way
longer
than
you
expect.
There's
really
only
one
good
reason
for
building
versus
buying
it's
when
you're
disrupting
an
industry
and
your
technology
solution
would
be
your
primary
point
of
differentiation.
A
Here's
where
I
might
get
a
bit
jumbled,
but
pretty
much
any
system
of
record
should
be
procured,
as
the
risks
are
just
too
high
to
build.
Your
own
systems
of
differentiation
and
system
of
innovation,
however,
are
where
you
get
Choice
again.
If
you
were
just
wanting
to
want
an
e-commerce
site,
are
you
sure
that
Shopify
magenta
or
any
of
the
other
famous
engines
are
not
good
enough?
Customizable
enough?
Are
you
sure
that
you
want
to
reinvent
the
wheel?
A
It
might
be
better
to
spend
100
hours
customizing
an
off-the-shelf
app,
then
500
hours
building
your
own.
Unless
you
have
a
massive
in-house
development
shop
or
an
external
contract
development
house
I
would
not
even
begin
to
recommend
creating
something
from
scratch.
Heck
look
at
my
own
company
pertainer
we've
spent
over
10
million
in
two
years,
creating
a
kubernetes
management
tooling.
A
Most
devs
are
either
not
I'm
most
sorry,
most
devs
are
either.net
or
JavaScript
and
experience
building
either
web
apps
or
installable
apps
very
few.
In
fact,
we
probably
have
All
of
You
In
This
Very
Room,
develop
in
microservices
and
deploying
containers.
There
are
so
very
few
Cloud
native
devs
that
companies
elect
to
self-build
new
apps.
They
need
to
be
sure
that
they
can
recruit
and
retain
one
of
you.
A
If
you
cannot
attract
and
retain
Cloud
native
devs,
then
I
would
strongly
recommend
the
services
or
specialist
development
houses.
If
you
are
a
cloud
native
Dev,
congratulations
encourage
your
mates
to
learn
the
new
stack
okay.
So
now
you
have
selected
your
app
stack
and
you're
either
going
to
buy
or
build,
but
now
what
you
need
some
somewhere
to
run
this
stack
and
that's
somewhere
likely
end
up
being
a
container
platform.
A
Today
there
are
two
primary
container
platforms:
Docker
for
smaller
deployments
and
I
would
argue
for
development
and
kubernetes
for
everything
else.
Unless
you
have
been
living
under
Rock,
You
will
be
very
aware
that
kubernetes
and
its
ability
to
run
container
is
based.
Apps
is
in
a
highly
automated
way
across
on-prem
or
Cloud,
truly
unlocking
hybrid
cloud
and
removing
platform
lock-in
kubernetes
is
awesome
and
it's
really
simply
awesome.
A
It's
the
cleanest
way
to
run
modern,
I.T
stacks,
and
so
it's
something
we
all
need
to
get
comfortable
with,
but
neither
Docker
or
kubernetes
should
be
considered
a
platform
they're,
an
orchestrator
which
is
just
one
element
of
a
platform.
Kubernetes
is
no
more
of
a
platform
than
an
engine
in
a
car
than
the
engine
alone.
Won't
get
you
down
the
road
to
the
shops.
You
need.
You
need
a
car
for
that.
A
A
Platform
comprises
all
of
these
elements.
You
cannot
fully
Embrace
kubernetes
without
the
ability
to
triage
container-based
apps
view
logs
from
short-lived
and
highly
Dynamic
workloads
and
automate
The
Continuous
deployment
of
applications
running
an
app
in
kubernetes
is
useless
without
people
being
able
to
connect
to
it.
So
inevitably,
you'll
also
have
to
load
balancer
proxy
DNS
server
and
dynamic
SSL
search
to
manage.
A
So
when
someone
says
kubernetes
assume
they
mean
all
the
above,
it's
why
I
laugh
when
I
hear
people
saying
that
they've
adopted
kubernetes
have
decided
on
AKs
eks
and
have
made
no
consideration
for
the
additional
tooling
needed,
I'm
sure
you've
all
seen
the
cnncf
landscape,
it's
mind-boggling
number
of
members.
These
are
all
here
because
they're
an
ecosystem
that
surrounds
kubernetes
and
there
are
vendors
providers
of
the
tech
that
enable
the
platform
mentioned
prior.
A
You
need
to
be
super
careful
not
to
get
drowned
in
here,
though
so
much
choice
is
good,
but
it's
also
very
bad
with
all
that
choice.
How
do
you
find
the
good
from
the
average?
How
can
you
know
which
products
are
worthy
of
your
time
to
invest
pilot?
How
do
you
know
what
can
be
here
six
to
12
months
from
now?
There
are
a
lot
of
tools
that
have
been
here
donated
to
the
cncf,
because
their
original
creators
were
overwhelmed
at
the
cost
to
maintain,
and,
and
so
so
they
have
donated
to
the
cncf.
A
A
They
also
end
up
dead,
be
sure
to
be
careful
when
you
choose
a
tool,
make
sure
it's
under
active
development,
make
sure
it's
backed
by
a
commercial
entity,
make
sure
the
commercial
entity
has
a
way
to
sustain
their
open
source
product
and
make
sure
that
other
people
are
using
it.
Lastly,
things
you
want
to
be
unique
when
it
comes
to
the
tools.
These
are
very
rarely
a
point
of
differentiation
for
you.
A
Are
you
navigating
the
cncf
landscape
and
looking
to
select
tools,
be
super
aware
of
compounding
complexity?
The
kubernetes
API
is
a
fast
moving.
Target
and
apis
are
deprecated
and
brought
from
alpha
to
Beta
to
release
at
nearly
the
speed
of
light
every
product
you
choose
that
uses.
These
apis
needs
to
release
a
version
in
lockstep
and
the
more
you
have
the
greater
the
chance
of
finding
yourself
in
a
position
where
you
cannot
upgrade
kubernetes
because
of
the
tool
you
rely
on
doesn't
support
the
new
version,
that's
dangerous.
A
Given
the
pace
of
what
cves
are
found
and
fixed
in
kubernetes,
you
should
upgrade
as
soon
as
possible,
but
not
be
forced
to
wait.
Sometimes
a
multi-tool
is
the
best
as
a
multi-tool
is
managed
as
a
single
package.
So
you
don't
need
to
do
the
work
to
figure
out
how
they
interrupt
matrixes
work.
The
multi-tool
suppliers
will
do
just
that
for
you
as
an
example,
multi-tool
red
hat,
openshift
or
container
one
vendor
one
tool
to
manage
the
complexity
of
a
number
of
underlying
Technologies.
A
But
why?
Because,
as
mentioned
previously,
Cloud
native
devs
are
very
hard
to
come
by
and
when
you
do
get
some,
you
need
to
make
them
as
efficient
as
possible,
and
wouldn't
it
be
awesome
if
there
was
a
way
to
bootstrap
non-cloud
native
devs
into
the
tech
stack
and
kubernetes
Engineers
are
equally
in
short
supply,
so
we
should
be
able
to
take
more
traditional
itops
it
admins
and
ease
their
attention
into
managing
kubernetes.
A
Okay.
So
you
have
your
app
and
you
have
your
platform.
Let's
get
this
puppy
live.
The
the
panacia
here
is
that
the
tooling
you
have
chosen
allows
you
to
spin
up.
Clusters
enables
the
login,
metrics
Etc
and
your
team
are
able
to
manage
a
lot
of
minimal
without
a
minimal
retraining.
Again,
the
goal
is
to
reduce
the
on-ramp
in
the
tech
adoption
and
then
reduce
the
day.
Two
operational
overhead
remember
the
reason
we
are
doing
all
this
is
to
get
apps
to
Market
quickly.
A
A
Be
careful,
though,
whilst
we
want
to
minimize
the
amount
of
change
the
existing
staff
need
to
undergo,
to
be
able
to
deploy
the
manage.
The
apps
and
kubernetes
be
very
clear.
It
is
different.
You
cannot
just
take
a
VM
admin
and
tomorrow
have
the
managed
containers.
The
tech
is
very
different,
very
different
and
it
needs
to
manage
differently.
You
do
Dr
differently,
you
do
BCP
differently,
you
review
logs
differently,
you
monitor
performance
differently
and
there
are
a
lot
of
differences.
A
A
Maim
is
pretty
well
known,
but
the
thing
is:
it's
accurate,
there's
a
lot
to
know
about
kubernetes
and
a
lot
of
things
to
trip
you
up.
It's
critical
that
the
complexity
is
well
understood,
respected
and
that
a
plan
is
in
place
to
be
dealt
with.
This
don't
be
fooled
by
those
that
says.
Kubernetes
is
easy.
They
are
ignorant
to
the
true
complexity
that
lays,
under
the
surface
sure
it's
easy
once
you're
a
trained
expert,
but
none
of
us
are
born
experts.
A
In
anything,
there
are
a
number
of
day
two
challenges
that
you
will
need
to
overcome.
Again.
These
are
challenges
due
to
the
challenge
in
architecture,
and
none
of
these
should
be
a
surprise
when
it
comes
to
your
kubernetes
clusters.
Do
you
want
to
treat
them
as
cattle
or
pets
pets
mean
you
need
to
update
them,
triage
them
closely,
manage
them
and
cattle
means
you
deploy
a
cluster
to
host
your
apps,
and
then
there
is
a
newer
version.
You
spin
up
the
new
cluster,
deploy
your
app
there
and
delete
the
old
far
simpler.
A
How
would
you
Monitor
and
report
on
slas?
How
would
you
ensure
security
and
compliance?
How
would
you
back
up
and
provide
the
UR
for
your
applications
if
you
are
modernizing
Legacy
apps?
Are
the
isvs
comfortable
in
supporting
them
in
containers?
Kubernetes
is
designed
to
be
dynamic.
If
you
have
a
cab
board,
they
can
accommodate
this
Dynamic
nature,
but
don't
try
and
be
a
hero
sure
it's
awesome
to
be
the
first
company
to
adopt
a
new
technology
from
cncf
landscape,
but
really
it's
that
is
it
that
smart?
A
What
happens
if
you
have
an
issue
and
there's
no
peers
around
you
to
help
you
out
a
deal?
You
want
a
local
ecosystem
around
you
around
the
tooling
local
events,
local
meetups
and
locals.
All
talk
about
the
same
Tech
stack.
That's
a
massive
risk
reducer!
So
don't
fall
into
that
trap.
Also
resist
the
urge
to
build
a
better
mousetrap
sure,
you're,
a
developer
engineer,
and
you
like
having
the
skills
to
build
apps
and
solutions.
But
is
it
really
a
good
use
of
your
time
to
try
and
build
a
better
tool?
A
That's
already
out
there
already
being
maintained
and
already
having
a
support
network
bass,
scripts
Powershell
scripts?
These
are
all
Nightmare
to
maintain
versus
readily
available
tools
and
predictable
release.
Cadence,
my
advice
is
to
ask
yourself:
can
I
pass
the
3am
test,
which
is
it's
3
A.M?
The
system
has
suffered
a
catastrophic
failure.
How
many
of
my
teams
can
rally
around
to
help
fix
it?
A
If
the
answer
is
one
or
two
you're
in
trouble,
I
also
strongly
recommend
ensuring
you
have
a
vendor
support
for
open
source
components
too
sure
they
have
no
upfront
license
costs,
but
then
again
at
3am
mongodb
has
failed.
Wouldn't
it
be
great
to
be
able
to
call
customer
customer
support
somewhere.
It's
why
VMware
nutanix
Ms
all
did
it
well
supporting
these
at
times
of
crisis,
I
never
lose
sight
of
the
goal.