4 ms·

There's this cycle of posts that are _When other people do things for you, it's expensive_ Look at these outrageous AWS prices. Look at these outrageous Datado

by ctvo 2y ago

There's this cycle of posts that are _When other people do things for you, it's expensive_ Look at these outrageous AWS prices. Look at these outrageous Datadog prices. Look at these outrageous Snowflake prices... And then of course, they lead to _Look how much cheaper my homegrown solution is_ It's a little tiring. You make trade-offs all the time. If the price isn't worth it, don't pay for it.

Dylan16807 2y ago
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.
- techostritch 2y ago
  > 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.
  - ctvo 2y ago
    > 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.
    - Dylan16807 2y ago
      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.
- smileysteve 2y ago
  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
  - Dylan16807 2y ago
    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.
- ctvo 2y ago
  > 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.
  - Dylan16807 2y ago
    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.
- consteval 2y ago
  > 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.
  - Dylan16807 2y ago
    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.
    - consteval 2y ago
      > 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.
      - Dylan16807 2y ago
        A bunch of adapters in parallel shouldn't add many units of complexity.

by ctvo 2y ago

Dylan16807 2y ago

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.

techostritch 2y ago
> 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.
- ctvo 2y ago
  > 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.
  - Dylan16807 2y ago
    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.
smileysteve 2y ago
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
- Dylan16807 2y ago
  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.
ctvo 2y ago
> 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.
- Dylan16807 2y ago
  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.
consteval 2y ago
> 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.
- Dylan16807 2y ago
  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.
  - consteval 2y ago
    > 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.
    - Dylan16807 2y ago
      A bunch of adapters in parallel shouldn't add many units of complexity.