Live data from Hacker News

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

news.ycombinator.com

31–38 of 38 posts

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

#31
post #30

Hi, Azure admin here. The Azure Policy service includes a set of built-in policies to handle tags. There's one policy that requires new resource groups to be created with specific tags. Another policy allows resources within the resource group to inherit the same tags. I think this combination of policies would solve the tagging problem quite neatly, though I haven't tested it myself.

Hi, I think the key issue with both the Azure policy, and the Amazon services is that they only work after a pull request has been merged. Then the build fails, and the engineer has to come back to their code, make a new Pull Request and then send it again, till it passes.

That's the feedback we got from users, so with Infracost, the Pull Request itself tells the engineer what needs to be done, along with exact code line numbers etc before going any further, so everything is fixed within the same pull request. Also, it works across all cloud providers, so FinOps can set central tags in a uniform manner no matter where the engineers are launching resources.

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

#32

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…

> but in practice this is a big loser in AWS where a staggering number of resources are created by one API call and then tagged as a followup API call

We have a bot at work that sends you (or a DL with a bunch of people) a nastygram if you forget to tag your resources, but it doesn't know this. So if CloudFormation isn't done, you'll get the email and then have to respond to everyone with a screenshot showing that you didn't in fact goof it up. I wonder if you can make it so EventBridge (or however it's implemented, I'm not sure) delay an event for 30 seconds so they don't actually look until CF is done tagging.

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

#34
post #24

I love how we just build complexity upon complexity. A tool for all the problems that this new tool gave that was solving all these other tools. A never ending mountain of complexity. In that sense coding (and hosting) is like the law. The entire ecosystem will just keep expanding in complexity decade by decade

Counterpoint to this is the rate at which you can grab some new infra and try something out is amazing. You need a Redis cache? Or a GPU? Here have one in a few seconds, instead if next month or never.

It is a bit like complaining about making tractor engines more efficient when you didn’t have those problems using animals and ploughs.

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

#35
post #24

I love how we just build complexity upon complexity. A tool for all the problems that this new tool gave that was solving all these other tools. A never ending mountain of complexity. In that sense coding (and hosting) is like the law. The entire ecosystem will just keep expanding in complexity decade by decade

Counterpoint to this is the rate at which you can grab some new infra and try something out is amazing. You need a Redis cache? Or a GPU? Here have one in a few seconds, instead if next month or never. It is a bit like complaining about making tractor engines more efficient when you didn’t have those problems using animals and ploughs.

You are describing corporate red tape for your organization. Those things were already possible before the cloud hype of last 5-8 years.

Anyway the point is also not that cloud didn't solve any issues but that by solving 1 issue, you get 5 new issues, and you solve one of those and you get again 5 new ones. And the loop keeps going endlessly.

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

#36
post #21

Earlier quoted context omitted.

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?

We started out with the Infracost CLI showing engineers cost estimates in the terminal before they deployed their code. The learning was that it also makes sense to check for other things like tagging policy issues and best practices not being followed as these things are more actionable than showing engineers a cost estimate. The cost estimate is actually more useful to trigger notifications on, e.g. if an engineer…

Cool! BTW do you know a great dashboard where I can compare VPS costs across all providers?

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

#37

Cloud costs to easily balloon out of control and I bet this is helping companies save money but this FinOps stuff also seems like something straight out an HBO's Silicon Valley skit.

hahaha love it - it'll keep evolving, and get more interesting for sure. I just think back to Dev and Ops, and how it went from a culture to a job title; testing was another one.

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

#38
post #24

I love how we just build complexity upon complexity. A tool for all the problems that this new tool gave that was solving all these other tools. A never ending mountain of complexity. In that sense coding (and hosting) is like the law. The entire ecosystem will just keep expanding in complexity decade by decade

Counterpoint to this is the rate at which you can grab some new infra and try something out is amazing. You need a Redis cache? Or a GPU? Here have one in a few seconds, instead if next month or never. It is a bit like complaining about making tractor engines more efficient when you didn’t have those problems using animals and ploughs.

> You need a Redis cache? Or a GPU?

But how often are these things truly *necessary"? I think they seem more necessary than they really are because they are so readily available.

Post reply on HN