rumno0

Just to show what it can do, some language servers built with it

- Makefile: https://github.com/owenrumney/make-ls

- Goreleaser: https://github.com/owenrumney/goreleaser-ls

Thanks -

If its a straight error, then the error response is returned and we're all happy!

If the handler panics, the server crashes, so that's something I'm off to fix now!

Thanks!!!!

I've been thinking about this comment for a few hours now! I love it! I like building VS Code extensions and realized quickly the benefit of writing the logic in an LSP but I would never have thought to do the SSH config thing you describe.

I've now started a Makefile lsp since you've inspired me to think about the painful scenarios that LSP can solve if I think a bit wider.

Cheers for that!!

I actually started out using that. I wanted a debug UI to track messages which was the major driver in creating my own tbh

I disagree - you should have docstring and I don't think this is worse by having it... its just not ideal

I wrote this for the infracost LSP so I could write multiple IDE extensions. Its not even really a language server, its just a neat way to parse the Terraform/Cloudformation and return diagnostics.

Language servers are cool!

thanks!

Thankfully, I finally had a reason to build an LSP (infracost LSP), so it motivated this and I'm really pleased with it

Yeah some times godoc comments look crap by necessity

This is effectively what Infracost Cloud is (https://www.infracost.io/)

It adds things like management of guardrails and policies that can be maintained by a finops role, or engineering manager. PRs can block or notify if thresholds are going to be breached by a specific PR.

To a certain extent I agree - I've worked on projects where a resource amounts to a rounding error in the overall cloud bill; for many organizations, cost is an important NFR for a project.

Going off the other threads of this post, how much engineers should know or care about billing seems to be open for debate; I think an engineer needs to appreciate that often cost is one of the many trade-offs that need to be accounted for

I just gave this a try with https://github.com/eksctl-io/eksctl/blob/main/examples/01-si...

ChatGPT gave me a decent chuck of terraform and running Infracost against it gave me a $515 monthly cost.

If you go to the settings of the plugin and get the absolute path of infracost binary then run

infracost breakdown --path .

in the dir with the terraform, does it give you a breakdown?

Hey Itay, thanks, and thanks for commenting, great to hear from you!!

The next step is certainly to look at the cloud account to get information on usage - this completes the picture of both for intended resources to create and what is already there.

Thanks for the feedback

Great feedback - thanks

Hey, thanks for the question - Infracost does three things at the moment: Cost estimation before code is merged (and this is what is in JetBrains now with this plugin); then it checks the code for best practices being followed (like if the code is using old instance types, or old volume types, or there is no retention policies in place etc), it will tell the engineers exactly how to fix those. and finally, it also checks to make sure all resources are tagged properly both with the key and value being checked. Again it tells the engineer how to fix it if there isn an issue.

So overall, the two main benefits are cost avoidance, and then engineering time saving or toil reduction, since all the issues get fixed before the code is merged. The product is being used by over 3,000 companies now in CI/CD; we have a few case studies on the website: https://www.infracost.io/safe-fleet/

Thanks for the feedback - appreciate the comments on the video, I can see that without audio the first minute or so is a bit dull -

Hope this Gif is clearer - https://github.com/infracost/jetbrains-infracost/blob/244ee8...

You're right, there are multiple roles for FinOps in an organization from the engineer up to finance and engineering management.

This is tackling one aspect of this - highlighting the cost to the engineer.

Our cost api is very regularly updated from the pricing data made available by the cloud providers.

Metadata about the resources that require cost estimation are rolled up and sent to the pricing API, it's generally pretty quick process even with large projects

Thanks, that's generally more readily available in the billing explorer for most cloud providers.

There is a definite case for pulling usage data from the cloud account to make suggestions about right sizing though, that's a definite roadmap item

oh okay, that's a shame. I'll put together a simple terragrunt and see what's going on

1. Not at the moment, but we're looking at other IaC tools to support on the road map.

2. There is a vscode extension - https://marketplace.visualstudio.com/items?itemName=Infracos...

3. That is a challenge, we use usage files, but in the future would like to pull it from the cloud account to be more accurate and the best suggestions. https://www.infracost.io/docs/features/usage_based_resources...

We support custom price books - https://www.infracost.io/docs/infracost_cloud/custom_price_b...

As for usage, at the moment it's driven from a usage file - https://www.infracost.io/docs/features/usage_based_resources...

In the future, we'd like to infer usage directly from the cloud account to give the most accurate view and do right size suggestion

I agree - there will always be an element of engineering knowledge required.

It's not dissimilar to AWS urging people to use Flex or Graviton instances, only we can decide if our workload will run appropriately!

Thanks!!

The plugin is using the CLI under the hood - so it should work as if you're using the CLI

I think this is the next natural evolution - bring in usage information directly from the cloud accounts then offer right-sizing suggestions and, like you say, reclaim garbage on demand.

Definitely one for the road map!

There was an interesting page on the FinOps Foundation site about this https://www.finops.org/wg/sustainability/

There is a potential intersection, but that might have to go further down the roadmap

That sounds like an idea for my next plugin :thinking:

Yes, we have got quite a lot of requests for those. On the roadmap for sure!

All fixed, appreciated!