7 ms·
Launch HN: Dashdive (YC W23) – Track your cloud costs precisely
Hi, HN. We (Adam, Micah and Ben) are excited to show you Dashdive (https://www.dashdive.com/ https://www.dashdive.com/), which calculates the cloud cost incurred by each user action taken in your product. There’s a demo video at https://www.dashdive.com/#video https://www.dashdive.com/#video and an interactive demo here: https://demo.dashdive.com https://demo.dashdive.com.
We talked to dozens of software engineers and kept hearing about three problems caused by poor cloud cost observability:
(1) Cost anomalies are slow to detect and hard to diagnose. For example, a computer vision company noticed their AWS costs spiking one month. Costs accrued until they identified the culprit: one of their customers had put up a life-size cutout of John Wayne, and they were running non-stop facial recognition on it.
(2) No cost accountability in big orgs. For example, a public tech company’s top priority last year was to increase gross margin. But they had no way to identify the highest cost managers/products or measure improvement despite tagging efforts.
(3) Uncertain and variable per-customer gross margins. For example, a SaaS startup had one customer generating >50% of its revenue. That customer’s usage of certain features had recently 1,000x’ed, and they weren’t sure the contract was still profitable.
(If you’ve had an experience like this, we’d love to hear about it in the comments.)
We built Dashdive because none of the existing cloud cost dashboard products solves all three of these problems, which often requires sub-resource cost attribution.
Existing tools combine AWS, GCP, Datadog, Snowflake, etc. cost data in a single dashboard with additional features like alerting and cost cutting recommendations. This is sufficient in many cases, but it falls short when a company (a) wants per-customer, per-team or per-feature cost visibility and (b) has a multitenant architecture.
By contrast, Dashdive uses observability tools to collect granular cloud usage data at the level of individual user actions (e.g. each API call or database transaction). We attribute this activity to the corresponding feature, the responsible customer and team and estimate its cost based on the applicable rate. The result is more detailed cost and usage data than can be obtained with tagging. This information can be used to detect anomalies in real-time and identify costly teams, features and customers. One of our customers is even using Dashdive to charge customers for their cloud usage.
We use Kafka to ingest large volumes (>100m/day) of product usage events, and our web dashboard supports real-time querying thanks to ClickHouse. This makes it fast and easy to answer questions like: “Over the past 14 days, how much vCPU time did customer X use on Kubernetes cluster A, and how much did that cost me?” You can answer such questions even when the same container or pod is shared by multiple customers, features and/or teams.
You can test drive the product with example data here: https://demo.dashdive.com/ https://demo.dashdive.com/. Given the high per-customer cost of our infrastructure and the manual steps required for setup on our part, we don’t offer self-serve onboarding or a public “free tier” to monitor your own cloud usage, but this demo gives a basic view of our product.
Right now, Dashdive supports S3 and S3-compatible object storage providers. We’re working to add support for other providers and services, particularly compute services (EC2, GCP VMs, ECS, EKS, GKE, etc.).
If there’s any service in particular you want to see supported, please tell us in the comments. We’re eager to see your comments, questions, concerns, etc.
- dev-docsai 3y agoVery cool and awesome stuff! Keeping track of cloud sprawl/spend can get super stressful, esp if you are mutli-cloud! Excited to see what you all continue to ship!!
- deleted 3y ago[deleted]
- ericb 3y agoVery 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 want, so I changed that language, but jedberg's objections in the comments below were, and are, valid concerns with what I was stating and any implementation.
- jedberg 3y agoThat would be a security nightmare. You don't want to give such powerful credentials to anyone, much less a 3rd party. But a good stopgap would be a feature to spit out an API command that someone could run (or a CloudFormation or TF file) where you can put your own credentials in and run it yourself.
- beachy 3y agoIf you could only turn things off then perhaps that is less than a nightmare in some settings.
- jedberg 3y agoThe only way it would be effective is if that credential had broad abilities to destroy, and I wouldn't want such a credential to get stolen. It would be bad enough for your most trusted operator to have it honestly. The best way to do it would be to run the delete with no access, see what permission errors you get, and then only give those permissions until you've successfully deleted the object. The safest way (but obviously more work) to do one off work like this is start permissionless and slowly open up. There are tools that can help with this, extracting the permission errors and generating the files to update the permissions.