Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Infracost (YC W21): Be proactive with your cloud costs

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Show HN: Infracost (YC W21): Be proactive with your cloud costs

#11

Post by aliscott »

beaviskhan wrote: post #6

I have used this tool in the past, though free tier only. It was easy to get up and running and easy to plug into a CICD pipeline. The problem we had with it in practice was that we largely preferred serverless technologies in AWS where the cost depended mostly or even completely on actual usage - things like Lambda invocations, SQS operations, or autoscaling ECS services, for example. In this case the estimates we g…

Great point about the multiple API calls. One of the big problems we’ve heard about using SCPs is that they are too late. If a deployment fails because of them the developer needs to go through another pull request/code review.

Estimating costs for serverless technologies upfront is definitely challenging. We're thinking of bringing in the last 30 days of usage for these resources to give engineers some visibility.

Re: Show HN: Infracost (YC W21): Be proactive with your cloud costs

#12

Post by hkh »

alexambarch wrote: post #10

I've seen Infracost around and think it looks cool, do you have any plans to add support for Pulumi? One advantage Terraform seems to have over Pulumi is the ecosystem of tools that support it.

Yep, for sure! It's on the roadmap. We are friends with the folks at Pulumi too. Love what they are building, so hopefully we will get some bandwidth and add support. And Cloud Formation too. Azure ARM ... haha there is a lot more to build :)

Re: Show HN: Infracost (YC W21): Be proactive with your cloud costs

#13

Post by jaxxstorm »

hkh wrote: post #12
alexambarch wrote: post #10

I've seen Infracost around and think it looks cool, do you have any plans to add support for Pulumi? One advantage Terraform seems to have over Pulumi is the ecosystem of tools that support it.

Yep, for sure! It's on the roadmap. We are friends with the folks at Pulumi too. Love what they are building, so hopefully we will get some bandwidth and add support. And Cloud Formation too. Azure ARM ... haha there is a lot more to build :)

I'm a a Pulumi employee, if you'd like to chat about how we can help add support, email me lbriggs[at]pulumi.com

Re: Show HN: Infracost (YC W21): Be proactive with your cloud costs

#14

Post by keepamovin »

akh wrote: post #5
keepamovin wrote: post #3

I love it! But as human processes go, it will need to surmount the "flaky tests" problem of, "let's just turn off this test because it's flaky and we need to merge this branch". I guess that means FinOps teams will still have to fight to be heard, but I think you are helping shift a lot of their burden! What remains seems more like organizational dynamics, but what are your thoughts?

Great point - indeed FinOps teams consistently rank "empowering engineers to take action" as their number 1 challenge ( https://data.finops.org ) - and by that they mean the human and organization dynamics of the culture change they want to create across the org. The testing analogy is a good one as this feature also shows the engineers the current "failing policies" on the main branch too, so whilst they could merge…

Nice! What did you start out doing, if you don't mind me asking? And how did you come to this, pivot, if that's what it is?

Re: Show HN: Infracost (YC W21): Be proactive with your cloud costs

#15

Post by danpalmer »

beaviskhan wrote: post #6

I have used this tool in the past, though free tier only. It was easy to get up and running and easy to plug into a CICD pipeline. The problem we had with it in practice was that we largely preferred serverless technologies in AWS where the cost depended mostly or even completely on actual usage - things like Lambda invocations, SQS operations, or autoscaling ECS services, for example. In this case the estimates we g…

I've not used the product, so it may already do this, but does it ask you for the data it needs in the Pull Request?

I have experience interacting with a logging system, where any diff to the logged data would need a tag like `log_size_increase=3 bytes` – the CICD system would then turn this, with the data already available, into an estimate of the overall extra storage needed.

Perhaps the same could be done. Rather than figuring out "usage" of some serverless systems, which is a very vague question and therefore hard to answer, perhaps it could be more specific. For example, how many requests per second is it expected to receive? Or, which other serverless functions call it (and therefore which will it necessarily have the scale of). Or, what increase in usage would be expected for this change.

Re: Show HN: Infracost (YC W21): Be proactive with your cloud costs

#16

Post by vasco »

keepamovin wrote: post #3

I love it! But as human processes go, it will need to surmount the "flaky tests" problem of, "let's just turn off this test because it's flaky and we need to merge this branch". I guess that means FinOps teams will still have to fight to be heard, but I think you are helping shift a lot of their burden! What remains seems more like organizational dynamics, but what are your thoughts?

For anyone following at home, once you've identified a test as flaky, your next action should be to turn it off. Nothing good comes from keeping flaky tests around. Detect them as soon as you can and either fix them _right there_ or skip them.

I've used this in practice in a company of ~80 developers at the time, applied it because read about it in some Dropbox papers, and have since seen it work in 2 other companies. Skip your flaky tests!!

Re: Show HN: Infracost (YC W21): Be proactive with your cloud costs

#17

Post by beaviskhan »

danpalmer wrote: post #15
beaviskhan wrote: post #6

I have used this tool in the past, though free tier only. It was easy to get up and running and easy to plug into a CICD pipeline. The problem we had with it in practice was that we largely preferred serverless technologies in AWS where the cost depended mostly or even completely on actual usage - things like Lambda invocations, SQS operations, or autoscaling ECS services, for example. In this case the estimates we g…

I've not used the product, so it may already do this, but does it ask you for the data it needs in the Pull Request? I have experience interacting with a logging system, where any diff to the logged data would need a tag like `log_size_increase=3 bytes` – the CICD system would then turn this, with the data already available, into an estimate of the overall extra storage needed. Perhaps the same could be done. Rather…

It's been a while since I used this tool, but as best I can recall there was a way to provide usage estimates to feed the variable cost calculations. The biggest problem we had was getting development teams to know and care enough to provide accurate numbers. The suggestion in the post below to provide 30 days historical data as a starting point could be a great way to have a meaningful baseline. If someone had better projections, they could provide them, but at least it wouldn't be a total crapshoot.

Re: Show HN: Infracost (YC W21): Be proactive with your cloud costs

#19

Post by akh »

vasco wrote: post #16
keepamovin wrote: post #3

I love it! But as human processes go, it will need to surmount the "flaky tests" problem of, "let's just turn off this test because it's flaky and we need to merge this branch". I guess that means FinOps teams will still have to fight to be heard, but I think you are helping shift a lot of their burden! What remains seems more like organizational dynamics, but what are your thoughts?

For anyone following at home, once you've identified a test as flaky, your next action should be to turn it off. Nothing good comes from keeping flaky tests around. Detect them as soon as you can and either fix them _right there_ or skip them. I've used this in practice in a company of ~80 developers at the time, applied it because read about it in some Dropbox papers, and have since seen it work in 2 other companies…

I suppose the difference between flaky tests and typos in tags/missing tags is that the latter is less about flaky-ness, and more about the engineer deciding not to fix the tagging issue and merging anyway. In Terraform, tags are fairly easy to fix and don't require the resource to be recreated so it feels like it should be a quicker fix then fixing/refactoring tests.

I think the easier we make it for engineers to fix tagging issues, the more likely it'll be for engineers to take action. Send me an email asking me to read the company's wiki page on tagging policy and I'll delete the email; tell me I have a typo on line 8 as soon as I open my pull request, I'll fix it and move on.

Post reply on HN