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

Launch HN: Dashdive (YC W23) – Track your cloud costs precisely

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 56 posts

Re: Launch HN: Dashdive (YC W23) – Track your cloud costs precisely

#11

Post by scapecast »

ericb wrote: post #3

Very cool! Feature request: I have really struggled with turning the thing costing me money off in AWS. If, with the right master credentials, I could consistently and easily do that somehow, that'd be a 10x feature. If you made that use-case free, you'd get tons of installations from people who desperately need this in the top of your sales funnel. edit: This used to say "in your app" and that wasn't quite what I wa…

We solved that exact problem with our open source tool Resoto. Specifically our "Defrag" module, which cleans up unused and expired resources:

https://resoto.com/defrag https://github.com/someengineering/resoto

The magic behind the clean up is Resoto's inventory graph - the graph captures the clean up steps for each individual AWS resource.

One of Resoto's users, D2iQ (now part of Nutanix), reduced their monthly cloud bill by ~78%, decreased from $561K to $122K per month. There's a step-by-step tutorial on our blog how they did it.

I don't mean to hijack Dashdive's thunder here though, congrats on the launch!

Re: Launch HN: Dashdive (YC W23) – Track your cloud costs precisely

#12

Post by ashug »

ericb wrote: post #3

Very cool! Feature request: I have really struggled with turning the thing costing me money off in AWS. If, with the right master credentials, I could consistently and easily do that somehow, that'd be a 10x feature. If you made that use-case free, you'd get tons of installations from people who desperately need this in the top of your sales funnel. edit: This used to say "in your app" and that wasn't quite what I wa…

This is an interesting point, and we could definitely consider something like this. Where exactly do you run into problems?

For example, let's say you've figured out that a particular EC2 instance or database is too costly. What is the sticking point for you in turning it off? Is it that the resource has other essential functions unrelated to the cost spike? Or is it the identification of the exact resource that's the problem?

Re: Launch HN: Dashdive (YC W23) – Track your cloud costs precisely

#15

Post by kapilvt »

ericb wrote: post #3

Very cool! Feature request: I have really struggled with turning the thing costing me money off in AWS. If, with the right master credentials, I could consistently and easily do that somehow, that'd be a 10x feature. If you made that use-case free, you'd get tons of installations from people who desperately need this in the top of your sales funnel. edit: This used to say "in your app" and that wasn't quite what I wa…

The CNCF project, Cloud Custodian fits these sorts of use cases pretty well, and supports periodic or event based triggers. https://cloudcustodian.io/docs/aws/examples/

Re: Launch HN: Dashdive (YC W23) – Track your cloud costs precisely

#16

Post by ashug »

neom wrote: post #14

I've been using vantage.sh - how are you thinking about differentiation there?

The key differentiation from Vantage and other similar products is the level of granularity.

Vantage is in the category mentioned above: it combines AWS, GCP, Datadog, Snowflake, etc. cost data in a single dashboard and supports tagging. For example, if I have a single tenant architecture where every customer has their own Postgres RDS instance, I can tag each RDS node with `customerId:XXX`. Then I can get cost broken down by customer ID in Vantage.

However, if my entire app (including every customer) uses the same large RDS instance, or if I'm using a DBaaS like Supabase, tools like Vantage, which rely on tagging at the resource level, cannot show a breakdown of usage or cost per customer. By contrast, we record each query to your monolith or "serverless" DB (SELECT/INSERT/UPDATE) along with the vCPU and memory consumed, tag the query with `customerId` and other relevant attributes, and calculate the cost incurred based on the billing rules of RDS or Supabase.

Re: Launch HN: Dashdive (YC W23) – Track your cloud costs precisely

#19

Post by ericb »

ashug wrote: post #12
ericb wrote: post #3

Very cool! Feature request: I have really struggled with turning the thing costing me money off in AWS. If, with the right master credentials, I could consistently and easily do that somehow, that'd be a 10x feature. If you made that use-case free, you'd get tons of installations from people who desperately need this in the top of your sales funnel. edit: This used to say "in your app" and that wasn't quite what I wa…

This is an interesting point, and we could definitely consider something like this. Where exactly do you run into problems? For example, let's say you've figured out that a particular EC2 instance or database is too costly. What is the sticking point for you in turning it off? Is it that the resource has other essential functions unrelated to the cost spike? Or is it the identification of the exact resource that's th…

When we evolved to SSO and subaccounts with various roles/access, there were resources running/used by different accounts. I would see the instance in the costs. But then, I'd try and find that instance, started by another dev, and get access to shut if off. And even though I'm the main account owner--which to me, means I should be able to nuke whatever, since I pay the bills, I always had trouble getting to it, and getting the permissions for what I wanted.

I used Vantage, which helped me see the problem, but then taking action on it was traumatic.

The barriers are:

- who owns it?

- what service is it in (if it is logs, for example)?

- where is the screen it is on?

- how do I get the permissions to kill it?

Re: Launch HN: Dashdive (YC W23) – Track your cloud costs precisely

#20

Post by ashug »

ericb wrote: post #19
ashug wrote: post #12

Earlier quoted context omitted.

This is an interesting point, and we could definitely consider something like this. Where exactly do you run into problems? For example, let's say you've figured out that a particular EC2 instance or database is too costly. What is the sticking point for you in turning it off? Is it that the resource has other essential functions unrelated to the cost spike? Or is it the identification of the exact resource that's th…

When we evolved to SSO and subaccounts with various roles/access, there were resources running/used by different accounts. I would see the instance in the costs. But then, I'd try and find that instance, started by another dev, and get access to shut if off. And even though I'm the main account owner--which to me, means I should be able to nuke whatever, since I pay the bills, I always had trouble getting to it, and…

Makes a lot of sense - in my opinion AWS doesn't do the best job with this. We had a similar problem with EKS where even as the root user I couldn't view cluster details (https://medium.com/@elliotgraebert/comparing-the-top-eight-m....).

I agree that this would be a great feature. To be honest, our product isn't currently focused on this sort of automatic management of resource lifecycle; we're much better at data collection. But thank you for flagging this! We'll definitely keep it in mind as we add support for compute services (right now we only support S3 and there's nothing to "spin down").

Edit: The part less related to permissions (how can I kill it) and more related to discoverability (which resource is it) is more adjacent to what we've already built and is something we can take a look at soon. Perhaps we can take a crack at the permissions aspect afterwards.

Post reply on HN