When almost all the money is going to the software and setup, it sure shouldn't cost less to do it yourself. It takes money to make a robust solution, plus healthy profit, but that money is spread across every customer.

Renting equipment is an entirely different issue, but I get the impression that the equipment cost is a pretty negligible percent of the number being discussed.

> It takes money to make a robust solution, plus healthy profit, but that money is spread across every customer.

The requirements of supporting the more demanding customers typically are amortized across all customers. Requirements re: security, SLA (uptime, data durability, etc.), data governance for example. It is difficult to both implement and market products that break these dimensions into tiers. You can sometimes do it for the very niche, tail of your customers (air gap regions, for example), but in a lot of products, everyone is sharing in these costs even if they only care about a subset of the capabilities.

The cost savings of scale are offset by the costs of say, needing to support Fortune 100s that need 99.99% availability even if Bob's Wordpress Page doesn't care too much about 99% vs 99.99%. You can apply that analogy to every dimension.

A homegrown solution targets specifically what your company actually cares about. It makes sense that it may be cheaper.

But again. YOU are intelligent, you are informed, you can look and see that Datadog provides a bunch of capabilities you don't need and you're paying for things you don't get benefit from and make the trade-off of building your own. Just stop telling me about it.

Making an argument that there's something abnormal about market competition and that's why prices stay high is different -- I'd read that.

If their amortized support cost is an appreciable fraction of the 83k, I feel like something has gone wrong.

And if someone is demanding 99.99% SLA, that cost should not be passed on to customers that only want the normal 99.8% with no refunds.

> provides a bunch of capabilities you don't need and you're paying for things you don't get benefit from

Capabilities such as?

It sounds like you're making a generic defense that could be applied to companies that justify their costs and to companies that don't.

> it sure shouldn't cost less to do it yourself.

This is an interesting point and something I often wonder about. I think there's a number of different reasons for it, obviously markup and the need to make a profit, but one thing I realized is that when you buy something like AWS, you're often paying for the platinum version, with redundant power, networking, etc, and not the bronze version, which a lot of people would settle for. If I setup my one single instance Grafana VM or physical server, it's going to be a lot less expensive than a solution that's both multiple layers of "platinum" and multiple layers of "markup"

Datadog probably runs on the cloud, which means you get the cloud markup and datadog's mark up both built in.

> I realized is that when you buy something like AWS, you're often paying for the platinum version, with redundant power, networking, etc, and not the bronze version, which a lot of people would settle for.

This is the difference in most cases.

Just taking availability as an example. Datadog has a 99.8% availability SLA. I suspect most companies would be fine paying for a 99% availability SLA, for example, at 1/4th the cost, but in most cases there's no way to scale down SLAs like that and launch a cheaper version.

There is a giant leap in cost (complexity, staffing, etc.) between 99% and 99.9% that most of these home grown solutions don't account for.

These nuances are lost in posts like these, and it is tiring.

99% is down three days a year, and 99.8% can still go down for 17 hours each year.

Neither of those is particularly hard to reach. The cost increase to go from one to the other is not a big percentage.

What do you even get if the SLA is breached? Looking it up I see it excludes planned maintenance, and "in the event the Service availability drops below 99.8% for two consecutive months, Customer may terminate the Service". That's useless.

Then you take the title and the average dev salary, and think about your best case scenario (only setting up the open source tools, onboarding your devs), your mid case failures (need to reboot, out of storage) and your worst case scenarios (hardware fails, lost storage, the high speed link goes down)

And you realize you're getting a deal

The worst case scenario is the most convincing one there, but the worst case scenario with a purchased service is often the same as DIY.

> it sure shouldn't cost less to do it yourself

The companies produce generic solutions. Because software is complex, and their customers exist in many domains with different needs and whatever.

When you can make a really focused solution, it becomes cheap.

Look at the C++ STL. How much am I using? Not much in comparison to the whole thing. I could write an implementation of std::vector in an afternoon and use it in my apps. But std::vector is like 10,000 lines long and almost impossible to read. Because it's a generic solution, like the rest of the STL.

DD provides solutions with adapters upon adapters. Using this language? Use this SDK. How about this one? Then this other SDK. Have these types of data points? Use this. Need this graph? Use this. And on and on.

But most customers are only gonna use a little bit. Okay, we'll use the ruby SDK to collect metrics. What about the other 30 SDKs because this is a generic solution? I dunno. But you're paying for them.

But this isn't a company with a small amount of customers. If you have a hundred adapters, and a thousand customers, your development costs per customer should be lower than DIY could reach.

Especially because you really know what you're doing by the time you write that tenth adapter, so each one is higher quality and much faster to make.

In the analogy, yes you could write a vector implementation in an afternoon. But if 50 other devs do the same thing, and then we add on all the debugging time, it starts to look like they're putting in more work than the big generic centralized version took.

> If you have a hundred adapters, and a thousand customers, your development costs per customer should be lower than DIY could reach

Hmm I don't think so because I think software complexity isn't linear. Meaning going from 1 unit of complexity to 2 is probably much, much easier than going from 99 to 100.

A bunch of adapters in parallel shouldn't add many units of complexity.

Depends because sharing logic like that can be dangerous. Each system is going to have exceptions and unique properties, and SOME will leak into the shared space. This is a hard problem. If what you were saying were true, software would be perfect. It's not though, it sucks ass.

I mean, try writing an API for 100 different consumers with different needs. Good luck! They're gonna ask you for X ... Z and B depends on F but F can't exist with C and C is just a bad idea overall but also O is there and that changes things and...