Speaker 1: Welcome back to the deep dive. Today, we're really getting
Speaker 1: into the weeds of Azure cloud deployment.
Speaker 2: Yeah, specifically how to make them wealth simpler and faster,
Speaker 2: more robust too exactly.
Speaker 1: And our guide for this is Selena Thresen's new book,
Speaker 1: az Your Bicep Quick Start pro It just came out
Speaker 1: July twenty twenty four.
Speaker 2: Right. It covers everything from the basics you know, Jason
Speaker 2: and air ARM all the way to advance the ICD
Speaker 2: and environment management.
Speaker 1: Our mission then really is to unlock what azure bicep
Speaker 1: can do for you. We want to show how it
Speaker 1: takes that often tangled mass of infrastructure management.
Speaker 2: It can definitely feel like that, sometimes it.
Speaker 1: Turns it into something streamlined, consistent and importantly secure. Absolutely,
Speaker 1: And to kick things off, Selena actually starts her book
Speaker 1: with a pretty compelling story.
Speaker 2: Ah, the origin story, you could.
Speaker 1: Say, kind of yeah. She talks about this high stage
Speaker 1: project wrestling with those old Jason based AIRM templates. Just
Speaker 1: sheer frustration.
Speaker 2: I think many can relate to that feeling, the verbosity,
Speaker 2: that complexity totally.
Speaker 1: She mentions the fear of manual errors, tight deadlines, just
Speaker 1: this sprawling list of Azure resources. It felt like there
Speaker 1: had to be a better way. You know. Then during
Speaker 1: this late night deployment issue, needing a really quick surgical fix,
Speaker 1: she stumbled upon BICEP and that.
Speaker 2: Was the light bulb moment exactly.
Speaker 1: She found its modular approach let her just zero in
Speaker 1: on the problem, changed one small reusable piece of code,
Speaker 1: and push the fix super fast.
Speaker 2: Wow. So it wasn't just fixing the bug. It changed
Speaker 2: how she thought about deployments completely.
Speaker 1: It showed her the path to automated, predictable deployments and well,
Speaker 1: that experience ultimately inspired her to write this book.
Speaker 2: Okay, so let's maybe rewind a bit. Start at the beginning.
Speaker 2: What exactly is infrastructure as code I see, especially an
Speaker 2: Azure and what role do those traditional ARM templates play?
Speaker 1: Right? So, IC basically means managing your infrastructure, your VMS, databases, networks,
Speaker 1: everything using code. Instead of clicking around in the Azure portal,
Speaker 1: you to find it all in files.
Speaker 2: And in Azure. The main engine for this is ARM,
Speaker 2: the Azure Resource Manager. Think of it as the control plane.
Speaker 2: It handles deploying, updating, deleting all your Azure resources consistently.
Speaker 1: The central nervous system you called it earlier.
Speaker 2: Yeah, that's a good way to put it. It works
Speaker 2: on a few core ideas. First, resource groups, you bundle
Speaker 2: related resources together, like all the parts of your web app, servers, database,
Speaker 2: storage go in one group. Makes management easier logical container exactly.
Speaker 2: Then you use declarative templates. These are files where you
Speaker 2: just describe what you want your end state to look like.
Speaker 2: You don't list the steps, just the final setup.
Speaker 1: Tell it the what, not the how.
Speaker 2: Precisely. AIRM figures out the how. It talks to different
Speaker 2: resource provider services that actually know how to create a
Speaker 2: VM or a storage account and so on.
Speaker 1: Got it.
Speaker 2: And you also have things like tags for organization key
Speaker 2: value pairs like environment dot prod or costcenter dot finance
Speaker 2: helps you track things.
Speaker 1: Okay, ARM sounds pretty foundational, but let's make it real.
Speaker 1: How would this help manage something really complex, like say
Speaker 1: a huge streaming service think Netflix.
Speaker 2: That's a great example because it shows the scale ARM handles.
Speaker 2: So for a Netflix like service, you'd probably define a
Speaker 2: main resource group maybe streaming service right inside a single
Speaker 2: ARM template, just one file. You could define all the bits,
Speaker 2: the web server, vms, the databases for user info, the
Speaker 2: CDN for video delivery, the authentication service.
Speaker 1: Everything all in one definition yep.
Speaker 2: And crucially, ARM gets the dependencies. It knows the database
Speaker 2: needs to exist before the web servers that connect to it.
Speaker 2: It orchestrates that automatically.
Speaker 1: Ah. So no more manual sequencing errors hopefully not.
Speaker 2: It simplifies bulk actions too, starting, stopping, maybe even replicating.
Speaker 2: The whole environment becomes one operation. Plus it ties into
Speaker 2: RBAC role based Access control for security.
Speaker 1: So only the right people can touch the right.
Speaker 2: Resources exactly, and you can enforce policies like naming rules
Speaker 2: or which regions you're allowed to deploy into. It all
Speaker 2: leads to consistent, automated and secure deployments, even for really
Speaker 2: complex stuff.
Speaker 1: Okay, that sounds powerful, but you mentioned earlier Selena's frustration.
Speaker 1: If Aaron is so capable, what was the big deal
Speaker 1: with writing these templates in Jason?
Speaker 2: Ah? Yes. The Jason challenge see JSON itself is you know,
Speaker 2: a standard data format, objects with curly braces, a raise
Speaker 2: with square brackets, key value pairs.
Speaker 1: It works fine for simple data transfer, right.
Speaker 2: But AIRM templates defining say dozens or hundreds of resources,
Speaker 2: they become massive, really verbose, deeply nested structures, lots of
Speaker 2: boilerplate code, brackets and commas everywhere.
Speaker 1: Hard to read, hard to write.
Speaker 2: Extremely it's like reading legal documents, almost very easy to
Speaker 2: miss a comma or a bracket leading to errors. Debugging
Speaker 2: was a nightmare, and just maintaining it over time that
Speaker 2: sheer verbosity. It was a major pain point.
Speaker 1: Okay, so Jason was the headache. Ter ash your BICEP.
Speaker 1: What is it and why is it seen? Is such
Speaker 1: a big improvement.
Speaker 2: BICEP is what's called a domain specific language a DSL.
Speaker 2: It was built specifically for deploying Azure resources. Its whole
Speaker 2: reason for existing is to be simpler, more concise, and
Speaker 2: way more readable than those Jason arm templates.
Speaker 1: Designed from the ground up to fix those Jason issues.
Speaker 2: Pretty much, it's all about improving the developer experience, reducing
Speaker 2: that complexity, making it easier to write correct infrastructure code,
Speaker 2: and catching errors earlier.
Speaker 1: What's really interesting, then, is how it tackles those specific
Speaker 1: limitations we just talked about, yea, how does it make
Speaker 1: life easier?
Speaker 2: The difference is stark, honestly. Readability is the first thing
Speaker 2: you notice. Remember that Jason snippet for a simple storage
Speaker 2: account maybe a dozen lines, lots of syntax noise, Yeah,
Speaker 2: kind of dense. The equivalent BICEP code it's like five lines.
Speaker 2: It looks much more like a simple declaration resource storage account,
Speaker 2: Microsoft Dot Storage storage accounts. It's cleaner, more.
Speaker 1: Intuitive, Okay, visually much simpler, but what about beyond just looks.
Speaker 2: Oh huge improvements in the workflow, Type safety and intellisens
Speaker 2: are big ones. As you type in tools like vs
Speaker 2: code byStep understands the Azure resource types and properties. It
Speaker 2: gives you autocompletion and flag errors right there.
Speaker 1: Like having a spell checker for your infrastructure code.
Speaker 2: Kind of yeah, but smarter. It catches structural errors, type mismatches,
Speaker 2: things like that before you even try to deploy. Save
Speaker 2: tons of time.
Speaker 1: Nice. Then there's automatic dependency management. Often you don't even
Speaker 1: need to explicitly say this depends on that. BICEP can
Speaker 1: infer the order based on how you reference resources. Ah
Speaker 1: less manual wiring exactly. It also has much better modularity
Speaker 1: built in. Creating reusable components is straightforward, air messages are clearer,
Speaker 1: debugging is easier, and it integrates smoothly with the Azure
Speaker 1: Cli PowerShell vs code all the standard tools.
Speaker 2: Seems like a much smoother experience overall. How easy is
Speaker 2: it to actually get started with it?
Speaker 1: Surprisingly easy. If you use visual Studio code, just install
Speaker 1: the extension and that gives you all the good stuff syntax, highlighting, IntelliSense, validation.
Speaker 2: Okay, just an extension install yep.
Speaker 1: And if you already have a bunch of JSON armed
Speaker 1: templates lying around, there's a command as bi sep decompile.
Speaker 1: It'll convert your jason files into BICEP.
Speaker 2: That's handy, so you can migrate existing stuff exactly.
Speaker 1: It gives you a starting point, lets you leverage what
Speaker 1: you've already built.
Speaker 2: All right, so we know why BICEP is better. Now
Speaker 2: how do we actually use it? What are the main
Speaker 2: parts of a BICEP file, the building blocks. Well, it
Speaker 2: still uses that declarative approach. You define the end state
Speaker 2: you want and Azure figures out how to make it
Speaker 2: happen till the what not the how exactly. The core
Speaker 2: elements you'll see are parameters, which are your inputs, things
Speaker 2: like resource names, locations, maybe VM sizes. You can give
Speaker 2: them default values, allowed values, descriptions, make them flexible.
Speaker 1: PRAM location string westis.
Speaker 2: Sort of thing precisely. Then you have variables. These are
Speaker 2: for storing values you reuse within the template, maybe constructing
Speaker 2: a unique name or a common setting.
Speaker 1: Like var storage skews standard RS.
Speaker 2: Then the main part resources. This is where you define
Speaker 2: the actual Azure services you want to deploy, the storage accounts,
Speaker 2: the virtual networks, the databases. You specify the type, API, version, name, location.
Speaker 1: And properties the actual infrastructure bits right.
Speaker 2: And finally, outputs. These are values that the template returns
Speaker 2: after deployment, maybe the public IP address of a VM
Speaker 2: or the connection string for a database. Useful for connecting
Speaker 2: deployments together.
Speaker 1: Okay, parameters, variables, resources, outputs seem straightforward, but how do
Speaker 1: we make templates you know, more dynamic handle different situations.
Speaker 2: That's where the more advanced features come in. You've got conditions.
Speaker 2: Using an if keyword, you can say, deploy this resource
Speaker 2: only if this parameter is true.
Speaker 1: Ah, so like only deploy monitoring tools.
Speaker 2: In production exactly, or maybe deploy a specific type of
Speaker 2: VM based on an environment parameter. Very useful for tailoring deployments.
Speaker 1: Makes sense.
Speaker 2: Then you have loops using four if you need, say
Speaker 2: five identical storage accounts instead of copying the resource block
Speaker 2: five times, you just loop over an array of names
Speaker 2: or configurations.
Speaker 1: Much cleaner, less repetition.
Speaker 2: Way cleaner now dependency handling. While BICEP is smart about dependencies,
Speaker 2: sometimes you do need to explicitly tell it. The order
Speaker 2: using dependsen.
Speaker 1: When would you need that. If it's often automatic.
Speaker 2: Sometimes it's subtle. Maybe resource B doesn't technically block resource
Speaker 2: A from being created, but resource A needs a value
Speaker 2: from resource B during its configuration. Explicit depends on insures
Speaker 2: B finishes completely first. It also helps prevent weird stuff
Speaker 2: like circular dependencies A depends on B and B depends
Speaker 2: on A.
Speaker 1: Right, avoiding those loops.
Speaker 2: Yeah, and managing complex chains like VM needs an NIC,
Speaker 2: which needs a subnet, which needs a VNT depends on
Speaker 2: clarifies those multi level relationships one needed.
Speaker 1: Got it crucial for complex setups.
Speaker 2: Absolutely and maybe most critical. Securely managing secrets never ever
Speaker 2: hard code passwords, apike is or connection strings in your templates.
Speaker 1: Big no, no, huge.
Speaker 2: The way to do it is with Azure key volt.
Speaker 2: You store your secrets securely in key volt, then in
Speaker 2: your BICEP template you reference them. You can define a
Speaker 2: parameter with a at secure decorator like.
Speaker 1: Peram admin password string.
Speaker 2: It's secure exactly, that tells bise up. In Azure this
Speaker 2: is sensitive during deployment. The value is fetched securely from
Speaker 2: key volt The secret itself never lives in your code
Speaker 2: or your source control.
Speaker 1: Much safer centralized secret management.
Speaker 2: And you control who or what like your deployment pipeline
Speaker 2: can access which secrets in key vault granular control.
Speaker 1: Okay, and what about when things go wrong? Errors? Debugging?
Speaker 2: BISUP tooling really helps here. The vs code extension gives
Speaker 2: you that real time validation, catching syntax errors as you type.
Speaker 2: Intell a sense helps you avoid typos in resource types or.
Speaker 1: Properties, catching things early.
Speaker 2: Yeah, and before you deploy for real. You can use
Speaker 2: the Azure cli command as deployment group validated. It basically
Speaker 2: does a dry run checks your template and parameters against Azure,
Speaker 2: finds potential issues like naming conflicts or missing dependencies, but
Speaker 2: doesn't actually create anything.
Speaker 1: A pre flight check. That sounds incredibly useful.
Speaker 2: It saves a lot of failed deployment cycles.
Speaker 1: Okay. So as these deployments get bigger, maybe across multiple
Speaker 1: teams or projects, how do we avoid just massive unmanageable
Speaker 1: BICEP files. You mentioned modules earlier.
Speaker 2: Yes, BISEEP modules are absolutely key for scaling. Think back
Speaker 2: to Selena's challenge with that plethora of resources. Modules are
Speaker 2: how you break that down? A module is just another
Speaker 2: BICEP file that defines a logical unit of infrastructure, like
Speaker 2: a standard virtual network setup or maybe a web app
Speaker 2: with its associated app service plan.
Speaker 1: So like creating your own reusable building.
Speaker 2: Blocks exactly, they offer encapsulation. The main template doesn't need
Speaker 2: to know the messy details inside the module, just its
Speaker 2: inputs and outputs. Reusability is obvious. Define at once, use
Speaker 2: it everywhere. They take parameters so you can customize each instance,
Speaker 2: and they provide outputs so you can chain them. A
Speaker 2: network module outputs a subnet ID, which a VM module
Speaker 2: then uses.
Speaker 1: How do you actually use them in code?
Speaker 2: You just create your module as a separate dot BISEEP file,
Speaker 2: say network dot bicep. Then in your main template use
Speaker 2: the module keyword, give it a symbolic name, point to
Speaker 2: the filepath, and pass in any required parameters.
Speaker 1: Module myv net dot network, dot bi SEP motor.
Speaker 2: Sort of thing precisely, and you can nest them too.
Speaker 2: Maybe you have a compute module that itself uses a
Speaker 2: VM module and a DISC module. You can build up
Speaker 2: really complex solutions from these smaller, manageable, reusable pieces.
Speaker 1: That sounds much more organized. So with modules in these
Speaker 1: advanced features, how do we handle different configurations for say,
Speaker 1: dev staging in production. We don't want the same settings everywhere, right.
Speaker 2: That's where parameter files come in. Instead of putting environment
Speaker 2: specific values directly in the BICEP file or passing them
Speaker 2: one by one on the command line, you create separate
Speaker 2: JSON files, maybe Maine dot parameters, dot dev dot json,
Speaker 2: Main dot parameters, dot staging dot Json, Maine dot parameters,
Speaker 2: dot prod dot json.
Speaker 1: So each file has the specific values for that environment exactly.
Speaker 2: The dev file might point to a small VM size
Speaker 2: and a dev database tier, while the prod file points
Speaker 2: to larger sizes and production tiers. When you deploy, you
Speaker 2: just tell Azure which parameter file to use for that
Speaker 2: specific deployment.
Speaker 1: Keeps the main BICEP template generic.
Speaker 2: And reusable totally, and you can pass complex types like
Speaker 2: arrays and objects as parameters too often defined in these
Speaker 2: parameter files, maybe in a ray of subnet configurations or
Speaker 2: an object describing VM settings, And again for sensitive stuff
Speaker 2: in production parameter files you'd reference as your key vault secrets,
Speaker 2: not put the actual secret in the JSON file.
Speaker 1: Okay, this is starting to feel really systematic. Let's connect
Speaker 1: it all up. How do we integrate BICEP into a
Speaker 1: proper CICD pipeline. Continuous integration, continuous deployment. That feels like
Speaker 1: the end goal here.
Speaker 2: Absolutely, CICD is about automating that whole flow. Code check
Speaker 2: in triggers, builds, tests and deployments reduces human error speeds
Speaker 2: things up. Takes a boring, which is good exactly by
Speaker 2: SEP works great with tools like GitHub Actions or az
Speaker 2: your DevOps pipelines. The typical flow is you push your
Speaker 2: BICEP code changes to your repository like GitHub or as
Speaker 2: your repos.
Speaker 1: That kicks off the pipeline YEP.
Speaker 2: The pipeline then usually runs steps to set up the
Speaker 2: Azure CLI logs into Azure securely using service principles or
Speaker 2: managed identities stored as secrets in the CICD platform, and
Speaker 2: then runs the as deployment group create command pointing to
Speaker 2: your BICEP file and the correct environment specific parameter file,
Speaker 2: and it can.
Speaker 1: Deploy to different environments based on say the.
Speaker 2: Branch name Yeah, easily. You can have conditions in your pipeline,
Speaker 2: like if the push was to the main branch, deploy
Speaker 2: using parameters dot pro dot json to the production resource group.
Speaker 2: If it was the develop branch, use parameters dot dev
Speaker 2: dot json for the dev environment. Ensures consistency.
Speaker 1: Nice. What about safety nets. If a deployment goes bad.
Speaker 2: Critical point, you need roll back and roll forward strategies.
Speaker 2: Rollback means quickly reverting to the last known good state.
Speaker 2: Maybe your pipeline detects a failure or monitoring catches an
Speaker 2: issue immediately after deployment. You might trigger another deployment using
Speaker 2: the previous version of the code or a specific rollback parameter.
Speaker 1: File get back to safety quickly.
Speaker 2: Right roll forward means you quickly fix the issue in
Speaker 2: your BICEP code, test it, and deploy the new, corrected version.
Speaker 2: The key is having automated ways to do either rather
Speaker 2: than scrambling manually. Makes sense and for really minimizing deployment
Speaker 2: risk and downtime, especially for user facing applications. You can
Speaker 2: use blue green deployments.
Speaker 1: Ah, I've heard of this. Two identical environments exactly.
Speaker 2: Let's say your live environment is blue. You deploy the
Speaker 2: new version of your application and infrastructure using BICEP, of course,
Speaker 2: to an identical but currently idle green environment.
Speaker 1: Deploy to the side.
Speaker 2: You test green thoroughly, smoke tests, integration tests, maybe even
Speaker 2: route a tiny bit of life traffic to it. Once
Speaker 2: you're confident, flip the switch. Flip the switch using something
Speaker 2: like Azure Traffic Manager as your front door. You redirect
Speaker 2: all live user traffic from blued green. Green is now live,
Speaker 2: Blue becomes idle.
Speaker 1: And if something goes wrong with Green after the switch.
Speaker 2: You just flip the switch back. Traffic goes back to
Speaker 2: the stable blue environment almost instantly. It dramatically reduces the
Speaker 2: risk and impact of a bad deployment. You just need
Speaker 2: to be careful about state management databases, user sessions during
Speaker 2: the switch. Hashtag tashtag outro.
Speaker 1: Wow. Okay, that was definitely a deep dive. We went
Speaker 1: from the pains of JSON ARM templates, uh huh.
Speaker 2: The verbosity, the complexity to really unpacking as your BICEP
Speaker 2: it's clean syntax conditions, loops those crucial modules for reuse,
Speaker 2: and then connecting it all into automated, reliable CICD pipelines.
Speaker 1: Right with strategies like parameter files keyvolt for secrets and
Speaker 1: even advanced techniques like blue Green deployments for resilience.
Speaker 2: Exactly, and the core takeaway for you the listener is
Speaker 2: hopefully that you can now approach AJUT deployments with more confidence.
Speaker 2: You can manage your infrastructure as code efficiently, ensuring things
Speaker 2: are consistent, reliable, and secure across dev, staging, production, all
Speaker 2: your environments.
Speaker 1: It's about moving away from manual clicks and potential errors
Speaker 1: towards automated, predictable infrastructure.
Speaker 2: That's the goal, less firefighting, more building.
Speaker 1: So to leave you with something to think about building
Speaker 1: on what we've discussed today from Selena Thresen's work, what's
Speaker 1: one piece of your own current infrastructure deployment process, maybe
Speaker 1: something manual, error prone or inconsistent that you could start
Speaker 1: simplifying and securing today by adopting biceps declarative power and
Speaker 1: a more modular automated approach