Episode 399 – Azure Infrastructure as Code with Greg Suttie - Microsoft Cloud IT Pro Podcast

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:03):
Welcome to episode 399
of the Microsoft Cloud IT Pro podcast recorded
live from the MVP Summit on 03/28/2025.
This is a show about Microsoft three sixty
five and Azure from the perspective of IT
pros and end users, where we discuss a
topic or recent news and how it relates
to you. This week, Ben and Scott get

(00:24):
a chance to catch up with Greg Sutti
at the MVP Summit.
While there, Scott and Greg have a chance
to sit down and discuss infrastructure as code
in Azure. They discuss what Greg has been
working on when it comes to Bicep, Azure
verified modules, Bicep configuration files, and more.
I'm here at MVP Summit

(00:45):
with Gregor, who decided to sit down and
was gracious enough to
join us today.
Gregor is an MVP
in Microsoft
Azure
infrastructure and code,
cost resource and configuration management, and probably a
bunch of other things where it has a
bunch of other skills. So, Gregor, why don't
you take a couple minutes, go ahead, introduce

(01:05):
yourself, and then we'll get into things. Thank
you, Scott. Yeah. My name is Gregor Sutti.
I'm an Azure architect for a company in
The Netherlands.
I am from Scotland, so I will try
and speak slowly so that everyone can understand
me.
My background, I was a developer from from
v b sixties,
then I moved over to .net, and then
I was doing SQL. So I've got a
bit of a data background, but I have

(01:26):
a development background, and then I moved to
become an Azure architect for Intercept in The
Netherlands.
I have been doing that for five years
now. Yeah. And I'm Azure MVP. I'm also
an MCT, so I do a lot of
Azure fundamentals training, Azure AI training. And, yeah,
that's basically my background. Training near and dear
to my heart. Mhmm. Love training. Love training.
I probably annoyed a bunch of people. I

(01:48):
I I was one of the writers for
the AZ 100 before I became the one
zero four. So
you you get a lot of stuff in
there to blame me for. Nice to know.
So tell me a little bit about your
experience as an MVP. I think folks always
ask that question.
Yeah. How do you come become an MVP?
What goes into it? Like, what's your Lyft
experience there? Good question. So, yeah, my background,
I always wanted to be an MVP. I

(02:09):
wasn't really sure what it was to begin
with, so I reached out to one of
another fellow Scottish person called Kenny Lowe, and
I asked him and he told me quite
a lot about the program. Really interested in
it. I had to say to myself, I
would love to become an MVP. So my
first step was I wrote the letters MVP
above my monitor at home, and I thought
that is my goal. I want to become
an MVP. You you put together a vision
board. No. I just put I just put

(02:31):
the letters MVP right above it. I thought
I'm gonna go for this. This is my
goal. I started off I don't have any
Azure experience, so I was working as a
dot net developer.
The cloud is obviously a big thing five,
six years ago. I wanted to learn Azure,
so I started off with just learning the
exams. So I started off with the development
exams, and I started off blogging about my
experience of learning, like, the developer exams. Like,

(02:53):
how am I what study material am I
gonna do? How am I gonna go about
learning this? I'm a hands on learner, so
the way I learn is by I don't
read much. Basically, I read the docs and
then hands on learning. So open up the
Azure portal, deploy the resources, and learn from
that. Then I did some practice tests, took
the exam and failed it the first time
around because I didn't have enough hands on

(03:14):
experience. I thought I knew enough to pass
the exam, but it turned out I didn't.
So I took a lot of learnings from
that, but I needed to spend more time
hands on. Took the exam again and passed
it, and today, as of now, I've done
13 exams. So I am quite exam heavy.
Kind of got a routine of studying hands
on, looking at the docs, blogging about my
experiences of what I've learned, what you need

(03:35):
to focus on for the exams. And, yeah,
from that, I then started attending the Glasgow
Azure user group where Sarah Lynn runs that.
She approached me because I was going quite
regular,
and she said, would you like to help?
So I'm kinda helping her with that. That
that's been very helpful for MVP. So I've
been blogging.
I would do some talks
and helping out the Azure user group. So

