►
From YouTube: How We Revolutionized Developer Experience With 3.5 Platform Engineers - Jessica Andersson, Kognic
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
How We Revolutionized Developer Experience With 3.5 Platform Engineers - Jessica Andersson, Kognic
Speakers: Jessica Andersson
As a small team there is a lot of leverage to be gained from using cloud native projects, but the task might seem daunting and something that you need to have a very large organisation to have any use of. This couldn’t be further from the truth! Join this case study and learn how Jessica and her team of three and a half Platform Engineers revolutionized the developer experience for 30 developers at Annotell with the help of cloud native projects.
A
A
We
are
a
sauce
company
and
we
try
to
strive
to
make
safe
perception
possible
for
autonomous
vehicles
and
we
were
funded
back
in
2018
and
our
headquarters
are
located
in
Gothenburg,
Sweden
right
now
or
like
I,
say
approximately,
because
honestly
we
grow
still
so
it
could
have
changed
since
last
or
checked,
but
we
run
90
employees
out
of
which
45
people
are
working
in
engineering
who
am
I.
Why
I'm
here
so
I'm
in
the
product
area
lead
to
engineering
enablement?
A
What
we
call
our
platform
functionality
working
with
developer
experience,
I'm
also
a
cncf
Ambassador
and
involved
in
Cloud
native
nordics
Community,
which
is
a
group
of
meetup
groups
in
the
nordics
in
Europe
and
I'm
located
in
Gothenburg.
You
can
see
the
small
Arrow
I'm,
also
a
local
Meetup,
organizing
Gothenburg
I'm,
going
to
tell
you
the
story
of
since
I
joined
in
June
2020
how
we
started
working
strategically
in
order
to
try
to
revenue.
This
is
a
hard
word.
A
Sorry,
revolutionized,
developer
experience
in
platform
engineering,
so
I'm
going
to
tell
a
story
about
how
we
used
specific
projects
in
order
to
help
us
with
it
and
I'm,
going
to
talk
about
extendedness,
search
manager,
Argo,
CD
and
I'm,
going
to
bring
about
the
story
from
starting
their
up
until
2022.
when
I
joined
back
it
was
infrastructure
and
platforming
was
happening
and
I
need
to
happen
basis.
A
lot
of
our
infrastructure
was
spun
up
from
one
of
us
co-fundors
and
it
was
done
to
the
point
of
oh.
It
works
great.
A
Let's
move
on
to
being
for
more
important
things.
So,
when
I
joined
there
was
no
one
really
working
with
these
things.
There
was
this
guy
that
used
to
fix
things
when
it
broke.
You
probably
recognized
the
story,
and
the
first
thing
I
did
was
to
use.
Try
to
you
know,
upgrade
kubernetes
play
security
patches
and
these
things,
but
most
of
all,
I
just
tried
to
assess
look
at
what
we
had
look
at
what
the
needs
were
and
try
to
figure
out
where
to
start
so
developer
experience,
it's
usually
called
The
X
as
well.
A
You
probably
heard
a
lot
about
it
this
week,
I
think
it's
like
really
fun
to
hear,
hear
all
the
conversations
going
around
about
this
and
you
might
wonder
like
why
do
I
care
about
developer
experience
and
I
used
to
be
a
developer
myself.
I
started
out
as
a
developer
and
then
I
moved
through
the
stack
and
as
a
developer.
It's
like
great
when
the
developer
experience
is
great
when
someone
has
already
solved
the
problem
for
you
and
you
can
focus
on
things
that
you
care
about.
A
And
we
have
these
common
needs
as
a
developers,
regardless,
if
you're
building
like
a
python
application,
a
scholar
application
whatever
it
might
be,
you
might
have
things
that
you
need
to
do
problems
they
have
in
common.
So
some
of
the
things
that
our
developers
care
about
is
like
Ci,
CD
load,
balancing
runtime
container
runtime,
spoiler
alert,
cognitas
metrics
logging
Etc,
but
what
the
company
cares
about
is
the
business
logic.
A
This
is
what
differentiates
each
team.
This
is
what
each
developer
actually
is
trying
to
achieve.
All
the
other
things
are
not
necessarily
evil,
but
they
are
needed
in
order
to
achieve
that.
So
the
less
time
we
can
have
them
spend
on
these
white
boxes,
the
more
time
they
can
spend
on
the
purple
box
and
the
more
time
they
can
actually
spend
towards
making
what
makes
our
company
stand
out
towards
the
competitive
features.
A
How
do
we
work
with
this?
We
work
with
this
with
the
golden
pass
paid
Road
hands
up,
who
heard
about
the
golden
path
before
paved
Road
same
same
right,
so
there's
actually
a
really
good
talk
from
last
kubernetes,
cubecon,
Cloud
native
counting
Valencia
from
Daniel
variant
regarding
what
was
it
called
from
kubernetes
to
pass
to?
What's
next
try
that
title
I
recommend
looking
at
that
talk.
They
will
be
linked
in
there
and
the
last
slide.
A
So
what
we're
looking
at
is
we're
trying
to
build
a
platform
you
saw
the
keynote
this
morning.
We
try
to
build
a
platform.
That's
trying
to
solve
all
these
common
needs,
building
on
all
the
best
practices
for
our
developers,
so
they
have
an
easy
way
of
actually
achieving
all
the
things
they
need
without
to
have
to
understand
all
their
underlying
Technologies,
because,
let's
face
it,
there's
a
lot.
A
So
in
the
end
to
iterate,
why
do
we
have
developers?
We
have
them
because
we
want
to
create
business
value
and
the
more
time
they
can
spend
on
that
the
biggest
chance
we
have
to
actually
succeed
as
a
company
and
that's
what
we
care
about
so
I
told
you
that
I
was
going
to
tell
how
we
were
three
and
a
half
platform
engineers
and
we
revolutionized
developer
experience.
How
does
being
a
small
team
impact
this
because
paid
Road?
A
We
are
three
and
a
half
person
people
like
how
does
that
differentiate,
so
something
some
uncomfortable
insights
that
we
have
come
to.
Is
that
one?
You
can't
do
all
the
things
it's
like
you
hear
about
all
the
cool
things.
You
can't
do
everything
you
have
to
be
conscious
of
where
you
spend
your
time.
That's
why?
When
we
started
out,
we
did
not
try
to
fix
everything
right
away.
We
tried
to
figure
out
what
what
is
causing
the
most
pain.
A
So
sometimes
it's
valuable
to
say
this
is
not
worth
the
investment
we
should
not
do
it
upgrades
take
time
and
they
are
frequent
and
then
there
there's
breaking
changes
and
then
you
have
to
upgrade
other
tools
and
you
have
to
change
how
you
do
other
things
and
roll
out
new
API
versions.
Etc.
It
takes
time
the
more
tools
you
take
in
the
more
time
you
will
spend,
maintaining
those
and
upgrading
them
continuously
and
you
probably
don't
need
a
service
mesh.
A
Joking
aside,
I
service
measures
are
great,
but
they
might
not
be
disillusioned
to
your
problem,
so
just
because
someone
else
needs
a
service
mesh,
it
doesn't
have
to
mean
that
you
need
a
service
machine
and
service
mesh
is
just
a
concrete
example
here.
It's
it
could
be
anything
I,
don't
need
a
service
mesh.
If
you
want
to
talk
about
not
needing
a
service
mesh,
you
can
come
talk
to
me
afterwards.
A
So
what
has
our
approach
been
like?
What
did
we
do,
and
now
it
sounds
like
I'm
going
to
give
you
like
most
mind-blowing
new
things,
but
it's
not
that
complex.
Honestly,
it's
just
remove
time
consuming
tasks
and
bottlenecks.
This
is
literally.
This
sentence
is
what
we
lived
for
for
the
last
few
years.
A
So
first
we
had
focusing
on
unblocking
the
developers
if
a
developer
is
blocked
and
need
to
wait
for
someone
else
in
order
to
be
able
to
do
the
things
that
they
want
to.
Do
that's
a
bad
thing
for
us,
so
our
main
focus
is
to
unblock
developers
and
make
sure
that
they
can
always
self-serving
reach
their
goals.
A
Second,
one
is
reminding
removing
time
consuming
tasks
from
the
platform
team,
so
the
platform
team,
as
I
mentioned,
there's
a
lot
of
things,
upgrade
six
time,
etc,
etc,
etc.
So
make
sure
that
the
team
doesn't
spend
time
on
things
that
they
don't
have
to
spend
time
on
and
once
you're
done
with,
that,
you
can
move
on
to
removing
time
consuming
tasks
from
the
developers
and
the
reason
why
the
team
is
before
the
developers
is
because
a
busy
team
will
not
be
able
to
remove
time
consuming
tasks
from
the
developers.
A
This
for
us
was
something
that
we
implemented
in
starting
to
use
due
to
unblocking
our
developers
so
as
a
startup,
probably
for
everyone,
I
mean
really.
What
you
do
is
that
you
try
to
find
out
the
next
big
thing
right,
so
you
build
something
you
want
to
test
it
and
you
want
to
evaluate
it,
and
then
you
want
to
do
that
as
often
and
as
quickly
as
possible,
in
order
to
see
if
you
build
the
right
thing
so
for
us,
this
often
means
pushing
something
to
production
and
pushing
to
production.
A
After
meant
that
you
wanted
to
expose
that
somehow,
usually
with
some
kind
of
DNS,
so
the
process
for
the
teams
oops-
that
was
a
bit
quick
sorry
was
that
they
built
the
application
and
then
they
deployed
application
and
they
had
like
a
load
balancer
service
type.
So
they
got
an
IP
for
that
and
then
they
went
with
that
IP
to
one
of
the
two
people
they
took
it.
Actually
they
kind
of
configured
DNS
record
in
cloudflare,
and
then
they
waited
like
they
sent
a
slack
message.
Hey
can
you
help
me
set
this
up?
A
A
We
want
to
remove
that
blocker.
So
what
we
did
was
that
we
looked
at
external
illness.
For
us
it
was
extremely
easy
to
install.
Basically
it
was
just
getting
a
cloudflare
API
token
and
add
it
to
the
configuration
and
get
it
up
and
running
the
external
device
tracks
ownership.
We
take
Steve
records.
So
this
is
an
example
how
we
can
look
in
cloudflow.
So
we
have
the
a-type
record
for
the
application,
which
is
hello
Argo.
A
We
use
something
that
I
found
running
and
then
it
has
the
corresponding
txt
record,
with
some
content
that
points
out
that
external
data
is
the
owner.
So
why
I'm
showing
this?
Because
when
we
migrated,
we
wanted
to
also
start
tracking
all
these
existing
services
with
external
data,
so
that
when
someone
removed
something,
we
also
removed
the
corresponding
DNS
record
and
we
didn't
have
to
care
about
manually,
configure
DNS
again.
A
So
what
we
did
was
that
we
added
manually
annotation
to
each
service
that
tool
which
DNS
record
it
should
have,
and
then
we
fake
the
takes
the
records
in
cloudflare
and
pretended
to
be
Argo,
adding
them,
and
then
it's
not
sorry
external
Dennis,
and
then
we
deployed
the
external
S3
cluster
and
honestly
it
worked
and
if
I'm
not
wrong,
I
think
this
look
like
us
a
week
to
do
and
that
included
like
figuring
out
what
was
running.
What
was
configured
some
custom
shell
scripts.
A
No
one
mean
there
before
right
and
in
the
end
it
was
a
great
success.
So
the
process
in
the
end
looked
right
instead
of
doing
the
getting
the
IP
asking.
If
someone
have
the
blocker
just
build
your
app,
you
deploy
the
presentation
and
you
got
the
DNS
record
and
you
kept
developing
the
return
of
investment
on
this.
One
was
really
good.
So
in
the
end
this
turned
into
a
total
self-serve
with
very
little
education.
The
team
members
and
developers
could
easily
set
up
their
own
their
nest
record.
A
It
was
it's
super
easy
to
use
and
they
were
no
longer
blocked.
So
if
we
look
at
this
kind
of
Matrix,
you've
probably
seen
it
before
we
have
a
effect.
That
is
the
outcome.
What
was
the
result
and
the
investment
on
the
top,
and
if
you
have
a
low
effect
and
a
low
investment,
then
you
have
a
medium
return
on
investment
kind
of
style.
In
this
case
we
had
a
low
investment,
as
I
said
about
a
week,
and
actually
it's
been
running
with
very
little.
A
A
So
next
up
is
search
manager,
and
this
was
one
of
those
removing
time
consuming
tasks
from
the
team
that
we're
looking
at
so
the
process
before
was
not
great.
It
has
some
kind
of
situations
that
were
very
contextual
based
on
where
we
were
so.
For
some
reason,
we
decided
that
we
were
going
to
terminate
the
SSL
records
inside
the
container
itself,
meaning
that
certificates
were
loaded
as
a
secret
into
the
deployment
the
volume
amount.
A
So
whenever
we
were
renewing
our
certificates,
which
happened
every
90
days,
we
had
to
renew
them,
which
meant
that,
basically,
we
were
doing
it
every
60
days
because
we
didn't
want
to
do
at
the
last
minute.
We
had
to
first
use
a
custom
shell
script
in
order
to
create
a
new
certificate
like
something
medical
worked
on
Terminal,
you
get
a
new
certificate.
Great
then
manually
added
the
secret
in
kubernetes
to
contain
the
new
certificate.
A
All
great
except
the
deployments,
don't
pick
up
a
new
exchange
secret
unless
they
are
redeployed.
So
then
we
also
had
to
do
rolling
restart
up
all
the
deployments.
I
mean
it's
a
pain.
It
was
not
great.
It
was
not
fun
and
also
it
was
like
this.
You
had
to
have
this
calendar
event
every
other
month,
like
remembering
you,
the
certificates
and
was
like
always
after
discussion.
It
took
a
lot
of
cognitive,
cognitive
load
for
the
team,
so
we
were
looking
at
search
manager.
A
Once
again,
I
would
say
it's
like
very
easy
to
get
up
and
and
start
running
so
once
again,
let's
encrypt
and
cloudflare,
and
we
had
to
get
like
connectors
to
search
manager.
And
then
we
pull
pulled
the
resources
from
the
official
release
and
you
get
a
lot
of
cluster
roles
Etc
and
a
lot
of
custom
resource
definitions
from
that,
and
then
we
configure
our
own
cluster
issue.
A
A
cluster
issue
is
a
configuration
that
says
like
four
well
for
what
like
connect
to
Let's
encrypt
and
connect
cloudflare,
and
how
do
you
want
to
configure
your
DNS
zones?
It
also
plays
very
nice
with
ingresses.
So
sometime
around
here,
we
also
started
using
ingresses
instead
of
load
balancers
in
our
services.
That's
another
story,
but
it
was.
It
plays
very
nice
because
we
no
longer
had
to
do
the
rolling
restarts
of
the
application
of
all
applications.
A
So
in
the
end
we
remove
the
manual
process
and
we
have
like
less
cognitive
load
and
there
is
no
rule
and
restart
of
all
the
things
great
right.
Where
do
I
put
this,
so
it
was
a
very
low
investment.
Honestly,
it's
not
a
huge
effect.
It
was
not
something
that
took
a
lot
of
time
from
us,
but
it
was
annoying.
It
was
really
nice
to
get
rid
of
so
I
would
say
like
a
medium
return
on
investment.
A
We
had
like
the
build
pipeline,
we're
posting
tags,
image
types
tags
that
were
built
to
Slack
and
then
the
developer
picked
up
his
tag
from
Slack
and
they
went
to
the
terminal
and
they
ran
a
magic
script,
I'm
saying
magic
because
it
was
magic
to
them
and
that
did
the
cube.
Ctl
set
image
in
the
cluster
live
setting
the
image
which
triggers
a
rolling
restart,
and
then
it
ran
Cube
CTL
rollout
status
to
see
what
was
going
on,
and
then
he
posted
a
slap
that
this
deployment
has
now
been
updated
with
the
new
image
tag.
A
So
this
was
good.
It
worked
well
for
very
long,
but
when
we
started
growing,
introducing
new
developers
doing
more
and
maybe
not
exactly
similar,
looking
deployments
Etc,
we
started
yet
for
a
point
where
it.
It
wasn't
really
that
great
anymore.
So
one
of
the
problems
was
that
it
was
a
black
box
for
the
developers.
They
didn't
know
what
happened
in
the
script.
A
They
weren't
really
sure
that
they
were
actually
live,
editing
the
image
in
kubernetes
and
this
one
it
was
the
one
that
kept
me
awake
at
night,
we
had
no
version
controller
was
running
in
kubernetes.
If
someone
accidentally
deleted
a
deployment,
there
was
no
good
way
of
actually
getting
it
back
and
like.
It
could
also
be
scary
for
people
to
change.
A
If
you
were
like
trying
to
change
what
the
amount
of
resources
your
application
were,
using
whatever
it
was
kind
of
hard
to
know,
because
there
was
some
yaml
files
in
git,
but
they
were
not
matching
what
was
actually
running
in
the
cluster.
So
if
you
wanted
to
change
that
and
then
apply
it
and
maybe
overwrite
something
there
was
a
live,
edited
Etc.
So
there
was
a
lot
of
uncertainty
in
managing
your
communities,
resources.
A
Right
I
have
these
hooks
up
so
also
it
was
hard
to
know
what
was
deployed
and
why,
because
this
slack
Channel
it
was
I
mean
there
were
so
many
new
messages
every
day.
I,
don't
know
how
anyone
used
that.
So
what
do
we
need?
Instead,
we
need
a
transparency.
We
needed
to
spend
less
time,
debugging
failures
and
we
needed
to
have
the
resilience
and
knowing
that
we
could
restore
our
systems
in
case
something
happened.
A
So
what
do
we
look
to?
We
looked
at
githubs.
That
was
obvious,
and
if
you
look
at
the
definition
of
githubs,
there
is
actually
a
really
good
web
page
that
I
forgot
to
link
up
right
now.
I
hope
it's
coming.
Otherwise
it's
in
the
last
slide
githubs
should
be
declarative.
You
should
have
a
system,
a
system
management
must
have
its
desired
status,
expressed
declaratively,
it
should
be
versioned
and
immutable,
it
should
be
pulled
automatically
and
it
should
be
continuously
reconciled.
A
A
We
looked
at
Argo,
of
course,
and
so
I
mean
everyone
loves
a
good
Gemma
VI
at
least
they
are
declarative
right.
You
can
I
mean
also.
The
same
goes
for
customize
and
Helm
charts
Etc,
it's
declarative.
You
can
use
that
and
and
then
putting
everything
in
GitHub
allows
us
to
have
it
versioned
and
immutable
and
I
mean
if
you
put
the
muscle
balance
protection,
no
one
can
overwrite
it
Etc
Argosy
to
pulls
automatically
from
GitHub,
and
then
it
continuously
reconcile
it
and
there's
a
link
to
other
project.
A
So
what
we
did
was
at
first
when
migrating,
because
we
had
this
as
I
mentioned
like
something
was
pushed
to
get,
it
was
not
really
what
was
running
in
cluster.
What
was
going
on
Etc?
What
we
did
was
we
started
out
by
trying
to
figure
out
what
was
actually
running
like
what
was
in
the
cluster,
and
then
we
started
to
just
export
that
back
to
yaml
files
continuously
and
trying
to
figure
out.
When
do
we
get
to
a
state
that
this
is
stable
enough?
A
And
so,
where
did
that
to
GitHub
repo?
And
then
we
started
setting
up
Argo
CD
with
sync
disabled
I'll,
go
see
it
with
sync.
Disabled
means
that
you
will
see
what
is
mismatching
but
will
not
try
to
apply
something
to
the
cluster,
which
is
great
if
you,
if
you
want
to
start
out
and
not
overwrite
something
I
have
like
double
clicking.
Sorry,
and
then
we
announced
an
migration
window
and
we
and
I
mean
we
could
probably
have
done
it
live,
but
at
the
same
time
we
thought
this
is
going
to
be
a
one-off.
A
We
are
like
at
this
time,
I
guess
33
developers
or
something
they
can
live
with
a
two
hour
window
where
we
say
please
don't
deploy
because
we've
messed
things
up
and
then
we
we
turn
it
on
and
it
was
a
success
or
I
will
get
back
to
it.
So
what
did
the
process?
Look
afterwards?
So
get
the
latest
tag
and
push
it
to
git
and
that's
it
and
then
it
worked.
I
mean
it
just
works
right.
A
In
the
end,
we
got
a
very
transparent
process.
It
was
much
easier
for
developers
to
see
what
was
going
on
what
happened
and
like
what
steps
were
involved.
The
negative
part
was
that
maybe
they
had
to
learn
a
few
things
that
they
didn't
have
to
care
about
before
they
had
to
know.
There
is
a
deployment
configuration
they
had
to
know,
there's
an
image
tag,
field
and
all
those
things,
but
in
the
end
exposing
that
to
them
actually
empowered
them
to
know
what
was
going
on
and
get
to
a
state.
A
But
it
was
easier
for
them
to
manage
that
we
had
the
resilience
we
were
able
to
restore
it
in
case
something
happened
and
damn
it.
It
was
easy
to
use.
Kinda
and
I
actually
wanted
to
be
a
slide
back
when
we
roll
This
Out.
This
was
not
a
one-week
effort.
I
can
tell
you
that
it
was
a
little
bit
longer.
It
took
a
lot
of
time.
A
So
let's
talk
about
the
star
and
easy
to
use,
because
well
the
technical
solution
was
probably
a
really
good
one
and
and
I
think
it
worked
really
good.
We
did
not
consider
the
cultural
parts
of
it
when
rolling
it
out.
To
some
extent
our
developers
were
not
that
happy
when
we
said
stop
using
your
magic
script
and
start
using
this
process
instead,
and
you
have
to
learn
a
lot
of
things
by
the
way.
They
were
not
that
happy
so
with
the
rollout.
A
We
should
have
spent
a
lot
more
time
and
effort
on
creating
buying
with
the
developers
in
order
to
get
them
more
aware
of
what
they
would
gain
and
why
we
were
doing
these
things
because
I
think
from
their
perspective,
it
was
like
platform
team
size.
We
should
do
this,
and
now
we
have
to
learn
a
lot
of
things
while
we
should
have
told
them
like
you
will
get
all
these
things,
and
these
are
the
reasons
why
we're
looking
into
this.
A
We
think
it
will
be
valuable
for
you
and
we
miss
that,
and
so
always
when
you
do,
this
type
of
change
is
important.
Consider
the
people
that
you
affect
with
those
changes
in
the
end
it
went
well-
and
this
is
a
note
from
one
of
our
developers
and
he
said
that
Curious
to
plotting
and
they
work
on
making
my
life
easier
as
a
developer,
Argo
CD
to
get
a
random
DNS
and
all
that
good
stuff
really
helped
me
today,
and
this
is
what
we
work
for.
This
is
what
we
are
striving
for.
A
This
is
what
we
want
to
achieve,
so
I
think
that
in
the
end,
this
is
a
success.
The
rollout
could
have
been
better
planned,
so
these
are
the
things
that
we
more
or
less
stopped.
Thinking
about
DNS
records,
certificates
and
deployments
and
then,
once
again,
the
small
star,
what's
up
with
the
Stars,
so
see
rebranding
when
you
Rebrand
from
one
name
to
another,
and
you
have
to
update
all
your
DNS
records,
all
the
look
and
feel
of
your
application
and
all
the
things.
A
Suddenly,
you
actually
have
to
care
about
these
things
again,
but
using
external
DNS
using
search
manager
and
using
August
CD
made
it
a
lot
easier
for
us.
It's
the
talking
itself
and
I'm.
Actually
thinking
of
writing
that,
but
not
today,
so
our
strategy,
as
a
platform
team,
has
been
to
focus
on
on
blocking
Developers,
removing
time
consuming
tasks
from
the
team
and
removing
time
consumer
talks
from
the
Developers
and
that's
all
I
have
for
today.
Thank
you.
Please
leave
me
feedback.