search

Azure / bicep

Bicep is a declarative language for describing and deploying Azure resources
MIT License
3.21k stars 745 forks source link

Question: Why not just embrace terraform? #409

Closed Lachlan-White closed 4 years ago

Lachlan-White commented 4 years ago

Is your feature request related to a problem? Please describe. Hi All, Love the progress to more abstraction, its a great move. Personally as a long time user of both ARM and Terraform. What is the thinking behind not just embracing terraform?

Is there a document page about this, in terms of the added benefit of bicep over terraform as an abstraction?

I love the idea and keen to take it for a test run, just want to get a better understanding of the thinking behind it and where it would potentially accel when compared to terraform?

slavizh commented 4 years ago

Please do not embrace Terraform!!!

arendej commented 4 years ago

Please do not embrace Terraform!!!

Why? The readme for bicep, indicating it's not production ready and is experimental, as opposed to Terraform which is stable, and is highly expanded-upon to work with more than just Azure, and does it all very well, including workspace handling and is a well thought out infra-as-code model. Even Ansible does a pretty great job at automating cloud provisioning on Azure. What separates bicep from the pack? What makes it unique? Good open-source communities/projects shouldn't be anti-anything without a solid reason.

slavizh commented 4 years ago

My view for Terraform is completely different from yours apparently :) . I will try to put some of the things that are wrong with Terraform. And these are just some of the things. Terraform is just wrapping things around ARM API and in many cases they are way behind what is available in ARM. From the people I know who has used Terraform the language is not good at all. YML has the same problems as JSON.

The guys here are trying to do something that does not require a bunch of teams to implement the latest stuff on Azure services otherwise the language becomes just another Az PowerShell module or Az CLI that needs constant update and multiple teams to take care of that.

As this is opened discussions I am just expressing my opinion. You are free to not agree with me but and I am free to not agree with you :)

alex-frankel commented 4 years ago

To clarify, we are embracing terraform in addition to bicep. We are not anti-anything :) There's enough usage of both to justify the investment, and we have a dedicated team at microsoft to make the TF experience as good as it can possibly be

ARM Templates are by far the most used language for declarative deployments to Azure, so bicep is really designed to make their experience better. Some of the reasons we see customers successful with ARM include:

Lachlan-White commented 4 years ago

Thanks for the insight @slavizh and @alex-frankel, Really good background. I work with Microsoft Azure all day every day and am also a HashiCorp Ambassador so keen to see both sides and both tools work!

Not sure who you are speaking to in regards to the language that terraform uses (HCL), but like bicep it started without all the capability and then added it, such as looping, etc. I'm not sure where YML comes into it.

Day Zero support is what I see as the main benefit for this one.

Can't wait to see it progress further!

alex-frankel commented 4 years ago

awesome - let us know if there are any other questions. Good if I close this?

Lachlan-White commented 4 years ago

Sure thing Alex close away. Thanks for taking the time !

ChristopherGLewis commented 4 years ago

Please do not embrace Terraform!!!

Why? The readme for bicep, indicating it's not production ready and is experimental, as opposed to Terraform which is stable, and is highly expanded-upon to work with more than just Azure, and does it all very well, including workspace handling and is a well thought out infra-as-code model. Even Ansible does a pretty great job at automating cloud provisioning on Azure. What separates bicep from the pack? What makes it unique? Good open-source communities/projects shouldn't be anti-anything without a solid reason.

Two words. State File.

Terraform's "source of truth" is the state file, not Azure. This can cause all sorts of chaos with any environment that doesn't completely block change access to the portal.

Now, if you said "Terraform HCL", that's a completely different situation and MS should support that (@alex-frankel ) as a source/destination for compile/decompile.

KatteKwaad commented 3 years ago