(03:56):
that's kinda how I got started in becoming
an MVP. And a lot of people reach
out to me on LinkedIn and say, how
do I become an MVP? So I always
say it's all about the community. It's all
about giving back. So whatever you learn, blog
it, write about it, share your knowledge, share
your things you've run into. Lots of times
I Google for for an issue and I
end up look at ended up on my

(04:17):
own blog.
So I started blogging because I've got terrible
memory. Oh, yeah. And sometimes I still still
end up on my own blog. So, yeah,
blogging, giving back to the community, user groups
are always helpful. But I would say you
don't have to a lot of people say
that you'd have to do public speaking. I
don't think you do. There's one of my
friends, Thomas Thornton, he's got an amazing blog
and that's all he does, and he's become

(04:38):
an MVP from from blogging. He's not into
public speaking. So just giving back to the
community as much as possible is is kinda
how you go about becoming an MVP. Gotcha.
Yeah. One of the other things, or at
least my experience there is I I I
did a similar thing. I wanted to be
an MVP. I never became an MVP, but
that was okay because the things that I
were doing, I still got to go out

(04:59):
and meet people and interact with user groups.
And that experience of like, yeah, oh, I
just landed from Google on my own blog.
Yep. It's definitely a thing that happens. So
I I often tell folks don't do it
with the expectation that you want to be
in a VP. Absolutely. Do it with the
expectation that you want to
participate in a community. You want to become
a better technical writer. You want to become

(05:19):
a better presenter. Whatever dimension or or mix
or match of those things are so that
you're getting something out of it. Yeah. And
and and that's really kind of the the
goal and where you want to land. So
I I I have to inquire. So your
Azure infrastructure as code is one of your
categories. Yep. Dot net developer. Yep. Have have
you crossed to the dark side? Do you

(05:40):
consider yourself an IT pro these days? No.
I'm not an IT pro. Generalist. Yeah. I'm
more so when I worked for JP Morgan,
they came up with this term t shaped
developer. So the idea is you are kind
of broad, but you go deep in one
area. So I thought that was quite good.
So my not my problem, but my background
is I am a bit of a master
of a jack of all trades, master of
none, and I decided I would try and

(06:01):
do infrastructure as code as kinda my deep
thing. So, yeah, I do data. I do
AI. I do infrastructure as code, cost management.
I do most of Azure. Probably the only
thing I don't really do is EKS, and
that's the one thing I've kinda because people
at my work to do all that. And
I'm like, you can you can stick with
that and I'll do the rest. So, yeah,
I get asked lots of questions about lots

(06:21):
of different things.
Infrastructure as code, and I have a very
lucky background. I work for a lot of
people, a lot of managers who taught me
how to do things properly, document things, do
pull requests with good comments, and and I
was just I've just got a really good
background for working for good people who showed
me how to do it the right way.
So infrastructure as code, build pipelines, doing everything

(06:43):
professionally. So that's why I got into Bicep.
I wanted to learn how to deploy resources
for customers
across different environments and do it properly. So,
yeah, I'm a big Bicep fan. That that
was gonna be my next question. Mhmm. So
Azure Resource Manager arm has changed a bunch
over the years Yep. From
declarative templates to
Bicep and

(07:03):
and having a domain specific language and and
a DSL.
And there there are certainly folks out there,
I think, that have done infrastructure as code
either on the arm side. They've done maybe
Terraform,
tends to be like my canonical one that
I go back to and and near and
dear to my heart. How how how are
you
finding Bicep, like, the transition from

(07:24):
traditional resource manager templates and and kinda
coming over that? And then are you
is are you just a a Bicep fan?
Are you using it with customers? Like, how
is how is kind of the getting past
the documentation and the POCs to, hey, here's
how this goes in the world for you?
Great question. I did luckily, I didn't spend

