Live data from Hacker News

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

news.ycombinator.com

21–30 of 56 posts

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

#21

How does your product differentiate from Yotascale?

Yotascale is in many ways similar to Vantage, so a similar answer to this one (https://news.ycombinator.com/item?id=39178753#39181486) applies.

When we were originally researching to see if anyone had done something like Dashdive already (i.e., specifically applying observability tools / high volume event ingestion to cloud costs), I did manage to find a Yotascale video in which they mentioned defining custom usage events in Kubernetes for a specific customer. It seemed more like a custom feature than a generally available part of their product, but I could be mistaken.

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

#24
post #18

How does this compare to Ternary?

Ternary is similar to Vantage in its offering so this answer (https://news.ycombinator.com/item?id=39178753#39181486) also applies here.

There are quite a few cloud cost tools out there which use AWS's cost and usage reports (or GCP/Azure equivalents) as their sources of truth, and as a consequence their data is largely based on tagging cloud resources with attributes of interest (e.g. EC2 instance XXX has tags customerId:ABC, teamId:DEF, featureId:GHI). These include Ternary, Vantage, Yotascale, and others (CloudChipr, CloudZero, Archera, Cloudthread, Finout, Spot by NetApp, DoiT, Tailwarden, CAST AI, Densify, GorillaStack, Economize Cloud). Some of these offer AI-based automatic tagging as well.

But even so, if I - for example - have a lots of k8s replica Pods which serve most of my application traffic, I can't use any of these products to figure out which customers, API endpoints, code paths, features, etc. are costing me the most. At best I could tag the entire Deployment, or maybe even each Pod. But the problem is that every Pod is serving lots of endpoints, customers, and features. However, Dashdive can give you this info.

From a technical implementation standpoint, Dashdive is much closer to application performance monitoring (APM) products or usage based billing products than it is to most cloud cost dashboard products.

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

#25

how are you ingesting from kinesis to clickhouse. are you using some custome sink connector or processes on ec2 or lambda?

We actually use Kafka rather than Kinesis, although they're very similar. For writing to ClickHouse from Kafka, we use the ClickHouse Kafka sink connector: https://github.com/ClickHouse/clickhouse-kafka-connect.

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

#26

Many engineering teams unquestionably find this challenging. Just a quick question, does it solely track usage, or can it also aid in cutting down costs?

You can use the usage and cost data Dashdive collects to identify cost spikes or ongoing inefficiencies (e.g. this particular feature is using more vCPU than should be necessary). But we won't do any automatic cost cutting for you (some products allow you to buy reserved instances or rightsize from directly within their app).

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

#28
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…

What you are saying might be problematic. This is a naive approach towards saving cost in the cloud. Companies who would pay big bucks for a platform like this, I would imagine they would optimize cost by managing commitments on Reserved Instance over 1 year/3 year or sometimes monthly via platforms like some non-aws platforms. Net-saving is much higher than just turning off/on instances.

Managing cost without impacting any infrastructure is the right way to do it in my opinion.

Post reply on HN