The state file is not really a problem as it can easily be refreshed or fixed in case of imports etc. I don't agree with the above statement that Terraform is just an ARM wrapper as it uses the REST APIs which makes it dependent only on the provisioning APIs. Whilst I do get that Bicep might be more directly on the metal to Azure, there are other things which we do that the Azure platform has just been terrible at: Certificate management. We generate Let's Encrypt certificates (internally of course) and roll them regularly whilst being able to deploy them to their respective destinations. We still have App Gateway V1s that don't load certs from KeyVault and KeyVault itself only allows for rolling of certs from limited certificate providers anyway so we've filled this requirement with Terraform quite nicely.

The final advantage for us is of course, it can be used with other cloud providers too

jdevalk2 commented 3 years ago

Commenting on closed topic :-)

The overall promise of Bicep seems good, it has latest support for ARM API.

I would pose a question : is there a number on how many production deployments are immediately using the "latest and greatest"? How many projects are waiting for bleeding edge feature, and when released immediately implement it? (Actually I do not know the answer to this myself, but it would help gauge the "immediately available" feature's value)

Thought and question to Devs: Could we not split off the ARM integration / decompilation piece of Bicep into a Terraform Provider? After watching the Ignite overview, that is the feature that caught my attention most.

The feature of "another language that is not JSON" Personally I believe that problem has been solved a couple times before, so I would need extra convincing there. Why learn another syntax and language and tooling?

That is the main drawback I see for Bicep : that it runs the risk of "yet another tool" for a development team to learn. (next to Ansible, Terraform, ARM) If I work on AWS, Google as well, I would have to know Terraform, or that platforms native choice.

Terraform promise was to shield you from the underlying platforms madness it seems. I agree sometimes that remains just a promise and it fails - adding more madness of its own. But a common language like HCL and tools to manage multiple clouds makes sense to me at some level. Bicep would take us away from that multi-cloud hybrid tooling ideal?

severity1 commented 3 years ago

in a real word scenario i would use terraform to provision AKS using the azurerm provider, then use the kubernetes provider and the helm provider to bootstrap my cluster and install my operational tools.

The reason people gravitated toward sterraform is because of the statefile, a means to track record changes idnependent and outside the influence of the target provider.

aucampia commented 1 year ago

Two words. State File.

Terraform's "source of truth" is the state file, not Azure. This can cause all sorts of chaos with any environment that doesn't completely block change access to the portal.

Actually, bicep is particularly poorly suited for cases where manual changes can happen when compared to Terraform.

With Terraform, if I delete a resource from Terraform, Terraform understands, by virtue of it's state file, that it should remove it from the underlying provider.

With Bicep, if I delete a resource, I have to be deploying with complete mode for it to delete the resource, and it does not support complete mode with some scopes, but regardless, when I do deploy in complete mode, everything in the scope (e.g. the resource group) that is not in the azure template gets deleted.

The state file may seem annoying, but not having it is also pretty annoying.

alex-frankel commented 1 year ago

Agreed that there are both pros and cons to the state file. In particular, you get a much more accurate plan output.

FWIW @aucampia, Deployment Stacks is designed to enable a lot of the update/delete workflows you are describing.

aucampia commented 1 year ago

FWIW @aucampia, Deployment Stacks is designed to enable a lot of the update/delete workflows you are describing.

Thanks for sharing, did not now about this. Seems pretty useful.

ChristopherGLewis commented 1 year ago

FWIW @aucampia, Deployment Stacks is designed to enable a lot of the update/delete workflows you are describing.

Thanks for sharing, did not now about this. Seems pretty useful.

Agreed that there are both pros and cons to the state file. In particular, you get a much more accurate plan output.

FWIW @aucampia, Deployment Stacks is designed to enable a lot of the update/delete workflows you are describing.

Agreed that there are both pros and cons to the state file. In particular, you get a much more accurate plan output.

FWIW @aucampia, Deployment Stacks is designed to enable a lot of the update/delete workflows you are describing.

Deployment Stacks are certainly looking like they will be the best approach - State management, but Azure controls the state and the Azure object themselves are state aware. This really eliminates the issue with Terraform's state going out of sync.