(07:44):
too much time in my career doing ARM
templates because ARM templates are a little bit
tricky to kinda understand. When you look at
them, you're like, what is the dependency chain?
How are things working? So I kind of
got on board with Bicep from the very
start. I open up Versus Code. I just
write Bicep. I basically just learned it by,
again, hands on. How do I deploy a
storage account? Let's start with some simple deploy

(08:05):
it like that. How do I parameterize it?
How do I deploy it? Do I deploy
it from my machine? Do I deploy it
from Azure DevOps or GitHub workflows? Runners. Sorry.
So, yeah, just learning it by hands on
and doing it, and I've been doing it
for five years now. Probably, I feel good
at it now, I would suggest. I've got
lots of experience. So when I'm at work,
I always do infrastructure as code using Bicep.

(08:27):
Everyone kinda asks me how to do things
because I I spend probably
70%
of the week doing Bicep for different customers.
Absolutely. I love it. I love the idea
that I can show customers how to deploy
their environment to dev and test in production
using the same templates. So all of the
same standards. The only difference is the config
for the actual deployment resources. So dev might

(08:49):
be a a cheap VM, and acceptance of
prod might be a more expensive VM. So,
yeah, I'm using Bicep a lot, and I
absolutely love it. Even today, we're talking to
the Bicep team, and I think that stuff's
great. Gotcha. And and before we started recording,
you had mentioned that some of the projects
you work on with customers might be around
migrations, things like that.
How do you see your customers

(09:12):
kinda going through those motions? And maybe if
I'm migrating to Azure,
I I I don't know your experience with
it. I'd be curious to understand. I I
see a lot of customers that kinda start
in the portal, and they just go next,
next, next. And I've I've got my virtual
machine, and I've got my VNet. And
oh oh, I I need a database. I
might stand up like a PaaS instance, like

(09:32):
manage instance, something like that. And then they
do it once and they go, how do
I do it again? Correct. And and and
what does that look like? So I'm curious
like, do your customers
move
kind of more traditionally? They come up, they
go through that same kind of motion, and
then you step in and help them take
those environments to a more repeatable
stamped out model? Yep. So it depends on

(09:54):
the customer, obviously. Some customers are already using
doing ClickOps and they're already in Azure. ClickOps?
Yeah. We call it ClickOps. Yeah. Yeah. And
the port then the portal just and then
you show them the value of Bicep and
you show them how you can repeat the
environment.
Because I always I always worry that potentially
a region may go down. You never know.
And they're in West Europe and they might
need to move to North Europe. And if

(10:15):
you've deployed that by hand using ClickOps, how
do you remember all the settings?
The person who's deployed it might move on
from the company and then you're kinda left
not sure what to do. So I will
show them that from a PowerShell file, we
call our Bicep templates. We deploy dev. We
roll it out. They kinda have a look
at it. They check the settings. They deploy
their workload on top of that. All good.
Then we move on to acceptance and production.

(10:37):
So once they see the value of it,
they're all in. And when I'm doing my
architecture designs upfront, I always put in a
section about why infrastructure of code's important, and
they kinda get it. The the buy in
to nobody's ever said, no. We're doing click
ops. But what I still see is sometimes
I'll deploy dev acceptance prod and some people
manually change things, and then then they realize

(10:58):
that there's drift. And then when they deploy
the resources, all of a sudden acceptance isn't
working, but dev is. And then they're like,
yeah, what's going on? And then you have
to show them, like, you have to use
infrastructure as code, you have to use build
pipelines, no touch deployment, like, but but I
always want to do click ups to get
things working quickly. I I get that. But
sometimes you just have to, like, teach these
people that that's gonna lead to pain. So,

(11:18):
yeah, we've we've had a customer recently who
we deployed dev acceptance and prod. We set
up the workload and then they manually changed
some things and, like, dev and acceptance
was was working but dev wasn't and then
it was because of the changes. Yeah. So
just a learning curve, but that's the way
to go. E easier to click run once
on a pipeline Yeah. Or or an action
than it is to click next, next, next,

