Awesome to see so much engagement on this topic from the HN community (I work on community at Coherence with Robert, who wrote this piece). Thanks, y’all! To f

Awesome to see so much engagement on this topic from the HN community (I work on community at Coherence with Robert, who wrote this piece). Thanks, y’all! To first address the idea that preview environments are trivial to build or are already solved, generally we think that’s not true except in a “rsync=dropbox” kind of way. On top of what we’ve already built at Coherence, which represents a considerable investment of resources (especially when compared to what’s available to software teams <30 heads), there’s still so much more to do before we are even close to 10x better than what teams do today with PaaS or Infra-as-code. Staging and other static pre-prod still has a place in the SDLC, the rise of previews doesn’t mean that these have no place. If your app has static integrations with 3rd parties, special data that needs to be manually managed, or integration with other workflows/teams/customers that require manual integration - staging/pre-prod has a huge place. In our case, Coherence supports static environments just as easily and fully as it supports previews (as do many other devops automation tools). To the point above about tons of work left to do, one of the biggest pieces is helping with data generation/automation for new environments. Integration with data anonymoization tools to make moving data from prod possible, data generation/seeding tools that can introspect a schema and generate realistic data, and a library of snapshotted datasets from other envs are all things that some teams do, but which should be available to everyone. Features like load testing and security scanning for ephemeral environments are adjacent areas of opportunity. There is absolutely no question that sprawling microservices make automating previews more complex, as do bigger teams. And the concerns around cloud cost are 100% valid. On cost, Coherence automatically does things like use spot instances and pause inactive environments. In practice, cost is not the primary issue with usability. Complex serverless systems often have the most trouble with dependencies across 100’s of functions and cloud-provided resources, and to us that only means that these kinds of systems will benefit the most as preview automation scales to encompass them (it still doesn’t do a good enough job today). That said, for a lot of real-world teams, there are cheap productivity benefits on the table if they’d invest in better developer experience. Alongside reproducible cloud-hosted dev envs, automated pipelines, and ephemeral environments, feature flags and canary releases are also relevant best practices for release management. Coherence doesn’t really help with either of those at this point, but great tools exist for lots of language/framework ecosystems already. We’re still a new product/company and we love hearing from users - feel free to ping hn@withcoherence.com with any questions/comments!