Microsoft Ignite 2020 was an incredible opportunity for our virtual attendees to learn about all the great new features and advancements at Azure. One of the big new releases we saw was Project Bicep. This video with Azure CTO Mark Russinovich gives you insight into this new way of managing your Azure infrastructure with Bicep.
Bicep is a Domain Specific Language (DSL) for creating your Azure resources. While many different methods may select programming languages such as Ruby, Bicep really aims to reduce complexity by introducing a cleaner syntax for you to reuse your code more often. Bicep is a transparent abstraction of ARM templates, which differs from using another general-purpose programming language. Bicep uses Azure Resource Templates (ARM template) files in JSON to compile and deploy your desired infrastructure.
The following are the goals and the non-goals of this new DSL from the Project Bicep Repository documentation. For more information reach out to the team on how to contribute, please visit the CONTRIBUTING documentation from the repository.
Goals
- Build the best possible language for describing, validating, and deploying infrastructure to Azure.
- The language should provide a transparent abstraction for the underlying platform. There must be no “onboarding step” to enable it to a new resource
typeand/orapiVersionin Bicep. - Code should be easy to understand at a glance and straightforward to learn, regardless of your experience with other programming languages.
- Users should be given a lot of freedom to modularize and reuse their code. Reusing code should not require any ‘copy/paste’.
- Tooling should provide a high level of resource discoverability and validation, and should be developed alongside the compiler rather than added at the end.
- Users should have a high level of confidence that their code is ‘syntactically valid’ before deploying.
Non-goals
- Build a general-purpose language to meet any need. This will not replace general-purpose languages and you may still need to do pre or post bicep tasks in a script or high-level programming language.
- Provide a first-class provider model for non-Azure related tasks. While we will likely introduce an extensibility model at some point, any extension points are intended to be focused on Azure infra or application deployment related tasks.
Is this ready for production use? If not, when will it be ready? Not yet. We wanted to get the 0.1 release out quickly and get feedback while we still have an opportunity to make breaking changes. By the end of the year, we plan to ship an 0.3 release which will be at parity with what you can accomplish with ARM templates. At that point, we will start recommending production usage.
What are you looking for feedback on? The language syntax and the tooling. Now is the best time to make breaking changes, so syntax feedback is very appreciated.
To learn more about Project Bicep, check out the following resources:
Azure Bicep on GitHub
Bicep Language Specification
Microsoft Open Source Code of Conduct
@BicepLang on Twitter
What advantage does this offer over Terraform HCL?
Doesn't this address the same requirements as Terraform's native DSL, except that it's limited to only a single provider domain (Azure), it's very nascent, and it introduces yet another language/dialect that needs to be learned. TF addresses the same needs, but it's extensible and already offers a large provider library, it's been around a long time and has been evolved, improved and hardened over many iterations and...
Terraform is awesome! If you want to use and love Terraform, continue using and loving Terraform! Personally, I don't care what flavor of IaC people use. I just want them to use IaC. Project Bicep came about because we at Microsoft recognize that authoring and maintaining ARM templates (yes, this is specific only to Azure) can be a bit challenging and we are improving upon our native implementation. All that said, we are fully comitted...