(11:39):
next, next, next Well, we have we have
10 web apps and one of the customers
was basically changing all the settings on the
web apps and acceptance and dev was working
and acceptance wasn't. And sometimes it's difficult to
compare two different environments, and they're in the
same region and they're in the same subscription,
but, I'm sorry, they're different subscriptions, but, yeah,
for for, like, web apps, there's a lot
of settings, and I had to go through
and manually compare them all. And, yeah, that

(12:00):
was a bit of a painful exercise, but
you kinda teach them that that's not the
way to go. So we've kinda put delete
locks in them or or making sure that
there's PIN so that they don't they don't
have access to go and do things unless
they elevate and and and do that kind
of stuff. Gotcha. Do you also find that
you like, maybe those more traditional migration customers
to teach them a little bit about I
I imagine you need to wear a little

(12:21):
bit of your software development hat and and
kinda get into
software development life cycle Yep. Because infrastructure as
code Mhmm. That needs to live someplace. Yep.
That that Bicep file
and the history of it and the versioning
of it, it's Yep. Gotta be in Azure
DevOps or GitHub or hopefully some type of
repository that's not your OneDrive or your desktop

(12:43):
or a little thumb drive over in the
corner. Yeah. That's the thing. You you have
to source control the the infrastructure as code.
And then, normally, what I do is internally,
where I work, we we will create the
repos for our customers.
And then I'll I'll lay all the bicep.
And then if they want, we'll give them
the bicep and put it into their Azure
DevOps, and then they can run pipelines. But
we tend to do it in our repos.
So it's me that's writing all of the

(13:04):
code, and then they just they just review
it and and check it. But, yeah, it
needs to make sure that it's source controlled
without doing proper proper proper pull requests and
and rep approvals and all that kind of
good stuff. Yeah. I also help build the
pipelines for them because a lot of customers
like, we've got infrastructure as code, but how
do we deploy it? It's like, they don't
want I'm gonna introduce you to our friend
Gamel. Yeah. They they don't want me to

(13:25):
deploy to production from my machine, which is
totally fine. Well, I have to set up
the pipelines for them, and then sometimes customers
don't know how to do that as well.
So I will build the ammo and build
all the pipelines for them, and then then
they're in a good place. But sometimes they
just don't quite understand because on on prem,
they're just manually changing things, and then they
wanna do the same in the cloud. And
they're like, no. Please don't. That's not really
best practice. So so I learn and you

(13:46):
just have to keep keep on the on
this case and make sure they're doing the
right things.
It's quite funny sometimes. That reminds me of
like sitting down with my kids maybe and
like,
no, don't do that. Yeah. Exactly. I I
really need you to go do your homework.
I mean, you tell them don't do that,
they'll let it. But we've got it working
then. And I'm like, yeah. You got it
working, but it's not repeatable. And and eventually,

(14:06):
it's things in that they need to do
things properly. Gotcha. Yeah.
Do you feel overwhelmed by trying to manage
your Office three sixty five environment? Are you
facing unexpected issues that disrupt your company's productivity?
Intelligink is here to help. Much like you
take your car to the mechanic that has
specialized knowledge on how to best keep your

(14:27):
car running, Intelligent helps you with your Microsoft
cloud environment because that's their expertise.
Intelligent keeps up with the latest updates in
the Microsoft cloud to help keep your business
running smoothly and ahead of the curve. Whether
you are a small organization with just a
few users up to an organization of several
thousand employees,
they want to partner with you to implement

(14:47):
and administer your Microsoft cloud technology.
Visit them at intelleginc.com/podcast.
That's intelligink,.com/podcast
for more information or to schedule a thirty
minute call to get started with them today.
Remember, Intelligink focuses on the Microsoft cloud so

(15:10):
you can focus on your business.
And how much do you find
that
you you you kinda spend your time just
keeping up with the churn of Azure? And
and as you see so you mentioned maybe,
like, deploying, like, a web app for a
customer, and they had two environments and a
setting changed over here and over here. Web
apps are also changing as as they go,

