►
From YouTube: Kubernetes and Taxes: Lessons Learned at the Norwegian Tax Administration - Bjarte S. Karlsen
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
Kubernetes and Taxes: Lessons Learned at the Norwegian Tax Administration - A Production Case Study - Bjarte S. Karlsen, The Norwegian Tax Administration (Intermediate Skill Level)
Day 1 Scenarios like running an application or two in a namespace are pretty well covered with blog posts, videos and talks.Handling lots of existing infrastructure, legacy culture and deploying hundreds of applications in tens of namespaces, not so much. This talk will give other large/government organizations a valuable insight that will help them succeed in migrating to a kubernetes-based infrastructure. The Norwegian Tax Administration (NTA) has over the last 2 1/2 years deployed a new platform based upon Kubernetes. All new Tax-applications since 2016 and old applications run on it. The mission for our project was ‘Faster Development and More Efficient Ops’. Standardization, automation and creating tools to enable developers to add value early are key factors to achieve this. Part of the platform is OpenSource APL 2.0 https://skatteetaten.github.io/aurora-openshift
About Bjarte
Bjarte Karlsen is an architect and developer responsible for the development/usage side of the Container Application platform that The Norwegian Tax Administration has deployed to run modernized applications. His tasks include creating tooling and code examples to support the kubernetes platform. Take a look at http://github.com/Skatteetaten and https://skatteetaten.github.io/aurora-openshift for more information.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 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.
A
Hello
Bree,
my
name
is
Bea
Arthur,
Galston
and
I
work
at
the
Norwegian
tax
administration.
Have
you
considered
adopting
kubernetes,
or
are
you
already
underway?
And
yes
good
in
this
talk,
I'm
gonna
give
you
some
insight,
hopefully
give
you
some
insight
in
what
we
have
learned
over
the
almost
three
years
that
we
have
been
on
this
journey.
A
I'm,
going
to
focus
mostly
on
how
we
use
the
clusters,
so
I'm
not
gonna
talk
so
much
about
how
you
set
off
the
cluster
and
how
you
just
get
a
simple
application
running
that
is
well
covered
in
the
literature
and
into
other
talks
today.
I
feel
so
I
have
35
minutes
and
there's
a
lot
of
things
that
digest
here
so
I'm
just
gonna
dive
right
into
it.
So
if
you
have,
if
you
have
questions,
we
can
take
them
at
the
end.
A
A
So
if
you
like
to
know
more
about
what
I'm
saying
now
or
things
around
it,
you
can
go
into
that
website
and
see
more
so
just
if
you
want
to
do
that
now
feel
free
on
this
offer.
So
before
I
start
on
the
technical
aspects,
I
wanna
just
tell
you
a
little
bit
of,
but
who
are
we
like?
No,
we
didn't
text
administration,
so
I
have
several
co-workers
sitting
here
in
the
audience
today.
They
can
raise
their
hand
if
they
feel
like
it.
A
On
the
top
part,
you
have
a
small
city
and
this
sort
of
Sodom
part
in
Norway
where
I
live,
you
have
Oslo,
it's
the
capital
in
middle
and
you
have
a
small
town
in
the
northern
part
of
Norway
called
we're.
Gonna,
that's
on
the
bottom
here,
and
here
you
actually
see
our
platform
is
called
Aurora.
I
said
you
earlier
not
to
be
confused
with
the
database
Aurora.
This
is
our
Aurora
platform.
This
name
has
been
used
internally
for
10
years,
and
here
you
see,
you
actually
have
your
aura
borealis,
the
Northern
Lights.
A
So
that's
kind
of
another
name,
so
our
platform
because
we're
from
Norway
you
know
nor
lights.
So,
as
you
can
see,
we
have
many
many
co-workers
working
on
IT,
and
but
this
is
just
the
IT
part
of
the
tax
administration.
There
are
like
6.5
thousand,
like
tax
officers
that
work
on
the
economics.
Part
of
taxes
in
Norway
and
our
our
IT
systems
are
pretty
sophisticated.
I
can
just
kind
of
tell
our
little
story
about
my
tax
return.
This
year,
I
got
an
email
saying:
hey
your
tax
return
is
ready.
A
Please
go
to
this
website,
not
like
a
link
like
security
code.
This
website
login
to
see
it.
I
logged
in
I
got
a
PDF
documents
and
pages
I
read
through
everything,
and
all
the
numbers
were
correct,
so
I
didn't
do
anything.
I
didn't
have
to
log
in
to
do
anything
I.
Just
it
was
there.
It
was
ok.
So
it's
turning
automatically
for
me.
No
answer,
it's
a
good
answer
and
you
might
think
I'm
joking
when
I'm
telling
that
this
is
the
same
for
96%
of
an
allusions.
A
So
we
don't
do.
We
don't
need
lawyers
to
do
tax
returns
or
anything
of
that.
It's
just
very
automated.
There
are
lots
of
systems
on
doing
that
just
to
set
the
context
here
so
enough
about
about
tax
tax,
Norway,
I'm
gonna
talk
what
we
learned.
This
is
the
mission
statements
on
why
we
started
on
this
journey.
This
came
out
of
a
report
in
2014.
A
That
said,
hey
you
need
to
be
faster
at
development
and
you
need
to
have
more
efficient
ops.
We
can't
continue
like
that
is
not
sustainable.
You
need
to
do
better,
so
we
try
to
do
better.
This
is
what
we
have
now.
We
are
six
open
chief
justice
because
of
the
network
infrastructure.
We
need
six
of
them
and
we
have
lots
of
different
teams
that
work
on
them
and
they
have
lots
of
applications.
Running
now
lost
depends
on
context
here.
A
A
So
we
have
a
lot
of
things
to
manage
here,
so
this
is
kind
of
the
context,
and
this
are
the
main
facts.
I'm
gonna
talk
about
today,
I
mean
you
start
off
talking
a
little
bit,
how
we
build
things
that
are
gonna
run,
then
how
we
get
them
running,
how
we
do
external
integrations
with
our
existing
infrastructure
and
how
we
observe
what
is
running
and
am
I
going
to
end
off
with
some
general
essence,
if
I
have
time,
hopefully
so,
building
applications.
A
On
each
of
these
sections,
I'm
going
to
start
off
we're
talking
a
little
bit
of
about
how
we
used
to
do
it
before
we
started
on
this
journey,
because
I
think
it's
very
relevant
to
have
in
mind
the
way,
your
culture
that
it
before
you
started
on
these
new
things.
So
this
is
how
we
used
to
do
it.
We
had
a
shared
Jenkins.
We
still
have
it
actually
for
some
legacy
that
is
deployed
to
a
virtual
server.
It's
manual
you
do
manually,
just
install
it
manually,
upgrade
it.
A
You
need
to
manually,
create
Jenkins
jobs,
need
to
man,
restart
Jenkins
jobs,
and
you
have
lots
of
polling,
so
a
lots
of
manual
steps
to
do
it
and
you
have
a
shared
build
queue
down
here
when
you
need
to
build
your
applications,
and
that
can
be
full
sometimes,
and
you
also
have
a
limits
on
how
often
you
can
run
your
job,
so
you
could
set
up
your
own
Jenkins
if
you
like,
but
this
is
kind
of
what
the
standard
package
was.
We
also
had
notably
a
demand
to
deliver
your
application
as
a
zip
file.
A
Now
it's
got
the
Totten
or
Norwegian
text.
Administration
is
mainly
a
Java
shop,
so
we
use
the
email
in
assembly
plugin
to
create
this
zip
file,
so
this
is
kind
of
an
existing
them
on
that
such
limitations
on
how
we
can
do
it
at
least
how
we
need
to
start
to
do
it
right
to
be
accepted.
So
this
is
how
we
do
it.
Now
we
have
a
junkie,
it's
containerized.
You
can
deploy
it
as
a
service.
A
It
runs
that
the
slave
swarm
plug-in
in
in
Jenkins,
because
we
need
we
want
our
notes
to
live
a
little
bit
longer
than
just
one
job,
because
we
use
maven.
We
use
some
node.
We
have
lots
of
artifacts
and
stuff
that
are
downloaded
to
our
to
our
node,
so
we
wanted
to
be
there.
So,
as
you
can
see
here
when
you
commit
there's
a
push
event
that
it
goes
to
Jenkins,
that
automatically
automatically
runs
your
jobs,
so
there's
no
polling
anymore
and
the
Jenkins
job
will
do
the
same
thing
I
used
to
do.
A
A
So
the
build
process
itself
looks
like
this.
In
order
to
achieve
this,
we
use
a
component
of
that
is
called
a
buildconfig
here.
That's
part
of
the
open
chief
distribution,
so
you
don't
need
this
to
do
this.
There
are
plenty
of
resolutions
like
today,
I've
been
to
demos,
with
code
fresh
and
with
the
branch
or
two
and
both
of
them.
You
could
also
achieve
this
with
those
kind
of
tools,
but
we
use
openshift.
We
used
open
shift
since
2015,
so
you
create
a
bail
config
that
uses
a
custom
strategy.
A
That's
basically
a
docker
image
that
builds
docker
images
and
yes,
this
runs
as
a
privileged
container
because
it
needs
to
write
now
because
we
use
docker,
we
don't
use
any
of
the
new
buildings
yet,
but
we
run
we
run
these
jobs
and
separate
nodes,
so
we
don't
build
where
we
run,
because
if
you
have
roots
in
a
docker
container,
what
can
you
do?
Then?
A
A
A
A
A
A
You
think
it's
easy?
Ok!
Can
you
come
and
work
for
us
because
I
think
it's
damn
hard
I
mean
doctor
and
Java
and
kubernetes
it's?
Oh,
it's
not
easy.
We've
used
so
many
times
on
this
to
get
this
right,
it's
a
lot
better
now
than
with
Java
10
that
you
will
see
used
to
be,
but
setting
setting
the
xmax
right.
The
memory
constraints
right
getting
exit
codes
right,
what
you
do
with
crush
stamps,
if
something
crashes
in
the
middle
of
the
night,
you
what
the
container
is
dead.
A
A
I
mean
to
do
this,
so
if
you
consider
going
down
the
route
of
doctrine
Java,
there
are
lots
of
existing
documentation
right
now
and
we
have
to
make
some
so
that
you
can
look
at
so,
but
just
don't
think
that
it's
easy,
because
it's
not
alexis
talked
about
today
about
gear,
ops
and
I
smiled
during
his
keynote,
because
I
sat
next
to
another
guy
from
digital
ocean
Matt
and
I
said
this
is
what
we
do.
It's
so
awesome.
He
says
it
now,
because
this
is
what
we
do.
A
A
Mentioned
we
use
jenkins
and
we
use
bitbucket
forget
and
a
part
of
this
of
these
tools
are
very
good.
There's
a
very
good,
very
good
integration
between
them.
They
were
already
good
push
events
but
Jenkins
Jenkins
file.
How
many
of
you
use
theories,
use
Jenkins
file,
syntax,
okay,
I'm
gonna.
Ask
you
again:
do
you
think
it's
easy?
A
No
okay,
I'm,
sorry,
I'm
gonna
rant
a
little
bit
now.
Jenkins
file
is
a
subset
of
groovy.
This
is
undocumented,
I
mean
okay,
so
Jenkins
X
is
on
the
way
we
haven't
had
time
to
look
at
Jenkins
acts
but
I'm,
not
sure
if
you're
gonna
do
it
because
right
now
we
have
a
library
where
we
unit
test
and
test
our
Jenkins
pipelines.
So
it's
a
lot
easier.
We
don't
like
burden
the
developers
with
that
they
use
our
library
and
they
just
configure
it.
So
it's
it's
better
now,
but
they
will
start.
There
were
a
lots.
A
So,
as
I
try
to
mention
now,
building
docker
images
for
pass
is
hard.
You
can't
just
take
a
docker
file
from
docker
hub
and
expect
it
to
work
like
for
us.
For
instance,
we
want
it.
We
want
you
to
use
our
base
image
because
we
want
to
have
a
security
checking
on
that
base
image
right.
You
want
to
know
that
use
the
right
one
and
you
don't
want
to
run
as
a
privileged
user,
and
you
can't
even
there
are
limitations
on
how
you
what
kind
of
use,
so
she
can
run
out
as
well.
A
So
it's
it
is
hard.
So
think
about
that.
Should
you
your
team's,
build
the
docker
images
for
me
from
their
own,
or
should
you
do
it
in
a
central
place
in
our
culture?
The
right
answer
was
to
build
it
in
the
central
place,
but
that
might
not
be
the
same
for
your
culture,
so
this
is
kind
of
like
our
build
contract.
A
We
have
some
some
several
contracts
that
I
try
to
define
and
how
we
do
things
here.
So
these
are
kinda
the
things
that
that
projects
when
they
come
on
our
platform.
We
said
this
is
what
you
need
to
do.
One
way
to
talk
about
building,
so
I'm,
not
gonna,
go
through
Allen
in
detail,
just
gonna
leave
it
up
there.
So
you
can
read
it
yourself.
A
Okay,
so
now
we
thought
about
how
we
build
stuff
and
when
you're
done
building
you
need
to
deploy.
You
need
to
get
things
out
there,
because
just
having
a
docker
image
in
a
in
a
in
a
docker
registry
doesn't
mean
anything
right
so
again,
I'm
going
to
show
you
a
little
bit
of
how
we
used
to
do
it
and
we
used
to
do
it
like
this.
A
We
are
there
three
homemade
tools
since
we're.
In
Norway
there
was
a
Norwegian
name
for
all
these
tools.
I
tried
to
translate
into
to
English.
In
the
best
way
it
was
a
command-line
tool
or
a
server
tool
called
deploy
tool
and
a
web
tool
up
there
and
at
the
bottom
of
the
right.
We
had
a
service
that
held
States
about
everything
that
was
running
so
when,
when
you
deploy
an
application,
you'd
fetch
some
configuration
from
a
get
file,
then
you
fetched
deliver
bundle
from
nexus.
A
Remember
the
same
thing
that
we
used
to
build
earlier
and
that
had
some
more
metadata
information.
So
you
could
compose
together
some
configuration
here
and
when
you,
when
the
troll
read
all
that
it
will
deploy
the
application
to
a
virtual
server,
so
it
didn't
set
up
the
server
for
uni.
You
need
they
had
a
server
in
place
before,
but
when
you
had
the
server,
you
can
just
use
this
tool
to
get
the
application
running
and
then
again
it
was
up
to
the
application
here
to
register
itself
with
the
lookup
service
manually.
A
So
that
was
something
that
they
had
to
do
right
now.
This
is
like
this,
so
we
have
some
new
tools
here.
They
kind
of
feel
the
same
need.
That
is
intentional,
that
we
want
tools
that
embrace
the
culture
and
try
to
fulfill
the
same
needs
that
we
had
before.
So
we
have
a
command-line
tool
called
a
oh
and
a
GUI
application
that
is
called
the
console
and
they
both
talk
to
an
API
that
does
the
heavy
lifting.
A
We
have
a
compostable
configuration
format
that
I'm
going
to
talk
to
you
a
little
bit
about
after
this
that
we
read
from
gates
and
then
we,
the
API,
will
add
and
apply
objects
to
curb
rebus
and
that
will
again
deploy
the
application.
So
we
don't
use
helm
because
hyung
went
stable
like
in
January.
That
is
like
two
years
late
for
us,
because
we
will
be
none
in
journey
for
a
while.
Are
we
going
to
use
humm?
We
don't
know
if
it
gives
us
value,
maybe
so,
when
we
deploy
an
application.
This
is
what
happens.
A
I'm,
not
sure
how
many
of
you
are
familiar
with,
with
the
open
shift
and
image
streams.
Okay,
so
not
very
many.
So
an
image
stream
is
basically
a
component
that
runs
in
kubernetes,
it's
on
its
way
downstream
from
OpenShift
into
Cabrini's
that
you
can
listen
to
a
targeted
or
image,
and
if
that
is
updated,
you
can
set
the
image
in
your
deployments
for,
in
our
case,
deployment
config.
But
it's
the
same
almost
the
same.
So
when
that
is
done,
it
will
then
create
a
replica
controller
or
replica
set.
That's
the
new
name.
A
A
So
that
is
why
I
got
the
version
with
name
one
two:
three
now
when
I
push
application,
one
three,
oh,
when
a
build
application
want
for
you,
I
don't
have
to
do
anything
because
my
specification,
my
intent,
is
to
run
version
1
and
in
the
build
process.
When
we
build
one
three,
oh,
we
will
push
the
one
tag
to
the
docker
registry,
so
the
new
application
is
automatically
rolled
out,
and
this
is
also
why
the
patching
works
right,
because
the
passing
works
in
the
same
way.
A
So
you're
a
config
like
I
mentioned
earlier,
is
a
composable
declarative,
configuration
format
right
now.
It
lives
in
gates.
We
have
considered
to
create
a
CR
D
for
it
to
have
the
Stadion
kubernetes,
but
we
don't
at
the
moment
right
now.
It
lives
in
gate
and
it
has
four
main
types
of
configuration
that
you
can
add
to
it
at
the
top.
You
have
a
global
file
that
is
called
about
and
it
lives
in
your
root.
A
Folder
there
you
can
set
settings
that
are
applicable
for
all
applications
for
one
team,
so
each
team
has
their
own
configurations
repo,
then,
for
each
application
you
have
a
base
file
for
our
application.
That
sets
information
about
the
basic
property
of
all
permutations
of
your
applications
and
just
the
reason
why
we
do
all
this
is
because
for
us
we
work
with
Texas,
so
testing
in
production
for
us
can
be
hard
for
sometimes
and
getting
testing
right
is
very
important.
A
We
have
lots
of
people
on
each
team
that
work
with
testing
and
quality
assurance,
because
sometimes,
if
we
do
a
calculation
wrong
and
send
that
out
to
somebody
the
interest
rate
of
that
being
wrong
can
be
so
huge
that
you
won't
believe
it.
So
we
need
to
push
things
out.
We
need
to
be
very
sure
about
quality
before
we
push
it
out
now.
A
So
I
see
time
is
running
here,
so
I
need
to
speed
up
a
little
bit.
These
are
examples
of
these
four
files.
You
have
a
global
file
at
the
top.
You
have
a
base
file
here,
an
environment
file
here
and
an
application
file
here
and,
as
you
can
see,
I
specify
purge
here
and
I
could
specify
version
here
as
well.
So
will
the
final
example
will
look
like
this,
so
this
is
kinda.
A
A
A
A
I've
tried
to
show
you
now
during
this
first
part
of
my
talk
that
we,
we
kind
of
feel
that
and
pray
embracing,
LASEK
existing
culture
that
you
have
is
important
like
admitting
that
this.
These
are
the
things
we
used
to
do
before,
and
there
are
gonna
may
not
lots
of
new
things
that
you
need
to
learn
and
of
old
things.
You
need
to
unlearn.
A
You
should
also
create
customized
tools
if
you
like,
like
dimension
Legos
earlier
today,
like
create
your
own
Legos.
If
you
feel
that
you
need
it,
build
upon
the
Lego
blocks
that
you
already
have
to
create
something
that
works
for
you,
so
we
created
a
known
or
own
congregation
format,
because
we
have
like
a
big
configuration
matrix.
We
need
our
back.
We
need
sane
defaults
in
corporate
standards,
so
these
are
kind
of
the
reasons
why
we
create
our
books.
If
that
is
right
for
you,
I
don't
know,
but
for
us
it
gives
a
lot
of
value.
A
So
now
on
to
external
integrations,
we
have
lots
of
things
outside
of
the
clusters
that
we
need
access
to
inside
the
clusters.
These
this
is
an
example
of
how
it
was
before
on
a
virtual
server.
You
need
to
push
large
Splunk
you.
You
often
need
an
Oracle
databases
or
to
have
States,
you
need
a
certificate,
and
you
need
to
open
some
firewalls
for
external
users
and
for
internal
users
need
to
open
firewalls.
A
So
before
all
of
these,
all
of
these
processes
were
manual,
so
we're
talking
weeks
to
set
up
the
server
before
you
can
set
up
the
application
right
now.
It's
like
this,
so
it
looks
very
familiar
very
similar,
that
is
by
design
again
you
embrace
what
you're
already
having
you
just
build
on
it.
The
difference
here
is
that
everything
here
is
automated.
A
A
So
that
is
kind
of
the
key
lesson
here
is
that
you
should
automate
all
existing
infrastructures
and
standardize,
because
if
one
of
these
parts
are
not
automated,
then
you
basically
can't
deploy
new
things
really
fast.
Then
you're
slowed
down.
So
it's
like
the
speed
of
the
slowest
one.
Is
they
just
get
the
speed
of
the
slowest
one
up
focus
on
that?
A
But
if
you
react
to
some
annotations
and
labels
and
create
some
of
the
resources,
how
will
you
get
the
answer
of
that
process
to
your
user?
Think
about
that
I
don't
know
if
anybody
has
a
really
good
solution
to
that
on
the
operator
pattern,
but
if
anybody
has
I
would
be
really
interested
to
talk
to
them,
because
for
us
right
now
we
just
annotate
the
resource
with
the
error
message
and
we
show
it
to
the
end-user.
So
if
anybody
has
to
be
a
good
solution
to
that
feel,
free
to
grab
grab
me
afterwards.
A
So
how
do
we
run?
Applications
we
have
now
built
showed,
showed
how
we
build
applications,
how
we
deploy
them
and
how
we
integrate
the
mid
or
existing
infrastructure.
So
how
would
do
we
run
them
again?
This
is
how
we
used
to
do
it
this
lookup
service.
You
might
recognize
this
from
the
picture
earlier
about
deploying
when
an
application
in
the
old
infrastructure
was
deployed.
A
It
would
register
itself
with
a
lookup
service
and
actually
it
will
continually
ping
the
lookup
service
during
its
lifetime
to
say:
hey,
I'm,
alive
I'm,
alive
I'm
alive,
and
we
have
a
separate
ops
board,
that's
kind
of
a
board
for
operators
of
applications
to
go,
look
at
the
status
and
they
will.
They
will
use
the
status
from
this
lookup
service
here.
A
Another
aspect
that
the
status
of
the
lookup
service
is
used
for
is
for
load,
balancing,
so
load,
balancing
the
old
way
was
kind
of
client
side
load,
load,
balancing
a
client
reads:
state
from
the
lookup
service
to
get
the
endpoints
for
other
applications
that
are
running,
and
it
will
just
manually
select
one
of
them
and
use
that
IP
and
port
to
call
this
service.
So
it's
entirely
client
driven.
So
this
was
what
it
used
to
be
right.
Now,
it's
like
this,
so
the
application
will
just
use
load
the
load,
balancing
facilities,
studies
in
the
platform.
A
We
don't
use
the
clients
at
all,
but
anything
more
be
used
like
DNS
things
and
when
it,
when
it
comes
to
looking
at
the
service,
you
see,
there
is
no
lookup
service
anymore.
The
lookup
service
is
now
the
kubernetes
cluster
that
has
all
our
states
and,
in
addition,
each
application
here
implements
a
contract
with
the
API
itself
that
we
also
connect
you
to
fetch
information
about
this
application.
That
can
be
what
kind
of
dependencies
do
you
run?
A
Now
what
you
can
see
about
both
of
these
two
solutions
is
that
you
see
a
lots
of
information
from
a
few
things,
but
for
us
we
want
to
see
the
opposite.
You
want
to
see
a
little
bit
of
application
for
many
things,
so
this
is
what
this
is.
What
we
have
made.
This
is
the
wall
board,
as
we
call
it.
It's
name
like
this
because
we
run
it
on
TVs
in
our
different
locations.
This
shows
lots
of
applications.
A
Each
of
these
squares
is
an
application
with
a
version
and
a
status
that
is
enormous
by
the
colors,
so
we
can
see
with
a
glance.
How
does
everything
run
and
the
reason
we
do
this
is
because
this
was
something
that
the
operators
will
already
used
to.
They
already
had
the
ops
board.
They
wanted
something
that
was
similar,
so
we
gave
them
something
that
was
similar.
A
So
this
is
a
runtime
contract.
We
want
people
to
create
microservices.
If
they
follow
12
factors,
then
it's
there
normally
they're
fine,
and
we
have
this
management
interface
that
works
kind
of
like
spring
with
actuator.
If
you're
familiar
with
that-
and
we
have
some
settings
regarding
logging,
so
this
is
kind
of
abstract.
A
How
can
I
do
this?
How
can
I
like?
Is
this
an
easier
way?
Yeah,
that's
nice!
Anyway,
we
have
a
tailored
service
template
that
is
available
in
github.
That
can
show
we
put
it
on
github,
so
everybody
else
can
see
as
well,
but
it's
mostly
for
our
internal
users.
How
can
you
create
an
application
that
follows
most
of
the
demands
of
the
platform?
How
can
you
easily
get
started?
How
do
you
expose
metrics
right?
You
expose
the
management
interface,
you
start
up
correctly.
A
So
we
don't
declare
what
test
environment
you
are
gonna,
deploy
your
application
in
in
the
build
pipeline.
We
declare
it
beforehand,
there's
a
loose
coupling
here.
So
if
one
team
wants
to
deploy
a
build
applications
to
five
different
namespaces
in
five
different
configurations,
that's
fine,
but
the
coupling
is
loose.
So
you
can
decide
for
yourself
leverage
the
platform,
leverage,
the
power
of
the
label
selectors
and
everything
else
you
have
there.
A
And
use
the
Lego
blocks
alexis
showed
earlier
today,
Legos
and
I
think
Legos
are
really
appropriate.
Here,
I
mean
kubernetes
is
Legos,
openshift
is
Legos.
Are
our
platform
is
also
Legos
I
made
them
in
one
sitting
in
the
second
row
here
it
works
on
another
part
of
the
Norwegian
government
and
they
have
also
they
use
our
stuff,
they
forked
our
stuff
and
they
used
our
stuff,
and
that
makes
me
really
happy.
Thank
you.
A
So
I
think
it's
very
very
nice
when,
when
other
people
can
do
that
and
use
the
Legos
for
what
it
is
to
create
a
system
that
fits
what
you
want
so
create
a
platform
that
fulfills
your
needs,
the
needs
of
your
organization
and
WiiWare
of
the
hype,
because
I
feel
there's
a
lot
of
hype
around
this
platform.
At
the
moment,
because
I
mean
you
can't
even
say
communities
before
something
new
has
happened
for
some
new
versions
out
for
something
new
is
there
I
mean
third-party
resources?
They
were
there
and
boots.
They
were
gone
now.
A
We
have
see
a
decent
set
right
so
be
aware
and
when
you
decide
kind
of
what
you
want
to
do
here,
remember
that
it
is
for
us
we're
governments,
I,
don't
know
man,
how
many
of
you
are
government
to
work
in
big
organizations,
but
you
should
is
rock
solid
if
you
want
to
play
with
unstable
stuff
on
your
own
clusters
play
coasters,
we
have
two
of
them.
We
play
with
this
all
the
time
by
the
way.
So
if
you
want
to
do
that
on
your
play,
cursors
go
ahead
and
do
that.
A
But
when
you
are
in
your
production
clusters,
don't
use
what
is
on
top,
don't
use
the
better
stuff
for
the
or
the
tech
preview
stuff,
because
at
the
end
of
the
line,
you
really
want
your
platform
to
be
boring
because
I
mean
should
this
be
exciting.
I
think
not
I
want
this
to
work
and
I
want
it
to
work
every
time.
I
want
it
to
be
predictable
and
I.
Don't
want
it
to
be
I.
Don't
want
surprises
so
when
I
run
a
deploy
command,
I,
don't
want
surprises.
A
A
How
we
manage
aggregated
logging,
okay,
each
node-
has
a
process
that
all
applications,
basically
log
to
an
empty
dear,
that
is
in
Tampa
fest,
and
that
will
each
node
will
then
read
that
and
forward
it
to
the
logger,
because
that
was
the
way
to
do
it
back
in
the
day.
So
now
we've
not
we're
using
at
looking
at
fluency
and
the
new
enterprise
connected,
but
we
don't
use
that
currently.
A
A
We
don't
have
any
state
now
and
it
answers
all
of
the
applications
that
run
here
now
are
stateless.
We
have
the
stayed
in
Oracle
like
outside
of
the
clusters.
We
are
looking
at
some
applications
that
are
going
to
migrate
over
that
have
states
that
are
stateful,
and
so
we
haven't
basically
looked
at
that
yeah.
So
we
aren't
calm
that,
for
you.