One thing that has frustrated me for some time with Azure Service Bus is that the network security features, such as Private Endpoints and Service Endpoints, are locked behind the premium SKU, which has a significant extra cost. I believe security features should not be locked behind expensive SKUs and should be available to anyone using the service, as they are with most other Azure services. This results in either paying extra for the premium SKU just for these features or running the cheaper SKU without the additional security features.
When you first start with Infrastructure as Code, it can be tempting to create one template to rule them all™ where you can deploy your whole infrastructure in a single deployment. If you’re only deploying a few resources, then this can be fine, but once you get beyond that and are deploying complex sets of infrastructure, it’s important to consider your blast radius.
So what do we mean by blast radius?
If you use Azure AD Multi-Factor authentication, then you should be aware that as of 27th February 2023, Microsoft will begin enforcing number matching with MFA requests using the authenticator app. So what does this mean?
What is Number Matching If you’ve used Azure AD MFA push notifications using the authenticator app, you’ll be familiar with the popup you get when logging in, asking you to confirm your request.
The problem with this approach is MFA fatigue.
One of the Infrastructure as Code tools I often talk about on this blog is Pulumi. I’m a fan of its ability to use real programming languages toe define infrastructure and the flexibility this brings to what you can do during a deployment. The benefits of Pulumi for developers who need to deploy infrastructure are clear, but for IT Pros, who maybe don’t have so much experience in using programming languages, it can be intimidating.
Pulumi allows you to use real development languages to create your Infrastructure as Code. Because of this, you will usually need several prerequisites and libraries installed in your development environment, depending on which language you are using. You can set these up on your development PC, but one alternative approach is to use GitHub Codespaces. GitHub Codespaces allows you to quickly deploy a pre-configured development environment, along with your code running as a cloud service.
As you probably know, I talk quite a bit about Bicep. Invariably when I do, I get a comment or question like “why would I switch from Terraform to Bicep” or “This is pointless, Terraform already does all this”. Well, here’s the secret: if you’re using Terraform and are happy with it, then Bicep isn’t aimed at you!
Microsoft’s primary goal when creating the Bicep language was to remove the barrier of entry when using Infrastructure as Code in Azure.
Absolutely nothi… oh wait, they might have some uses.
When choosing an Infrastructure as Code (IaC) tool, there are many differentiating factors among the options available, but one that often comes up in this conversation is whether or not they use a state file. Some languages, such as Terraform and Pulumi, use a state file to track what has been deployed outside the cloud provider’s system. In contrast, other languages, like ARM templates and Bicep, don’t have a state file and rely on the actual state of the resource.
Over the last few months, I’ve been working on YouTube series called Bicep for Real, which aims to help you learn the Bicep language whilst applying it to a real project and a real-world scenario. This series goes beyond just Bicep and covers version control, automated tests, CI/CD and automated deployments. The aim is for people to come away from this series not only with knowledge of the Bicep language but also how it applies to their projects and real-world workloads.