(15:31):
things like that. Like, how do you think
about that as an architect and incorporating
maybe additional parameters into your templates and Yeah.
It's it's challenging. Yeah. I mean, I I
do a lot of training and and when
you're doing training and have the slides and
you're like, let's go into a storage account
and deploy a storage account and the settings
will change because the the the UI of
the the portal updates quite a lot and
yeah. It's challenging. It definitely is. So to

(15:54):
kinda keep on top of that, we are
making use of what's called the Azure verified
modules. So within Bicep, Microsoft are working on
this Bicep kind of ex they extract the
modules for you, they write the modules for
you, and then we just call them. So
they've got an ongoing GitHub project called Azure
Verified Modules. They've pretty much got all of
the Azure resources built, and we just call
that. So we make use of that, which

(16:14):
is which is awesome. Going forward, Microsoft are
kinda trying to push everybody towards using Azure
Verified Modules. So that helps a lot. So,
yeah. So I I work in Azure storage.
Mhmm. I'm I'm one of the people that
signs off on those on the on those
verified modules for for the team that that
builds them and pushes them out there. I
think it's a a very interesting model that
that's kind of moving there. If you think

(16:36):
about, like, being a customer in the past,
you might have gone to Microsoft and read
the documentation or landed up in a samples
repo, things like that. But you were largely
left to your own devices. Yep. And and
sure, there's
support there. Yep. And and you can reach
out to CSS, but they might have to
Microsoft customer support. But they
they kinda have to do some debugging and

(16:58):
and things with you along the way. So
one of one of the niceties
of AVM or those Azure Terraform
modules in there Terraform modules in there as

(17:19):
well. So it's not just Bicep. It's Bicep
and Terraform. They're there. And and one of
the things that I like about those
is
not only the kind of nice sample nature
that's there, they've also implemented a bunch of
best
practices and learnings that come in. Like, I
I know when we were working on the
storage modules and kind of working through that
partnership, there was a lot of kind of

(17:40):
things around best practices,
best default state. What's what's what's just like
the best configuration? If somebody picked this up
and they did a fire and forget deployment,
what's the best state that customer needs to
be in and where they need to be?
So there there's a lot of that in
there as well. Like, zone of resiliency is
a consideration from the front

(18:00):
and being able to tie that all together.
So
I I think as AVM matures,
it'll definitely become a a good place for
customers to to look to. I have a
lot of my customers come to me today
and say,
why EVM?
Especially my Terraform customers, why EVM versus
the HashiCorp modules or the

(18:21):
or or something else that's out there in
open source. And,
really, I think the biggest thing is the
supportability
built, maintained,
supported
by Microsoft,
and
customers get that support as well. So I'd
encourage anybody to go out and take a
look at APM.
Some of the modules

(18:42):
are kind of in a beta state, alpha
state. They're they're they're in various states of
release.
But as that gets sealed up across all
the services that are out there, it becomes
kind of a broader ecosystem over time. One
of the best things I think is you
can you can put that in a design
for a customer. So I'm designing right now,
design document, I can tell them all this.
And the documentation for the Azure verified modules

(19:04):
references the Well Architected Framework. And one of
the best things about the docs for EVM
is you can go to usage examples
and the bot one is always well well
architected framework and it shows you the Bicep.
So the docs for Bicep alone are sometimes
a little bit tricky to to figure out
what is the ID reference, what is what
it says it's an array, the property might
say an array and you're not sure what

(19:25):
goes in that array. But the AVM, the
well architected framework, has very nice examples of
how to deploy things with best practice in
mind to that. That's one of the keys
of using it, I think. Yeah. And it
will it will make it better going forward.
Yeah. Yeah.
Not just just raised, but, like, the the
fixed enums, the fixed values. I think it's
a kind of good set of,
if not best practices, certainly like guardrails or

(19:47):
referential material. Yep. In the case of, like,
a storage account, you you don't we might
want the underscore, like, standard underscore LRS versus
just standard LRS. Like, whatever it happens to
be
as as you're pumping those things through.
I I I'm curious because you you you
mentioned kind of architectural docs and design docs
and things like that. Do you take advantage
of kind of any of the tooling that's

