►
From YouTube: Lighting Talk - Deploying, Managing and Securing Applications on Kubernetes Without... Bruno Andrade
Description
Lighting Talk - Deploying, Managing and Securing Applications on Kubernetes Without Knowing Kubernetes - Bruno Andrade, Shipa
Deploying applications is not as easy as many teams expected and scaling the number of applications and users just adds to that complexity. During this talk, we will discuss a completely different way of doing that that will allow you to deploy, manage and secure applications without building and managing a single Kubernetes related object and YAML file
A
They
spend
that
time,
basically
gluing
up
a
lot
of
components
together,
yellow
files,
custom
scripts
and
so
on
and
so
forth
and
great.
Now
that
the
platform
is
built,
we
give
kubernetes
as
the
interface
to
our
developers,
but
what's
actually
happening
is
as
soon
as
developers
they
start
applying
the
applications.
A
They
see
that
this
is
actually
driving
them
down
to
the
infrastructure
layer
level
where
they
have
to
learn,
manage
and
create
things
such
as
deployment
sets
ingress
rules,
custom
scripts
for
development,
many
of
them
they
have
to
learn,
terraform
so
on
and
so
forth,
and
what
they're
reporting
back
is
that
application
deployment
now
and
updates?
Now
they
have
become
more
complex
than
before,
because
now
they
have
to
learn
a
bunch
of
infrastructure
components
rather
than
just
the
application
itself
the
developers
they.
A
They
complain
that
they're
spending
a
lot
of
time
on
tasks
that
are
infrastructure
related
instead
of
application
purely
and
that's
fair,
the
value
they
deliver
is
the
application
and
its
updates,
and
because
developers
they
are
being
dragged
down
the
possibility
of
pushing
misconfigured
files.
All
the
way
from
your
ci
pipeline
down
to
your
kubernetes
cluster
is
real,
and
that
can
change
the
state
of
your
cluster
and
the
state
of
our
applications.
A
But
that's
not
only
it
from
a
platform
team
perspective
what's
happening.
Is
we
spend
that
one
to
two
years,
gluing
everything
together,
bringing
together
those
crypts
and
those
terraforms
and
yellow
files,
and
so
on?
But
as
soon
as
applications
starts
to
be
deployed-
and
we
start
to
get
some
scalability
now,
what
happens
is
kubernetes
is
very
object.
Centric
rather
than
application-centric,
and
what
I
mean
by
that
is
it's.
It
becomes
really
hard
at
scale
for
us
to
implement
security
controls
and
policies
at
an
object
level
rather
than
application.
A
So
we
need
to
see
what
are
all
the
objects
that
are
related
to
my
app:
what's
the
health
status
of
each
of
them,
so
it
becomes
really
complex
and
now
we're
getting
a
lot
of
pressure
from
our
developers
actually
because
they
don't
like
that
interface,
they
don't
like
being
dragged
down
into
the
infrastructure
and
at
the
end
of
the
day,
what
we're
actually
being
tasked
with
is.
Can
you
deploy
yet
another
platform?
A
So
that's
the
question
that
we're
faced
today
so
in
order
to
try
and
help
with
that,
we
started
thinking
about
it
a
bit
differently
in
a
way
that
why
don't
we
think
about
an
application
framework.
Rather
than
individual
solutions
or
cluster
focused
solutions,
so
we
started
thinking
about
that
and
when
you
think
about
an
application
framework,
what
would
that
look
like?
A
So,
in
order
for
that
to
be
effective,
you
have
to
come
up
with
more
components
or
that
application
framework
has
to
offer
you
more
components
such
as
integrated
security,
multi-cluster
support,
I'm
pretty
sure
many
of
the
organizations
out
there.
You
are
implementing
multiple
clusters,
either
on
premises,
manage
cloud
providers
and
manage
kubernetes
versions
and
so
on.
A
We
don't
like,
ripping
and
replacing
everything
so
that
for
that
application
framework
to
be
really
effective
for
us,
it
needs
to
fit
right
into
our
current
stack,
so
it
needs
to
fit
into
our
ci
pipeline
and
it
needs
to
fit
into
our
monitoring
tools
or
incident
management
and
so
on
and
so
forth.
Any
needs
now
to
to
fix
the
last
mile
deployment.
A
A
lot
of
us
are
spending
a
lot
of
time
today,
trying
to
actually
piece
together
our
cd
tools
that
are
out
there
in
our
kubernetes
clusters
and
a
lot
of
them
forces
you
to
actually
have
to
build
custom,
scripts,
terraforms,
scripts
and
so
on,
and
they
are
not
really
doing
it
well.
So
we
need
something.
We
need
that
application
framework
to
actually
automate
that
and
make
that
completely
seamless.
A
So
the
application
can
flow
from
my
get
repo
all
the
way
to
my
kubernetes
clusters
without
me
having
to
intervene
and
maintain
a
bunch
of
custom
scripts
and,
last
but
not
least,
a
lot
of
folks.
They
don't
like
hearing
that,
but
the
the
reality
is.
If
you
are
implementing
kubernetes
today,
it's
because
you
changed
what
you
were
implementing,
what
you
implemented
actually
yesterday.
So
the
reality
is,
you
are
probably
going
to
be
looking
at
changing
kubernetes
in
the
future
or
changing
cluster
versions,
or
maybe
changing
cloud
providers
so
that
application
framework
needs
to
be
extensible.
A
So
we
can
swap
components
underneath
it
and
the
developers
and
the
applications
they
will
not
be
impacted
from
a
development
perspective.
Same
way,
we
can
look
at
table
stakes
type
of
functionality
where
they
have
some
automated
logging
monitoring,
some
support
to
can
area
and
a
b
releases.
But
for
that
to
be
effective
and
lasting
in
our
organization,
we
need
to
allow
our
developers
to
stop
thinking
now
about
object
on
kubernetes
and
really
focus
on
the
application.
A
It
needs
to
fit
the
the
workflow,
so
it
needs
to
fit
the
ci
and
it
needs
to
fit
what
they're
doing
from
a
git
repository
perspective,
either
git
lab,
bitbucket
and
so
on
and
so
forth.
You
need
to
decouple
the
apis
and
give
them
self-service
apis,
as
mentioned.
If
we
want
to
change
kubernetes
versions
or
cloud
providers
version
underneath
that
cannot
affect
our
developers,
so
they
need
to
be
working
at
a
level
up
and
a
decoupled
self-service
api.
A
Although
in
need
there
needs
to
be
security,
we
we
need
to
actually
detach
our
developers
from
that
in
a
way
that
it
is
embedded
in
the
process,
but
they
don't
have
to
learn
and
know
how
to
create
them,
and
we
need
to
give
them
more.
Observability.
Again,
we've
seen
a
lot
of
developers
and
even
platform
engineering
teams
saying
that
they
need
better
observability,
better
observability,
but
what
we
understood
from
that
is
that
they
wanted
to
see
how
their
applications
are
actually
behaving
and
the
components
related
to
it.
A
So
we
need
to
give
them
that
and
it
also
needs
to
be
extensible.
So
how
do
we
implement
that
framework?
Let's
say
we
as
a
platform
engineering
team,
we
create
a
framework
spec
and
the
framework
spec
is
completely
abstracted
from
kubernetes,
there's,
nothing
related
to
gke,
on-premise,
kubernetes,
k3s
and
so
on.
But
it's
related
to
your
application,
and
here
you're
going
to
define
things
such
as
the
amount
of
memory
and
cpu.
A
What
you
can
do
is
once
once
the
file
you
can
attach
actually
that
that
framework
to
a
cluster
reality
is
one
single
framework
cannot
address
all
the
requirements
from
all
the
apps
we
have.
So
we
can
define
multiple
frameworks
and
these
frameworks.
They
can
have
different
configurations,
security
teams,
network
policies
and
so
on,
and
you
can
now
attach
these
frameworks
to
different
clusters
you
have
and
by
attaching
them.
These
frameworks
are
automatically
going
to
start,
giving
you
all
the
functionality
or
giving
your
application.
A
So
all
the
applications
that
are
deployed
using
them
can
automatically
consume
them
and
on
the
developer
side,
what
we
do
is
we
allow
the
developer
to
keep
using
the
same
repo,
the
same
ci
tool,
but
now,
instead
of
us
building
a
bunch
of
cd
scripts
and
and
terraforms
and
helm
charts
to
make
our
cd
tool
or
even
our
ci
pipeline,
deploy
to
kubernetes.
We
attach
this
ci
pipeline
to
your
frameworks,
so
you
don't
need
to
build
anything
for
get
helm.
Forget
terraform,
forget
scripts.
A
They
now
connect
directly
to
these
frameworks
and
a
few
other
things
happen
here.
Actually,
your
developers,
they
don't
need
to
build
a
single
kubernetes
object.
They
actually
could
care
less.
If
it's
running
kubernetes,
they
don't
know
if
it's
gke
aks
115,
114
170,
they
are
solely
focused
on
deploying
their
code
and
as
soon
as
the
ci
deploys
the
application
code,
just
the
application
code.
No
objects
to
that
framework.
That
framework
is
then
now
responsible
for
creating
all
the
apps
automatically.
A
So
now
we
have
a
very
structured,
automated
cd
component
that
is
going
to
get
our
applications
not
only
from
the
git
repo,
all
the
way
to
deployment
without
without
being
worried
about
infrastructure,
but
also
post
deployment.
Where
we
have
monitoring
hooked
up.
We
have
security,
we
have
network
policies,
audit
and
others
at
the
end
of
the
day,
using
the
application
management
framework
as
part
of
your
cd
process
and
post
deployment
as
well.
It
accelerates
the
kubernetes
adoption.
A
It
removes
completely
the
need
to
create
yaml
and
object
files,
no
more
scripts
and
helm,
charts
and
terraforms
for
your
applications
to
be
deployed,
and
you
allow
your
developers
to
be
focused
on
the
application,
so
they
are
finally
happy
with
the
with
the
platform
engineering
team
and
we
as
a
platform
engineering
team.
Now
we're
focused
on
controls,
extensibility
performance,
so
we
become
now
a
key
piece
in
our
team
and
in
our
organization,
instead
of
just
being
a
bunch
of
yaml
engineers
right.