►
From YouTube: Agile Architecture and NFR in a Cloud Native Design
Description
There is a presumption in the industry that with the advent of cloud and agile processes , having a solution architecture practice is sometimes a hindrance. The prevalent idea is - we can just use the tools provided , and call them one by one , no need for architecture design . I want to focus the talk on how NFRs help in designing a Cloud native solution , and the important role the Solution Architect plays within an enterprise .
At the end of the talk , I want every developer/cloud engineer/k8 operator to understand , that no matter , what role they play within the enterprise , it still pays to think about architecture. I also want to focus on how having a central architecture / CCOE team , that deploys best practices , patterns , and principles across the enterprise , can help , and how to setup such a team in an organization .
A
A
warm
welcome
to
all
of
you.
Thank
you
for
attending
the
second
edition
of
kubernetes
community
days,
bangalore
shout
out
to
the
kcd
bangalore,
organizing
team,
especially
kevan,
aravind
and
prithvi,
who
really
helped
me
a
lot
in
putting
together
this
topic.
I
hope
you
all
have
a
wonderful
session,
so
today's
topic
is
agile
architecture
and
nfr
non-functional
requirements
in
a
cloud
native
design.
A
A
So
what
is
the
agenda
for
today?
So
this
is
a
lightning
talk
around
10
to
15
minutes,
and
I
will
briefly
touch
on
the
context
and
background
what
is
architecture?
Who
are
what
are
architects?
Why
does
architecture
matter
what
are
nfrs
or
non-functional
requirements
in
architecture,
and
how
does
this
link
with
cloud-native
architectures?
A
So,
let's
start
with
some
context
from
physical
machines
to
vms
virtual
machines
to
containers.
We
have
really
come
a
long
way
earlier.
Our
focus
was
on
on-prem
systems,
then
we
went
on
a
modernization
journey
to
cloud-based
workloads
and
now
the
talk
of
the
term
is
cloud
native
architectures,
as
all
of
us
know,
kubernetes
and
all
of
that
docker.
A
But
do
you
know
what
has
stayed
the
same?
I
missed
all
these
technology
innovations
and
new
technologies
and
kubernetes
and
containers
and
docker
and
serverless
what
has
stayed
the
same.
The
business
requirements.
They
have
not
changed,
so
the
business
necessarily
does
not
care
about
kubernetes
or
whether
you
are
using
promoters
or
whether
using
githubs.
They
are
only
concerned
about
their
business
outcome.
A
So
while
we
will
have
new
frameworks
and
new
technologies
and
they
will
obviously
work
as
a
catalyst
in
unlocking
new
opportunities,
but
the
requirement
for
a
well
architected
workload
that
can
help
serve
the
business
use
case
will
always
take
the
same.
It
will
never
go.
Sometimes
we
engineers
are
extremely
influenced
by
new
technologies
and
toolkits,
like
say,
for
example,
any
new
shiny
thing
that
is
available
in
the
market,
but
we
should
never
undervalue
or
ignore
the
essence
of
everything
which
is
architecture,
so
the
requirements
for
scalability
for
fault,
tolerant,
perform
and
workloads.
A
These
requirements
are
not
new
requirements.
They
have
not
come
up
because
of
this
cloud
native
revolution.
This
requirements
was
always
there
and
no
matter
what
technology
framework
or
paradigm
we
choose.
We
must
always
ensure
we
do
not
compromise
on
the
basic
architectural
talents,
so
that
is
very
important
to
focus
on
the
basic
architectural
concepts,
practices
and
patterns.
A
So
I
know
most
of
us
are
very
interested
in
learning
new
learning,
new
things.
We
want
to
go
into
this
new
shiny
world
of
containers
and
container
orchestration,
like
humanity
stalker
all
of
that,
but
we
might
only
be
able
to
give
better
value
to
our
end
users.
If
we
take
a
step
back
to
so
to
achieve
some
competency
on
cloud
native
architectures,
we
need
to
start
here
from
architecture.
A
So
what
is
architecture?
This
is
the
first
question
that
comes
to
our
mind
right.
What
is
architecture,
how
can
we
easily
define
architecture?
So
this
is
a
very
complicated
definition
of
architecture,
the
fundamental
organization
of
a
system,
its
relationship
to
each
other,
but
this
is
not
consumable.
This
is
a
kind
of
a
definition
that
is
good
for
an
ieee
definition,
but
it's
not
good
to
consume
right.
So
this
is
another
definition,
which
is
a
little
bit
better
than
that
definition.
A
So
here,
grady
booch
defines
architecture
as
a
set
of
significant
design
decisions
that
shape
a
system
that
shape
the
structure
and
behavior
of
the
system.
Where
significance
is
measured
by
cost
of
change
again.
This
is
a
much
better
definition
than
ieee
one,
but
still
not
a
good.
This
is
a
very
good
definition
by
martin
fowler.
He
says
architecture
is
a
set
of
design
decisions
that
must
be
made
early.
Okay,
now,
coupled
with
that,
if
we
get
this
definition
by
matthew,
parker
also,
who
says
architecture
are
decisions
which
are
hard
to
reverse.
A
So
if
I
combine
martin
fowler
and
this
guy's
definition,
then
what
is
architecture.
Arctic
architecture
can
then
be
defined
as
those
design
decisions
that
must
be
taken
early
on
in
the
project
life
cycle
because
they
are
very
hard
to
reverse
later
on
because
reversing
those
decisions
reversing
those
architectural
concepts
or
practices.
There
is
a
huge
cost
involved
in
terms
of
money
in
terms
of
effort,
and
all
of
that,
so
any
decision
that
needs
to
be
taken
early
on
can
be
regarded
as
an
architectural
decision.
A
So
some
example,
one
of
the
example
could
be
whether
you
go
with
a
synchronous,
api
based
communication,
or
you
go
with
an
asynchronous
message:
bust
based
communication.
So
this
can
be
treated
as
an
architectural
decision.
This
is
a
decision
you
need
to
take
early
on
because
it
might
be
very
difficult
to
move
from
a
synchronous
to
asynchronous
or
asynchronous
to
synchronous.
There
might
be
some
cost
involved
with
it
in
terms
of
effort
in
terms
of
financial
cost,
resourcing
all
of
that.
A
So
now
we
understand
what
is
architecture
right,
architecture
set
of
decisions
that
needs
to
be
taken
early
on,
because
changing
them
later
has
an
impact.
But
then
what
are
architects?
So
this
diagram
is
a
very
nice
diagram.
As
you
can
see
here,
I
am
showing
a
cube
in
the
left.
The
person
is
seeing
it
as
a
circle
in
the
right.
The
person
is
seeing
it
as
a
rectangle,
but
the
reality
is
more
complex,
so
there
are
different
perspectives
right.
Somebody
might
think
that
this
is
like
a
circle.
A
Some
might
think
is
a
rectangle,
but
it's
an
architect's
job
to
have
an
holistic
overview
of
the
system
and
say
that
no,
this
is
neither
a
circle
nor
a
rectangle,
rather
a
cuboid,
so
an
architect
must
have
a
holistic.
Understanding
of
the
system
is
very
important
and
there
might
be
a
different
spectrum
of
views
and
viewpoints,
and
they
need
to
take
care
of
all
of
these
different
perspectives
and
then
come
up
with
an
holistic
view.
A
So
this
is
an
architect's
idea,
and
I
really
like
this
quote
by
gregor
hoff,
who
says
an
architect
doesn't
have
to
be
the
smartest
person
in
the
room.
Instead,
they
make
everyone
else
smarter.
How?
By
having
that
holistic
view
of
the
system
helping
the
team,
take
those
architectural
significant
decisions
that
needs
to
be
taken
early
on
in
the
project
and
not
later,
but
then
why
do
we
need
architecture?
This
is
another
very
important
question.
We
know
who
are
architects.
We
know
what
is
architecture,
but
why?
So?
This
is
a
very
nice
code.
A
If
you
think
good
architecture
is
expensive,
try,
bad
architecture,
so,
architecture
matters.
Why
does
architecture
matter?
Because
without
having
a
good
architecture,
you
will
lose
the
ability
to
respond
to
your
business
needs
you?
It
will
become
very
hard
for
you
to
ship
new
features
to
support
your
customers.
Why?
So,
let
us
go
with
this
graph,
which
is
called
design,
stamina,
hypothesis
again
by
martin
farmer.
So
if
you
see
this
red
arrow,
this
is
an
architecture,
good
design,
architecture
graph,
whereas
this
graph,
which
is
the
blue
one,
has
no
design.
So
this
is
the
no
design.
A
This
is
a
good
design
or
good
architecture.
The
blue
curve
is
obviously
a
little
ahead
in
the
beginning,
but
in
the
next
part
you
see
the
velocity
decreases.
Why?
Because
the
system
is
not
well
architected,
if
you
are
changing
something
in
the
left,
something
is
breaking
in
the
right.
Nothing
is
working.
You
cannot
build
new
features,
something
is
breaking
or
some
it's
not
modular
enough.
A
It's
not
extensible
enough,
because
there
is
no
good
architecture
involved,
whereas
this
red
light,
you
can
redline,
you
can
consider
as
a
good
architecture,
maybe
initially
it
is
a
little
bit
behind,
but
over
time
it's
because
of
its
modular
nature.
Because
of
its
loosely
coupled
nature,
you
can
add
on
good
features
without
compromising.
So
this
is
the
reason
why
we
need
good
architecture.
This
is
very
important
to
understand.
So
what
is
agile
architecture
so
agile
architecture?
A
Is
this
pathway
from
immediate
architecture
to
architectural
intent,
this
road
map,
so
from
immediate
architecture,
which
is
my
current
architecture
to
this
architectural
intent
and
the
good
thing
with
agile
architecture?
Is
both
your
immediate
architecture
and
your
architectural
intent
will
evolve
over
time.
So
the
roadmap
is
this
journey
from
this
immediate
to
the
final
goal
to
the
architectural
intent.
So
obviously
there
will
be
differences,
but
they
need
to
be
aligned.
A
A
Not
having
a
design
based
on
strong
architectural
foundation
will
ultimately
lead
you
to
not
being
able
to
achieve
business
objectives.
This
is
very
important,
so
architecture
is
an
extremely
complicated
topic.
It
has
design
business
strategy,
human
dynamics,
id
and
vm
all
of
this,
but
to
start
the
journey
we
should
focus
on
something
which
is
quantifiable,
and
that
is
in
a
first
or
non-functional
requirements.
What
are
any
first
scalability
reliability,
efficiency,
security,
maintainability,
extensibility,
testability
observability.
These
are
just
some
of
the
universe.
A
There
are
many
more
like
performance
cost
effectiveness
as
a
cloud
or
a
software
architect.
Our
job
is
to
ensure
that
our
design
is
compliant
with
this
enablers.
If
my
design
is
compliant
with
this
nfl,
then
it's
automatically
scalable
it's
automatically
reliable.
Then
I
automatically
get
a
well
architected
design.
A
What
is
the
most
important
thing
that
I
need
to
focus
on
is
that
the
essence
of
architecture
has
remained
the
same.
We
have
gone
from
say,
for
example,
from
vms,
to
containers,
to
container
orchestration
to
server
list,
but
the
architecture
lessons
had
not
changed,
so
everything
has
stayed
the
same.
This
constraints
and
the
attributes
like
scalability
reliability,
performance,
effectiveness,
disability.
These
are
not
new
things.
These
have
stayed
the
course
of
time.
A
They
were
important
even
in
the
data
center
applications,
and
they
are
important
even
now,
even
sometimes
more
than
they
were
before
so
moving
on
migrating
to
the
club
does
not
mean
that
you
need
do
not
need
to
think
about
scalability.
You
do
not
need
to
think
about
efficiency.
You
need
to
think
about
them,
even
when
you
are
in
the
cloud
or
even
cloud
native.
The
same
constraints
are
present
in
cloud
also,
but
the
tool
chain
available
is
more
robust
and
much
more
easier
to
consume.
A
Even
if
you
see,
for
example,
at
a
high
level,
the
aws
well
architected
framework,
so
it
has
the
same
principles:
reliability,
security,
operational
experience,
xp
excellence,
cost
optimization.
These
are
all
the
same
things.
These
are
all
the
same
non-functional
requirements.
I
was
talking
to
you
about
now.
Let's
come
to
cloud
native,
so
we
all
know
what
is
cloud
native
cloud
native
is
the
new
way
of
working
with
cloud
to
take
the
full
power
of
the
cloud
and
it's
based
on
a
lot
of
principles
and
practices.
These
are
some
of
the
principles
right
now.
A
What
if
I
say,
I
take
one
of
these
principles:
okay,
and
I
try
to
prove
to
you
that
this
is
just
an
extension
of
the
same
non-functional
requirements
that
we
discussed,
so
we
have
already
discussed
nfrs.
Now
we
are
in
cloud
native
principles.
What
if
I
can
relate
the
truth?
So,
let's
take
an
example.
One
of
the
key
principles
of
cloud
native
architecture
is
immutability.
What
does
that
mean?
That
means
an
infrastructure
should
not
be
modified
in
place
after
deployment.
A
Rather
than
modifying
the
infrastructure,
I
should
have
an
automated
way
of
creating
another
instance
of
the
infrastructure
or
application.
This
means
that
I
have
an
automated
pipeline
that
can
help
me
deploy
that
application
again
so
say,
for
example,
my
application
goes
down.
I
can
leverage
that
same
pipeline
to
deploy
it
again,
so
immutability
or
immutable
architecture
is
actually
leading
the
way
to
reliability.
A
So
reliability
was
the
nfr
I
discussed
earlier,
whereas
immutability
is
a
cloud
native
principle,
so
they
are
kind
of
linked.
That
is
the
idea
I'm
trying
to
push
here
that
these
are
not
new
things.
These
are
all
linked.
So
in
conclusion,
what
I
want
to
explain
here
and
what
is
the
kind
of
message
that
I
want
to
push
forward-
is
that
non-functional
requirements,
so
the
basic
essence
of
architecture
has
not
changed
earlier.
We
were,
for
example,
in
from
monolith
to
microservices
to
even
based
systems,
from
virtual
machines
to
containers
to
container
orchestration
to
serverless.
A
The
tool
chains
have
evolved,
the
the
flavors
have
evolved,
but
the
basic
tenants
of
cloud
native
architecture,
the
non-functional
requirements
like
scalability
performance.
They
have
not
changed.
If
you
can
design
something
which
respects
the
non-functional
requirements
of
your
business,
then
you
will
automatically
get
a
well
architected
system.
Now
that
well
architecture
system
can
be
implemented
using
cloud
native
tool
chains.
It
can
be
implemented
using
containers,
they
are
very
compatible.
That
is
true.
A
A
We
should
not
lose
focus
on
the
tenants
of
non-functional
requirements.
They
are
still
as
relevant
as
ever.
We
should
always
ensure
that
we
respect
the
non-functional
requirements
of
our
architecture.
We
always
should
try
to
have
good,
well
architected
systems
that
have
an
agile
approach
to
architecture
and
that
respects
the
non-functional
requirements
like
scalability
performance
availability,
so
the
cloud
might
be
new
cloud
native
might
be
new
cuban.
It
is
my
opinion
today
there
is
q
when
it
is
tomorrow.
A
There
might
be
something
else,
but
if
we
as
a
whole,
as
an
architectural
community,
as
a
iit
community,
keep
our
focus
on
the
basic
non-functional
requirements,
the
basic
architectural
principles
and
tenants,
we
will
end
up
with
good,
well
architected
workloads.
Thank
you.
I
hope
you
had
a
great
session
and
I
hope
you
have
a
great
kcd
2022
also
take
care.