(20:09):
out there? Maybe do you have a favorite
one for, like, visualizing your templates and the
resources that are visualizing,
I Yeah. Sometimes I just when I deploy
the bicep in Visual Studio Code, you can
get a a resource visualizer. But one tool
I'd really like to call out is what's
called the AZ quick review, AZ QR. I
don't know if not a lot of people
know about this. I have not heard of
this. So it's an ex It's a cool

(20:29):
name. It's a GitHub project. It's a open
source GitHub project. And if you run that,
so what we do is we run this
tool after we've built the the bicep. We've
run the pipeline. The last step of the
pipeline is you can point it at your
subscription where you've just deployed it. And against
the way I'll architect the framework, it'll generate
a CSV that lists all the resources. It
will tell you your security scores. It will

(20:50):
recommend
what you've not done, what you should do.
And it's very in-depth and it is very
good for finding out like, oh, I'm using
service endpoints. I should really be using private
endpoints. I'm not using TLS 1.3 or 1.2.
It'll tell you all that good stuff that
is built in. So we just call this
tool. You can run it against a tenant
and do all the subscriptions. You can run

(21:11):
it against an individual subscription or you can
even do it against a resource group and
even a resource. And it prompts out a
CSV file at the end and you redo
that as part of the build. You get
the art artifact from Azure DevOps, and you've
got something to show the customer. And you
can do that. You can run that tool
at any point. So if you're not even
using Bicep, you can still run the tool
against your environment, and it'll give you a
list of recommendations. So excellent. It's really good.

(21:33):
I wish Microsoft would look take maybe even
do something towards using something like that because
it's really useful. Once you've deployed your your
infrastructure's code, it basically gives you a score
and says here's the good parts, here's the
not so good parts. Go and fix that.
And that's, again, against the well architected framework.
So it's building on top of AVM as
well. Gotcha. Yeah. So what what's your
favorite
feature in Bicep?

(21:54):
Favorite feature in Bicep? Oh, that's a good
question. Let me think. I only think. Favorite
feature in Bicep.
I like the Bicep parameters. So that's a
kind of when you have a a main
dot Bicep file, and we talked about before
where you're deploying the dev environment, the test
environment, and the production environment, these three environments
may differ just from the the size of
the VM, let's say. So the VM for

(22:15):
dev may be like a a small VM,
and then you can have a para a
bisect parameter file for the the dev environment.
We've also got one for acceptance and prod.
So the acceptance and prod
variables will consider a larger VM, more disk
size, maybe an extra disk. So you can
configure all that and bicep. So that means
that you're deploying all these resources with three
different environments with the three different settings. So

(22:36):
that, I really like that. I think that's
really cool. That's been out for a while.
Yeah. It's it's a good way to rationalize
things through, like, because often it's t shirt
sizing. It's small, medium, large. And that's much
easier for somebody to figure out than what's
a d sixteen
Yep. V five or v six or Yep.
Oh, oh, no. A d 16 s versus
a d 16. And and and you can

(22:57):
kind of bake that logic in into your
own custom
enums along the way. What what do you
see as kind of the biggest
kind of stumbling block or or pitfall with
your customers and bicep today? Like if somebody
is new to it, like,
what are one or two things that they
should look out for? A lot of our
customers believe us to write the bicep, which
getting them on board is quite tricky. You

(23:18):
just have to, like, we will write the
bicep and kinda sometimes they want to take
the repo off of us and look at
it and and they don't have the skills
to learn bicep. So scaling them on on
that is is sometimes a bit of an
issue. Yeah. They they just want someone else
to deploy it and then then they'll they'll
put their workload on. So
we tend to just look at the device
that fall and deploy that. So it'd be
nice if some of our customers had people

(23:38):
who learn the device as well just to
just to so when we are not that
not around and they want to change it,
then I've got other people to do that.
Gotcha. And how about when you're out there
training? You mentioned you're an MCT Mhmm. So
a Microsoft certified trainer. Yep. Kinda what are
the things that you point out to students
to look out for? In terms of In
in terms of
maybe maybe not pitfalls of bicep, but here's

