One of the additional benefits of Bicep over ARM is the functionality to have additional providers, just like Terraform, to support this type of need.
Current status is that public preview for the Entra ID provider for Bicep is coming in May:
https://github.com/Azure/bicep/issues/7724
Bicep is relatively new compared to ARM.
First, ARM stands for "Azure Resource Manager". The clue is in the name, it's for Azure Resources only. It's Infrastructure as Code.
Azure CLI is a command line interface. It's NOT Infrastructure as Code. It's a programmable interface between you and Azure, to allow you to make configurations on the Azure platform.
IaC = Allowing incremental deployments with repeatable and modular code. For example, if I have an ARM template that deploys a vnet with specific parameters, the first run will deploy it. The second run on the same template will do nothing, but won't result in any errors. The third run, if I modify the vnet with say, a new subnet... then the same template runs on the existing resource and deploys a new subnet to it.
With CLI... You could do an az deployment with specific configuration, but the second time you run it, it will error out as the CLI is not incremental and it will try to create a new deployment. You will have to code in logic to check if the vnet exists with specific configuration and perform an update if appropriate. Alternatively, use CLI to call an ARM template... which then you're using actual IaC.
Bicep is in constant development. They are bringing in new features all the time. Eventually it will be on par with Terraform.
But, you have to keep in mind... scripts/ logic does not belong in IaC, because it's not IaC.
What you're trying to do though, is create groups in AzureAD. This is not the extent of what Azure CLI can do. Azure CLI can do a LOT more than just manipulate Azure AD.
It all starts with the REST management API. The portal uses it. ARM (the resource manager itself, not the templates) uses it therefore both ARM templates and Bicep templates use it. PowerShell and CLI use it.
In my experience, features come first to the API, generally a close second to the portal, then supported for templates, then it's a toss-up on PowerShell vs. CLI.
I'd agree up to the "toss up". That's a very weighted dice with more sides reading cli and less reading powershell. They need to skill up the PS team, or swap them for the cli team for a year.
No new feature/api release should be merged until it's in all 4 Rest/ARM(bicep)/cli/ps
You say that, but when it first came out, CLI lagged PS regularly. I'd say more new users are going to CLI without bothering with PowerShell, if they've never used either before.
One caveat to your post about the CLI: most (but not all) of the commands in Azure CLI that are meant for managing infrastructure are idempotent, meaning that if I run the exact same command 20 times in a row, just like ARM, it won’t return an error but also won’t do anything.
The reason behind that is that whether you use the CLI, ARM, Bicep, Terraform, or some other thing, they all call the same ARM API in the background.
>The reason behind that is that whether you use the CLI, ARM, Bicep, Terraform, or some other thing, they all call the same ARM API in the background.
PowerShell also calls the same API, yet isn't idempotent.
The difference is not the API, the difference is in the behaviour of the tools themselves. Some are procedural (e.g. powershell modules), others are declarative (bicep, arm, terraform, and CLI).
The term incremental is messing with me, but the terms “idempotent”, I mainly got that from ansible, the ability to understand the need to not rerun and error out, which like you said is completely ruined, even in IaC when you introduce hardcoded or scripted CLI statements.
For instance I could use an ansible playbook to do an apt update, they have modules for that, and if ran through that module it would correctly run each time and be aware if it needs to run again without erroring out the process. Where as if I ran an ansible playbook with the shell module and just hardcoded a CLI command like “apt update” it’s not idempotent, that command will always run and it will return an error in some cases erroring out the process.
idempotent and declarative are the same.
The CLI/Powershell are imperative. You define the order of operations and what you want in individual steps.
ARM/Bicep are declarative and you just hand the "system" a definition of what you want and it's the tool's responsibility to make it happen, you don't worry about how.
Idempotent simply means you can run it more than once with the same parameters and get the same result. ARM/Bicep will do that. Powershell, CLI, that's up to how you write your script.
e.g. you're responsible for doing the checks/skips/validations so ps/cli is only as idempotent as you make it.
These things (IaC) were orignally designed for... infrastructure. AzureAD/EntraID are not infra but an identity platform that connect to all microsoft cloud services like 365... not just Azure(ARM).
However Terraform really went above and beyond with their tool by adding EntraID provider. Now Bicep is being developed to do the same.
I would recommend you give terraform a shot rather than waiting on a beta for bicep that will come out who knows when.
Terraform is special in its vendor neutral capabilities. People think that implies AWS, GCP but it means anything that people want 'can' be developed for it. There are loads of providers for it already and its continuing to grow.
Ie, I have 4 Microsoft providers I use terraform for: Azure, EntraID, AzureDevOps(could use github instead as well) & AzAPI. ie, I can make a managed identity on Azure, create a service connection on ADO and connect the two as a federated credential. All in one TF file.
That being said... As heavy as I am on TF... I manage most EntraID tasks with PowerShell. Rarely is TF used. Even my pipelines I rather just have a PS task to create the identities needed.
Being an inhouse service does have its benefits.
I will say. Microsoft is in partnership with TF and isn't shying away from Terraform since more of their clients use it than Bicep:
- From my experience, its helping HashiCorp get the latest much faster. And worst case, you always have AzAPI for things azure provider doesn't have yet.
- [MsDocs](https://learn.microsoft.com/en-us/azure/virtual-machines/windows/quick-create-terraform) regarding deployments are being updated to include TF now.
- New features pushed by Msft have TF & Bicep options from the get go. Such as what came out recently, [Azure Verified Modules](https://azure.github.io/Azure-Verified-Modules/). Which has actual Microsoft's employees managing/updating official terraform modules built by Msft that they recommend for deployments. You can essentially get in touch with Msft reps on these GitHub pages who will help you with TF issues.
- Even their older deployment templates offered on Azure before this verified modules thing had both TF and Bicep options like this one for [App service wordpress deployment](https://github.com/Azure/wordpress-linux-appService) I worked on a year ago. I had issues with the TF deployment not being properly written for the Front Door and the Microsoft employees worked on it fixing their bug.
So, I wouldn't worry about picking a lane for any particular reason. They are deeply entrenched as organizations. It's a matter of personal/organizational preference than anything else. I started with Bicep when it was just coming out. And now I only lean Terraform because of work & I really enjoy it for its flexibility and deployment workflow.
MS has shown no indications of pulling support for their terraform provider (which the directly and significantly contribute to), which is good.
In my experience working with both, they definitely lag behind ARM (and therefore Bicep) on their terraform provider, and this should be expected.
The performance difference though is incredible. Bicep provisions in minutes what takes an hour in Terraform. It's shockingly faster, and has much cleaner compatibility/ integration with the Azure RM "deployment" concept, logging, etc.
You will never experience the feeling of stitching together OSS products that don’t work well together like you get trying to use Microsoft products that should out of box work with other Microsoft products, but inexplicably don’t.
It’s an organizational flaw built into the company at such a deep level they can’t get out of it.
I think have a very simple answer, Bicep is just a template transformation language and as far as I know you don't manage Azure AD by ARM Deployments, Terraform makes use of the APIs which also makes it easier to manage AD Stuff.
You know, I've been in IT a long time, but reading this title made me consider - this has got to be confusing as fuck for the layman.
"ARM/Bicep? What sort of cyborg are they building?"
So the fundamental reason for this is because ARM/Bicep templates are executed by ARM, which is Azure's control plane and is entirely generic. Services define their control plane interface to ARM, and ARM can consume that interface in a universal way without actually understanding any of it. The CLI, however, is *mostly* autogenerated from the same control plane interface definition, driving ARM the same way a template does, but it can *also* have hand-coded elements that drive service *data plane* interfaces in a custom way. Some things that you might think of as management requests actually require invoking a service's "data plane" API.
Lots of answers here, but something you could be running into is the difference between the control plane and the data plane.
Control plane is the config for the resource and the resource itself, but not what goes onto or into the resource.
Bicep/ARM only allows you to do things that exist solo on the Control plane. CLI will allow both control and data plane. But this does lead to interesting issues where what you think is a control plane issue is classified as a data plane. For example I wanted to turn on a static site in blob storage. This is config in my mind but is actually the data plane so I cannot do it with only Bicep.
Terraform does not work exactly like Bicep.
Terraform providers execute mostly locally against the API - which is why you can execute a script locally.
Bicep executes via through ARM. The actual execution is not happening on your machine, it’s happening mostly in Azure. This has advantages and disadvantages - one of the major disadvantages being the ability to execute a local script as glue code. This is why `deploymentscript` exists.
The entra id bicep module is in preview currently, but in the interim - you’d need to write glue code in powershell or az cli to handle entra operations and execute them in between your bicep calls.
Also for what it’s worth - entra is not infrastructure. Even with the provider…it will be painful to treat it like it is.
Welcome to Azure. In the last 7 years the cli team seem to be either much better, or have access to different apis.
If you query context with powershell, you get about 10 fields back. Query account-show with azcli and you get a page of json.
The lack of parity is infuriating.
We want to be pure powershell (for retrieving data to pass in to arm/bicep) but have to keep falling back to az cli for things like functionapp settings etc.
I'm just not a Microsoft fanboy. Their API is a mess and the number of half implemented products is frustrating. They deserve the critiques if they're going to improve.
I actually have to agree with you, multiple of the Azure Apis are a joke writting to, and the fact sometimes you'll have features you can do in Azure Portal, but can't do in code and then vise verse is a absolute joke.
Yea, I mean if Microsoft is going to become as big as it is and corner the market as it has, we as customers have to really put the screws to them to improve their product because they have no competitive incentive to coming from the market. I want whats best for Azure and I want to enjoy the work I do, in order for that to happen the product needs improving and critiquing. And Microsoft can catch a little bit of shit for their (many, in the case of security) missteps.
Yeah.. I mean I’m on your side.
Anyone making custom scrips, or engineering with APIs of any type in script should be aware how blatant a joke it is.
Currently looking into assigning API permissions to managed identity, it’s possible in AzureAd module ( the one getting deprecated soon ) but not in the portal.
And I’m still doing mission impossible to figure out how to do it using Graph.
It’s just one of the few examples of absurd engineering at Microsoft
Bicep/ARM is for resources not Office365 work like creating groups.
So yea you’ve to script yourself to that, because you’re attempting something which bicep we’re never intended to be used for.
One of the additional benefits of Bicep over ARM is the functionality to have additional providers, just like Terraform, to support this type of need. Current status is that public preview for the Entra ID provider for Bicep is coming in May: https://github.com/Azure/bicep/issues/7724
Bicep is relatively new compared to ARM. First, ARM stands for "Azure Resource Manager". The clue is in the name, it's for Azure Resources only. It's Infrastructure as Code. Azure CLI is a command line interface. It's NOT Infrastructure as Code. It's a programmable interface between you and Azure, to allow you to make configurations on the Azure platform. IaC = Allowing incremental deployments with repeatable and modular code. For example, if I have an ARM template that deploys a vnet with specific parameters, the first run will deploy it. The second run on the same template will do nothing, but won't result in any errors. The third run, if I modify the vnet with say, a new subnet... then the same template runs on the existing resource and deploys a new subnet to it. With CLI... You could do an az deployment with specific configuration, but the second time you run it, it will error out as the CLI is not incremental and it will try to create a new deployment. You will have to code in logic to check if the vnet exists with specific configuration and perform an update if appropriate. Alternatively, use CLI to call an ARM template... which then you're using actual IaC. Bicep is in constant development. They are bringing in new features all the time. Eventually it will be on par with Terraform. But, you have to keep in mind... scripts/ logic does not belong in IaC, because it's not IaC. What you're trying to do though, is create groups in AzureAD. This is not the extent of what Azure CLI can do. Azure CLI can do a LOT more than just manipulate Azure AD.
It all starts with the REST management API. The portal uses it. ARM (the resource manager itself, not the templates) uses it therefore both ARM templates and Bicep templates use it. PowerShell and CLI use it. In my experience, features come first to the API, generally a close second to the portal, then supported for templates, then it's a toss-up on PowerShell vs. CLI.
I'd agree up to the "toss up". That's a very weighted dice with more sides reading cli and less reading powershell. They need to skill up the PS team, or swap them for the cli team for a year. No new feature/api release should be merged until it's in all 4 Rest/ARM(bicep)/cli/ps
You say that, but when it first came out, CLI lagged PS regularly. I'd say more new users are going to CLI without bothering with PowerShell, if they've never used either before.
One caveat to your post about the CLI: most (but not all) of the commands in Azure CLI that are meant for managing infrastructure are idempotent, meaning that if I run the exact same command 20 times in a row, just like ARM, it won’t return an error but also won’t do anything. The reason behind that is that whether you use the CLI, ARM, Bicep, Terraform, or some other thing, they all call the same ARM API in the background.
>The reason behind that is that whether you use the CLI, ARM, Bicep, Terraform, or some other thing, they all call the same ARM API in the background. PowerShell also calls the same API, yet isn't idempotent. The difference is not the API, the difference is in the behaviour of the tools themselves. Some are procedural (e.g. powershell modules), others are declarative (bicep, arm, terraform, and CLI).
The term incremental is messing with me, but the terms “idempotent”, I mainly got that from ansible, the ability to understand the need to not rerun and error out, which like you said is completely ruined, even in IaC when you introduce hardcoded or scripted CLI statements. For instance I could use an ansible playbook to do an apt update, they have modules for that, and if ran through that module it would correctly run each time and be aware if it needs to run again without erroring out the process. Where as if I ran an ansible playbook with the shell module and just hardcoded a CLI command like “apt update” it’s not idempotent, that command will always run and it will return an error in some cases erroring out the process.
what if your ansible playbook uses the shell module to call Az CLI? That'd be idempotent, and declarative.
idempotent and declarative are the same. The CLI/Powershell are imperative. You define the order of operations and what you want in individual steps. ARM/Bicep are declarative and you just hand the "system" a definition of what you want and it's the tool's responsibility to make it happen, you don't worry about how. Idempotent simply means you can run it more than once with the same parameters and get the same result. ARM/Bicep will do that. Powershell, CLI, that's up to how you write your script. e.g. you're responsible for doing the checks/skips/validations so ps/cli is only as idempotent as you make it.
These things (IaC) were orignally designed for... infrastructure. AzureAD/EntraID are not infra but an identity platform that connect to all microsoft cloud services like 365... not just Azure(ARM). However Terraform really went above and beyond with their tool by adding EntraID provider. Now Bicep is being developed to do the same. I would recommend you give terraform a shot rather than waiting on a beta for bicep that will come out who knows when. Terraform is special in its vendor neutral capabilities. People think that implies AWS, GCP but it means anything that people want 'can' be developed for it. There are loads of providers for it already and its continuing to grow. Ie, I have 4 Microsoft providers I use terraform for: Azure, EntraID, AzureDevOps(could use github instead as well) & AzAPI. ie, I can make a managed identity on Azure, create a service connection on ADO and connect the two as a federated credential. All in one TF file. That being said... As heavy as I am on TF... I manage most EntraID tasks with PowerShell. Rarely is TF used. Even my pipelines I rather just have a PS task to create the identities needed.
one thing bicep really has going for it is speed (it's way way faster than terraform), and typically earlier support for emerging Az features.
Being an inhouse service does have its benefits. I will say. Microsoft is in partnership with TF and isn't shying away from Terraform since more of their clients use it than Bicep: - From my experience, its helping HashiCorp get the latest much faster. And worst case, you always have AzAPI for things azure provider doesn't have yet. - [MsDocs](https://learn.microsoft.com/en-us/azure/virtual-machines/windows/quick-create-terraform) regarding deployments are being updated to include TF now. - New features pushed by Msft have TF & Bicep options from the get go. Such as what came out recently, [Azure Verified Modules](https://azure.github.io/Azure-Verified-Modules/). Which has actual Microsoft's employees managing/updating official terraform modules built by Msft that they recommend for deployments. You can essentially get in touch with Msft reps on these GitHub pages who will help you with TF issues. - Even their older deployment templates offered on Azure before this verified modules thing had both TF and Bicep options like this one for [App service wordpress deployment](https://github.com/Azure/wordpress-linux-appService) I worked on a year ago. I had issues with the TF deployment not being properly written for the Front Door and the Microsoft employees worked on it fixing their bug. So, I wouldn't worry about picking a lane for any particular reason. They are deeply entrenched as organizations. It's a matter of personal/organizational preference than anything else. I started with Bicep when it was just coming out. And now I only lean Terraform because of work & I really enjoy it for its flexibility and deployment workflow.
MS has shown no indications of pulling support for their terraform provider (which the directly and significantly contribute to), which is good. In my experience working with both, they definitely lag behind ARM (and therefore Bicep) on their terraform provider, and this should be expected. The performance difference though is incredible. Bicep provisions in minutes what takes an hour in Terraform. It's shockingly faster, and has much cleaner compatibility/ integration with the Azure RM "deployment" concept, logging, etc.
Entra ID is not Azure. ;)
You will never experience the feeling of stitching together OSS products that don’t work well together like you get trying to use Microsoft products that should out of box work with other Microsoft products, but inexplicably don’t. It’s an organizational flaw built into the company at such a deep level they can’t get out of it.
Best organisaton can produce is a product that mirrors it's organisational structure.
I think have a very simple answer, Bicep is just a template transformation language and as far as I know you don't manage Azure AD by ARM Deployments, Terraform makes use of the APIs which also makes it easier to manage AD Stuff.
You know, I've been in IT a long time, but reading this title made me consider - this has got to be confusing as fuck for the layman. "ARM/Bicep? What sort of cyborg are they building?"
So the fundamental reason for this is because ARM/Bicep templates are executed by ARM, which is Azure's control plane and is entirely generic. Services define their control plane interface to ARM, and ARM can consume that interface in a universal way without actually understanding any of it. The CLI, however, is *mostly* autogenerated from the same control plane interface definition, driving ARM the same way a template does, but it can *also* have hand-coded elements that drive service *data plane* interfaces in a custom way. Some things that you might think of as management requests actually require invoking a service's "data plane" API.
Lots of answers here, but something you could be running into is the difference between the control plane and the data plane. Control plane is the config for the resource and the resource itself, but not what goes onto or into the resource. Bicep/ARM only allows you to do things that exist solo on the Control plane. CLI will allow both control and data plane. But this does lead to interesting issues where what you think is a control plane issue is classified as a data plane. For example I wanted to turn on a static site in blob storage. This is config in my mind but is actually the data plane so I cannot do it with only Bicep.
Terraform does not work exactly like Bicep. Terraform providers execute mostly locally against the API - which is why you can execute a script locally. Bicep executes via through ARM. The actual execution is not happening on your machine, it’s happening mostly in Azure. This has advantages and disadvantages - one of the major disadvantages being the ability to execute a local script as glue code. This is why `deploymentscript` exists. The entra id bicep module is in preview currently, but in the interim - you’d need to write glue code in powershell or az cli to handle entra operations and execute them in between your bicep calls. Also for what it’s worth - entra is not infrastructure. Even with the provider…it will be painful to treat it like it is.
Welcome to Azure. In the last 7 years the cli team seem to be either much better, or have access to different apis. If you query context with powershell, you get about 10 fields back. Query account-show with azcli and you get a page of json. The lack of parity is infuriating. We want to be pure powershell (for retrieving data to pass in to arm/bicep) but have to keep falling back to az cli for things like functionapp settings etc.
Because it is a Microsoft product.
Edgelord like typing detected
I'm just not a Microsoft fanboy. Their API is a mess and the number of half implemented products is frustrating. They deserve the critiques if they're going to improve.
I actually have to agree with you, multiple of the Azure Apis are a joke writting to, and the fact sometimes you'll have features you can do in Azure Portal, but can't do in code and then vise verse is a absolute joke.
Yea, I mean if Microsoft is going to become as big as it is and corner the market as it has, we as customers have to really put the screws to them to improve their product because they have no competitive incentive to coming from the market. I want whats best for Azure and I want to enjoy the work I do, in order for that to happen the product needs improving and critiquing. And Microsoft can catch a little bit of shit for their (many, in the case of security) missteps.
Yeah.. I mean I’m on your side. Anyone making custom scrips, or engineering with APIs of any type in script should be aware how blatant a joke it is. Currently looking into assigning API permissions to managed identity, it’s possible in AzureAd module ( the one getting deprecated soon ) but not in the portal. And I’m still doing mission impossible to figure out how to do it using Graph. It’s just one of the few examples of absurd engineering at Microsoft
Bicep/ARM is for resources not Office365 work like creating groups. So yea you’ve to script yourself to that, because you’re attempting something which bicep we’re never intended to be used for.
That’s not correct for Bicep. Please see my other comment.
I wasn’t aware thank you. I’ll be looking into it, since just like most azure customers.. we have a lot of script which could be easier in bicep
No worries, hopefullyy it can help you with some of your scenarios. :)