Comment by ffggffggj | Hacker News Reader

Comment by ffggffggj | Hacker News Reader

This is not a great technical article. I don’t find it makes me curious. It’s entirely content marketing, zero technical content, clearly aimed at people who manage engineers but aren’t engineers. Doesn’t discuss drawback (doesn’t really define anything with enough clarity for there to be drawbacks anyway) and ends with a sales pitch.

The obvious problem here is that this approach is far too expensive for any org that isn’t a tiny startup whose production system fits on a half dozen hosts. Consider a column store DB that’s configured in a multi region manner. Is every engineer bringing that up in their preview environment? If they aren’t, it isn’t faithful to a critical production performance constraint. If they are, the company is probably paying twice the cloud costs of their competitors at least, and they don’t get the capacity planning benefits of a fixed staging deployment.

Why would you configure your column database as multiregion in every environment? You can run 99% of your tests, iteration, validation, etc, against a single shard. And even the same instance if you don't need to make any schema changes. You don't need a faithful production performance match until you want to validate performance characteristics, which often comes long after you've validated other correctness criteria that doesn't need prod-scale infra.

So once you've validated everything, you maybe stand up the prod-scale stack for less than an hour to run your at-scale tests, then tear it down again. Definitely not doubling your cost because you're not keeping anything around, and you're only using it when needed. Most places in my experience actually don't do this, and instead have a copy stood up somewhere just wasting money as you've described.

One reason is that transaction performance could be very different, even regardless to data volume.

Your points are all correct of course, but then that wouldn’t be a preview environment, would it? It would be shared database state in a database staging environment.

Which, for what it’s worth, is also how I have seen this problem managed when it came up.

As for costs, maybe true, but it could also take a lot longer than an hour to bring up a large deployment. And if every engineer is doing this for one hour a week, and you have a few dozen engineers, there’s a 2x cost increase with a tougher capacity planning problem since your load is now tied to your hiring plans.

Reply on news.ycombinator.com