(24:00):
some things that you should think about. And
because like any other
language, like it is a domain specific language,
it's got a set of constraints and kind
of guardrails in it and and and rules.
Yep. But those also often come with new
ways of thinking about things, and here's how
you have to
adapt your thinking. Or the way you did
it over here in Arm might be a

(24:20):
little bit an Arm template, a resource manager
template might be Mainly around structuring the code.
So what I like to do is I
put all the parameters at the top, and
then I'll have the variables, and then I'll
draw like a line and the styles across
the code, and no hard coding from that
point onwards. So I try and teach people
to make sure that the modules that you're
calling, there's no hard coded locations. It's all

(24:41):
parameterized at the top. It's all well documented.
In Versus Code, you can use, a
Versus Code Copilot and you can get it
to document everything for you. Put descriptions above
all your modules so that everyone knows what
what the code does. I'm a firm believer
of leave the code in a good state
so that some if I'm off, someone could
pick up the bicep and try and figure
out what it's doing. I'll generate a diagram

(25:02):
as well and put leave that in the
repo so people can see what I've deployed.
Some of the pitfalls I always think are
when you're using Versus Code as a beginner
in anything, they say generate generate this for
me and you never really learned, you know,
I'm always worried that like you can let
it fly from reading a book, but the
minute you're sitting in a cockpit and try
and fly a plane, you really struggle. So
you need to get hands on and learn

(25:22):
what things do. A good example is in
a module in Bicep, you have the name
of the module, you have the name of
the deployment, and you have the name of
the, like, the storage account for example, and
those three names are different. And I see
a lot of people creating the module called
create storage and then they'll put the name
of the deployment, create storage, and then put
the name of the storage account, create storage,
and then they'll start there and go, why
is that not working? Because they haven't learned
the reason these three parameters are slightly different

(25:44):
even though they're all called name. So So,
yeah, there are one or two pitfalls of
learning it. But the other thing to do
is if you're really stuck, deploy the resource
using ClickOps and then go into the arm.
You can export the template. Now the feature's
coming out, but you can click on generate
bicep and it'll actually show you the bicep.
So sometimes you need to figure out, like,
a good example might be TD encryption SQL
Server. You deploy in the portal. You type

(26:06):
the you type the portal, and then you
can see the bicep and see what the
setting is to turn that on. And that
that's always a good way of kind of
reverse engineering your bicep. I think if you're
doing things like
Azure firewall rule collections, the the documentation is
quite tricky to kind of follow it. So
you you deploy it by hand and then
work out what goes where and then it
needs to be in the right order. So
that's that's always that's always a good way
of doing it as well. That's one of

(26:27):
the biggest pitfalls is figuring out what does
the parameter mean? What what's it expecting? Yeah.
Yeah. I do that with customers a lot.
They they come in often
they they I I think their intentions are
good. Mhmm. So and and I I tend
to be the same way. Like, I I'd
rather get hands on with it than go
read a book about it. Yep. And so
I'll often just start opening Versus Code and

(26:47):
and
then, oh, it doesn't work. It's broken. But
that trick of going to the portal and
let me see how the portal does it
because I I always used to when I
was a trainer and and doing the
the infrastructure exams, the the one point I
always wanted my students to take away was
the Azure portal, when you're deploying something or
you are updating something, it is an ARM

(27:09):
expression generator. Yep. So it it's great at
expressing those values in a way that, like,
you can go get to the end and
and get the template. Get the ARM template.
Great to hear that they've got get a
bicep template coming. That that that's certainly a
a nicety that's there. You also mentioned working
in Versus Code, GitHub, Copilot, things like that.
I haven't played around with ARM templates too

(27:31):
much or really gotten hands on with with
Bicep with GitHub Copilot, but I do a
lot of PowerShell and Bash. Super helpful there.
What's your experience been? Is is it a
good Oh, fabulous. Good augmentor Yes. Where even
for, like, new thing where it's Yeah.
Yeah. You can actually one of the things
that people might not know is I talked
about AVM modules. You can go into GitHub
Copilot and reference that external GitHub repo and

