DRUIDS: Datadog Reusable User Interface Design System
druids.datadoghq.com
druids.datadoghq.com
even npm package[2] asks for login
NPM is full of every other company's internal component library they open source/release publicly. Datadog would have been nothing special.
* Sales Force - Lightning
* Atlassian - AtlasKit
* Microsoft - Fluent UI
* Uber - BaseWeb
* SAP - UI5 Web Components for React
* Palanti - Blueprint
* AWS - Cloudscape
This is some of the best documentation I have ever seen, and a very elegant design, too.
WOW.
I am working on documentation for my own product right now, and this is inspiring.
https://carbondesignsystem.com/
Obv for non-DS docs, Stripe's docs are gold medalists.
Of course, they do give you the source, so that’s nice.
But for some reason, I can't even look at the page. It's giving me a headache, just a few seconds of looking at it makes me feel... very off. Almost feel like I'm staring at an optical illusion. Super weird.
It makes their front-end engineers and designers happy and acts as a recruiting tool: Look at what we're building for internal use and our culture of open source contributions.
> Surely it just puts a burden on the maintainers because they can no longer just send a quick email or Slack message to the relevant channel saying "we're going to break backwards compatibility for widget X, make sure you update".
It sometimes does, if they bother to support public issues vs. it being available but mostly only supporting internal use cases.
1. Low risk. Not likely to create competitors or give away the secret sauce.
2. Allows partners to build lookalikes/similar look and feel apps.
3. Enables vendors/partners to contribute in a meaningful way that helps both parties.
For Datadog I think it makes sense.
Same reason people build new libraries or languages. They feel limited by the "thing" they're using. :)
Looking at process cpu use and there's no time scale...
Some visualizations you can cross filter on, some you can't. Some only hide things in that specific visualization.
It's also very slow.
It also doesn't work at all on mobile.
Not sure why anyone would be jumping to use this.
Imagine a forest dwelling witch (in very basic terms).
just terrible.
imo they should drastically simplify their billing dimensions so a simple human can understand it. for a certain size of company it just makes no sense to need to be engaged with a sales teams.
We approached them to see if they would work with us on reducing the massive bill that resulted. They agreed to cut it by 50% if we signed up for additional services. I'm not talking about a future volume discount; we were working with them for a good faith credit once we discovered the mismatch with their billing model (we had already filtered out those instance types)
Objectively, we owed the money. However, every other vendor I've run into works with small companies like ours without resorting to those kinds of tactics, so it's a pretty terrible look for them.
Too much friction in their sales process. But I guess I am not the target audience.
This is one of the reasons why I steer away from anything that requires a demo. If an org can't present even a read-only interactive version of the product, then it likely means that there is a KPI/OKR-heavy pitch intended for management or non-engineering business stakeholders to hear (of which the upselling you alluded to is a part).
The majority of the (F)OSS alternatives out there can be demo'ed with little-to-no engineering lift from prospective users. This is meaningful for the adoption story because it creates bottom-up pressure to internally pitch to relevant stakeholders— a much more powerful tool than external pitches. The fact that Datadog seems either unwilling or incapable of doing this historically, while touting one of the more expensive products in that particular vertical, suggests that the product value-add may not speak for itself (at least to a significant subset of engineers).
But there are some caveats. Facets can break in unexpected ways and the last time you want to be dealing with this is when you're dealing with a fire in production.
We also had some collector troubles and support basically did nothing but wasted our time in calls repeatedly
DIY only make sense at a very small scale or very large scale, everything in between is usually best offloaded to those which do it as their core competency.
It seems like very small scale has the highest leverage of utility-priced services (and often fits into free tiers of many).
More broadly I’ve never used managed service that would “just work” and wouldn’t require substantial configuration and often times bunch of workarounds but maybe those exist
Yes, in theory, in the middle scale, you should outsource things, but in practice, it only works if the managed service is at the right price.
From https://druid.apache.org/ :
> Druid unlocks new types of queries and workflows for clickstream, APM, supply chain, network telemetry, digital marketing, risk/fraud, and many other types of data. Druid is purpose built for rapid, ad-hoc queries on both real-time and historical data.
Custom, perhaps?
As much as I love the product, I'll have to reconsider my usage of Datadog in future projects.
For example early on in AWS Lambda’s life, DataDog was hosting a session at reInvent that looked like a semi-advanced dive into the new technology. Awesome! I was legitimately excited and thought this might be one of the better sessions of the conference. I show up only to find it is 30 minutes of stand up comedy, 10 minutes of the most basic “how to create a lambda function” tutorial (probably ripped right from Jeff Barr’s blog), and 15 minutes of “you should buy DataDog”.
To this day, we use “DataDog” as in team meetings as a term to communicate shadiness etc.
(Edited to fix typo on Barr’s name)
If you ask them about it, they'll “happily” put you onto hourly on-demand billing (which seems to fix the unique vs. count thing, too), which is more expensive if you let something run on-demand for a whole month... but isn't the point of an on-demand service that you're not running it for a whole billing period?
Also, their agent logs fairly noisily, and of course its logs count toward your quota! I upgraded a cluster without also upgrading the agent, and didn't notice for about a week that each agent was happily spamming away about some long-deprecated Kubernetes API no longer being available[0]. At $2.55/million log lines and fewer than a million lines logged, this was not a costly mistake, but it's the principle of the thing. Why should an incompatibility in their agent (which their dashboard could specifically alert about, but doesn't!) cost me money?
[0] https://github.com/DataDog/helm-charts/issues/620#issuecomme...
I don't think I've ever explicitly given these phone numbers to tools like this (e.g. signing up to Datadog with a phone number), so this seems like sensitive PII that must have been leaked and scraped in some shady source that these sales "data-enrichment" tools happily take.
Optionally have your work provide you a work phone and only give that out for work activities.
This is one of the better ones I've seen: https://github.com/yaelwrites/Big-Ass-Data-Broker-Opt-Out-Li...
From a purely B2B perspective, the most egregious offender IMHO is Zoominfo largely because of the wide adoption in sales orgs. You can opt-out here: https://www.zoominfo.com/privacy-center/update/remove
I don't know who they are or what they do. I asked my coworkers - they didn't know either.
"Everybody knows about x" where x is any proper noun in the software space is frequently a bad bet. The software world is exceedingly large, and people are familiar with chunks of it.
I want to second this - today is the second time I heard of them. The first was a job offer on LinkedIn that also failed to describe what Datadog did. It did talk a lot about how it was enterprise scale and important, though.
I declined to look further into it.
You asked your coworkers! That demonstrates an interest, why wouldn't you ask Google?
And one of the better known vendors in monitoring services.