►
From YouTube: An Introduction to Infrastructure as Code
Description
If you've even slightly dipped your toe into the cloud world, then you've probably been told that Infrastructure as Code or IaC is how you should be deploying your cloud resources. But what does this mean, what is IaC? If you write a bit of PowerShell, isn't this IaC, and most importantly what is the benefit of using IaC?
In this session, we will start from the very basics of what IaC is, why you might want to use, and what it's going to bring that will make your life better. Along the way, we will look at some examples and see it in action. By the end of the session, you should be clear on what IaC means to you, and how you can get started with using it in your cloud environment
A
Just
thinking
about
it,
well,
hello,
everybody
we're
live
on
the
net
foundation,
youtube
for
the
virtual
user
group
and
we're
here,
I'm
from
south
florida
and
sam
here
is
from
uk,
and
this
is
part
of
the
microsoft
cloud.
South
florida
user
group
presentation
and
we're
also
this
today
we're
doing
it
via
the
live
stream
that
that
net
foundation
supplies.
So
I'm
also
a
volunteer
with
the.net
foundation,
and
if
you
get
a
chance,
you
can
go
over
there
and
check
it
out.
A
There's
actually
there's
a
speaker
area
now
where
you
can
submit
yourself
as
a
speaker,
and
I
got
some
feedback
here
and
you
can
also
get
support
for
your
meetup.
If
you
have
a
meet
up,
you
can
get
the
free,
meetup
posting
and
then
you
can
also
request
support
to
have
you
know,
live
stream,
support
and
and
demand
generation
for
your
user
group.
So
anyway,
with
that
I'm
gonna
let
sam
take
it
from
here
and
thanks
for
coming.
B
No
problem
well
good
evening.
Everyone,
as
mentioned
my
name,
is
sam
samkogen,
I'm
a
microsoft
mvp
from
the
uk
and
I
work
as
a
solutions
architect
for
a
company
called
willis
watson,
and
I
spend
my
day
working
with
microsoft,
azure
and
in
particular
I
spend
a
lot
of
time
working
with
infrastructure
as
code
and
deploying
resources
into
the
cloud,
and
so
today
we're
gonna
have
a
session
that
that
looks
at
what
infrastructure's
code
is
and
gives
a
bit
of
an
introduction
as
to
why
this
is
something
you
might
be
interested
in
and
how
to
get.
B
Started
yes,
as
I
mentioned,
I'm
based
in
the
uk,
and
I
I
do
a
lot
of
community
stuff
around
microsoft,
azure
and
other
things,
you'll
find
there's
a
lot
of
information.
I
put
on
my
blog
at
samkogen.com
if
you're
interested
and
if
you
want
any
of
the
slides
or
the
code
samples
from
today's
session,
you'll
find
them
on
github
as
well
at
github.com
kogan.
So
you
can
see
them
all
there
and
I'll
provide
those
links
on
twitter
as
well
afterwards,
if
you're
interested.
B
So
we're
going
to
start
off
first
of
all,
looking
at
what
is
infrastructure
as
code
and
what
it's
all
about,
and
why
it's
something
you
might
be
interested
in
having
to
pick
up.
So
if
you
look
at
the
sort
of
the
definition
of
it,
it's
it's
what
it
says
here:
it's
provisioning
resources
using
machine,
readable
definitions,
okay,
what
does
that
actually
mean?
In
particular?
B
What
do
we
mean
when
we
talk
about
modern
infrastructure
as
code,
because
in
reality
you
know
any
sort
of
provisioning
of
infrastructure
using
code
of
some
sort
could
be
considered
infrastructure
as
code.
So
writing
bash
scripts.
Writing
some
powershell
and
those
sort
of
things
could
be
considered
as
a
way
of
defining
your
infrastructure
as
code,
but
there's
a
quite
a
specific
meaning.
B
I
mean
that's
fine.
You
can
certainly
do
that,
but
it's
not
really
scalable
and
it's
not
something
you
want
to
be
doing
to
get
a
repeatable
infrastructure,
and
so,
as
we
move
into
that
cloud
world
and
and
in
particular,
as
more
developers
take
you
make
use
of
these
cloud
environments.
It's
no
longer
the
it
ops
teams
who
are
actually
managing
a
lot
of
these
resources
developers
are
building
them
themselves.
We're
moving
to
this
devops
mindset
infrastructure
as
code
is
something
that's.
That's
been
more
and
more
prevalent,
particularly
in
the
development
world.
B
So
when
we
talk
about
infrastructure
as
code,
what
would
particularly
in
the
modern
usage
there
are
a
few
traits
that
we've
got
here,
that
really
sort
of
document.
What
an
infrastructure
is
code,
language
or
tool
would
provide,
and
the
first
thing
and
probably
the
most
common
traits
between
any
of
the
tools
we're
going
to
look
at
is
that
they're
declarative.
B
So
this
really
sort
of
removes
the
bash
scripts
of
the
powershell
scripts
and
so
on,
where
you're
writing
imperative
code.
That
goes,
you
know
one
line
after
another.
What
you're
doing
with
most
infrastructure
as
code
tools
is
you're
declaring
what
you
want
to
see
what
you
want
to
be
deployed
and
caring
less
about
how
it
gets
deployed.
So
you're
saying
I
want
three
virtual
machines
and
some
storage
accounts,
and
I
want
them
in
this
region,
and
I
want
them
configured
this
way.
B
Give
me
those
you're
not
worrying
about.
You
know
how
you
actually
tell
the
cloud
platform
to
get
them
you're,
not
necessarily
worrying
about
handling
errors,
you're,
just
declaring
what
you
want
and
assuming
that
it
will
be
taken
care
of
for
you
in
combination
with
that
they
are
generally
idempotent,
so
that
if
you
run
the
same
piece
of
infrastructure
as
code
more
than
once,
it
will
give
you
the
same
result.
B
It
won't
do
something
different
the
next
time.
You
run
it
even
if
the
resources
already
exist,
whereas
you
know
if
you're
running
a
powershell
script,
for
example,
and
you
run
a
create
command
and
the
resource
was
already
there.
It'd
probably
give
you
an
error,
whereas
generally
a
declarative,
infrastructure's
code
tool
would
would
recognize
that
and
would
deal
with
it
and
would
give
you
the
same
result
at
the
end.
So
the
infrastructure
will
be
in
the
same
state
generally
they're
immutable,
or
at
least
that's
the
design
idea
behind
them.
B
B
Reusability
is
a
quite
a
big
thing,
so
you
want
to
be
able
to
take
your
code
that
you
write
as
infrastructure
as
code
and
and
use
it
more
than
once.
Just
like
you
would
with
a
you
know,
some
classes,
you
write
in
your
actual
programs.
You
want
to
be
able
to
to
make
them
generic
and
then
pass
in
some
parameters
and
reuse
them
to
create
your
development
environment
and
your
test
environment,
your
production
environment.
You
don't
want
to
have
to
write
unique
code
every
time
and
in
combination
with
that,
ideally,
you
can
make
them
modular.
B
So
not
only
are
they
reusable,
but
you
can
package
up
into
useful
modules,
your
infrastructure
as
code
and
pass
them
around.
Your
teams
share
them
with
the
community,
those
sort
of
things
so
maybe
you've
written
a
really
good
piece
of
infrastructures
code
that
will
deploy
a
virtual
machine
configured
in
a
certain
way
ready
for
use
by
a
certain
team,
and
you
want
to
be
able
to
pass
that
to
that
team
and
they
can
use
it,
but
you'll
still
manage
it.
B
You
can
create
use
reusable
modules
and
then,
lastly,
due
to
the
sort
of
the
declarative
and
the
odd
important
approach
here,
we
get
we
get
sort
of
built
in
the
ability
for
drift
correction.
So
if
all
of
our
infrastructure
is
actually
declared
in
the
code
file,
then
that
is
our
effectively
our
desired
state.
So
if
we,
then
we
run
that
piece
of
code
against
an
environment
that
maybe
somebody's
gone
into
manually
tweaked
and
we
didn't
want
them
to.
Then
it
should
reset
that
environment
back
to
how
we
define
things
in
our
code
file.
B
B
So
why
would
you
want
to
use
it?
Why
bother
moving
away
from
manually,
deploying
things
using
the
the
portal
or
writing
a
bit
of
powershell
and
so
on?
Again,
we've
got
some
some
tenants
here,
the
top
one
on
the
list.
There
is
about
consistency,
so
if
you're
deploying
things
manually
using
the
the
portals,
then
you
aren't
necessarily
going
to
get
things
working
or
getting
things
configured
the
same,
every
time
that
you
you
create
them
and
in
fact,
more
likely
than
not
you're
going
to
have
something
slightly
different.
B
Every
time
you
deploy
a
resource,
and
so,
if
you're
going
to
declare
without
in
your
infrastructure's
code
file
instead
and
just
rerun
that
when
you
want
to
create,
you
know
more
virtual
machines
or
so
on,
you
can
pretty
much
guarantee
that
your
virtual
machine
should
look
the
same.
Every
time
you
do
a
deployment.
B
You
don't
want
to
have
to
wait
for
some
complex
scripts
to
run
or
for
somebody
to
manually,
go
in
and
press
all
the
buttons
and
realize
that
they've
changed
set
something
wrong
and
go
back
and
so
on
so
infrastructure
as
code,
because
you've
already
defined
what
you
want
things
to
look
like
the
actual
deployment
time
is
going
to
be
fairly
minimal,
because
it's
just
running
your
code,
there
should
be
no
interaction
required.
You
should
be
able
to
just
run
your
code
and
get
your
resources
out.
The
other
end
pretty
quickly.
B
It's
very
rare
that
you're
actually
going
to
be
building
whole
environments
of
code
by
yourself
unless
you're
working
in
a
very
small
environment,
so
often
you're
going
to
be
collaborating
with
other
teams
or
with
other
people
on
your
team.
Maybe
you've
got
a
networking
team
that
deals
with
how
you
build
your
actual
networking
infrastructure,
and
then
you
want
to
layer
on
some
application,
infrastructure
and
and
so
on,
and
so
by
having
all
your
code
files
or
having
your
infrastructure
in
code,
you
can
collaborate
on
those
files.
B
Just
like
you
would
any
other
piece
of
code,
so
you
can
put
them
in
a
version
control
repository.
You
can
share
them
between
teams.
You
can
have
you
know,
code
reviews
you
can
have
pull
request
policies
and
so
on.
You
can
work
as
a
collaborative
team,
creating
those
resources
and
sharing
resources
between
the
teams
as
much
as
you
need,
because
it's
just
code
at
the
end
of
the
day.
B
Similarly,
because
it's
code,
you
can
also
use
it
as
a
sort
of
a
you
know:
accountability
and
change
management
tooling.
So
if
you're
going
to
put
these
things
into,
get
you
can
see
who's
made
changes.
You
can
see
what
the
difference
is
between.
You
know
what
you're
trying
to
deploy
today
and
what
was
in
deployed
last
week,
and
you
can
see
what
changes
are
being
made
and
we'll
see
some
demos
of
that
in
a
minute.
B
Scaling,
as
I
mentioned,
is
something
you're
probably
going
to
want
to
do
with
a
cloud
environment
you're
going
to
want
to
scale
up
and
scale
down
environments.
You
potentially
want
to
deploy
lots
of
environments.
You
want
to
create
test
environments
that
you
create
ad
hoc
and
then
tear
them
down
again.
B
If
you've
manually
got
to
go
with
and
create
more
virtual
machines
and
then
do
that-
that's
not
sustainable,
whereas
you
know
with
a
with
a
properly
created
infrastructure
as
code,
the
amount
of
virtual
machines,
you've
got
running
could
be
as
simple
as
changing
a
parameter
from
one
to
two
or
you
know
whatever
and
deploying
a
test
environment
could
be
as
simple
as
just
creating
some
extra
parameter
files
and
running
them
so
very
quickly.
We
can
scale
up
the
amount
of
resources
we
need
and
scale
down
again
when
we're
done.
B
Because
of
this
we
talked
a
bit
already
about
change
control
and
alongside
that,
we've
got
versioning.
So
we
can.
We
can
version
the
files
either
manually
or
we
can
put
them
in
a
version
control
system
and
keep
track
of
that,
and
also
again
because
this
is
just
code,
we're
writing.
We
can
test
it
and
I'll
show
you
some
demos
in
a
bit
about
how
we
can
test
your
infrastructure
as
code
files
and
then
finally,
your
infrastructure
as
code
becomes
part
of
your
documentation.
B
B
It's
already
documented
in
your
version
control
system,
and
you
know
you
see
who
actually
made
the
changes,
and
you
can
read
that
as
part
of
your
documentation
to
determine
what's
being
deployed
so
now
now
we
have
a
set
of
resources
that
allow
us
to
deploy
resources
very
quickly,
very
efficiently
and
with
a
lot
of
governance
and
change,
control
around
that
which
is
much
better
than
again
somebody
manually
going
in
and
clicking
some
buttons
and
then
forgetting
what
they
did
when
they
come
back
to
it.
A
month
later,.
B
So
we're
going
to
delve
into
some
of
the
tools
and
how
some
of
the
infrastructure's
code
works
now,
but
before
we
do
that,
I
just
want
to
bring
up
one
thing
here,
which
is
the
fact
that
we're
looking
here
at
infrastructure
as
code
and
there
is
a
difference
between
infrastructure
as
code
and
configuration
management
as
code,
and
they
are
two
sort
different
sets
of
tools.
We're
talking
about
writing
infrastructure
as
code
which
deploys
actual
resources.
So
virtual
machines,
storage,
accounts
web
applications,
all
those
sort
of
things,
whereas
configuration
management
usually
refers
to.
B
They
are
usually
something
that
goes
hand
in
hand
with
infrastructure,
as
code,
so
usually
you'd
use
some
of
these
infrastructure
as
code
tools
to
actually
deploy
some
virtual
machines.
And
then,
when
you're
done,
you
would
trigger
your
puppet
or
your
chef
system
or
whatever
to
then
go
and
configure
that
virtual
machine,
usually
by
passing
it
some
details
about
how
to
register
with
your
your
puppet
server
or
your
chef
master
or
whatever,
and-
and
it
would
then
take
over
from
the
infrastructure's
code
once
it's
finished.
B
So
we're
going
to
look
at
two
different
classes
of
infrastructure
as
code
toolings
and
we've
broken
them
down
into
into
those
that
are
provided
by
the
cloud
vendors
themselves.
So
each
of
the
big
cloud
providers
has
their
own
set
of
infrastructure
as
code
tooling,
you
can
use
with
their
cloud
and
then
we're
going
to
look
at
some
third-party
tools
as
well,
that
are
sort
of
vendor
agnostic
and
we'll
see
what
the
difference
is
and
when
you'd
like
to
use
one.
B
B
Okay,
so
we're
going
to
have
a
look
first
at
these,
these
cloud
vendor
toolings,
so
we're
going
to
concentrate
on
the
three
big
cloud
providers
so
at
aws,
azure
and
gcp.
Obviously
there
are
other
cloud
providers
who
may
have
their
own
tooling
as
well
and
they're,
probably
along
similar
lines
and
but
we'll
focus
on
these
three.
B
B
And
they
are
what's
being
different,
they
all
have
fairly
similar
traits,
so
they
are
direct
from
the
cloud
provider.
They
are
supported
by
that
cloud
provider.
So,
if
you,
if
you're,
if
you're
using
their
tooling-
and
you
have
problems
with,
they
will
generally
be
able
to
help
you
with
those
issues
and
they
are
most
of
the
time
going
to
get
updates
the
fastest.
B
So
when
you
deploy
resources
into
the
cloud
provider,
you're
creating
those
resources
actually
in
the
cloud
and
some
of
the
tooling,
particularly
when
we
look
at
the
third
party
ones,
will
actually
record
what
you're
doing
in
what
they
call
the
state,
and
so
this
allows
them
to
have
sort
of
a
history
of
what
you've
done,
have
a
way
of
keeping
track
of
what's
been
created.
What's
what's
been
destroyed
and
so
on
and
and
yeah?
That's
usually
something
you
have
to
manage
separate
to
your
cloud
provider.
B
So
these
cloud
provider,
tooling
native
tooling,
are
not
state-based,
so
they
effectively
use
the
actual
state
of
resources
in
the
cloud
as
their
state.
They
don't
have
a
separate
state
file
which
has
some
benefits,
because
you
don't
have
to
manage
that
state
file.
It's
not
something
you
have
to
care
about
and
look
after,
which
can
be
quite
painful,
but
you'll.
B
Other
things
in
the
negative
column,
obviously
each
of
these
tools
is
is
for
a
specific
cloud.
They
don't
work
with.
You
know
you
can't
use
cloud
formation
to
deploy
things
into
azure
or
anything
like
that.
There's
no
collaboration
between
the
cloud
providers,
so
you
are
limited
to
using
a
single
cloud,
they're
also
closed
source.
So
none
of
the
cloud
providers
actually
release
the
source
code
for
any
of
these
tools.
B
B
B
Assuming
you
are
talking
about
azure
blueprints,
then
yeah
they
are,
I'm
not
sure
I
would
bundle
them
into
the
infrastructure
as
code
bracket.
They
are
a
sort
of
a
higher
level
abstraction
which
can
include
infrastructure
as
code.
So
you
can
use
arm
templates
with
blueprints,
but
blueprints
are
doing
a
bit
more
than
that
in
the
terms
that
they
work
with
policy
and
governance
as
well.
But
yes,
they've
been
on
this
slide
and
perhaps
they
could
have
been
and
then
previous,
how
are
logs
analyzed
for
silent
non-ideal
states.
B
B
B
So
we're
gonna
have
a
quick
look
at
a
demo
now
so
again,
we're
gonna
have
a
look
at
the
sort
of
the
cloud
native
ones
and
we're
going
to
focus.
Look
here
looking
at
the
azure
tooling,
just
because
I'm
most
familiar
with
that
one
and
have
a
look
at
arm
templates,
so
arm
templates
or
azure
resource
manager
templates.
B
We've
got
a
template
file
here,
and
this
is
a
very
simple
template.
So
what
we're
trying
to
do
here
is
deploy
a
storage
account.
That's
all!
So.
We've
got
this
file.
You
can
configure
your
templates
to
actually
receive
parameters,
so
we're
passing
in
a
a
parameter
here,
called
storage
account
name
which
just
allows
us
to
vary
the
the
actual
name
of
the
storage
account.
So
we
could
reuse
this
template
to
deploy.
B
B
So
this
is
where
we
are
actually
creating.
The
storage
account
and
this
uses
a
syntax
as
defined
by
microsoft,
and
there
are
a
couple
things
you'll
have
on
every
resource,
so
every
resource
is
going
to
have
a
name
and
we're
just
passing
in
from
that
parameter.
So
this
uses
a
sort
of
function,
language
that
microsoft
have
created
here,
which
you
can
define.
I
want
to
use
that
parameter.
B
Then
we've
got
the
type
of
resource,
and
this
uses
a
naming
convention
again
that
microsoft
has
set,
which
is,
in
this
case,
microsoft,
storage
for
storage
accounts
and
then
an
api
version.
So
each
each
resource
in
in
azure
will
have
an
api
effectively
that
you
can
use
to
create
from
and
that
changes
over
time.
So
you
can
define
the
version
of
that
api.
You
want
we're
defining
some
tags.
B
We
define
the
location
that
the
resource
gets
to.
Deploy
to.
You
can
see
here,
I'm
not
actually
putting
a
a
real
location
in
what
I've
used
is
there.
There
are
some
built-in
functions.
You
can
use
a
sort
of
mini
programming
language
to
actually
define
certain
things.
In
this
case.
There's
a
resource
group
function
which
gets
me
information
about
the
current
resource
group
I'm
deploying
to
and
if
you're
not
familiar
with
azure
resource
group
is
basically
just
a
bucket
where
you
put
your
resources,
there's
a
folder.
B
If
you
want
so
I
can
get
the
information
about
the
resource
group
I'm
deploying
into,
and
I
can
just
grab
its
location.
So
everything
that's
going
into
that
resource
group.
I'm
deploying
is
going
into
that
location,
then
a
kind
which
is
these
big
parts
here
to
the
kind
and
the
sku
are
just
properties
that
are
defined
for
that
are
specific
to
a
storage
account.
So
a
storage
account
has
these
values
a
web
application
will
have
different
properties
that
are
specific
to
a
web
application.
So
in
this
case
it
needs
a
kind.
B
B
So
we
can
define
any
number
of
resources
in
this
resort
section
we
could
have
dependencies
if
we
wanted
to.
We
can
build
up.
You
know
quite
a
big
file
here.
If
you
wanted
to
to
actually
create
resources,
you
can
also
have
multiple
files
and
call
one
file
from
another
and
so
on.
So
it
is
a
you
know:
it's
a
fairly
complex
set
of
tooling
the
json
language
is,
you
know
you
talk
to
most
people
is
quite
verbose
and
there
are
there
is
efforts
going
on?
B
When
I
want
to
deploy
it,
I'm
passing
in
just
a
name
here
you
could
have
multiple
parameters,
files
or
maybe
I
had
a
development
parameters
file
and
a
production
parameter
file,
and
so
on.
At
the
time
I
come
to
deploy
the
resources,
I
would
tell
it
you
know
which
parameters
file
I
want
to
use,
and
it
will
pass
that
in
so
to
actually
deploy
the
resources.
B
But
you
can
see
here,
let
me
zoom
in
a
little
bit,
we've
got
those
two
files,
so
we
can
actually
deploy
arm
templates.
You
need
to
either
use
powershell
or
cli
to
to
do
to
basically
trigger
the
template.
You
can
also
pass
it
to
a
rest
api,
but
we're
gonna
use
powershell,
so
we're
gonna.
Do
the
new
az.
B
And
so,
as
I
mentioned,
we're
deploying
into
a
resource
group
which
is
just
a
holder
for
the
resources,
we
need
a
name
for
the
deployment,
so
we'll
just
call
it
a
resource
group
name.
So
I
think
I've
got
one
configured
here
yeah,
so
we've
got
an
arm
demos,
resource
group.
This
is
the
azure
portal,
if
you've
not
seen
it
before,
and
this
is
just
a
resource
group
I've
created
which
is
empty.
Currently.
B
B
B
In
this
case
it
checks
for
the
validation
of
the
storage,
account
name,
which
needs
to
be
unique,
and
that's
why
that
failed,
but
that's
going
to
go
and
run
now
and
that
will
take
a
a
little
while
I
mean
the
storage
accounts,
don't
actually
take
too
long
to
deploy.
But
obviously
you
know
you
are
waiting
for
resources
to
be
allocated
and
and
so
on.
B
B
B
So
these
tools
allow
you
to
create
again
infrastructure
as
code,
but
because
they're
third
party
they
generally
both
of
these
are
are
cloud
agnostic.
So
they
have
the
ability
to
create
resources
in
all
of
the
major
cloud
providers.
They
also
have
the
ability
to
look
at
other
resources
as
well.
That
aren't
you
know
specifically
cloud
providers,
so
you
can
use
them
to
create
resources
in
you
know:
aws
gcp,
azure,
but
also
things
like
dns
providers.
You
can
even
use
them
to
deploy
things.
You
know
some
things
on-prem
as
well.
B
They
have
a
lot
of
what
they
call
providers
available.
Most
of
them
have
they
both
have
50
plus
providers
that
you
can
actually
use
your
infrastructure
as
code.
So
if
you're,
you
know
looking
to
do
either
multi-cloud
or
looking
to
deploy
alongside
you
know
other
other
resources,
they
can
be
a
very
useful
tool.
One
of
the
most
common
reasons
you
might
use
them
is,
if
you're
looking
at
using
cloud
providers
plus
kubernetes.
B
So
if
you're,
you
know,
let's
say
you're
hosting
your
kubernetes
cluster
in
in
a
cloud
provider,
but
you
also
want
to
write
infrastructure's
code
and
then
deploys
your
applications
on
top
of
your
kubernetes
cluster.
Then,
and
if
you
look
at
the
cloud
native
providers,
they
don't
they
don't
deal
with
that.
They
mainly
they'll
deploy
the
the
kubernetes
cluster
for
you,
but
they
won't
deal
with
anything
on
top
of
that,
whereas
something
like
terraform
or
polymer,
you
can
use
the
same
language
to
create
resources
inside
that
kubernetes
cluster.
B
You
just
deployed
that's
a
fairly
common
approach,
so
they
can
support
multi-cloud.
They
support
non-cloud
resources.
Both
of
these
languages
are
stateful,
so
they
have
state
files
that
you
need
to
manage.
They
state
files
will
need
somewhere
to
live.
If
you're
doing
you
know
development,
just
by
yourself,
you
can
store
your
state
file
on
you
on
your
pc,
but
that
doesn't
scale
beyond
one
person
and
it's
not
you
know
it's
not
very
secure,
so
you
can
put
them
in
other
places,
so
you
can
put
them
in
s3
buckets.
B
You
can
put
them
in
as
your
storage,
but
you've
got
to
manage
that
you've
got
to
make
sure
it's
secure
and
backed
up
and
so
on,
but
because
they
are
stateful
because
they
know
what
you've
deployed
they
offer
some
additional
features.
So
they
allow
you
to
do
plans
which
you
can
have
it
tell
you
what
it's
going
to
do
before
it
does
it.
So
when
you,
when
you
come
to
deploy
some
resources
you
can
find
out,
you
know
that
it's
actually,
okay,
I'm
going
to
create
a
storage
account.
B
They
also
offer
some
abilities
around
destruction,
so
when
you're,
when
you're
done
with
some
resources-
and
you
want
to
get
rid
of
them,
if
you're
looking
at
the
cloud-
the
cloud
provider
native
tooling,
you
will
generally
need
to
go
in
and
delete
those
manually
or
delete
the
container
they're
in
like
the
resource
group
in
terms
of
azure,
whereas
because
these
tools
know
what
they've
created,
they
also
know
that
they
can
destroy
it.
So
you
can
write
a
single
command.
B
Then
it
will
delete
everything
that
you
created
with
the
the
infrastructure
is
code,
which
is
a
really
nice
tool.
If
you
want
to
build
a
cleanup
after
yourself,
if
you're,
deploying
temporary
development
environments
and
so
on,
both
terraform
and
pollumi
are
open
source.
So
you
can
have
a
look
at
the
source
code.
You
can
download
it.
You
can
use
it
without
any
any
additional
cost
and
yeah
they
make
all
that
source
code
available
for
free.
B
There
are
some
downsides,
the
obvious
one
is
sort
of
the
opposite
of
what
we
talked
about
with
the
cloud
provider.
Tooling
is
when
a
new
resource
is
released
or
settings
changed
and
so
on.
You
have
to
wait
for
the
third
party
provider
to
actually
update
their
resources
to
reflect
that
change.
It's
not
usually
very
long.
Most
of
them
have
releases
every
couple
of
weeks
and
you'll
get
a
change
reflected
fairly
quickly,
but
you
know
it
can
be
slower
than
if
you're
working
with
a
with
a
native
cloud
provider
tooling.
B
We
mentioned
the
fact
that
you've
got
to
manage
and
secure
and
backup
that
state
file,
if
you
want
support
for
the
tooling.
So,
if
you
need
your
help
and
support
you,
either
reliant
on
using
some
of
the
community
stuff
through
github
issues
and
so
on,
or
you
need
to
pay
for
a
third
party
support
contract
with
the
provider.
B
And
additionally,
if
you
want
some
of
their
more
advanced
features,
some
of
the
enterprise
components
you
are
going
to
have
to
pay
for
those
they
are.
They
come
at
an
additional
cost.
Both
of
these
tools
have
an
enterprise
and
a
pro
edition
which
you
can
you
pay
for,
but
both
of
them
do
have
free
and
open
source
editions
that
you
can
use
without
any
cost.
B
So
we're
doing
exactly
the
same
thing
as
we
did
previously
with
the
arm
template
we're
creating
a
storage
account,
so
not
different
really,
but
you
can
see
here.
The
language
in
the
terraform
file
is
whilst
similar
to
an
arm
template
it's
a
bit
less
verbose,
so
this
isn't
json.
This
is
this
is
actually
a
language
that
is
unique
to
terraform.
It's
the
hashicorp
configuration
language
and
it's
used
to
declare
the
resources
in
a
similar
way
to
what
we
do
with
arm
templates.
B
But
you
know
you
can
just
say
it
is
a
little
less
verbose
and
what
we've
got
here
is
we've
got
a
declaration
so
that
we're
using
the
azure
provider.
So
I
mentioned
these
tools
have
lots
of
different
providers,
whereas
with
that
arm
template,
obviously
we
were
only
deploying
to
azure,
so
we
didn't
need
to
define
a
provider,
but
with
terraform
we
actually
have
to
tell
it
so
we're
using
the
azure
rm
provider,
then
we're
creating
a
resource
group,
and
this
is
one
of
the
things
upfront.
B
That's
a
bit
nicer
than
the
azure
tooling,
is
that
you
can
create
a
resource
group
as
a
native
resource.
You
can
create
resource
groups
with
arm
templates,
but
it's
more
involved
because
they
deploy
at
different
what
they
call
scopes.
You
have
to
have
nested
templates
to
deploy
a
resource
group
which
is
a
bit
of
a
pain
whereas
with
terraform
we
don't
have
to,
because
we
can
just
use
it
as
another
resource.
B
Then
we've
got
our
storage
account
and
you
can
see
here
that
I'm
actually
referring
to
the
resource
group
in
my
storage
account
resource
to
get
the
name
from
it.
So
not
only
only
does
that
allow
that
to
flow
through,
but
that
adds
me
an
implicit
dependency
here
that
the
resource
group
has
to
be
created.
First,
before
the
actual
storage
account
can
be
created,
everything
else
is
very
similar,
so
we're
passing
in
the
same
account
tiers
the
replication
types
and
so
on,
and
then
we've
got.
B
We've
got
an
output
here
which
we
didn't
do
before,
but
we
had
an
output,
so
this
will
spit
out.
What
I'm
asking
for
here
is
the
actual
storage
account
connection
string
that'll.
Give
me
that
at
the
command
line,
when
I
run
it-
and
so
this
is
just
accessing
the
properties
of
that
resource,
using
this
dot
notation
and
to
be
able
to
grab
me
that
information,
so
that
will
that
this
is
basically
it's
doing
the
same
thing,
but
it
looks
a
bit
simpler
and
it
uses
that
hcl
language.
B
So
there's
a
command,
there's
a
terraform
command
line
tool
and
we
can
do
terraform
plan
and
what
this
does
is
it
takes
what's
in
our
terraform
file
and
it
compares
it
to
the
state
file
and
it
works
out
what
it
actually
needs
to
do
to
get
the
what's
in
the
cloud
to
match
what
we're
asking
for.
So
at
the
moment
we
don't
have
anything
running
in
azure
from
this
file.
So
what
has
come
back?
B
Is
it's
basically
telling
me
it
wants
to
create
two
resources,
which
is
my
resource
group
and
my
storage
account,
and
you
can
see
that.
Actually,
if
you
scroll
up
it,
gives
us
a
lot
more
information.
It
gives
us
the
information
about
those
resources
as
well.
So
if
you
want
to
check
the
various
properties,
we
can
have
a
look
at
some
of
them,
so
some
of
them
it
knows
now
some
of
them.
It's
not
going
to
know
until
it's
actually
deployed
them.
So
it
can't
tell
us
so
simple.
B
If
you
look
at
the
arm,
template
we've
told
it
which
location
and
what
the
name
is
so
it
can.
It
can
tell
us
what
they
are,
but
what
it
can't
tell
us
is
the
id,
because
the
id
is
something
that
gets
generated
by
azure
when
you
create
it,
and
so
it
won't
know
that
until
it's
deployed
and
you'll
see,
there
are
a
few
things
in
here
that
you
know
won't
know
until
after
quite
a
lot
of
them.
B
And
that
will
now
go
off
and
actually
create
the
resources
in
azure
for
me
and
then
come
back
and
tell
me
that
it's
done
so,
you
can
see
you
can
watch
it
as
it
actually
creates
the
resources.
We've
hit
the
same
problem
that
I
I've.
I've
also
obviously
used
the
name
here
as
well.
So,
let's
just
in
there
do
that
again.
B
So
yeah
that's
going
to
go
and
create
those
resources
for
me
and,
at
the
same
time,
it's
going
to
add
them
to
my
state
file.
So
it
will
know
that
you
know
I've.
That's
what
I've
done
so
that
it
can
then
do
a
plan
next
time,
and
if
I
make
some
changes
to
that
storage
account
it's
going
to
come
back
and
tell
me
what
the
changes
are.
B
So
that's
creating
the
storage
account
and
this
the
resource
group
should
already
be
created
and
there
we
go
it's
finished
and
you
can
see
here
it
has
spit
out
the
connection
string
that
I
asked
for
so
I
can
use
that
to
connect
to
the
storage
account
now.
The
other
thing
I
mentioned
is
we
can
do
a
destroy
command.
So
again
I
can
run
terraform
destroy
because
it
knows
what
I
created.
B
It's
going
to
just
come
up
and
tell
me
you've
you
you
previously
had
these
two
things
now
you
want
me
to
delete
them
and
again.
I
need
to
confirm
that
I
that
I
want
that.
But
it's
going
to
show
me
there
you
go
so
it's
going
to
destroy
two
things
so
I'll
say
yes
and
that
we'll
go
ahead
and
delete
those
now
for
a
couple
of
things:
it's
probably
not
that
significant,
but
if
you're
building
very
complex
templates
or
creating
a
lot
of
resources,
this
can
be
really
useful.
B
One
of
the
most
useful
things
I've
found
with
this
is
we
when
we're
deploying
things
into
azure.
If
you're
familiar
with
azure,
you
often
need
to
create
service
principles
which
are
basically
accounts
that
run
your
applications
or
that
run
be.
You
know,
provide
you
with
a
an
application
identity
and
you
can
create
those,
but
quite
often,
if
you're
using
arm
templates,
you
can't
actually
create
them
with
arm
templates.
B
You
have
to
go
and
create
them
manually
using
some
powershell
or
manually
in
the
portal,
and
more
often
than
not,
when
people
go
and
delete
their
azure
resources,
they
forget
to
delete
their
service
principles
and
you'll
find
in
your
azure
id
tenant.
There
are
tons
of
expired
and
unused
service
principles
because
no
one's
cleaned
them
up,
whereas
if
I
create
these
resources
using
terraform
terraform
has
a
service
principle
object.
B
I
can
create
them
with
that
and
when
I'm
done
with
my
application
and
now
you
run
the
destroy
command,
not
only
does
it
clean
up
my
application,
but
it
deletes
the
service
principle
as
well.
So
I
know
I've
cleaned
up
everything
without
having
to
remember
to
go
and
clean
up.
That
thing,
then,
in
a
different
place
that
I
usually
forget
about.
B
So
that's
terraform,
the
other
tooling
we
mentioned
is
palumbi.
So
plume
is
a
bit
newer.
It's
been
around
for
about
two
or
three
years,
but
palumi
is
similar
in
terraform
in
a
lot
of
ways.
In
that
it's
doing.
You
know
very
similar
things
that
it's
deploying
resources.
It
has
a
lot
of
providers
and
so
on,
but
the
key
aspect
that
differentiates
it
is
that
it
allows
you
to
write
your
infrastructure
as
code
in
actual
programming
languages.
B
You
know
who
are
perhaps
not
wanting
to
learn
a
new
language
like
hcl
and
instead
are
keen
to
just
reuse
the
language
they
already
use
for
writing
their
applications
to
deploy
the
infrastructure,
and
that
makes
it
a
bit
easier
to
try
and
get
the
development
teams
more
involved
in
deploying
these
infrastructure,
rather
than
relying
on
it,
ops
teams
to
do
it
for
them,
and
so
what
we've
got
here
is
the
same
example
using
polomi.
So
creating
a
storage
account,
but
we're
using
c-sharp
here
to
actually
do
that.
B
It
takes
a
little
bit
of
getting
used
to
writing
sort
of
declarative
infrastructure
in
a
more
imperative
language.
But
it's
it's
not
too
bad,
and
you
can
see.
This
is
not
too
dissimilar
from
terraforming
that
we're
deploying
a
lot
of
those
we're
deploying
the
same
resources.
They
have
the
same
properties,
but
instead
of
using
their
hcl
language,
I'm
using
c
sharp.
So
if
you're
familiar
with
c
sharp,
this
should
make
sense
in
terms
of
what
we're
doing
here,
we're
using
the
same
language
constructs
to
create
those
resources.
B
Now,
if
you're,
just
declaring
plain
old
resources
like
this,
it's
not
too
different
where
it
has
a
real
benefit,
at
least
in
my
view,
is
when
you're
doing
more
complex
things,
so
things
like
loops
and
conditions,
you
can
do
loops
and
conditions
in
terraform,
but
if
you've
ever
tried
to
do
a
for
loop
in
terraform,
I'm
sure
you
will
understand
the
pain,
because
it's
not
a
particularly
nice
way
of
actually
working,
whereas
this
is
just
c
sharp.
I
can
write
a
c
sharp
for
loop
just
the
way.
B
I
would
look
in
you
know
in
a
normal
normal
program
and,
and
it
just
works
the
same
with
this
statements
and
so
on.
So
when
you
start
doing
more
complex
things,
perhaps
when
you
want
to
do
things
sort
of
around
your
infrastructure
as
code
that
aren't
part
of
the
infrastructure
as
code
spec
having
a
real
programming
language
is
actually
quite
nice.
B
B
The
commands
are
slightly
different,
so
instead
of
teleport,
you've
got
a
pallumi
command
and
you
can
do
pollutant
preview
rather
than
terraform
plan,
but
it's
basically
doing
the
same
thing,
and
this
will
go
off
and
talk
to
that
now.
It's
asking
me
here
for
a
a
passphrase.
This
is
worth
me
mentioning.
B
B
One
of
the
nice
features
of
pollumi
is
they've
taken
that
state
file
concept,
but
they
now
allow
you
to
encrypt
the
data
in
the
state
file,
either
with
a
passphrase
like
I've
done
here
or
using
a
secret
provider
like
as
your
key
vault.
You
can
actually
have
it
encrypt
the
data
in
that
file
so
that
you
no
longer
have
to
worry
about
the
fact
that
there
are
sequence
in
it
because
they're
all
encrypted.
B
B
B
It
just
summarized
this
for
me,
so
they've
taken
the
sort
of
the
view
there
to
give
you
a
high
level
view,
but
if
I
want
to,
I
can
go
into
the
details
here
and
I
can
see
a
very
similar
information
to
what's
in
what
was
in
terraform.
This
doesn't
tend
to
show
you
those
results.
You
know
there's
so
values
it
doesn't
know
at
this
point.
B
There
are
some
key
values
here
that
will
sort
of
drive
what
you,
what
routes
you
go
down.
One
of
the
first
things
you'll
look
to
look
at
is
whether
or
not
you
have
the
need
to
deploy
to
multiple
cloud
providers,
because
if
you
do,
then
you
really
need
to
be
looking
at
the
third
party
providers
of
terraform
or
pollution,
so
that
might
make
that
choice
for
you.
B
B
Infrastructure's
code
is
just
code,
so
once
we've
started,
writing
those
code
files,
we
can
start
making
use
of
all
the
tooling
that
we
would
use
with
other
code.
So
we
can
use
common
ids
you
can.
You
saw
that
I
was
using
visual
studio
code,
visual
studio.
You
can
use
the
tooling
you're
familiar
with
to
actually
write
them.
B
You
can
put
them
in
your
version,
control
repository
of
choice
and
use
all
the
features
of
version
controlling
you
know,
pull
requests
code,
reviews
all
those
sort
of
things
you
can
test
those
resources,
so
you
can
run
write
some
tests
that
actually
check.
You
know
that
you,
your
your
code,
is
actually
deploying
the
resources
you
want
it
to
that
is
configured
in
the
right
way
and
so
on,
and
you
can
even
build
ci
cd
pipelines
using
that
code
to
deploy
and
test
and
create
resources.
B
This
first
one
is
designed
to
be
run
before
you
deploy
anything
and
what
it
does.
It
goes
and
checks.
Firstly,
that
I've
got
the
correct
files.
The
files
exist
that
the
files
have
the
actual
sections
that
the
arm
template
is
supposed
to
have
and
that
they
convert
properly
into
json.
They
missed
a
comma
or
a
semicolon
or
something
it
will
pick
this
up.
It
checks
that
I'm
creating
the
actual
resources
that
I
expect.
B
So
these
are
the
list
of
resources
that
should
be
in
my
template
and
it
will
check
that
they
exist
and
it's
running
like
a
pre-flight
check.
So
you
remember
before
we
ran
the
arm
template
and
it
failed
because
I
hadn't
got
the
storage
account
name
right.
You
can
actually
run
the
tests
that
are
run
at
that
point
using
a
separate
command
as
this
test
ac
resource
group
deployment
command.
You
can
run
this
by
itself
to
just
run
those
tests
and
not
try
and
deploy
anything,
and
this
template
will
do
that
as
well.
B
Weirdly,
though,
when
you
run
this,
you
actually
need
a
resource
group
to
exist
to
deploy
to
even
if
you're
not
actually
deploying
anything.
So
the
other
part
of
this
test.
You
may
see
in
the
beginning
of
this
before
all
section,
we're
actually
creating
the
resource
group
at
the
beginning
of
the
template,
and
then
we
tear
it
down
again
at
the
end.
B
B
B
Okay,
well,
in
the
interest
of
time,
we
will
I'll
figure
out
why
they
didn't
work.
They
did
work
before
the
the
call,
but
anyway,
so
that
what
I
would
have
given
me
basically
was
a
list
of
the
tests
that
it
run,
and
it
would
have
shown
me
that
one
of
those
tests
had
failed
because
I'd
intentionally
missed
a
file
off,
but
you
could
run
those
tests.
B
So
one
of
the
things
you're
quite
often
going
to
want
to
do
is
to
check
that
what
you
deployed
is
what
you
expected
to
be
deployed
now,
to
do
that,
you
need
the
resources
to
be
deployed,
which
is
slightly
a
bit
of
a
pain,
but
you,
if
you
deploy
those
resources,
you
can
then
use
pester
again
to
actually
go
and
grab
the
resources
and
compare
them
to
what
you
expect
to
be
there
and
run
some
tests.
So
we're
checking.
You
know
the
reason
the
network
exists
and
there's
a
subnet
called
public
subnet.
B
It's
got
this
ip
range
in
it
that
we've
got
some
virtual
machines,
the
virtual
machines
in
the
right
region
and
so
on.
We
can
write
those
tests
to
be
as
complex
as
you
want
to
actually
check.
What
you're
deploying
is
is
what
you
expect,
and
we
can
then
take
that
a
step
further
and
we
can
actually
build
some
ci
cd
pipelines
to
to
do
that.
B
So
this
is
a
ci
cd
pipeline.
I
built
in
azure
devops,
but
you
could
do
it
in
any
ci
cd
tool
and
this
particular
pipeline
is
a
pipeline.
That's
meant
to
deal
with
when
we've
changed
our
templates,
so
the
assumption
here
is
we're
going
to
write
some
templates
and
we
want
to
share
them
with
other
people
in
our
company,
and
so
when
we've,
when
we've
written
those
templates
and
we
we
commit
them
into
our
git
repo,
it's
going
to
run
this
pipeline
and
this
pipeline
does
a
few
things.
Firstly,
it
runs
some
tests.
B
There
are
three
sets
of
tests.
It
runs
this
arm
ttk,
which
is
a
best
practice
sort
of
testing
set.
It
runs
the
test
we
just
tried
to
do
in
a
failed
and
then
runs
the
infrastructure
tests,
and
you
can
see
here
actually
in
between
that
there's
a
step
where
I
go
and
actually
deploy
the
infrastructure
for
these
tests
to
run,
and
so
we
can
do
that
part
of
our
pipeline
publish
test
results,
and
then
we
destroy
that
infrastructure
that
we
created
then
assuming
they
all
pass,
and
if
any
of
those
fail,
then
we'll
stop.
B
At
this
point
and
we'll
get
a
failure
result
that
we
can
dig
into,
but
assuming
all
the
tests
pass,
we
then
run
some
commands
to
actually
zip
up
those
files
and
copy
them
up
to
a
storage
account.
So
this
is
effectively
a
sort
of
release
pipeline
for
our
templates
so
that
we
can
get
them
into
that
storage
account
where
they're
going
to
be
consumed
by
other
members
of
our
team.
Before
we
do
all
that,
we
run
some
tests
to
make
sure
these
pass.
B
Our
criteria
for
release
before
we
can
get
to
those
we
have
another
pipeline
in
here,
which
is
a
more
of
a
release
pipeline.
This
is
going
to
deploy
our
infrastructure
into
our
environments,
so
this
is
not
not
talking
about
the
templates
themselves,
but
actually
creating
resources
with
those
templates,
and
so
we've
got
two
environments,
and
this
is
using
the
yaml
pipeline,
which
is
a
bit
harder
to
read.
B
But
we've
got
two
environments:
we've
got
a
development
environment
and
we've
got
a
production
environment
and
each
of
those
environments
we're
having
it
run
that
resource
the
arm
template,
but
we're
passing
in
a
different
parameter
file.
So
we've
got
a
dev
parameter
file
and
we've
got
a
production
parameter
file.
B
You
see
here,
we've
got
those
two
stages
so
with
development
and
production,
so
development
has
to
happen
first
and
we've
then
got
an
approval
step
here
that
when
it
gets
to
where
it
deploys
to
development,
you
have
to
somebody
has
to
come
in
and
actually
approve.
They
want
to
move
the
deployment
into
production.
So
there's
a
gate
there
for
us
to
do
that
and
again
you
could
build
those
pipelines
to
be
as
complicated
as
you
want.
You
can
have
as
many
environments
and
different
approvals
built
some
tests
in
there
as
well.
B
B
B
The
blast
area
make
your
template
specific
to
the
life
cycle
of
things,
so
things
that
are
on
a
similar
life
cycle
probably
live
together,
keep
them
small
and
focused
so
that
you
can
just
deploy
those.
You
know
the
particular
bits
you're
interested
in
store
your
code
in
version
control.
If
that's
your
first
step
into
doing
any
sort
of
development
based
approach,
look
at
version
controllers
as
the
first
route
into
that.
B
B
Any
other
questions
I'm
happy
to
answer
them.
So
this
is
what
iesc
tools
are
you
looking
at
for
the
near
future?
Where
do
you
think
things
are
heading
with
iac
yeah?
So
there's
a
few.
I
I
work
with
quite
a
few
tools.
I
guess
one
of
the
things
I
am
doing
quite
a
lot
more
work
in
paloom
at
the
moment,
I'm
quite
I'm
working
quite
a
lot
of
development
teams
and
so
being
able
to
write
stuff
in
c
sharp
has
been
very
beneficial
and
I've
enjoyed
working
with
that
tool.
B
B
Those
are
the
sort
of
the
two
areas.
There
seems
to
be
a
lot
of
movement
in
the
infrastructure
as
code
being
real
code
stuff
at
the
moment,
so
pollute
me
being
one
of
them.
Terraform
have
recently
released
some
some
abilities
to
write
some
of
their
stuff
in
actual
code.
It's
only
certain
things.
I
think
it's
mainly
around
aws.
B
A
B
A
B
Any
news
regarding
the
azure
sdk
management
libraries
they're
in
beta
for
month.
I
don't
know,
unfortunately
answered
that
one.
My
answer,
that
one
is
it's
not
something
I
have
been
that
involved
with,
so
I
can't
answer
that
one
afraid
jenkins
are
unassembled.
Would
you
suggest
they're
different
tools
and
I've
not
worked
with
either
them
that
much,
but
obviously
jenkins,
is,
is
more
of
a
ci
cd
tool.
Whereas
and
simple
is
more
of
your
configuration
as
code
tool.
B
Well,
yeah
configuration
management
is
code
tool,
although
it
is
moving
into
more
areas
which
I
guess
you
could
you
could
do
some.
You
know
more
of
the
ci
cd
stuff
in
in
and
symbol
as
well,
so
it
depends
what
you're,
what
you're
trying
to
do
if
you're
looking
for
a
pure
ci
cd
play,
then
jenkins
is
probably
where
you
would
go
with
that,
whereas,
if
you're
looking
for
more
of
a
hybrid
with
you,
you
want
to
do
configuration
management,
and
even
you
can
even
use
and
simple
to
do.
B
You
sort
of
you
know
your
infrastructure
as
code
deployments
for
for
cloud
providers
as
well,
but
it's
not
as
developed
as
your
pure.
You
know
your
pure
emphasis
code
pieces
and
some
of
the
some
of
the
ways
you
have
to
do.
It
are
a
little
bit
janky,
but
but
yeah
it
depends
what
you
want
to
use
it
for,
but.
B
So
there's
one
even
david
about
about
pharma
years
of
farmers,
I'm
aware
of
I
haven't
tried
it,
but
farmers
farm
is
very
similar
to
bicep,
in
that
it
is.
If
it
was,
it
wasn't
written
by
microsoft.
It
was
done
by
by
mvp,
I
think,
but
it's
a
an
abstraction
on
top
of
arm
templates.
So
it
does.
It
does
the
same
sort
of
thing
as
as
bicep,
where
you
write
your
actual
template
in
a
different
language
and
then
it
sort
of
compiles
them
into
an
arm
template.
B
So
what
you're
actually
running
when
you
deploy
is
still
an
arm
template
but
you're
not
using
the
json
language
and
so
it'll
be
interesting
to
see
what
happens
because
obviously,
bicep
and
pharma
are
quite
similar
and
do
a
similar
thing,
and
you
know
obviously,
microsoft
all
are
working
on
on
bicep,
but
they
you
know
having
spoken
to.
I
do
quite
a
lot
with
work
with
the
arm
team
at
microsoft
and
they
are
very
open
to
having
you
know,
other
approaches
to
doing
it
and
supportive
of
that
so
yeah.
It's
interesting
one.