bicep VS infracost

My requirements need me to populate APIM's set-backend-service and rewrite-uri. With the above json, a user-defined function is required. And alas, as of now it's not possible in bicep :(

Bicep unfortunately chose to create a DSL instead of just exposing the dotnet API to allow IaC. Now there is a nuget package for Bicep core (https://github.com/Azure/bicep/pull/5826) you may be able to use dotnet code.

Yes, as of version 0.3 Azure Bicep is production ready. It is supported by Microsoft Support Plans and Bicep has 100% parity with what can be accomplished by ARM template.

I suggest reading the bicep documentation as I don't think it will require 12,000 words to determine the answers to your questions.

Bicep is open source with a strong community supporting it. All the binaries for the different supported operating systems can be downloaded from the official releases page of the Bicep open source project.

It sounds like you're running into this: https://github.com/Azure/bicep/issues/1631

The backend code is C#, with CosmosDb/TableStorage for persistence. Our client tools are also mostly C#, with some TypeScript, and some Python. Our backend code is currently closed-source, but our Bicep repo gives an example of our coding style.

The Microsoft Azure Deployments team aims to make deploying resources to Azure simple, safe, predictable, and reliable. We own the Template deployment orchestration service, client-facing tools including our open source DSL - Bicep, and various other services aimed at bringing customers up to speed with Infrastructure as Code. We are at the heart of the Azure control plane with great opportunities for cross-team collaboration and impact, have a lot of autonomy to shape the direction of our own products, and enjoy having a hands-on approach with customers to help drive our feature design.

u/nezoic can you open an issue for this here please: https://github.com/Azure/bicep/issues

Wonder how long until we get our first request to add support for this to infracost https://github.com/infracost/infracost? At least the price list looks a lot simpler than AWS / Azure / GCP - more like UpCloud! Though honestly, if it starts to work, I'm sure the number of prices/services will grow exponentially.

If you’re a Terraform fan, you’ll love this one. What if I tell you you can couple your infrastructure as code with bill forecasting? Sounds fantastic, huh? That’s what infracost.io is all about: it will scan through your Terraform files when you commit some changes to git and estimate the resulting billing of your changes! Pretty handy to have before getting unpleasant surprises.

Infracost https://github.com/infracost/Infracost (cli tool for cloud cost estimates from terraform) is always looking for new contributors. I’m one of the maintainers and we’re an approachable lot who are happy to help you through your first dip into open source.

I wanted to share an interesting learning from the open source project https://github.com/infracost/infracost/ and see what people think about writing policies for cloud costs using things like Open Policy Agent and HashiCorp Sentinel. For example: https://github.com/infracost/actions/tree/master/examples/opa

Awesome! Let me know how it goes :) We also have CloudFormation in our target: https://github.com/infracost/infracost/issues/190

Hi, we’re Ali, Hassan and Alistair, co-founders of Infracost ([https://www.infracost.io](https://www.infracost.io/)). Infracost shows engineers the cost of each Terraform change in CI/CD before resources are launched. When something changes, it posts a comment with the cloud cost impact. e.g. you’ve added 2 instances and volumes, and have changed an instance type from medium to large, this will increase your bill by 25% next month from $1000 to $1250 per month.

We launched the first version of Infracost just under a year ago (https://news.ycombinator.com/item?id=26064588). As we said in our first release ‘the people who are purchasing cloud resources are not shown costs upfront, so they don’t know how much the resources will cost before launching them’. Our assumption was that because we are open source and the engineers are flying blind, they would pull us into the workflow. Actually, something different is happening:

The engineers are not pulling us in - it turns out to be the senior DevOps, SREs and platform teams. One of their challenges is figuring out how their small team of 7 people can fulfill the infrastructure requirements of hundreds of engineers. To solve this, they have created and put in place processes for engineers to provision infrastructure when they need. Now they want to implement cost policies and guardrails so that these hundreds of engineers don’t blow past all budgets. For example, if a change will result in a higher than 15% increase, leave a warning. If a change results in a >25% increase in costs, block the change till a team lead has reviewed it.

This has two implications for us. First, we need to create an output that isn’t only used by humans but is also digested into other systems to make further decisions. The second is the people we have been speaking to are not our end users. We need to figure out how we can get introduced to our end users, and create a different set of questions for each persona.

Now, we are reworking our JSON output and creating examples with standard policy tools like Open Policy Agent (OPA), HashiCorp Sentinel and Conftest. We’d really love your feedback around the cost policies use-case. You can check out the repo for GitHub Actions at (https://github.com/infracost/infracost) (our other CI/CD integrations are listed here: https://www.infracost.io/docs/#4-add-to-cicd).

We'd love to hear how you think about policies and guardrails.

We've been thinking about this for a while, and if there is any way we can catch these types of cost spikes before they happen. We've managed to do it for Terraform resources using an estimation approach, and using a usage file, you can model expected usage-based resources (https://github.com/infracost/infracost/blob/master/infracost...), but this one has got us thinking more about policies.

To be clear - we would not have been able to catch this one right now :'(

Would love to hear thoughts / brainstorm ideas - is there any way we can proactively catch these types of cost spikes?