(27:52):
ask it to generate bicep based off of
that project. So instead of it gen writing
generic bicep, it'll actually write bicep that's targeting
the Azure verified modules, which is really good.
So I use it to generate documentation.
If I'm doing if I'm even if I'm
doing bash scripts or I'm looking at someone
else's script, I always do slash explain and
it'll it'll explain to me what the script's
doing. That's also very helpful. Mainly generate documentation,

(28:14):
putting your variables at the top, making sure
there's descriptions on everything, and kind of explaining
I was trying to write a little bit
at the top of the file on explaining
what I'm trying to do. Like, what I've
maybe I've taken a what I sometimes do
is I'll go to the Azure Architecture Center.
I'll look for the zero trust diagram. I'll
deploy that as an example when I'm teaching
someone Bicep, and I'll put in the link
to the diagram, explain all of the resources

(28:36):
at the top of the the Bicep file
so that people have got some understanding before
it's doing. Because that's what I tend to
see is when people are deploying Bicep for
the first time, they don't know how to
make resources talk to each other. So someone
will create a storage account, someone will create
a manager of the entity and a SQL
Server, and then they'll say, how do I
get the manager of the entity to talk
to the SQL Server to get to go
to the storage account? And then that's where
it starts to get tricky. You you just

(28:57):
need to read the docs and spend a
lot of time in figuring it out or
deploy it manually and reverse engineer. That's that's
the way forward. I think it's always been
hard to figure out the Mhmm. Dependencies. Yep.
And
I don't know if there's just an easier
way to do it. It's just the the
way the system comes. Yep. If I give
you a bunch of Legos,
your Lego house needs to look different than
mine sometimes. Yep. And sometimes that just turns

(29:19):
into, like, oh, we dumped the whole thing
out in front of us, and now we
now we gotta figure out how that composes
and and and how all that goes. Some
of the other nice things is the Bicep
configuration files. So if you're not used to
that or you don't know about that, you
can add a configuration file where you can
say, like, don't show warnings.
You can say, only use the latest version
of AVM modules. That's a nice one. So
if a new version of the module comes

(29:40):
out, your code won't build and you have
to go and change the code or you
can make an error or a warning. Kinda
kinda like, you know, I I might with
the container. Yeah. Exactly. Say, hey, play all
the latest image tag kind of thing. The
one thing that we were talking about earlier
is it would be nice to know if
the underlying API has changed from version 0.12
to 0.13,
what are the changes? That's one thing we've

(30:00):
we've we've asked for for some sort of
feedback on, like, what was the difference between
the previous API and this API? Because nobody
really knows and it's really hard to find
the docs. So that that would be an
interesting nice change. I use I use Copilot
all the time. And the more you use
it, it starts to get frightening. You you
start you may write Bicep for an Azure
Firewall and it just knows that you're gonna
write an Azure Firewall policy next. It's like

(30:21):
it's like how did you know that? It's
really, really smart. It's super useful and saves
a lot of time. Thanks for taking the
time to chat with me today. Thanks for
having me. Let you get back over to
MVP Summit and get some good learnings and
and give us some good feedback and Will
do. Thanks for coming in. Thank you. Thanks
for having me.

(30:41):
If you enjoyed the podcast,
go leave us a five star rating in
iTunes. It helps to get the word out
so more IT pros can learn about Office
three sixty five and Azure.
If you have any questions you want us
to address on the show, or feedback about
the show, feel free to reach out via
our website, Twitter, or Facebook.
Thanks again for listening, and have a great

(31:01):
day.

All Episodes

Episode 399 – Azure Infrastructure as Code with Greg Suttie

Episode Transcript

Popular Podcasts

On Purpose with Jay Shetty

Stuff You Should Know

Dateline NBC

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Episode 399 – Azure Infrastructure as Code with Greg Suttie