>> What's up, peeps? You don't want to miss this episode. I'm here with Alex
Frankel and we're going to beat on that
Infrastructure as code drum. We're going to beat
on it really hard. Look, I got to be
honest with you-all, I've never been a huge
fan of ARM templates; they are hard, they're messy, but I'm super-excited because on
the next episode of DevOpsLab, Alex, he's going to share with us the next generation of arm
templates called Project Bicep. [MUSIC] >> Welcome to the DevOpsLab. Man, everyone that follows me know I'm a massive fan of
Infrastructure as Code. Infrastructure as Code is one of the most powerful and underutilized
aspects of DevOps today. Today, we have a very special guest. We've got Alex Frankel
with us, and Alex, he's going to show us something super-exciting and
that's Project Bicep. Welcome to the show, Alex. >> Thanks for having me, Abel. >> Man it's great to have you back. Why don't you tell our viewers
a little bit about yourself, what you do at Microsoft. >> I am a Program Manager on
the Azure deployments team. That's everything
having to do with like native Infrastructure
as Code on Azure. ARM templates, blueprints, and now this bicep project that
I'm going to show you. >> Cool. This Project Bicep, what is this Project Bicep? >> ARM templates can get a little unwieldy to author once you get
to a certain level of complexity, even honestly in simple cases, as you've seen through your series. Even though you've done a
great job demystifying things, there's still a lot
of complexity there. The reason that it's so
complicated is because you're taking the ARM template language, which is almost like a DSL, and your shoehorning
it into a JSON file. With Bicep, really what we're
doing more than anything else is taking that DSL and giving
it its own file to live in. It's a.bicep file, and it
allows you to express all the stuff that you can express in
ARM templates just in a cleaner, more readable, easier
to author language, and then we transfile it
into an ARM template, and that's still what is being
deployed at the end of the day. It's similar to that Typescript, JavaScript dynamic that you
may already be used to. >> This is starting
to make me excited, because like you said, shoehorning JSON and trying to
make it do more than it can do. Basically, you've created
a language around ARM? >> Yeah, more or less. I think what we like to say is that we've done half of a new language. The syntax is all fair game to play with and make
easier to work with. But the on-time we're not changing, it's still ARM templates, and all the knowledge
that you have of how to author Azure resources in ARM, all that carries forward into Bicep. >> Very, very cool. Now,
I want to see this, like, how do we do this? >> Cool, yeah. I have a bunch
of good stuff to show you. Just to start out, at a high level, what you're doing with Bicep is your authoring this Bicep
language and you're going to run a build command to transfile it or compile it
from Bicep into ARM templates, and then at that point
it's just ARM templates. All the things that you've learned about through this series of day zero support and pre-flighting and functions and all
that good stuff,, all that is still
there and represented. Let's actually start writing some code and see what
this thing looks like. >> Cool. >> Let's go into VS code. What you're looking at
here is main.biceps. It's a new file extension
for Bicep files. You'll see I have the Bicep
language service running, and I have the Bicep VS Code
extension installed here, and you can go and get this
from the marketplace right now. You can install all the tooling. I'm going to switch
over to the Bicep repo. Here's the repo. You
can go to it right now, GitHub.com/Azure/bicep. We walk you through all the basics
you need for getting started. Really all you need is the Bicep
CLI to do that transfilation, and then the VS Code extension just to improve your
authoring experience. >> Cool. >> Go ahead. >> I can go ahead and
install this extension, and basically, I can
just start writing. That's all I need to do, to set up? >> Exactly. We have
everything installed. I have bicep CLI installed, and this blank file is
a valid Bicep file. I can do Bicep builds and, then do main.bicep, and it's going to turn it into the
equivalent JSON file. If we go back to our File Explorer, we see we have main.js now and
it's skeleton ARM template. I can actually deploy this It'll do nothing but it's a
valid ARM template. >> Right, cool. What if I
want to build something, what if I want to
provision some resources? >> Let's write some code. There's
no overplayed skeleton code like we have in the JSON file. I can just write in the resources. The first thing that I'm going to
write is the resource keyword. Its a top level,
first-class model thing. I'm going to call this FTG, which is just the friendly
name of the resource, and then the next thing I need
is the type of the resource. I can just start typing in here. I can start saying, "Okay,
I want a storage account." I started typing storage account, and IntelliSense has all the types and all the API versions
that exist in Azure, and there are quite a few of them. I'm going to pick the
latest API version for storage accounts,
which is 2019-06-01. You'll notice that
it's all one string. In the ARM template, we had typed an API version as
separate properties. Collectively, that's what really defines what properties you
can include in the resource. We combine them into a single string because
that really is the type. Then we simply just type
equals open brackets, and now I can actually start declaring the properties of a
resource that I care about. Here's all the intelliSense
that I would expect from any modern tooling. Of course I need a name so I'll
just call this unique storage for now. Right and spell. >> I need things like the location
and I'll just say eastus. I have properties that I
know I need like kind, so I'll add the kind property. Then we're able to pull in all the information from the
actual API definition of how you create a storage
account in Azure to get the different kind properties
that I have available to me. So I'll do kind of storage. I need a sku. The sku has a name property. So you see I get a
warning because I'm missing the name property from the storage account and then I get all the enum values for the different storage skus
that are available to me. >> Wow. >> If the storage team were to
come out with a new storage sku, that would show up in IntelliSense
because we really are just this native representation
of the Azure resources. >> Men that IntelliSense is sick. That's freaking awesome. >> Yeah, it's a really,
really big improvement. Now, we've had elements of IntelliSense in the
ARM template tooling. We have a language service for
ARM template tooling as well. You've been able to get
some of this information. What we haven't had until Bicep, and this is something that I'm
personally really excited about, is the ability to get IntelliSense on the previously declared resources. Let me show you what
I'm talking about. It's common when I
create a storage account to want to get the endpoints, the Blob URI so I can actually start sending information to
that storage account. I'm going to use
another keyword called output and I'm going to say output and I'll say bloburi
and it's going to be a string. Parameters and outputs
are strongly typed. So I need to say this is going to be a string and then I just do equals. Again, I'm just getting
IntelliSense the whole way through. I want to pull information
from this storage account, so I'm going to do stg. Now I'm going to do dot, and I'm getting that
same IntelliSense. I'm actually getting
even more IntelliSense because if you do a query
of a storage account, you do a get call on
a storage account. There's more information than
when you actually created the storage account
up a few lines above. So if I do storage.properties, I'm now going to get all of this other information that I can
pull from the storage account. If I start typing primary
endpoints, it'll show up there. If I do dot, I can do blob. This is the actual blob
endpoint that is created for this storage account and IntelliSense
help me all the way through. >> Wow, that is sick. I love this. Cool. >> We're doing a much richer job of just type safety
and type checking. Bicep is actually checking
that your output the string, then this property also
better be a string. If I change this to int, I'm going to get an error because we know that the blob is going to be a string and so we can check those sorts of
things for you as well. >> Cool. So how do I get
documentation for this? Because you've got me excited
now just that little demo. I want to start playing with this. How do I even get started with this? >> The repo is a really
great place to start. If you go to s/azure/bicep
we have a tutorial here. You go to "Getting Started", we'll walk you through
installing the tooling, and then we walk you through
a pretty thorough tutorial of the absolute basics all the way through to using all
the advanced features. Some of which I'll be
able to show you today, but pretty much everything
is included here. >> Cool. What's my
normal workflow then? Let's say, I need to provision
some stuff in Azure for project, so I create a dot Bicep file. I start adding all that stuff in. How do I then compile that? I guess it's going to turn
into an ARM file, right? >> Right. Exactly. Today and
we're in and I should say this, we're in a very early
experimental release. I happen to think the
tooling is already really good and the
language is already good, but we're still in the
process of making, breaking changes, and
things like that. >> Okay. >> For today, you have to build this file from a Bicep
file into an ARM template. Let's do that. I'll do Bicep builds
again the same way as before. I did not save. You got to save. But now if I go to the JSON file, I'll see that same
information represented here. I have my storage account, I have my output. All this voodoo of using the reference function
and the resource ID function. You don't need to worry about any of that anymore. We take care of that. >> Nice. >> Now, it's just an
ARM template file so I can do the same
things that I'm used to. I can do, for example, az deployment group create, which is the command I use to deploy a template
file and I could just say.f /-f main.json
not the main.bicep. Send it to a specific resource group. I can do -c, which is the what if, that's confirmed with what if. I can take this ARM template and use all the normal ARM template
tooling that I'm used to, to do things like what
if or plug it into a pipeline or whatever
I need to do with it. >> Cool, that is super, super cool. Another question for
you, because nearly trying to think of what
I want to start doing. So once I start trying
to provision stuff is going to be a little bit more
complex than just a storage account. Like if I start building stuff out that is
dependent on other stuff, is it capable of doing
like looping and taking the values from one thing and assigning it to stuff
that I'm doing later on? How complex can we make this? >> You can make it as complex
as you need it to be. Really a lot of ARM template and Bicep and any other
inferences code or config language authoring is a lot of wiring up
between things, right? >> Right. >> I may have a storage
account and I need to use this endpoint on
another resource type. Or I may need to pull keys from Cosmos DB so I can start using
it and all that sort of stuff. Really, it's just an extension
of really this core idea, which is I want to declare a resource and I want to
pull properties from it. I can go through here. Let's see if we can find
something good to look at. I'm just going to bounce
into the Bicep playground, which is just a web-based
version of the language service. There's a bunch of samples that the community
has been contributing to get started and kick-start
the Bicep development. This is a little more complicated, but really the same core idea. I have a bunch of parameters here. So ARM templates have parameters, Bicep has parameters,
I have some variables, and then I have a
website in this case, and a server farm or
an App Service plan. That's what it's
called in the portal. With the server farm and the website, you need to wire those
two things together. I've created my server
farm down here, same as it looks in an ARM template, just the cleaner syntax. Then I have my website which needs
reference to the server farm. This is that wiring up
that we talk about, which is I need the server farm's ID and I can
just pull that information directly by referencing what we call the symbolic name or the
resource identifier. Previously, you would need
to do like resource ID and then Microsoft.storage
and blah blah blah. Now you can just do farm.ib. It's much simpler to grok and simpler to read
and simpler to author. >> It really is. Wow, this makes me excited. I can take a dot Bicep file and I can compile it down
into an ARM template. I have a bunch of ARM templates
that currently exist. Is it possible to take my
ARM template and turn them into Bicep file so I can just
use Bicep moving forward? >> Yeah, exactly. Let me just switch this
back to a blank Bicep file. We have a decompile button
in a Bicep playground, which you can get a
link to from the repo. >> Okay. >> So if we go into Quickstarts, so I'm in Azure Quickstart Templates. There's almost a thousand
great ARM templates here that have been
validated and you can use. I want to use this as
a jumping off point. I'm going to go to the raw link here. >> I'm going to chose
the decompile button, and I'm going to
point it to that URL. >> Cool. >> Now it's going to
bring that in and decompile so it's going to go from right to left instead
of left to right. >> Yeah. >> This is now a working bicep file and I can just use it in my project. Let's go to the next
level and we'll show you something really
cool, which is modules. Let's take this bicep turn, will go back to VS code, I'm going to add a new
file I'm going to call web app.bicep and I'm just going
to copy and paste that over. The bicep COI has a decompile
command in it as well, so if you have the
file on your machine, you can just do bicep decompile, should be here, bicep decompile
right here and then you just point it to your JSON file and it all generate the bicep file. >> Nice. Very nice, that's so cool. Wow. >> Now we want to
consume that web app, we want to use it as
part of our project. We're going to do this. We're going to set the target scope so that's
another keyword in bicep, we're going to set the a target
scope to a subscription. Ninety five percent
of the time you're deploying an ARM Template to
an existing resource group. But you may want to
create the resource group and then deploy F2
right, very common. We can very quickly say, we're going to target
the subscription with this deployment and I want to create a resource group and
then I want to deploy that web app bicep file
to that resource group. Let's do resource rg. We're going to say resource group just like we did for
the storage account. Resource groups are simple, they just need a name. We'll say "Devops-demo" and a location and we'll
just say "Eastus." Now I'm going to use another
keyword called module, which is just a pointer
to another biceps file. I'm going to say web app mod. The type in this case is just
going to point to that web app.bicep module and
this needs a name, which is the name of the
deployment resource, which I can talk about in a second. It's a little bit of
the abstraction we came through but I need
to give it a name, so I'm going to call
this "Web app deploy". Then I can have params which are
the parameters in the bicep file. If I do control space here, this is looking at that
other bicep file seeing what parameters are available and showing them to me in intellisense. The wiring up just gets
really trivially easy. >> I can't wait to use this. >> I can override the web app name, which has a default value, so I may want to call it, "Adotfrank.webapp" or
something like that, or I can leave it alone. Now I am still getting
a red squiggly, so why am I did in a red squiggly? The reason is because my target
scope is a subscription, but this module, it needs to be
deployed to a resource group. I haven't told it what
resource group to deploy to. My do control space here, I have another property
called "Scope." Scope, I'm going to say, okay, I want to deploy to this rg.name. This resource group
had a spelling error, and you'll see bicep tell me, did you mean resource
group because we can give you that
approximation for you. I have resource group here
and I'm just pointing it to the resource group
that I just created. Again, I'm just
pulling that name from the symbolic name or the
resource identifier. Now I have the whole enchilada, I have the resource group
and I want to create and then the stuff that I
want to deploy to it. Now it's the same drill, I just do bicep builds main.bicep
and it's going to take them multi-file project
and basically compile it into a binary or a build artifact, which is the JSON file. It has both resource group and the underlying deployment
to that resource group, also contained in here. It gets a little heinous
we're now at a 104 lines, but you can trust us, I promise we're compiling
it in the right way. This is how you can really start
to simplify your projects, break them down into smaller,
more manageable pieces. All the good software engineering practices that we've learned
over the last 40-50 years, you can now apply it to bicep. >> I freaking love this Alex. This is so cool. Tell me, what stage is bicep at right
now, is it's still beta? >> We are using the
Word experimental right now so it isn't in 0.2 release. What we're saying basically, this is our time to get it out to you guys really early
and get feedback, which we've been getting a ton
of which has been awesome. Go to the Repo, open
issues, start discussions. Our goal right now is to
get to an O.3 release early next year and that's going to be one to one parody
with ARM Templates. That's when we're going
to start encouraging more production usage and do fewer, maybe not zero but fewer breaking changes so you can start
to really rely on it. >> Fair. Is it safe to say right now, we should just play around
with it and give you feedback? We shouldn't do production
work with it just yet? >> You can only in the sense that the ARM Template that we
produce is a GA service, if the ARM Template works, it's going to keep working tomorrow. But the bicep code we may ship breaking changes and
change the syntax so your bicep code may stop working
as we iterate on new features. >> Okay. Wow, this has
been super cool, Alex. Thank you so much for coming
here and showing this to us. I've all recognize how important
infrastructures code is, but I got to be honest ARM Templates, they're just hard, they
are hard to author, they're hard for me to author. Our tooling has
improved dramatically, especially the last couple of years, but it's still hard. This is so freaking cool. It's really using code to describe our infrastructure instead
of this giant blob of JSON. Looks so freaking amazing and
this is right up my alley, I can't wait to try it. People, if you want to know more, check out those links down below, Let's play with Project Bicep. Let's give Alex lots of feedback and then join us next time
on the DevOps Lab. [MUSIC]
